Helloo Nick!

I am glad you got back to me.

I suspect that I have spent more time this past week looking at the ITK affine 
transforms than anyone else[1] this week. With that here is my current 
understanding...

1) The CenterTransformInitializers estimates an initial "Center" and an initial 
"Translation" parameter from either the geometry or the first moments. From my 
problematic experiences, getting the initial transform which is a "good" guess 
is been critical for the optimizer to head to the correct solution.

2) The Center parameter of a transform can either be "Fixed" or an optimizable 
parameter. The transforms with the "Centered" monkier are the the ones with the 
Center parameter optimizable. This issue seems to be what you were referring to 
in to message.

In many ways the point I am trying to make is independent of #2. I have 
observed that it's important to have the "Center" of an affine transform ( or 
sub parameterization thereof ) at the center of the object you are trying to 
register. That is the coordinate space of the optimizable parameters' point 0 
is near the center. This enables rotation to easily rotate around the center, 
as well as scaling to maintain the same relative center when "zooming". This 
issue is independent of wether that center point can be optimized.

For example, consider changing the origin of an image for alignment by say 500, 
and compensating with just an initial translation and not setting the "Center" 
parameter. If we are trying to optimize rotation and translation, then the 
optimization path would be very difficult to traverse with these 
inter-dependent parameters to force it to rotate around the center of the 
object. This scenario may be more common in microscopy then medical imaging, 
due to microscopy frequently having multiple subjects across large images. I 
could write up a IPython Notebook to illustrate the case.

So that is my understanding of why using a fixed center is important. I thought 
this may have been shared knowledge, but perhaps is not or is incorrect...

Now I am trying to understand how this interacts with all the coordinate frames 
involved with the ITKv4 registration framework, and the composite transforms. 
Specifically the composite transform apply the transforms in "reverse 
order"[2]. As I understand that that means that the newest transform get 
applied first. So that transform parameters are being optimized in the images 
space not in the virtual domains we are working towards. Therefore the center 
of our transforms is still important as we composite transforms?

I hope I explained that clearly, a white board may really be needed....

Thanks,
Brad


[1] 
https://github.com/SimpleITK/SimpleITK/compare/master...9bc9bc8440e64d94099d3519eb23bcc16c7cf015
[2] http://www.itk.org/Doxygen/html/classitk_1_1CompositeTransform.html

On Jul 28, 2014, at 8:57 PM, Nicholas Tustison <[email protected]> wrote:

> Hi Brad,
> 
> I apologize for the delayed response.  I’m still catching up on my 
> workload after moving to CA.  We might want to talk to Luis as it 
> was my understanding that the “center” component of the linear 
> transforms might be a carry-over from all the “Centered” transforms, 
> e.g., 
> 
> http://www.itk.org/Doxygen/html/classitk_1_1CenteredAffineTransform.html
> 
> which, if I remember correctly, Luis said were somewhat sub optimally 
> conceived but this was such a long time ago that I might be completely
> misremembering.  However, fixing the center for all transforms within 
> a composite transform is certainly not necessary within the specified
> framework.  Rather, the matrix and offset are updated with the “Center”
> being updated implicitly.
> 
> Nick
> 
> 
> 
> On Jul 24, 2014, at 7:27 AM, Bradley Lowekamp <[email protected]> wrote:
> 
>> Hello,
>> 
>> There are a lot of transforms involved in the new registration framework.
>> 
>> I am trying to figure out what the implications for the fix parameters of 
>> the transform "Center" ( ie center of rotation/scaling ) are when combined 
>> with composite transforms and the fixed/moving/registration coordinate 
>> frames...
>> 
>> Based on how the transforms are composed it seems necessary to set the  fix 
>> "Center" for subsequent transformations. Additionally, I am unsure how one 
>> would "improve" ( poorly defined? ) the center for a subsequent transform ie 
>> Affine after a similarity...
>> 
>> Are there some documented guidance or figures to help with this issue?
>> Do we have a comprehensive diagram of these transforms?
>> 
>> Thanks,
>> Brad
>> 
> 

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.php

Please keep messages on-topic and check the ITK FAQ at:
http://www.itk.org/Wiki/ITK_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/insight-developers

Reply via email to