[Insight-developers] itkVector, itkPoint and normals

[Will Schroeder]

Hi Jim-

In that case I would argue that itkVector should not be implemented with vnl_vector :-) I think memory issues
are very important. My experience with big data sets is that the difference between choosing one package over another often boils down to its performance when the data is large, which is usually a function of memory as the system strains to swap, etc.

Will

At 08:22 AM 1/3/2001 -0500, Miller, James V (CRD) wrote:
>Will,
>
>I'm not sure I agree with point about not using vnl_vector due to memory constraints.  itk::Vector
>already uses vnl_vector and I imagine in most circumstances we will have more pixels in our images
>than points in our meshes.  So we have already accepted this overhead for images.
>
>An itk::Vector is only 8 bytes bigger than an itk::Point. So if we had millions of points the
>overhead would not be that excessive.
>
>Jim
>
>
>
>-----Original Message-----
>From: Will Schroeder [mailto:will.schroeder@kitware.com]
>Sent: Wednesday, January 03, 2001 6:48 AM
>To: luis.ibanez@ieee.org; Miller, James V (CRD);
>insight-developers@public.kitware.com
>Subject: Re: [Insight-developers] itkVector, itkPoint and normals
>
>
>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
>
>
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers