[Insight-users] Rigid3DTransform error Attempting to set a non-orthogonal rotation matrix
Matthias Keil
matthias.keil at igd.fraunhofer.de
Fri Feb 13 13:26:26 EST 2009
Hi Karthik,
thanks for your answer! This made things a lot clearer to me.
It's no surprise to get non-orthogonal matrices from the Amoeba if it is
not designed to re-orthogonalize them, when working together with the
Rigid3DTransform.
I will definitely change to the Versor3DTransform and the corresponding
optimizer for my 6 DOF registration. I think that it is also easier to
understand the resulting transformation parameters. Given the fact that
Versor gives 3 radians and Rigid3D gives the 3x3 matrix for the rotation
information.
You are absolutely right that currently I am not considering scaling or
shearing.
I will try Versor on Monday then.
Thanks again,
Matthias
> Two points:
>
> 1. The Amoeba optimizer, (nor any other optimizer except the
> VersorRigid3DTransformOptimizer) does not re-orthogonalize the transform
> after every iteration. It simply wobbles using the Neadler mead simplex
> algorithm on an array of 12 parameters in your case. The scales help a bit
> here, if they are acute enough for instance 1:1000 etc.
>
> 2. Why not optimize fewer parameters when you can. (Hint: Use the Versor
> transform, with has 6 parameters). I would understand your argument for
> using 3x3 matrix, if were to have different scales for the shear
> components,
> or if you needed scaling etc... but your scales aren't different.
>
>
> On Fri, Feb 13, 2009 at 4:57 AM, Matthias Keil <
> matthias.keil at igd.fraunhofer.de> wrote:
>
>> 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<http://www.igd.fraunhofer.de/%7Emakeil>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _____________________________________
>> 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
>> <http://www.igd.fraunhofer.de/%7Emakeil>
>>
>>
>> _____________________________________
>> 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
>>
>>
>
>
> --
> Karthik Krishnan
> R&D Engineer,
> Kitware Inc.
> Ph: 518 371 3971 x119
> Fax: 518 371 3971
>
--
--
| 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
| e-mail : matthias.keil at igd.fraunhofer.de
| skype : matthias.keil.office
| web : http://www.igd.fhg.de/~makeil
More information about the Insight-users
mailing list