[Insight-developers] ITK image for diffusion weighted data

[Karthik Krishnan]

Hi Gordon and others,

Luis asked me to send an email summarizing the status of the ITK image 
for diffusion weighted data:

Here is the proposal and details

http://www.itk.org/Wiki/Proposals:VectorImage

The classes recenlty committed to handle the same are

http://www.itk.org/Insight/Doxygen/html/classitk_1_1VectorImage.html
http://www.itk.org/Insight/Doxygen/html/classitk_1_1VectorImageToImageAdaptor.html
http://www.itk.org/Insight/Doxygen/html/classitk_1_1DefaultVectorPixelAccessor.html
http://www.itk.org/Insight/Doxygen/html/classitk_1_1Accessor_1_1VectorImageToImagePixelAccessor.html


A Test for the image and the adaptor, with some timing statistics to 
allocate a 200x200x200 image with 6 Diffusion weighted measurements and 
fill the buffer with some value.

http://www.itk.org/Testing/Sites/chiarugi.uiowa/Linux64-g++-3.4-opt/20050805-0100-Nightly/Results/__Testing_Code_Common_itkVectorImageTest.html
There is a typo in the message output: It reads Allocating an Array, 
FixedArray and VectorImage respectively.

Funnily contrary to what I would have expected the VectorImage is faster 
than the FixedArray. I would have expected them to be comparable. Turns 
out this is because the "operator=" in FixedArray is not inlined by the 
compiler due to a for loop in there!

$ nm -C itkVectorImageTest.o | grep FixedArray | grep operator= | grep float
itk::FixedArray<float, 6>::operator=(itk::FixedArray<double, 3> const&)



Of course the image will be largely useless until the iterators support 
it unless you want to use the slow SetPixel/GetPixel methods.   The 
implementation of iterators for these images is still pending. More on 
the wiki.

Thanks
Regards
Karthik

>
>
> ------------------------------------------------------------------------
>
> Subject:
> ITK Image for DWI data
> From:
> "Gordon Kindlmann" <gk at bwh.harvard.edu>
> Date:
> 5 Jul 2005 17:52:43 -0400
> To:
> "Luis Ibanez" <luis.ibanez at kitware.com>
>
> To:
> "Luis Ibanez" <luis.ibanez at kitware.com>
> CC:
> "Kikinis MD Kikinis" <kikinis at bwh.harvard.edu>, "William E Lorensen" 
> <lorensen at crd.ge.com>, "Steve Pieper" <pieper at bwh.harvard.edu>
>
>
> hello,
>
> This is the message that I said I'd send to Luis after the Programming 
> Week, based on our informal discussions about the need for an ITK 
> image that can gracefully handle the kind of data that arises in 
> diffusion-weighted image experiments.
>
> The basic requirements are:
>
> - a pixel type for a vector/array/list of measurements, in which the 
> number of measurements is known only at run time.  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).
>
> This came up in the context of doing DWI processing in ITK, and there 
> are at least two cases in this context:
>
> - 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.
>
> I'm not likely to be the one to implement a prototype of this kind of 
> image (unless we want more Dashboard fireworks!), but I wanted to 
> remind us of the need, and to volunteer to continue to be a sounding 
> board for ideas, and a tester for possible implementations.
>
> Gordon
>
>
>