[Insight-developers] itkVector, itkPoint and normals

[Will Schroeder]

Hi Luis-

Some points regarding itkPoint :-)

>There are some differences between the itkVector and
>itkPoint that could be interesting to reduce.
>
>1) To declare its template parameters they are now:
>
>   itkPoint<  dimension, type >
>   itkVector< type, dimension >

No big deal, this should be changed.


>2) Currently to hold its data:
>
>   itkVector : uses a vnl_vector_fixed<T,dimension>
>   itkPoint  : uses an array of T type
>
>That makes difficult to use the itkPoint in computaions
>using vxl numeric library. For example, to apply an
>Affine transformation to a Point, we have to extract
>its elements to a vnl_vector, in order to use the matrix
>multiplication operator defined in vnl, or perform
>the matrix multiplication explicitly.

It is a bad idea to change the original internal representation of itkPoint 
due to
memory requirements. We worked hard to trim the Mesh data structure
down to a minimal memory footprint. (We are assuming millions of points
and/or cells, the addition of a few bytes will add up quickly). We can add some
operators that would allow the point to function gracefully with the vnl stuff.


>3) itkPoint uses the terms "Coord" and "CoordRep"
>as contractions. That makes its API looks quite
>different from the itkVector API.

We can make the point and vector look more consistent. I agree with you
Luis, getting rid of CoordRep in favor of ValueType, etc. makes the code
consistent and a little more compact,

>4) Additionally it could be convenient to define
>operation between points and vectors, like
>
>    Vector = Point - Point
>    Point  = Point + Vector
>    Point  = Point - Vector

These are good suggestions. The vector returned would be a vnl vector;
the Points would have the necessary operators to operate in the
context of vnl.


>In general the presentation of itkVector seems to be
>more appropiated for coordinates computation, maybe
>it would be convenient to make itkPoint look similar.
>
>Could that changes introduces problems for other uses
>of the itkPoint ? ( eg. in itkMesh ).

Other than memory footprint, what you suggest looks good. Do you want me to 
take a crack at changing the class?

Will