[Insight-developers] itkPoint from a math perspective

[Luis Ibanez]

George,

The Covariant vector is different from a Vector in the
sense that it doesn't represent a difference between two
points in space.

Covariant vectors represent the direction orthogonal to
a subspace. That's the case of the cross product between
two vectors, the result is something orthogonal to the
subspace defined by the two original vectors.

For example, the normal vectors in a triangular mesh
should be CovariantVectors, the gradients of a scalar
function should be CovariantVectors.

One easy way to see the difference is to take a circle,
draw some of its normals, and then apply a scale factor
only in the vertical direction. The circle became an ellipse.

If the normals you draw behave like vectors, they will not
be orthogonal to the ellipse anymore. If they are covariant
vectors, they will still be orthogonal to the ellipse.

In general the distintion between Vectors and CovariantVectors
only matters if:

  - you apply non-rigid transforms to the space:
    like anisotropic scale, or shearing.

  - you have a non-orthogonal coordinate system.


For us, the distintion is critical in at least two areas:

  - Optimizer based on gradients
  - Geometric transformations (e.g. Affine)


Covariant vector components can have any values,
what makes them different is how they interact with
other geometric objects.


It is clear that's sometimes anoying to be restricted by
the types in the library, but they are preventing users
for writing code with conceptual errors.

A very nice description of Covariant/Contravariant is
in the book: "Tensor Geometry: The geometric viewpoint
and its uses" by C. Dodson and T. Poston.

That will be a good basis if we ever include MRI tensor
images in the toolkit.


Luis



---------



On Mon, 16 Jul 2001, George Stetten wrote:

> Luis,
>
> I've never been clear what the itkCovariantVector is for.
>
> You say:
>
> itkCovariantVector = itkVector X itkVector (cross product)
>
> What do you use them for and what restrictions apply to their values?
>
> Thanks
>
> George
>
> Luis Ibanez wrote:
>
> > Damion Shelton wrote:
> >
> > > seedPos.Get_vnl_vector().normalize();
> >
> > an itkPoint is a position in space.
> > Normalization is not defined for points.
> > (it doesn't makes sense to normalize the
> > components of a position).
> >
> > In fact, returning a vnl_vector from an
> > itkPoint is just a backdoor for type missuse.
> >
> > Normalization is defined for itkVectors
> > which are the relative position of one
> > itkPoint with respect to another.
> > (in this case the normalized vector
> > codes for a direction in space).
> >
> > If normalization is required in a function,
> > maybe the itkPoint is not the expected parameter.
> >
> > What is this particular function doing ?
> >
> > >
> > > This is a relatively simple operation - for more complex operations (dot
> > > products, for instance), I found it neccessary to duplicate Point data in
> > > order to avoid horribly messy code.
> >
> > Dot product is not defined over points in space,
> > but over vectors, representing the projection of
> > one vector over the other.
> >
> > Could you post the example of what the function is
> > intended to compute ?
> >
> > The typical experience in computer graphics is that
> > these types are often used in the wrong sense, just
> > because all look like n-d arrays.
> >
> > But their difference are quite important if they
> > are mapped by a affine transform.
> >
> > >
> > > To summarize: Is there an easy way to interchange
> > > Points, CovariantVectors, and vnl_vector's?
> >
> > yes:
> >
> > itkVector = itkPoint - itkPoint
> > itkPoint  = itkPoint +/- itkVector
> >
> > itkPoint + itkPoint = Undefined
> >
> > itkCovariantVector = itkVector X itkVector (cross product)
> >
> > scalar = itkVector * itkVector (dot product)
> >
> > Now, all three, itkPoint, itkVector and itkCovariantVector
> > have a vnl_vector() method, the only justification for this
> > conversion is to use any of the vnl methods that requires
> > a vnl_vector as an input. This conversion will imply a hit
> > in performance.
> >
> > > I'm concerned that having to explicity convert back and
> > > forth between data types is an impediment to clear code, and possibly a
> > > speed handicap as well, since these interconversions would occur many
> > > hundreds of thousands of times in my code.
> >
> > Agree on the performance side,
> > but it is important to be careful with the missuse of the types.
> > an itkPoint is different from an itkVector, and an itkCovariantVector.
> > They are all different mathematical concepts. The possibility of
> > converting
> > them to vnl_vectors was provided only because vnl doesn't make this
> > distintion, and use only vnl_vector in the linear algebra sense as
> > opposed of the geometric sense.
> >
> > In other words, a vnl_vector is like a Nx1 vnl_matrix,
> > or like an array in Matlab.
> >
> > Luis
> >
> > _______________________________________________
> > Insight-developers mailing list
> > Insight-developers@public.kitware.com
> > http://public.kitware.com/mailman/listinfo/insight-developers
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>

-- 
Luis Ibanez                                      CB#:   7060
Research Assistan Professor                      phone: (919) 843 5436
Division of Neurosurgery                         fax:   (919) 966 6627
University of North Carolina at Chapel Hill      email: ibanez@cs.unc.edu
Chapel Hill, NC 27599-7060                       http://www.cs.unc.edu/~ibanez