[Insight-developers] Vector & CovariantVector

[Luis Ibanez]

Hi Arnaud,

The reason why it is important to represent normals as CovariantVectors
instead of Vectors, is that they behave differently under certain Affine
Transforms.

The easiest case to visualize, is the one of a Sphere of radius  = 1.0.

If you apply an anisotropic scaling with factors:   ( X = 1.0, Y = 1.0, Z = 0.5)
the sphere will become a flattened ellipsoid where the semi-axis in the Z
direction is half the size of the ones in the X and Y directions.

Let's track what will happen to a CovariantVector and a Vector under
this transformation (and let's pick them with the same component values):

For example:

    Vector(  0.0,  1.0,  1.0 )  and  CovariantVector ( 0.0, 1.0, 1.0 )

After the transformation, they will become respectively:

   Vector(  0.0,  1.0,  0.5 )  and  CovariantVector ( 0.0, 1.0, 2.0 )

If we have used a Vector in order to represent the normal, we would
have found that after the anisotropic scaling the "normal" vector is
no-longer perpendicular to the surface of the sphere.

You are correct in that, unfortunately, there are many places in the
toolkit where CovariantVectors should have been used, but they
are not. The same actually apply to Vectors and Even Points, if
you dig deep enough in the ITK geological records.  For example
we have still places where we take a pointer to doubles as a valid
representation for Spacing, and Origin.


    CovariantVectors should not operate with points,
    only Vectors should.


What specific operations between Normals and Points did you have in mind ?

In practice, it is common to find that when you are needing to apply
one of the missing (or intentionally non implemented) operations,
it is a symptom of a misinterpretation of geometrical elements.

For example:

   Attempting to add two itkPoints, is most certainly a mistake.
   as well as it is to multiply a Point by a scalar.


(and I'm not implying that you were doing this in your code,
these are simply illustrative examples of why type abstractions
are important here).


   Regards,


          Luis


--------------------------------------------------------------------------------------------
On Fri, Mar 27, 2009 at 11:43 AM, Arnaud Gelas
<arnaud_gelas at hms.harvard.edu> wrote:
> Hi Luis,
>
> While fixing the "assert" issue in itkCrossHelper, I read your message
> stating that normals should be represented as CovariantVector.
>
> First could you remind why CovariantVector are important (I know it is
> related to AffineTransformation)? I remember there is a mathematical reason
> why this is, i just do not remember what the reason is.
>
> Then, practically, the introduction of covariant vectors in ITK is quite
> recent, with regard to itk lifespan. Some parts of the toolkits (the most
> recent ones) use covariant vectors where they should, but older parts are
> still using the original design where everything is made of vectors.
>
> Practically, when working with low level operations, you don't really have
> choice if you don;t want to rewrite everything:
>
>   * itk::Point - itk::Point = itk::Vector
>   * itk::Point as one method GetVectorFromOrigin() which returns one
>     itk::Vector
>   * itk::Point + itk::Vector = itk::Point
>   * and few more operators in itk::Point (+=, -=, /etc/...)
>
> Now, if the basic operations, such as,  but not limited to, those listed
> above, were to return covariant vectors, it would be of course my pleasure
> to support covariant vectors.
> Now, the modifications we are speaking about here, are not for the faint of
> heart, as it touches itk kernel and would most surely impact a lot of
> classes. Did I heard the word "backward compatibility" before? Would there
> be any magical design pattern that would allow us to work around this? I'm
> very junior with design patterns, to say the less, but would an adaptor or
> decorator be possible? I am willing to help implement solutions, I just
> cannot figure what the good solution is. Would you think about anything?
>
> arnaud & alex.
>
>
>