[Insight-developers] Centered Transforms
Blezek, Daniel J (Research)
blezek at crd.ge.com
Mon Mar 14 08:50:20 EST 2005
Stephen, Luis,
I'm always gratified when a posting gets attention, usually means you are on to something interesting...
Agreeing that self-reporting is not necessarily helpful or useful, could we consider having each transform produce "suggested scales"? Of course we'd have to agree which thumb to use... For instance, I'd love to do this:
optimizer->SetScales ( transform->GetSuggestedScales ( ExpectedTranslation ) );
The transform would return a set of scales, based on the expected translation for the problem.
The main reason I'm asking is that we'd like to try many different metrics for a particular problem we have. Our transforms will start with rigid, go to affine, and then to some deformable transform (unspecified yet), and yet only specify one parameter, i.e. ExpectedTranslation. Doing this by hand for each transform is fine, and useful; could others benefit from my experiences? This begs the real question: is it possible to have the transform specify a useful set of scales that cover the general problem space. My scales tend to follow Luis' thumb, perhaps only because I've never seen Stephen's.
Thanks,
-dan
-----Original Message-----
From: Stephen R. Aylward [mailto:aylward at unc.edu]
Sent: Saturday, March 12, 2005 10:36 PM
To: Luis Ibanez
Cc: Insight-developers (E-mail); Miller, James V (Research); Blezek,
Daniel J (Research)
Subject: Re: [Insight-developers] Centered Transforms
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
More information about the Insight-developers
mailing list