Proposals:VectorImage: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
Line 16: Line 16:
<tt>Excerpts from Gordon's email:</tt>
<tt>Excerpts from Gordon's email:</tt>


   - While a given DWI protocol has a fixed number of measurements, a user can reasonably want to analyze and compare DWI datasets with any number of different measurements without having to recompile.
   - While a given DWI protocol has a fixed number of measurements, a user can reasonably want to analyze and compare DWI datasets  
with any number of different measurements without having to recompile.
  - The list of measurements should not add to the nominal dimension of the image,
since, for example, the orientation information will not include that axis (e.g. DWI datasets have 3-D orientation information, not 4-D)


   - The list of measurements should not add to the nominal dimension of the image, since, for example, the orientation information will not include that axis (e.g. DWI datasets have 3-D orientation information, not 4-D)
   - For reasons of memory efficiency, as well compatibility with memory-layout of other software,
it would be ideal if the memory representations of the pixels' values were contiguous (so that the last DWI value for the
Nth pixel proceeds the first DWI value for the N+1st pixel).  It was the point that led Luis to reconsider the
initial suggestion of simply creating an image of arrays (which also suffers a heavy one-time cost in allocating each pixel's array).


   - For reasons of memory efficiency, as well compatibility with memory-layout of other software, it would be ideal if the memory representations of the pixels' values were contiguous (so that the last DWI value for the Nth pixel proceeds the first DWI value for the N+1st pixel)It was the point that led Luis to reconsider the initial suggestion of simply creating an image of arrays (which also suffers a heavy one-time cost in allocating each pixel's array).
   - using ITK to process the numerous existing NAMIC diffusion datasets in an efficient way.  This is
the most pressing case.  Some people are already estimating tensors from DWI in ITK, but they're using
volume-interleaved memory layout, which is opposite of what we would want.  It would be very convenient
if NAMIC participants could experiment with linear, non-linear, and other tensor estimation methods within
a standard frameworkLacking such a framework, every NAMIC group is going to come up with their own non-interoperable methods.


  - using ITK to process the numerous existing NAMIC diffusion datasets in an efficient way.  This is the most pressing case.  Some people are already estimating tensors from DWI in ITK, but they're using volume-interleaved memory layout, which is opposite of what we would want.  It would be very convenient if NAMIC participants could experiment with linear, non-linear, and other tensor estimation methods within a standard framework.  Lacking such a framework, every NAMIC group is going to come up with their own non-interoperable methods.
   - Doing filtering or tractography in the DWI space, instead of in the space of estimated tensors.  At  
 
least one published tractography method (Conturo PNAS '99) interpolate DWIs and estimate tensors at every  
   - Doing filtering or tractography in the DWI space, instead of in the space of estimated tensors.  At least one published tractography method (Conturo PNAS '99) interpolate DWIs and estimate tensors at every step, and this has the advantage of dealing with noise in its own domain, instead of complicating it with the additional step of tensor estimation.  Other methods (such as estimating two tensors per DWI list) also require access to the original DWIs.
step, and this has the advantage of dealing with noise in its own domain, instead of complicating it with  
the additional step of tensor estimation.  Other methods (such as estimating two tensors per DWI list) also  
require access to the original DWIs.


= Proposed Implementation.. feel free to add =
= Proposed Implementation.. feel free to add =

Revision as of 15:51, 1 August 2005

ITK: Vector Image

What is a vector image

Create a templated n-dimensional vector image class.

This class differs from Image in that it is intended to represent multiple images. Each pixel represents 'k' measurements, each of datatype 'TPixel'. The memory organization of the resulting image is as follows:

  ... Pi0 Pi1 Pi2 Pi3 P(i+1)0 P(i+1)1 P(i+1)2 P(i+1)3 P(i+2)0 ...

where Pi0 represents the 0th measurement of the pixel at index i.

Conceptually, a VectorImage< double, 3 > is the same as a Image< Array< double >, 3 >. Creating the latter incurs a cost of allocating an Array for each pixel, which we would like to avoid.


Why ?

Excerpts from Gordon's email:

 - While a given DWI protocol has a fixed number of measurements, a user can reasonably want to analyze and compare DWI datasets 

with any number of different measurements without having to recompile.

 - The list of measurements should not add to the nominal dimension of the image, 

since, for example, the orientation information will not include that axis (e.g. DWI datasets have 3-D orientation information, not 4-D)

 - For reasons of memory efficiency, as well compatibility with memory-layout of other software, 

it would be ideal if the memory representations of the pixels' values were contiguous (so that the last DWI value for the Nth pixel proceeds the first DWI value for the N+1st pixel). It was the point that led Luis to reconsider the initial suggestion of simply creating an image of arrays (which also suffers a heavy one-time cost in allocating each pixel's array).

 - using ITK to process the numerous existing NAMIC diffusion datasets in an efficient way.  This is
the most pressing case.  Some people are already estimating tensors from DWI in ITK, but they're using 

volume-interleaved memory layout, which is opposite of what we would want. It would be very convenient if NAMIC participants could experiment with linear, non-linear, and other tensor estimation methods within a standard framework. Lacking such a framework, every NAMIC group is going to come up with their own non-interoperable methods.

 - Doing filtering or tractography in the DWI space, instead of in the space of estimated tensors.  At 

least one published tractography method (Conturo PNAS '99) interpolate DWIs and estimate tensors at every step, and this has the advantage of dealing with noise in its own domain, instead of complicating it with the additional step of tensor estimation. Other methods (such as estimating two tensors per DWI list) also require access to the original DWIs.

Proposed Implementation.. feel free to add

The VectorImage class:

 template <class TPixel, unsigned int VImageDimension=3 >
 class ITK_EXPORT VectorImage : public Image< Array< TPixel >, VImageDimension >
   {
   ...
   typedef Array< TPixel >     PixelType;
   typedef TPixel              InternalPixelType;
   ...
   // Override a few methods of image like Allocate() 
   // (Should this be a virtual method. It is not currently)
   }