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

[Miller, James V (Research)]

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