[Insight-users] Versor3DRegistration and the masks of meanSquareMetric

[Luis Ibanez]

Hi Martin,

You are right, the existence of the "Centered" transforms is confusing.

They are there for historical reasons.

Initially, ITK transform did not considered the center of rotation
at all. That is, they all rotated (and scaled) around the origin of
coordinates.  Experiences with image registration revealed that this
was not appropriate since most images have their origin in one of its
corners, and rarely the rotation required is centered there. Most
anatomical images require rotation around the geometrical center of the
image.

In order to correct for this deficiency, we added the "Centered"
transforms, but did it in such a way that the center of rotation itself
was also subject to the corrections performed by the optimizer.

The Centered transforms were very successful, and we decided that all
transform should indeed be "Centered" by default, but that the center
coordinate shouldn't be part of the parameters to be optimized.

On this logic, the transform were refactored and so you find that today
the plain "Affine" transform has the option of setting the Centered of
coordinates.

At that point, we were trapped in the dilemma of backward compatibility,
versus "doing the right thing".  The right thing to do is to deprecate
the Centered transforms and remove them from the Toolkit. However, since
users already had code that used them, we need a certain period of
duality, when both the new and old transforms are available, and we let
users know that the Centered transforms are going to disappear from
future releases, and that they can use the plain transforms because they
now offer the option for setting the Center of rotation.


So...

To summarize:  Please don't use the CenteredEuler3DTransform anymore,
                use the Euler3DTransform instead.



   Regards,



     Luis



-----------------------
Martin Urschler wrote:
>> I may be wrong here, but is there any reason to optimize both the 
>> center and the translation ...
>>
>> For the VersorRigid3DTransform which may be re-written as
>>
>> p' = R(p-C) + C + T = Rp +  C(I-R) + T
>>
>> If you were to optimize just R and T and specify a default center, you 
>> should still be able to arrive at an equivalent translation that 
>> rotates about any other center, if the optimizer does a good job.
> 
> 
> I see your argument and basically agree with it. But thinking about that 
> I ask myself why there exist Euler3DTransform and 
> CenteredEuler3DTransform separately. The latter one explicitly take the 
> center of rotation as optimization parameters as well, right? Since 
> AffineTransforms (or some of the others for which Centered versions 
> exist) are derived from MatrixOffsetBaseTransform (defining the same 
> basic behaviour VersorRigid3DTransform is showing), what are the 
> Centered versions good for in addition? Or am I mixing up something here?
> 
> regards,
> Martin
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
> 
>