Hi,
I am performing fine registration of two meshes and I wish to know the final transformation in terms of the angles the 'DATA' mesh rotates about the X-Y-Z axes to align with the 'MODEL' mesh. I understand that the option to view the transformation matrix in terms of EULER angles allows me to visualize these angles I am talking about. To test this out, I was giving my mesh known rotations of 90 degrees to PHI, THETA and PSI respectively, keeping everything else as zero. I first gave the sample a rotation of PHI=90 degrees, keeping THETA, PSI and the translations as 0. The output of this transformation led to a rotation along Z-axis by 90 degrees, however visually I could also see that the sample had translated to a new position in space although in the output transformation matrix the value of my translations were all 0. Similar observations were seen in cases where I gave the mesh a rotation of THETA=90 and PSI=90, keeping everything else as zero. To further test out the system, I tried performing a fine registration of the rotated mesh with the original mesh (I did this without matching the centres)hoping that the matrix which I would obtain as a result of this registration would be an inverse of the transformation I had given the system while rotating it by 90 degrees. This holds true for rotations of PHI and PSI, however for the case where the rotation was given to THETA, the meshes just don't align (infact they seem to be mirror images of each other).
Later on when I also do a match bounding box centres operation on the two meshes (rotated and intact-I rotate the mesh again by the same amount and then match the centres) to check if what I am observing visually(that the rotated sample has translated) and what I view in the transformation matrix (no translations) are actually same; I see that the rotated sample has actually translated as it had rotated, but these translations were completely missing when I had done the fine registration without aligning the centres. Infact now after matching centres , when I again perform fine registration the samples just don't align.
I can't figure out the reason for such discrepancies. Please enlighten me. I tried looking at your source code for fine registration, but I could not find the piece where you compute the angles from the rotation matrices.
There is also a second part of my question, which is basically a continuation of whatever I have described above. Whenever I give my mesh a rotation of THETA greater than 90 degrees, it basically rotates the sample in such a way that the values of PHI and PSI become 180 degrees and THETA becomes (180-THETA), for eg. a rotation of PHI=0.THETA=135,PSI=0 is basically taken as a PHI=180, THETA=45,PSI=180, similarly PHI=0,THETA=210,PSI=0, is taken as PHI=180,THETA=-30,PSI=180. I suspect this 180 degree rotation of PHI and PSI are responsible for the samples not aligning and being mirror images when I perform the registration.
I was trying to attach some snapshots of what I have described so that it could be easy for you to understand, but I am not able to attach the files.
PLEASE HELP...
Confusion in interpreting Euler angles
Re: CONFUSION IN INTERPRETING EULER ANGLES
I believe that most of the issues you are referring come from the Euler angles themselves. We never use this way of representing a matrix internally as it has several drawbacks (gimbal lock, etc.). Moreover the Euler angles are not unique. You can always represent a given rotation matrix with various combinations of Euler angles (especially for very simple rotations such as the ones you are testing ;).
When trying to estimate a transformation in 3D, please stick to the more simple 'angle / axis / translation' form (I guess you are using the 'Apply Transformation' tool to make the conversion?). But of course even this way of representing a transformation is not unique! So you might not always 'see' what you expect... The best way to test if a registration worked well is still to clone the entity before anything, move the entity, register it and eventually compare it to the original clone.
And please mind that the ICP algorithm is a local optimization process. It only works properly if the two clouds are already roughly registered (i.e. quite close to each other). Otherwise it might converge to a local minimum. And a rotation of 90 degrees is already too big in the general case.
Another issue of your process might be that when you apply a simple rotation matrix to an object, it will implicitly rotate around the point (0,0,0) by default. If your object is not centered on (0,0,0) itself, then this operation will actually translate your object's center. And this may explain why the ICP algorithm compensates for this actual center shift.
And here is a last remark: pay attention that no other transformation has been applied to your entities (you can check that the 'Transformation history' matrix - in the cloud properties - is the same as the one applied by the ICP algorithm). By the way this is a good way to check how well the ICP algorithm worked (apply a transformation matrix, use the fine registration tool, and eventually check that the transformation history matrix is back to (almost) the identity.
P.S.: to add images, use the 'Attachments' tab below the message edition frame, and be sure that the images are not too big (i.e. width and height below 1000 pixels I believe).
When trying to estimate a transformation in 3D, please stick to the more simple 'angle / axis / translation' form (I guess you are using the 'Apply Transformation' tool to make the conversion?). But of course even this way of representing a transformation is not unique! So you might not always 'see' what you expect... The best way to test if a registration worked well is still to clone the entity before anything, move the entity, register it and eventually compare it to the original clone.
And please mind that the ICP algorithm is a local optimization process. It only works properly if the two clouds are already roughly registered (i.e. quite close to each other). Otherwise it might converge to a local minimum. And a rotation of 90 degrees is already too big in the general case.
Another issue of your process might be that when you apply a simple rotation matrix to an object, it will implicitly rotate around the point (0,0,0) by default. If your object is not centered on (0,0,0) itself, then this operation will actually translate your object's center. And this may explain why the ICP algorithm compensates for this actual center shift.
And here is a last remark: pay attention that no other transformation has been applied to your entities (you can check that the 'Transformation history' matrix - in the cloud properties - is the same as the one applied by the ICP algorithm). By the way this is a good way to check how well the ICP algorithm worked (apply a transformation matrix, use the fine registration tool, and eventually check that the transformation history matrix is back to (almost) the identity.
P.S.: to add images, use the 'Attachments' tab below the message edition frame, and be sure that the images are not too big (i.e. width and height below 1000 pixels I believe).
Daniel, CloudCompare admin