[Insight-developers] Re: Suggestion: Tensors and Tensor ImageFilters

[Luis Ibanez]

A parallel discussion on the implementation of DTI images in ITK
is being held at the Wiki pages of NAMIC:

  http://www.na-mic.org/Wiki/index.php/NAMIC_Wiki:Community_DTI

A draft ITK implementation of a DiffusionTensorPixel type has
been posted at

http://www.na-mic.org/Wiki/index.php/NAMIC_Wiki:DTI:ITK-DiffusionTensorPixelType

This code compiles with the current CVS version of ITK,
(soon to be ITK 1.10).

This rough implementation is mostly based on the approach used for
Vector images and RGB images, as suggested by Martin Styner in the
DTI discussion page:

http://www.na-mic.org/Wiki/index.php/NAMIC_Wiki:DTI:Tensor_format

This approach however is not well suited for what Jim suggest below,
namely to be able to store tensors only in regions of interest of
the image. The concern with using indirection (e.g. smart pointers)
is that (a) the pointer will take 4 bytes for storage and (b) assignment
of smart pointers involves a Mutex operation which makes access very
slow.

The implementation is also focused in diffusion tensors (assuming
symmetry) as opposed to representing generalized Tensors. Given the
demanding memory requirements of DTI images it seems desirable to
take advantage of the symmetry and store only 6 numbers. Note that
the API is still providing matrix-like notation for accessing the
Tensor elements.


I would rather keep the DiffusionTensorPixel as an isolated class,
instead of a member in a hierarchy of tensor types.  The Generic
Programming approach used in ITK make possible for us to write
filters based only on the API of the PixelType without requiring
such pixels to belong to any particular hierarchy.  It is enough
for us to make sure that the API of the DiffusionTensorPixel class
looks very close to the API of any eventual itkTensorPixel.
This has worked nicely already for dealing with vector-like images
such as images of itkVectors, images of itkPoints, images of
itkCovarianVectors, and images of itkRGBPixels.



    Luis


------------------------------------
Miller, James V (Research) wrote:

> Another consideration with respect to memory management:
> 
> I am concerned with the amount of memory needed to represent an 
> volume of tensors.  I imagine that in an image of tensors, not all the 
> tensors are of interest (i.e. pixels outside the anatomy or region of
> interest). If this is the case, we should design the tensor pixel class
> to take minimal storage if we do not intend to access the pixel.  In an 
> ITK image, the pixels in a filter's output image may allocated by the
> pipeline.  We may want this allocation of the pixels to take minimal
> storage.  For instance, a tensor pixel could be a stack based object
> but hold a pointer to vector or matrix that is used for its storage class.
> When the pixel is needed, the memory for the vector or matrix will then
> be allocated.  
> 
> I am not sure that we can make such a tensor pixel look as stack based
> as the other ITK pixel types.  Algorithm writers may to make an additional
> call on a tensor pixel to force its bulk data allocation.  
> 
> One thing we have done in the past is have an image of SmartPointers to matrices.  Iterating over an image returns a smart pointer to a matrix.
> That smart pointer may be null or point to real matrix.  We could use an approach like this.  But we may be able to go a step further and hide 
> the internal pixel memory management from the programmer so that a tensor
> appears to be stack based.
> 
> In order to reuse all the iterators in ITK, we need an tensor pixel type
> to appear as a stack based object.
> 
> As for symmetric verses non-symmetric tensors, we'll need to decide
> between using an object oriented approach (class hierarchy of tensors)
> or a generic programming approach (where we have separate tensor classes
> that have a common API).  The former allows for code reuse but may require virtual function invocations.  The latter may require code duplication avoids virtual function invocations. We should look at the vnl_matrix<>, vnl_sym_matrix<>, and vnl_matrix_fixed<> for ideas.
> 
> I think we need to see a list of the types of operations that one would
> want to apply to a tensor pixel and the list of operations that one would
> want to apply to an image of tensor pixels.  
> 
> Jim
> 
> 
> 
> 
> 
> -----Original Message-----
> From: insight-developers-bounces at itk.org
> [mailto:insight-developers-bounces at itk.org]On Behalf Of Jeffrey Duda
> Sent: Tuesday, February 01, 2005 1:21 PM
> To: torsten at synapse.sri.com
> Cc: insight-developers at itk.org
> Subject: [Insight-developers] Re: Suggestion: Tensors and Tensor
> ImageFilters
> 
> 
> I've actually been working on writing code for processing dti data in 
> ITK.  I've developed a DiffusionTensorPixel class as well as some code 
> for IO, eigen decomposition, filters for calculation of various scalars 
> (anisotropy, etc) and interpolators that incorporate various 
> reorientation schemes.  I'd be happy to show you what I've got, although 
> I'll probably need to clean it up a bit first.
> 
> -jeff
> 
>>----------------------------------------------------------------------
>>
>>Message: 1
>>Date: Mon, 31 Jan 2005 22:26:26 +0000
>>From: Torsten Rohlfing <torsten at synapse.sri.com>
>>Subject: [Insight-developers] Suggestion: Tensors and Tensor Image
>>	Filters
>>To: insight-developers at itk.org
>>Message-ID: <41FEB092.4080509 at synapse.sri.com>
>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>>
>>Greetings!
>>
>>It appears that there is not much functionality in ITK currently for 
>>processing (MR diffusion) tensor data. I am therefore currently in the 
>>process of writing such components myself.
>>
>>Since I am planning to contribute the resulting code to ITK (if there is 
>>interest), I wanted to ask for comments on some design decisions before 
>>getting too far into the endeavour. Of course I would also be very 
>>interest to hear whether this work has been done already (or is in 
>>progress somewhere) and my efforts are, therefore, futile.
>>
>>Most fundamentally in terms of design, I am unsure whether the basic 
>>tensor processing operations (e.g., eigenvalues, eigenvectors, 
>>potentially common anisotropy measures) should be implemented entirely 
>>in image filter classes for tensor images (similar to the vector 
>>gradient magnitude filters for example). It seems to me that a separate 
>>tensor class would make sense to provide access to basic functions such 
>>as eigensystem decomposition, which is useful for many tensor 
>>operations, whereas the anisotropy measures for example should probably 
>>go into filter classes.
>>
>>Also, can anyone think of a reason why the tensor dimension (i.e., the 
>>tensor matrix size) should be a template parameter (as opposed to fixed 
>>3x3)? My current state of mind is that tensor image dimensions should 
>>definitely be templated to allow processing of 2D slices, whereas the 
>>tensors themselves really don't seem to make much sense in anything 
>>other than 3D.
>>
>>Looking foward to comments and suggestions.
>>
>>Best,
>>  Torsten
>>
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
> 
>