[Insight-users] itkFixedCenterOfRotationAffineTransform

[Stephen R. Aylward]

Hi,

Yes they would still need to be rescaled.   Scaling is application 
specific more than image-size specific.  For example, when mosaic-ing 
histology, there is often very little rotation, but we still need to 
allow for some rotation - translation is often very large.   For MR 
series from one study, it is often "more" rotation than translation 
(admittedly arguable and unspecific - but relative).   Such knowledge, 
implemented as scaling, speeds registration.

Stephen

Miller, James V (Research) wrote:
> With respect to the scales, we've also been wondering if a change in coordinate system would
> remove some of the necessity of the scales.  For instance, if the image is "rescaled" so that
> the domain of the image fits in [-1, 1] (center of the image moved to the origin, and the bounds
> of the image at +-1), would the transform parameters need to be rescaled at all?
> 
> Jim
> 
> 
> -----Original Message-----
> From: insight-users-bounces+millerjv=crd.ge.com at itk.org
> [mailto:insight-users-bounces+millerjv=crd.ge.com at itk.org]On Behalf Of
> Blezek, Daniel J (Research)
> Sent: Thursday, September 08, 2005 10:32 AM
> To: Simon Warfield; insight-users at itk.org
> Subject: RE: [Insight-users] itkFixedCenterOfRotationAffineTransform
> 
> 
> 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.
>