[Insight-developers] Inverse transforms
Stephen R. Aylward
aylward at unc . edu
Mon, 03 Nov 2003 13:55:17 -0500
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
--
===========================================================
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