[Insight-developers] Inverse transforms

[Stephen R. Aylward]

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
> 
>