[Insight-developers] inverse transformations
Paul Koshevoy
koshevoy at sci.utah.edu
Mon Oct 10 19:04:31 EDT 2005
Hi,
I've put together a proposal in hopes of generating a little bit more
discussion on this issue:
http://www.itk.org/Wiki/Proposals:InverseTransform
Thank you,
Paul.
On Fri, 7 Oct 2005, Paul Koshevoy wrote:
> Date: Fri, 7 Oct 2005 10:33:44 -0600 (MDT)
> From: Paul Koshevoy <koshevoy at sci.utah.edu>
> To: <insight-developers at itk.org>
> Subject: Re: [Insight-developers] inverse transformations
>
> Greetings,
>
> Perhaps I wasn't clear enough in my original posting, I'll try to give
> you some background information here. I have written an automated image
> mosaicing application that requires some minor modification to the
> itk::Transform and several of the derived classes. I've been
> porting these changes from ITK 1.8.1 to 2.0.1 to 2.2.0 by hand.
>
> When porting to ITK 2.2.0 I've noticed a comment in the
> itkAffineTransform.h that the BackTransform API is deprecated. It seems
> there has been an effort underway to standardize the inverse
> transformation API which resulted in the GetInverse method.
>
> My original posting has pointed out two of my problems with the
> GetInverse method. You can compare my changes to itkTransform.h and
> itkAffineTransform.h against ITK 2.2.0, my version of those files is in
> the attachment.
>
> I would like to know what are the chances of my changes being merged into
> the main ITK tree.
>
> Thank you,
> Paul.
>
>
> On Thu, 29 Sep 2005, Paul Koshevoy wrote:
>
> > Date: Thu, 29 Sep 2005 18:08:13 -0600 (MDT)
> > From: Paul Koshevoy <koshevoy at sci.utah.edu>
> > To: insight-developers at itk.org
> > Subject: [Insight-developers] inverse transformations
> >
> > Hi,
> >
> > I am working on an automatic image mosaicing problem with
> > Ross Whitaker and Tolga Tasdizen.
> >
> > I am having some problems with the current implementation of the
> > inverse transformation -- the GetInverse method.
> >
> > First, GetInverse is not a virtual function. Therefore, the
> > transform type must be known in order for the right GetInverse
> > to be called, which means it must be specified as a template
> > parameter.
> >
> > Second, GetInverse is not meaningful for transforms where no general
> > inverse exists. For example, the inverse of a radial distortion
> > transform may require a different number of parameters than the
> > forward transform.
> >
> > For my application I need a general method for inverse transformation
> > of a point. The way I would go about this is by declaring
> >
> > virtual bool
> > GetInverse(itk::Transform<TScalarType,
> > NInputDimensions,
> > NOutputDimensions>::Pointer & inverse) const;
> >
> > The requirement that the inverse transform and the forward transform
> > must be of the same type is too restrictive. The transforms which do
> > not have a general analytic inverse should be able to return an
> > iterative numeric inverse wrapper class instead.
> >
> > An alternative solution is to provide BackTransformPoint,
> > BackTransformVector and BackTransformCovariantVector as virtual member
> > functions of the itk::Transform base class. These (currently deprecated)
> > methods are already provided by a number of transforms. Transforms that do
> > not have a general inverse may use an iterative numeric inverse method
> > internally. This is the approached I have used so far (with minor
> > alterations to ITK 1.8.1 and 2.0.1).
> >
> > Are these observations accurate and are my proposed solutions acceptable?
> >
> > Paul.
> > _______________________________________________
> > Insight-developers mailing list
> > Insight-developers at itk.org
> > http://www.itk.org/mailman/listinfo/insight-developers
> >
More information about the Insight-developers
mailing list