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

[Karthik Krishnan]

On Wed, 2005-09-07 at 17:38 -0400, Gordon Kindlmann wrote:
> 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.
> 

Ok.. This should be possible with tonight's CVS snapshot. I just
finished adding support for neighborhood iterators using functors..

I put in a couple of example adaptors, so you could extract components
from a VectorImage etc, 
itk::VectorImageToImageAdaptor
Others could be easily created as need arises.

> 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. 

To a filter, or a user, a  
VectorImage< float, 3 > 
looks just like a 
Image< Array< float >, 3 > == Image< P, 3 >

It would make sense for P to have a bunch of operations defined, so
filters can work just as usual with it.

For instance 
P1 + P2, P1*P2, P1*scalar, etc.....

I would hesitate to add these operations to itk::Array, since its too
general. People could for instance be using an Array of images or an
array of transforms. You can't define any operations here. It the same
reason why there is both itk::Vector  and itk::FixedArray.

So, I should probably create another pixeltype "VariableLengthVector" or
something like that...

>  One could further  
> imagine doing vector-valued non-linear filtering (such as anisotropic  
> diffusion), which requires some notion of a gradient.  

I can certainly see operators for linear filters.. How do you define
non-linear operators on the pixel type ?

What is exp( Array< float > ) ? 
>From a first glance I don't think any of the non-linear filters can be
used on VectorPixels. They would require creation of a new family of
filters.. (which shouldn't be hard to do). Maybe I am just not aware of
sensible mathematical operators here...

> 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)- 

I need to define NumericTraits for a pixel whose length is not fixed at
compile time:

For instance 
const PixelType itk::NumericTraits< PixelType >::Zero;
does not make sense anymore cause you cannot return a PixelType of the
right length.

I would just add an overloaded function to *all* pixel traits that
reads:

const PixelType NumericTraits< PixelType >::Zero( PixelType & );
and
const PixelType NumericTraits< PixelType >::Zero( ImageType * );

> 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.
> 

Feel free to chip in.

Thanks
regards
karthik
> 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
> >
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers