[Insight-developers] Inverse transforms

Luis Ibanez luis . ibanez at kitware . com
Mon, 03 Nov 2003 14:12:59 -0500 

I'm ok with changing the Get/Set Transform methods of the Registration
classes to Get/Set FixedToMovingTransform.  For the case of the Resample
image filter this will be a bit artificial since this filter is not
restricted to be used in the context of the registration framework.
There is no mention to what Fixed/Moving means in the context of pure
resampling. This may not be a big deal as long as we define/explain
those terms in the documentation of the renamed Set/Get transform
methods of the ResampleImageFilter.

I think that the real confusion is not arising from the ImageToImage
registration methods but from ModelToModel and ModelToImage methods.
When registering a SpatialObject to an Image, the transform should map
the coordinates of points in the spatial object into the coordinate
frame of the image. Such transform (not the inverse) will be the one
to use directly for resampling the image into the reference system of
the spatial object (using the current resample image filter). The same
transform is the one that should be used by a visualization module in
order to display the spatial object overlaped in the context of the
image.

When initializing a registration using landmarks, it is a matter of
convention to define in what direction the transform will be computed.
It looks like we have simply choosen a convention that is contrary to
what we use for image to image registration.


To summarize:

- I'm ok with changing the Set/Get method names,

- I think we should look closer at the definitions we use
   for model based registration.



    Luis


---------------------------
Stephen R. Aylward wrote:
> Works for me.
> 
> This change would be made to Get and Set Transform methods of 
> itkImageRegistrationMethod, itkResampleImageFilter, 
> itkImageToSpatialObjectRegistrationMethod, 
> itkMultiResolutionImageRegistrationMethod, 
> Code/Algorithms/*Registration* (basically).
> 
> On the tcon should we dicuss timing - issues regarding timing for this 
> are also the issues regarding the ImageIO flipY change Bill is suggesting.
> 
> What other "major" changes are lurking?  Perhaps we should list them now 
> and at the tcon.   The issues with SpatialObjects and 
> lists/vectors/line/curve might need changes in naming as well.
> 
> Stephen
> 
> 
> Lydia Ng wrote:
> 
>> Hi All,
>>
>>
>>> **** Lydia and Luis and Jim and Julien - if you agree, I'll send out a
>>> call for votes on what to call these functions...
>>
>>
>>
>> Here is my other 2 cents worth:
>>
>> I would be reluctant to change/swap "fixed" and "moving", because we are
>> actually the changing/moving the "moving" image. Hence, the term "fixed
>> image" and "moving image" are accurate descriptions.
>>
>> The point of confusion is that we are using an "inverse mapping". I
>> think there is a general agreement that "inverse mapping" is important
>> (for reasampling and more computation for the metric).
>> So maybe the best option is to qualify the name of the transform.
>> FixedToMovingTransform?
>>
>> Cheers,
>> Lydia
>>
>>
>>> -----Original Message-----
>>> From: Stephen R. Aylward [mailto:aylward at unc . edu]
>>> Sent: Monday, November 03, 2003 6:08 AM
>>> To: Lydia Ng
>>> Cc: Insight-developers (E-mail); Luis Ibanez; Julien Jomier; Miller,
>>
>>
>> James
>>
>>> V (Research)
>>> Subject: Re: [Insight-developers] Inverse transforms
>>>
>>> Hi Lydia, Luis, Jim, and Julien,
>>>
>>> I think it is something we can easily handle, but perhaps we need to
>>> document and warn for now (in the code and software guide) and change
>>> member function names for the 2.0 release.
>>>
>>> What I would expect giving a moving image and a fixed image is for the
>>> transform to move the moving image into the space of the fixed image.
>>> For the spatialObject registration stuff, we need to go from the
>>
>>
>> object
>>
>>> to the fixed image since the object is generally quite sparse.
>>> Similarly, I TOTALLY agree that resampling is an issue since an
>>
>>
>> inverse
>>
>>> cannot always be applied and holes result otherwise.
>>>
>>> I think the simplest fix is to rename Fixed and Moving to Source and
>>> Destination or maybe swap Fixed and Moving or something like that.   A
>>> one time shot with a script, and we can provide the script to the
>>
>>
>> world.
>>
>>>  Again, this would probably be for 2.0.
>>>
>>> It is a concern to me that the people in the caddlab are just now
>>> realizing this, and we've been doing registration using ITK for quite
>>> some time.   We are having to regenerate results for upcoming
>>> publications.   We just didn't realize the transforms were from the
>>> fixed to the moving since those words have such strong connotations.
>>>
>>> So, in summary, I totally agree with the design and the implementation
>>> in ITK.  It is what has to be done, and it is really excellent!    I
>>> just think we need a name change.
>>>
>>> **** Lydia and Luis and Jim and Julien - if you agree, I'll send out a
>>> call for votes on what to call these functions...
>>>
>>> Thanks,
>>> Stephen
>>>
>>> Lydia Ng wrote:
>>>
>>>
>>>> Hi Stephen,
>>>>
>>>> I agree with you it would be nice to address the inconsistencies.
>>>>
>>>> "Inverse mapping" is important in resampling because it avoids the
>>>> problem of overlap and holes. At each iteration of image-to-image
>>>> registration you are implicitly computing the resampled image (with
>>>
>>
>> the
>>
>>>> current parameters) - so wouldn't the same issues of overlap occur
>>>
>>
>> here
>>
>>>> as well?
>>>>
>>>> Just to clarify, currently with the "inverse mapping" scenario, the
>>>> equation for the mean squares metric looks something like this:
>>>> Sum{over all p in the fixed image region} ( F(p) - M(T(p)) )^2
>>>>
>>>> So for each p, we compute mapped position T(p) using the transform
>>>
>>
>> and
>>
>>>> then interpolate the moving image value at T(p).
>>>>
>>>> What would be the equivalent equation and computation steps with
>>>> "forward mapping"?
>>>>
>>>> The second issue is what happens when the transform is not
>>>
>>
>> invertible?
>>
>>>> For example, BSplineDeformableTransform is useful for representing a
>>>> warp but there is no inverse. In this case, we can't easily
>>>
>>
>> flip-flop
>>
>>>> from inverse to forward mapping or vice versa.
>>>>
>>>> - Lydia
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Stephen R. Aylward [mailto:aylward at unc . edu]
>>>>> Sent: Friday, October 31, 2003 11:42 AM
>>>>> To: Insight-developers (E-mail)
>>>>> Subject: [Insight-developers] Inverse transforms
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> 1) ITK registration actually returns a transform from the fixed
>>>>
>>
>> image
>>
>>>> to
>>>>
>>>>
>>>>> the moving image
>>>>> 2) ITK resample image filter expects a transform from the fixed
>>>>
>>
>> image
>>
>>>> to
>>>>
>>>>
>>>>> the moving image
>>>>> 3) No model-to-image registration process is easily implemented
>>>>
>>
>> using
>>
>>>> a
>>>>
>>>>
>>>>> fixed-to-moving image transform - the model drives where in the
>>>>
>>
>> fixed
>>
>>>>> image the fit should be calculated.   So, all
>>>>
>>
>> spatial-object-to-image
>>
>>>>> transforms, the landmark-landmark registration stuff we are doing,
>>>>
>>
>> and
>>
>>>>> the ICP method we are implementing apply the transform to the moving
>>>>> model/points to quantify their match with the fixed image/points.
>>>>> Therefore we have to pass the Inverse transform to the resample
>>>>
>>
>> image
>>
>>>>> filter for them.
>>>>>
>>>>> We have the landmark initialized MI registration app that must
>>>>>
>>>>> 1) register using landmarks
>>>>> 2) resample the image using the inverse of that transform
>>>>> 3) invert the transform to initialize the MI registration process
>>>>> 4) resmaple the image using the non-inverse of that transform
>>>>>
>>>>> This is really inconsistent.   Can be documented by saying most
>>>>> image-image transforms are fixed to moving transforms and all
>>>>
>>
>> spatial
>>
>>>>> object transforms are moving to fixed.   I say most image-image
>>>>> transforms since we are writing one that internally calculates
>>>>
>>>>
>>>> features
>>>>
>>>>
>>>>> and landmarks from the moving image to drive the registration with
>>>>
>>
>> the
>>
>>>>> fixed image.
>>>>>
>>>>> I consider this a huge flaw with no easy answer - I understand why
>>>>
>>
>> the
>>
>>>>> resampling is driven by the fixed image.   However, couldn't the
>>>>> resampling take the inverse and all of the rest be done in the
>>>>
>>
>> correct
>>
>>>>> way: tranaform maps moving to fixed?
>>>>>
>>>>> Stephen
>>>>>
>>>>> -- 
>>>>> ===========================================================
>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
> 
>