[Insight-users] Optimizing transforms

Tue Sep 5 07:49:18 EDT 2006

Dear Luis,

Thanks for this extensive explanation of the interrelation between 
transforms and optimizers. Indeed this should be pointed out more 
extensively in the software guide, especially with the registration 
examples: In iterativeClosestPoint2.cxx e.g., a Levenberg-Marquardt 
optimizer is used happily in conjunction with an Euler3DTransform. As 
many ITK users, I usually get orientation from the example code and thus 
was violating the basic optimization rules without knowing it, because 
the example made it look like a good practice...

Best regards,
Tobias

Luis Ibanez wrote:

>
> Hi Thomas,
>
> You are right, it is not trivial to find the optimizer that will match
> a particular combination of Transform and Metric. It will be good to
> add more documentation in that regard to the ITK Software Guide.
>
> For the particular scenario that you mention, there is a conflict
> between the use of the Levenberg-Marquardt optimizer (LMO) and the
> RigidTransform. The difficulty arises from the fact that the LMO
> assumes that the set of parameters to be optimized form a Vector
> space (e.g. that addition of two vectors of parameters produces
> a vector of parameters that belong to the same space, and that
> taking a vector of parameters and multiplying it by an scalar will
> also produce a vector of parameters that belongs to the vector space.)
>
> This is not the case for the Rigid3DTransform because the Versor
> (unit quaternion) parameters do not form a Vector Space. E.g. the
> addition of components of two Versors do not produce a valid Versor.
> Versor must be "composed" instead of "added".
>
> What you already experienced is that the LMO will navigate through
> the space of parameters on the assumption that additions are valid
> and therefore will deviate from the orthogonality requirement of
> the rotation matrix, to end up in the domain of a general Affine
> Transform.
>
> The right answer in this case would be to write a modified LMO
> that is aware of the fact that the three first values of the
> parameters array of a VersorRigidTransform are the components of
> a Versor, and that they do not follow the algebraic rules of Vectors.
>
> The LMO should be aware that when computing derivatives of
> the metric with respect to the parameters of the Versor, the operations
> are not those of subtraction but those of composition with inverses.
> Code could be copied for this purpose from the Versor Gradient Descent
> optimizer.
>
> If you write this new version of the LMO, this will make an very nice
> paper for the Insight Journal   :-)
>
> ---
>
> About your question regarding the derivation of the Similarity
> transform. Your are right. This is a bug in the implementation
> of the transforms and should be fixed.
>
> What happen with the Rigid2D case is that the parameterization
> of the Transform is rather direct: 1 angle, 2 translations.
> (Although you could argue that it could be also parameterized
> as two cosines and two translations...)
>
> The parameterization of a Rigid 3D transform offers many other
> possibilities: Versors, Euler angles,....
>
> The particular choice of deriving the Similarity Transform from
> the Versor transform was based on the fact that the Versor
> parameterization is the best option for representing rotations.
>
> You could argue that we must have provided variant of the similarity
> transform that derive each one from on of the variants of the rigid
> transform. That's a possibilitiy, but will probably be too confusing
> for users.
>
> You can indeed derive the Similarity transform from the Euler Rigid
> 3D Transform. I would discourage you from doing so, just because
> the Euler angles are a poor representation for rotations. However,
> they are widely used....
>
> Note that the Euler angles *do not* form a vector space, as you
> can easily verify by adding 90 degreed to each one  of their
> independent components and verifying that the operations are not
> commutative. Most of the time users "conveniently" ignore this
> fact and pass the angles as parameters to be optimized by
> gradient descent optimizers, that assume the parameter space
> to be a vector space. Thing may work reasonably well if the
> angular increments are small (e.g. 0.01 radians).
>
> Note also that the Scale in the Similarity transform *does not*
> form a vector space. Scales shouldn't be added and subtracted.
> Their operations should be done in a logarithmic space. That is,
> the log of scales do form a vector space. Optimizers that perform
> addition and subtraction on parameters that are supposed to
> represent scaling factors, are also violating the basic assumption
> of those scaling spaces.
>
>
>
> You are right that these additional restrictions prevent users
> from freely exchanging Transform, Metrics and Optimizers as
> it was intended in the design of the Registration Framework.
>
> Note however that the problem is not a *software* problem.
> Instead it is a *mathematical* problem. It is a disconnect
> between the assumptions of some optimizers and the realities
> of the Transforms.
>
>
> If you were using only Evolutionary Optimizers, these details
> of the Transforms will have never bother you, because these
> optimizers do not assume the parametric space to be a Vector
> space.
>
>
> One potential software solution, could be delegate to the
> Transforms the functionality of computing derivatives and the
> functionality of adding values to their parameters. In this way,
> each transform will implement the correct operation regardless of
> whether its parameters form a vector space or not.
>
> As you can imagine this will be a major refactoring of the
> Transforms and optimizers in ITK, but it is worth considering
> if it will simplify the usage of Transforms and Optimizers
> in a transparent way.
>
>
> ---
>
> It is difficult to present all these details in the Doxygen
> documentation, because it is written on a class by class basis.
>
> These trade-off would be better presented in the ITK Software Guide.
>
>
> Please let us know if you have other comments,
>
>
>
>    Thanks,
>
>
>       Luis
>
>
>
> -----------------------
> Thomas Boettger wrote:
>
>> Dear ITK-users,
>>
>> lately a colleague asked me about how to choose thje 'right' optimizer
>> for different transforms in ITK and I thought I knew the answer or at
>> least the software guide could help me.
>> But I soon figured out that it is not that simple. And there are at
>> least some important facts missing in the documentation, which I would
>> like to discuss. It would be interesting to get other users comments
>> on the problems I ran into.
>>
>> We want to solve the following scenario:
>>
>> I want to optimize a points metric using ICP and start with a
>> Rigid3DTransform and the Levenberg-Marquardt optimizer (just like in
>> the examples). The optimizer gets passed an array of 12 parameters and
>> is in fact optimizing the transform as if it were an affine one. I
>> tested it with the affine transform and the Rigid3DTransform. Results
>> were the same. I do not wonder, because how would the optimizer know
>> the difference between an affine matrix and a rigid matrix... You
>> cannot optimize Rigid3DTransforms? Where is my mistake? If this is
>> true, I think this fact should be mentioned somewhere in the
>> documentation.
>>
>> Optimization works with the Euler3DTransform. It does not work for the
>> VersorRigid3D transform as the VersorTransform needs the
>> VersorTransform optimizer which is a single valued one and does not
>> work with PointsetToPointset metrics...(I can write my own metric...I
>> know)
>>
>> Then I went from rigid transformations to similarity transforms.
>> Unfortunately I looked at Similarity2DTransform and played around with
>> it and it worked. Then I went to the 3D case and wanted to do the same
>> as I did with the rigid transform before. It did not work. After a
>> while I figured out that Similarity3DTransform is derived from the
>> VersorRigid3DTransform. Then I would have to use the VersorOptimizer(
>> single valued... pointset metric... write my own... ) What about the
>> LM-Optimizer? Why? Couldn't one derive a Similarity3DTransform class
>> from the Euler3DTransform? Everything would be easy.
>>
>> Or another question could be: Why is Similarity2D derived from Rigid2D
>> and Similarity3D from VersorRigid3D?
>>
>> It would be great if someone could explain to me the concept behind
>> all these design decisions.
>>
>> All those little things stop me from using different transforms in a
>> rather exchangable way in my optimization scheme, because a different
>> transform sometimes even implies different optimizers. And i finally
>> do not benefit from the generality of the registration framework
>> design. It only makes things complicated for me.
>>
>> Please let me know if I do something fundementally wrong.
>>
>>
>>  Best regards,
>>
>>    Thomas
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>>
>
>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>

-- 
Dipl.-Inform. Med. Tobias Heimann
Deutsches Krebsforschungszentrum         (German Cancer Research Center)
Div. Medical and Biological Informatics E130      Tel: (+49) 6221-423548
Im Neuenheimer Feld 280                           Fax: (+49) 6221-422345
D-69120 Heidelberg                              email: T.Heimann at dkfz.de
Germany                       http://www.dkfz.de/mbi/people/tobiash.html