[Insight-developers] Inverse transforms

[Lydia Ng]

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).=20

So maybe the best option is to qualify the name of the transform.
FixedToMovingTransform?

Cheers,
Lydia=20


> -----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
>=20
> Hi Lydia, Luis, Jim, and Julien,
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> **** Lydia and Luis and Jim and Julien - if you agree, I'll send out a
> call for votes on what to call these functions...
>=20
> Thanks,
> Stephen
>=20
> Lydia Ng wrote:
>=20
> > 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
> >>
> >>--
> =
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>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
> >
> >