[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