[Insight-developers] Inverse transforms
Mark Foskey
mark_foskey at unc . edu
Mon, 03 Nov 2003 15:52:22 -0500
Luis Ibanez wrote:
>
> 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.
This is why I suggested SetResampledToOriginalTransform (actually I had
SetTransformResampledToOriginal, but that kind of goes against the
ITK convention).
>
> 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
>>
>>
>>
>
>
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk . org
> http://www . itk . org/mailman/listinfo/insight-developers
--
Mark Foskey (919) 843-5436 Computer-Aided Diagnosis and Display Lab
mark_foskey at unc . edu Department of Radiology, CB 7515, UNC
http://www . cs . unc . edu/~foskey Chapel Hill, NC 27599-7515