[Insight-users] itkFixedCenterOfRotationAffineTransform

[Luis Ibanez]

Just for the record,

the class

       itkFixedCenterOfRotationAffineTransform

is obsolete, now that the AffineTransform has been updated
to offer the option of setting the center of rotation, but
still not pass it to the set of parameters to be optimized.

This class would be deprecated in future versions of ITK.


Please us the class

             itkAffineTransform




   Regards,


       Luis



--------------------------
Stephen R. Aylward wrote:
> 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.
>>
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
> 
>