[Insight-developers] Centered Transforms

Sat Mar 12 22:36:05 EST 2005

I totally agree (with all but your rule of thumb :) - my thumb is 
different :) ).

Also, the scalings between angle/quaternion/versor/whatever and the 
translation will probably be different for each transform.  There isn't 
a good way to generalize scalings across transforms - so having them 
self report which parameters are related to translation, scaling or 
whatever is not useful.

Daniel - do you agree?

Stephen

Luis Ibanez wrote:
> 
> Yeap,
> unfortunate these scales are very application-specific.
> 
> In general the ratio between the rotation and translation scales
> depends on the physical size of the image to be registered.
> 
> 
> As a rule of thumb I tend to use :
> 
>   angles scales      = 1.0
>   translation scales = 1.0 / ( 10.0 * number of pixels * spacing )
> 
> 
> Note also that when doing multi-resolution, is is usually useful
> to have different scale ratios at each one of the resolution
> levels. For example, at the top level you usually want to focus
> on translations and discourage rotations.
> 
> At the end, the ratio of these scales should be associated to the
> "expected" registration values, e.g. how much rotation and how much
> translation do we anticipate.
> 
> 
> 
>      Luis
> 
> 
> 
> -------------------------------
> Stephen R. Aylward wrote:
> 
>> Cool idea...  I do all conversions between transforms via center, 
>> matrix, and offset - that is what led to the recent changes so that 
>> those terms were handled consistently.   Also added matrix to 
>> parameter converts for quaternion and other transforms.  Since center 
>> of rotation is not a parameter for most transforms, you must use 
>> center et al.
>>
>> The problem with incorporating scales in transforms is that scales are 
>> quite application specific.  The transorms can possibly report which 
>> params are translation, rotation, scale, or skew related....it is a 
>> bit unclear which categories should be used...we can keep thinking 
>> about this...
>>
>> Stephen
>> -----Original Message-----
>>
>> From:  "Blezek, Daniel J \(Research\)" <blezek at crd.ge.com>
>> Subj:  RE: [Insight-developers] Centered Transforms
>> Date:  Thu Mar 10, 2005 2:45 pm
>> Size:  4K
>> To:  "Stephen R. Aylward" <aylward at unc.edu>,   "Miller, James V 
>> \(Research\)" <millerjv at crd.ge.com>
>> cc:  "Insight-developers \(E-mail\)" <insight-developers at itk.org>
>>
>> Stephen,  I suppose by opening my mouth, I get some of the blame.  
>> Well here goes anyway.
>>
>> I've been looking at the transforms as well, and on think that could 
>> use some revamping is setting scales for optimizers.  It would be 
>> great if the transforms provided some runtime clue as to which 
>> parameters related to translation, so a framework to swap 
>> transformation types like what you describe (and I'd love to know how 
>> you do it) can generically set a translation scale factor for any 
>> transform.
>>
>> -dan
>>
>> -----Original Message-----
>> From: insight-developers-bounces at itk.org
>> [mailto:insight-developers-bounces at itk.org]On Behalf Of Stephen R.
>> Aylward
>> Sent: Monday, March 07, 2005 4:59 PM
>> To: Miller, James V (Research)
>> Cc: Insight-developers (E-mail)
>> Subject: Re: [Insight-developers] Centered Transforms
>>
>>
>> Hi,
>>
>> Yup - the terms center, offset, and translation aren't my favorite 
>> either (I didn't pick them, I am following the ITK standard)...it was 
>> decided quite some time ago to call "translation" the component of the 
>> transform that defines the shift to be applied after rotation about a 
>> center of rotation.   The offset vector defines the amount of shift to 
>> apply after a rotation when a center of rotation has not used.
>>
>> Center (of rotation) must be maintained since it is not specifically 
>> being optimized during registration.  That is, it must be stored since 
>> it isn't being passed.
>>
>> Furthermore, since center isn't being optimized, rotation can only 
>> decoupled from shifting during registration if the optimizers update 
>> translation instead of offset during registration.   So, translation 
>> is a parameter of the optimizer instead of offset.
>>
>> So, the optimizers drove the addition of the concepts of center of 
>> rotation and translation in the transforms.
>>
>> Having a center of rotation greatly simplifies certain registration 
>> optimizations compared to image alignment when rotation were limited 
>> to being about the origin.  ITK began years ago by having registration 
>> optimization temporarily move the origin of an image to the center of 
>> the image during registration, and then move the origin back after 
>> registration, but that really is a hack - the origin really shouldn't 
>> move during registration...so, we added the concept of a center of 
>> rotation...
>>
>> I hope this clarifies things a bit.   I don't like classes that have 
>> redundant/linked variables that must be kept in sync, but there is no 
>> way that Bill would let us remove the Get/SetOffset functions :)   
>> And, actually, I don't think we should either... :)
>>
>> So this is the rock and the hard place that we are between...   With 
>> that in mind...any ideas/suggestions?   I've been working with the 
>> transforms quite a bit - switching between them within a single 
>> application and composing them in chains while using center of 
>> rotation.    This has revealed some inconsistencies in how offset and 
>> translation are handled (not surprisingly) as well as inconsistencies 
>> in their APIs.    This lead to the development of the 
>> MatrixOffsetTransform base class that we are adding to make sure all 
>> of the affine, similarity, rigid, translation, and rotation transforms 
>> handle these concepts consistently.    I just want to make sure we all 
>> agree on which is the lessor of the evils :)
>>
>> Sorry for the long email...just looking for someone I can share the 
>> blame with when we ultimately pick a standard... :)   Anyone.... 
>> Anyone... :)
>>
>> Thanks,
>> Stephen
>>
>>
>> Miller, James V (Research) wrote:
>>
>>> I don't think I am going to be of much help since I do not understand 
>>> the difference between an "offset" and a "translation".
>>>
>>> Skimming through the headers, it looks like transforms like the 
>>> affine transform are defined by equations
>>>
>>> y = Ax + b
>>>
>>> where A is the "matrix" stored in the transform and "b" is the offset.
>>>
>>> To me, it looks like the only things that need to be STORED are the
>>> matrix and offset.  With the "center" and "translation" being 
>>> computations
>>> based on A and b.  Conversely, you could argue that one would want to
>>> set the center and translation. In doing so, the matrix A and offset b
>>> would have to be updated. However, I would favor not storing the 
>>> center and
>>> translation if there are truly secondary parameters completely 
>>> defined by
>>> A and b.
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: insight-developers-bounces at itk.org
>>> [mailto:insight-developers-bounces at itk.org]On Behalf Of Stephen R.
>>> Aylward
>>> Sent: Monday, March 07, 2005 1:15 PM
>>> To: Insight-developers (E-mail)
>>> Subject: [Insight-developers] Centered Transforms
>>>
>>>
>>>
>>> When someone updates the center of rotation or matrix for a 
>>> transform, either the translation or the offset must be implicitly 
>>> updated for consistency.   This implicit update is necessary since 
>>> translation and offset are related to one another via the transform 
>>> matrix and the
>>
>>
>> --- message truncated ---
>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>>
> 
> 
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers

-- 
===========================================================
Dr. Stephen R. Aylward
Associate Professor of Radiology
Adjunct Associate Professor of Computer Science and Surgery
http://caddlab.rad.unc.edu
aylward at unc.edu
(919) 966-9695