Proposals:InverseTransform: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| Line 6: | Line 6: | ||
= Existing limitations = | = 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. | * 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 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 functinality at all. | |||
= Proposed changes = | = Proposed changes = | ||
Revision as of 17:36, 10 October 2005
Proposal
A more flexible inverse transform API in needed in order to support numeric inverse transformation for transforms which do not have an analytical inverse.
Existing API
Currently, the inverse transformations are available via the GetInverse method and the deprecated BackTransform API (analogous to the TransformPoint, TransformVector and TransformCovariantVector forward transform API). 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 transform object. The GetInverse method fills in the parameters that define the inverse transform.
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 functinality 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 base 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.
