[Insight-developers] itkPoint from a math perspective

[George Stetten]

Luis,

Thanks for your (usual) thoughtful reply.

What you call "Covariance" I usually call "Codimension."  I'm not sure how the
concept of covariance applies to vectors normal to a surface, but I immagine it's
explained in the book you reference.

Covariance is something we use in a different way.  We generate a covariance matrix
by summing the outer
products of unit vectors with themselves, to analyze populations of orientation
measurements.

George


Luis Ibanez wrote:

> 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