[Insight-developers] Inverse transforms

Mon, 03 Nov 2003 10:08:07 -0500

I tend to support methods with names like "SetTransformMovingToFixed", 
or "SetTransformResampledToOriginal". That tends to reduce ambiguity. 
I would be reluctant to change the terms "moving" and "fixed", since 
that best seems to match what actually happens.

Miller, James V (Research) wrote:

> How much of the decision of the inverse mapping is driven by the
> the simplicity of metrics in the inverse mapping case?
> 
> Your metric is now:
> 
> Sum{over all p in the fixed image region} ( F(p) - M(T(p)) )^2
> 
> If the transform is changed to go from moving to fixed, the operand 
> of the metric is not that different
> 
> 	(F(Tm2f(q)) - M(q))^2
> 
> however, you need iterate over an non-rectangular region to compute the
> metric. This sounds difficult and slow.  
> 
> It sounds like this is an engineering decision to make the registration
> metrics pratical.  If so, then we just need to be very clear in the
> documentation as to that the output transformation does. 
> 
> We should also provide a resample filter that will resample a moving image
> to the fixed image coordinate system for display of the final results and
> for transfering information from the moving image to the fixed image
> coordinate frame.  For simple transforms, this will call the
> ResampleImageFilter passing in the inverse of the registration transform.
> For more complicated transforms, it will have to an incremental search to
> establish the inverse mapping.
> 
> Jim
> 
> 
> -----Original Message-----
> From: Lydia Ng [mailto:lng at insightful . com]
> Sent: Monday, November 03, 2003 1:20 AM
> To: Stephen R. Aylward; Insight-developers (E-mail)
> Subject: RE: [Insight-developers] Inverse transforms
> 
> 
> 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