[Insight-users] itkFixedCenterOfRotationAffineTransform

[Blezek, Daniel J (Research)]

Simon,

  There are many inconsistencies among the Transforms.  After the dust settles on 2.2, I propose to have a close look at these classes.  One thing that has bugged me is having to have special optimizers for Versor and Quaternion transforms.  We might change the SetParameters call to normalize the Versor/Quaternion or add a AddDelta that would do the job.  Then our Optimizers would be more general.

  The other thing we've kicked around is how to set scales in a more general way.  One possibility is to have each Transform provide a SuggestScales function that would take some clues as to the expected Translation, but it may be difficult to do this with any flexibility, i.e. some Transforms care about scales and shears, but others don't.  Another thought was to provide a set of helper classes that provide rules-of-thumb.  For instance, I may like to set scales one way, and I could write and contribute a class that does this for some Transforms.  Luis may do it a different way and could contribute another method.

  And of course it would be nice to make the transforms' parameter ordering a bit more consistent, but that will likely break all sort of existing code.  Including ours!

-dan

-----Original Message-----
From: insight-users-bounces+blezek=crd.ge.com at itk.org
[mailto:insight-users-bounces+blezek=crd.ge.com at itk.org]On Behalf Of
Simon Warfield
Sent: Thursday, September 08, 2005 10:12 AM
To: insight-users at itk.org
Subject: Re: [Insight-users] itkFixedCenterOfRotationAffineTransform


Marius Staring wrote:

> Hi,
>
> we noticed that the FixedCenterOfRotationAffineTransform has dimension 
> * (dimension + 2), which equals 15 in 3D, but it should be 12, so 
> dimension * (dimension + 1). Nothing is done with the last 3 
> parameters, as it should be because 
> FixedCenterOfRotationAffineTransform has a FixedCenterOfRotation.
>
> Are these thoughts correct and is this a bug, or am i missing something?
>
> Regards,
>
I noticed some other inconsistencies in the transform parameterizations.
The registration examples illustrate the need to using scaling in the 
optimization, especially to balance translation against other parameters.
The AffineTransform and QuaternionRigidBody transform have translation 
parameters as the last of the parameters.
The Similarity3DTransform has:
http://www.itk.org/Doxygen/html/classitk_1_1Similarity3DTransform.html#z1527_1
``There are 7 parameters. The first three represent the versor, the next 
three represent the translation and the last one represents the scaling 
factor.''

I don't see an easy way to plug different transforms into a generic 
class that sets the scales for the optimizer. It seems that special 
arrangements would need to be made for each different transform being 
used, to work out which parameter indexes correspond to translations, 
and to set them specially.

-- 
Simon 

_______________________________________________
Insight-users mailing list
Insight-users at itk.org
http://www.itk.org/mailman/listinfo/insight-users