[Insight-developers] RE: Vector image pixel type ?

Miller, James V (Research) millerjv at crd.ge.com
Thu Sep 8 09:07:01 EDT 2005


I think the vector image was also to support fMRI analysis.
Here, standard mathematical operations would need to be supported.
Addition, subtraction, inner/outer products, multiply by a matrix.

For many of these analyses, svd and eigensystem analysis is done.
In this case, the vector data (perhaps over a neighborhood) would be 
copied into a vnl_matrix and passed down vnl algorithms.

Jim

-----Original Message-----
From: Gordon Kindlmann [mailto:gk at bwh.harvard.edu]
Sent: Wednesday, September 07, 2005 5:38 PM
To: Karthik Krishnan
Cc: Luis Ibanez; Bill Lorensen; Miller, James V (Research); Insight
Developers List
Subject: Re: Vector image pixel type ?


hello,

If I remember correctly, the creation of the VectorImage was  
motivated by the practical usage constraints of working with  
diffusion-weighted MRI data, wherein you have multiple values  
(baseline or diffusion weighted) per pixel, but it is cleanest to  
defer learning the number of values per pixel from compile-time to  
run-time.  So, my answer is based on concerns specific to DWI, but I  
think others should chime in with thoughts on other ways the  
VectorImage can be used.

The immediate use case for the VectorImage is to do tensor estimation  
from the DWI values.  This is a simple per-pixel operation that  
computes a single tensor from the DWI values, in combination with  
accompanying information about the acquisition protocol (gradient  
directions, NEXs, etc).  This use doesn't require any mathematical  
operations on the image as whole, akin to filtering.  That is, we  
would not be doing scalar multiplication or addition on VectorImage  
pixels.  If you're asking about this with respect to the impending  
ITK release, I would say that no pixel arithmetic is required.

However, you can easily imagine doing such filtering (such as  
Gaussian blurring and up/downsampling) on DWIs, because I believe it  
would be just as justified, from a physical and image processing  
standpoint, as doing such filtering on any other kind of MR image, as  
long as the operation were done component-wise.  One could further  
imagine doing vector-valued non-linear filtering (such as anisotropic  
diffusion), which requires some notion of a gradient.  Those kinds of  
processing may complicate the interpretation of the data as a DWI  
image from which tensors can be meaningfully extracted, but I don't  
think those complications are qualitatively different than the  
interpretation of scalar MR images which have been so filtered.

In these respects, the VectorImage as used for DWI should be no  
different than any existing multi-valued image types which support  
scalar multiplication and addition operations (though the number of  
components is fixed at compile-time)- that is: pixels values are  
truly mathematical vectors.

However, other people may want to use the representational  
flexibility of VectorImages for other applications and needs, so  
other developers should probably help us determine the class of  
operations that makes sense.

best,
Gordon


On Sep 7, 2005, at 5:01 PM, Karthik Krishnan wrote:

> Hi Gordon,
>
> The VectorImage supports all iterators that image supports and as  
> you know has IO support .  So it can do anything that Image< Array  
> < T >, N > can do, (without fragmenting the memory)
>
> What exactly do you intend using this image for ?
>
> 1. Do you intend performing mathematical operations on this image ?
>
> (For instance applying a linear filter, say Gaussian smoothing on  
> VectorImage will require its PixelType to support mathematical  
> operations.)
>
> If you do then itk::Array  needs to support mathematical operators  
> like +, *, etc...
> I would just leave Array as is and create another Pixel type,  
> similar to the array, since Array is intended to represent a  
> collection of any N types.
>
>
> Let me know what you think.
>
> Regards
> karthik
>



More information about the Insight-developers mailing list