[Insight-users] Rigid3DTransform error Attempting to set a non-orthogonal rotation matrix

Matthias Keil matthias.keil at igd.fraunhofer.de
Fri Feb 13 04:57:42 EST 2009


Hi Luis, and all other list members,

sorry for making my point a bit unclear. By saying:
> I am using the following parameter values for Rigid3DTransform:
> - first 9 rotation parameters are set to 0.1
> - the three translation parameters are set to 0.001
>
> And the simplex delta parameter values for the optimizer:
> - first 9 values set to 5
> - the last 3 values set to 0 (as there is no translation) 
I did not mean that I am constructing a rotation matrix in the format 
you proposed:
> When you set the first 9 parameters of the transform to 0.1
> you are construction a rotation Matrix:
>
>        0.1  0.1  0.1
>        0.1  0.1  0.1
>        0.1  0.1  0.1 
What I was actually trying to say is that I am initializing the 
optimizer scales of the Rigid3DTransform in the way I mentioned above. I 
am using the Amoeba optimizer to create the actual rotation matrix in 
all iterations. E.g. the rotation matrix computed by Amoeba that is to 
be applied in the first iteration and which fails the orthogonality test is:

1.0   0.0                    0.0
0.0   0.996194_72026824951_    0.0871557_36982822418_
0.0  -0.0871557_22081661224_   0.996194_72026824951_

This is supposed to be a -5 degree rotation about the x-axis (the first 
step of the Amoeba optimizer). The corresponding rotation matrix should 
actually look like this (I highlighted the differences in the matrix 
elements calculated by Amoeba and by hand):

1.0   0.0                    0.0
0.0   0.996194_69809174555_    0.0871557_42747658180_
0.0  -0.0871557_42747658180_   0.996194_69809174555_

Please do note especially the difference between the sin(alpha) at 
column 3 row 2 and -sin(alpha) at row 3 column 2 in the rotation matrix 
computed by Amoeba.
This difference is one reason why the matrix resulting from multiplying 
the rotation matrix with its transposed matrix looks like this:

1.0   0.0                       0.0
0.0   1.0000000431793548        1.4844458107177161e-008
0.0   1.4844458107177161e-008   1.0000000405819116

Comparing this matrix to the identity matrix causes the orthogonality 
test to fail.

The question is now:
Why do I get a non-orthogonal rotation matrix from the Amoeba optimizer?
> If you don't now how to initialize a rotation matrix, then
> you should at least use the Transform Initializer class
Thanks for the hint, I will have a look at it. Although I am not setting 
the transformation by hand but using the Amoeba optimizer instead, as 
mentioned above.
> Another potential way of producing a consistent
> rotation matrix is to use an itkVersor, set its axis
> and rotation angle, and then extracts its Matrix.
This would also be a possibility but I think that my scenario using the 
Amoeba optimzer should also work, right?

Best regards,
Matthias
Luis Ibanez schrieb:
>
> Hi Mathias,
>
> A rigid transform necessarily requires an Orthogonal matrix.
>
>
> If you try to force a non-othogonal matrix into the transform,
> then the transformation will contain Scaling and Shearing
> effect, which is something that a Rigid Transform shouldn't
> include.
>
> The Rigid Transform class is correctly rejecting your Matrix
> as an inappropriate input.
>
>
> When you set the first 9 parameters of the transform to 0.1
> you are construction a rotation Matrix:
>
>        0.1  0.1  0.1
>        0.1  0.1  0.1
>        0.1  0.1  0.1
>
> that is obviously non-orthogonal, and therefore
> it can not be a valid representation of a rotation
> in 3D space.
>
>
> If you don't now how to initialize a rotation matrix, then
> you should at least use the Transform Initializer class, as
> it is illustrated in the examples:
>
>
>    Insight/Examples/Registration/
>                      ImageRegistration12.cxx
>                      ImageRegistration13.cxx
>                      ImageRegistration14.cxx
>                      ImageRegistration6.cxx
>                      ImageRegistration6o.cxx
>                      ImageRegistration7.cxx
>                      ImageRegistration7o.cxx
>                      ImageRegistration8.cxx
>                      ImageRegistration9.cxx
>                      MultiResImageRegistration2.cxx
>
>
>
> Another potential way of producing a consistent
> rotation matrix is to use an itkVersor, set its axis
> and rotation angle, and then extracts its Matrix.
>
>
>
>     Regards,
>
>
>
>        Luis
>
>
> ---------------------
> Matthias Keil wrote:
>> Hello,
>>
>> with regards to this e-mail to the mailing list which unfortunately 
>> did not get any feedback:
>>
>> http://www.nabble.com/funning-observation-regarding-SetMatrix%28%29-in-VersorRigid3DTransform-class--tp20409801p20409801.html 
>>
>>
>> I am writing to the mailing list hoping to get some more insight into 
>> the problem.
>>
>> Using Rigid3DTransform and the Amoeba optimizer for registration of 2 
>> volumes (one was manually rotated by 5 degrees around the x axis) 
>> seems to be quite challenging to me. Unfortunately I can't initialize 
>> my registration in a way which makes it compute any iterations. I do 
>> get the error "Attempting to set a non-orthogonal rotation matrix" 
>> mentioned in the subject everytime. As pinpress guessed right, there 
>> is a test for the identity matrix.
>>
>>> My guess is that in ITK library somewhere, there is a check (e.g., 
>>> to check
>>> if determinant of the matrix is exactly 1, because it is a "rigid"
>>> transform), but the tolerance is not set properly which caused the 
>>> problem
>>> that I experience.
>>
>> This test is implemented in itkRigid3DTransform.txx line 77.
>>
>> I am using the following parameter values for Rigid3DTransform:
>> - first 9 rotation parameters are set to 0.1
>> - the three translation parameters are set to 0.001
>>
>> And the simplex delta parameter values for the optimizer:
>> - first 9 values set to 5
>> - the last 3 values set to 0 (as there is no translation)
>>
>> My question is now as pinpress already asked
>>
>>> However, is such checking necessary?
>>
>> Thanks in advance for any help,
>> Matthias
>>
>> -- 
>> | Dipl.-Ing. Matthias Keil
>> |
>> | Fraunhofer Institute for Computer Graphics (IGD)
>> | Cognitive Computing & Medical Imaging
>> | Fraunhoferstraße 5, 64283 Darmstadt, Germany
>> |
>> | phone  : +49 6151 155 212
>> | fax    : +49 6151 155 480
>> | mobile : +49 173 5709746
>> | e-mail : matthias.keil at igd.fraunhofer.de
>> | skype  : matthias.keil.office
>> | web    : http://www.igd.fraunhofer.de/~makeil
>>
>>
>> ------------------------------------------------------------------------
>>
>> _____________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ITK FAQ at: 
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-users

-- 
| Dipl.-Ing. Matthias Keil
|
| Fraunhofer Institute for Computer Graphics (IGD)
| Cognitive Computing & Medical Imaging
| Fraunhoferstraße 5, 64283 Darmstadt, Germany
|
| phone  : +49 6151 155 212
| fax    : +49 6151 155 480
| mobile : +49 173 5709746
| e-mail : matthias.keil at igd.fraunhofer.de
| skype  : matthias.keil.office
| web    : http://www.igd.fraunhofer.de/~makeil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090213/25507a27/attachment-0001.htm>


More information about the Insight-users mailing list