[ITK-dev] [ITK] Optimizing composite transforms and center of transform

Tue Jul 29 19:55:16 EDT 2014

Sorry, Brad, but I’m having a hard time following what
the problem is exactly.  I agree with you that getting a
good initialization, i.e., centering the objects of interest
to be registered is important.  And that is something 
we do in ANTs by employing the centered transform
initializer or aligning origins by converting the result to
a translation transform.  That translation transform is then
pushed onto the composite transform queue.  

If that is followed up by other transforms to be optimized,
such as rigid or affine, the moving image is already "centered"
in the virtual domain within the similarity metric classes and 
optimization in terms of translation to center the objects is (or 
at least, should be) minimal.

Does that help?

Nick

On Jul 29, 2014, at 4:16 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:

> Hello,
> 
> Ok, to further explore this problem, and hopeful help other people too: I created an IPython Notebook viewable here:
> http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/blob/master/Transform%20Composition%20And%20Order.ipynb
> 
> It doesn't come through on the static page, but I added some nifty interactive slider widgets to change the rotation parameter. Which is really the point  to enable understanding of the parameters for the transform and how they should be best optimized. The notebook should work with SimpleITK >= 0.8 and IPython Notebooks 2.1. I'll encourage every one to try it out :) IPython Notebooks widget are very cool!
> 
> EXPLANATION:
> 
> The the order of the composite transform is that the new transforms are applied first.
> 
> BUT they map from the virtual domain ( fixed ) to the moving image. Therefore if your first transform moves the center of mass to the origin then the second added transform's space will be centered on the mass, which is good for optimizing rotation and affine parameters.
> 
> QUESTION:
> 
> Therefore I am inclined to conclude that its best practices to map the fixed and moving image to the virtual domain such that the center of mass ( or some other "center feature" ) are at the origin. This would then the scale, rotation and other affine parameters around the center, with out having to used the "Center" parameter the transforms currently have.
> 
> Is this what others are doing in their registration? For general best practices should this be recommend?
> 
> @Brian I know I have seen this multi-domain description many time, but I think I may have just gotten it... Is the well describe in the literature some place? I think this may be an important part add the software guide.
> 
> Thanks,
> Brad
> 
> 
> 
> 
> On Jul 29, 2014, at 5:38 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
> 
>> Hi Brad,
>> 
>> Your assessment that the fixed center is important is correct.
>> 
>> In most cases, a transform with a Center is the first transform in a
>> Composite transform. There not any issues here.  However, if the
>> transform with a Center is further along the chain, then a
>> CenteredTransformInitializer that was applied before the registration
>> is started will not generate the desired result. In this case, we
>> would have to respond to an Event in the registration process and
>> estimated the center on the imaged after the other transforms have
>> been applied. It is more work, but it is a more unusual case.
>> 
>> HTH,
>> Matt
>> 
>> 
>> 
>> On Mon, Jul 28, 2014 at 10:11 PM, Bradley Lowekamp
>> <blowekamp at mail.nih.gov> wrote:
>>> 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 <ntustison at gmail.com> 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 <blowekamp at mail.nih.gov> 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
>>> _______________________________________________
>>> Community mailing list
>>> Community at itk.org
>>> http://public.kitware.com/mailman/listinfo/community
> 