[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