Proposals:InverseTransform

Proposal

A more flexible inverse transform API is needed in order to support numeric inverse transformation for transforms which do not have an analytical inverse.

Existing API

• The inverse transformation functionality is available via the GetInverse method. The GetInverse method is not virtual, even though it is declared in the base class. The GetInverse method expects as its parameter a pointer to the forward transform object. The GetInverse method fills in the parameter list of the passed-in forward transform such that it would define the inverse transform.
• The inverse transformation functionality is also avaible via the deprecated BackTransform API (analogous to the TransformPoint, TransformVector and TransformCovariantVector forward transform API).

Existing limitations

• Since the GetInverse method requires that the type of the inverse transform must be the same as the type of the forward transform, the possibility of a numeric inverse transform is automatically precluded.
• The fact that there is no virtual method for inverse transformations is a big limitation and inconvenience.
• The identity transform does not provide any inverse transformation functionality at all.

Proposed changes

• The current GetInverse method may make perfect sense for transforms which are analytically invertible to a transform of the same type (Translation, Scale, Rotation, etc). It may make sense to keep this API intact.
• A virtual method declared at the base class should be provided that would return a pointer to a transform object. At the discretion of the forward transform, the inverse transform could be an analytic inverse or a numeric inverse.
• A new iterative inverse transform class must be defined. This class should be parameterized by the forward transform type. The numeric inverse can be implemented using the Newton-Raphson method for nonlinear systems of equations.
• In order for the Newton-Raphson numeric inverse transform to be used, the forward transform API must define a method for evaluating the derivative of the transform with respect to the input image dimensions -- another Jacobian, different from the Jacobian currently provided by the forward transforms.

It makes some sense to implement the numeric inverse transform as a subclass of itk::Transform -- in order to provide a consistent API across forward and inverse transforms:

 template <typename TForwardTransform>
 class NumericInverseTransform : 
   public Transform<TForwardTransform::ScalarType,
                    TForwardTransform::OutputSpaceDimension,
                    TForwardTransform::InputSpaceDimension>

However, not all of the expected functionality associated with the forward itk::Transform class makes sense for a numeric inverse transform. For example, there is only one parameter that defines a numeric inverse -- a reference to the forward transform. Therefore, the GetParameters/SetParameters methods are meaningless.

The following addition is proposed for the itk::Transform interface:

 // Return an inverse transform -- the derived class must decide what to do here.
 // The default implementation throws an exception.
 virtual typename Transform<TScalarType, 
                            NOutputDimensions, 
                            NInputDimensions>::Pointer GetInverse() const;

The following forward transform interface is required by the Newton-Raphson solver.

 // evaluate F = T(x), J = dT/dx (another Jacobian):
 void Eval(const std::vector<ScalarType> & x,
           std::vector<ScalarType> & F,
           std::vector<std::vector<ScalarType> > & J) const;

Current status

I have a working implementation of the iterative numeric inverse using the numerical recipes code for the Newton-Raphson nonlinear solver. Currently, it is implemented within the deprecated BackTransform API (requiring minor modifications to the itk::Transform class). The inverse transform class does not derive from the itk::Transform class. This code is not up-to the ITK coding standards and will require some re-writing before being considered for inclusion into the ITK tree. Also, I am unclear whether the use of the numerical recipes code is allowed within ITK. If not, that will have to be rewritten as well.

---

ITK: [Welcome | Site Map]