[Insight-developers] Hierarchy of Transformations : Math vs C++

[Luis Ibanez]

On Wed, 20 Dec 2000, Paul Hughett wrote:
 
> 1. It seems to me that you are adding unnecessary complexity by using
> separate classes for Euclidean, Similarity, and Affine transformations.
> The representations are all the same (matrix plus offset) and the
> difference is only in what conditions the matrix must satisfy.  These
> conditions can be tested by using IsEuclidean, etc methods as needed.

Agree, that's the reason why the internal representation (matrix + offset)
can be set on "a" base class. 

Maybe the hierarchy is not that complex. In fact, the base class contains 
only the matrix and the offset. Then the Rigid transform contains metods 
for defining translations and rotaions. Next, the Similarity transform adds 
only a set of Scale() methods. And finally the Affine transform will add 
Shears().

The AffineTransform that you have already implemented, contains all the
difficult parts. The rest of the hierarchy will be just two files with 
a redistribution of the methods.

One of the first thing that we want to do when defining a registration
problem is to choose the particular transformation to use. The issue
is not to be able at each moment to ask the transformation if it is 
Euclidean or not, but to ensure that it is at all times, specially 
because this transformation will be generated or altered on the fly by the 
optimization method.  Restricting the methods that can alter the matrix could 
be one of the safest ways to keep the conditions imposed on the transformation.

> 
> 2. The distinction between proper and improper transformations is at
> least as important as the one you intend to use and is not reflected
> at all in your proposed hierarchy.  The distinction between affine and
> linear is probably less important but may matter in some applications.
> 
Agreed, the transform hierarchy don't have to be limited to the affine family,
it can be extended to cover all the transformations of interest for the 
toolkit.

> 3. The base class for transformations is not any of the above, but a
> more generic transformation class that transforms points in a given
> number of dimensions into other points; as a practical matter, it
> should probably be bijective and continuous, but we may not want to
> actually force that in the class definition. 
>

That's the point where the mathematical notion goes in contradiction
with the Object Oriented style. I agree that the generic transform in the
mathematical sense is the one with the minimum number of restrictions, 
but in OOP the base class is the one with the minimum of functionality,
so the maximum of restrictions.

Maybe in languajes like Eiffel we could really represent the mathematical
structure, because during derivation, we can select what methods of the base
class will be visible in the derived class and some public method can be 
made private, on a method by method basis.

> 4. The file Documents/Registration.pdf discusses some of these issues
> in more detail.
> 

Yes, the Registration.pdf describes the central concerns about the types
of transformation to consider for the toolkit, and we are trying to 
create classes following the principles stated in the document...
The question is just, how to map this proposed structure in a practical 
C++ implementation ?


One possible alternative is to use a flat set of Transformation classes as 
opposed to a hierarchy, that could be ok for the Registration hierarchy 
given that the other components are templated over the Tranform type.




Luis