[Insight-users] Optimizing transforms

[Luis Ibanez]

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
> 
>