[Insight-users] MetaImageIO and vector fields: GetPixelType small bug?

[Tom Vercauteren]

Hi Stephen,

This indeed makes sense.

What could maybe be improved is how the MetaImageIO writes an image.

>From what I understand of the "Write" function, it never writes data
in an array form
( such as MET_SHORT_ARRAY) but always write a multi-channel MetaImage.

We could thus do something like keep this behavior and add a field to
the header of the MetaImage that specifies the pixel type. If the
reader finds this tag, the correct PixelType is returned by the
"GetPixelType" function and otherwise we fallback to the current
behavior. As I understand it, the "GetPixelType" does not force the
pixel type that a user will use but rather gives him a hint of the
pixel type that should be used.

An alternative would be to write vector pixel images using
MET_**_ARRAYs. This second solution makes it difficult to
differentiate between vectors and covariant vectors though...

Tom

On 3/5/07, Stephen R. Aylward <Stephen.Aylward at kitware.com> wrote:
> Hi Tom,
>
> I debated this issue for quite some time, and decided to go with the
> convention that (to me) was closest to what ITK was already doing.
>
> If the image has multiple variates per pixel, it is considered to be a
> multi-channel image, and the element type is the type of each variate.
> In that manner, we can have an RGB image of chars or an RGB image of
> floats as well as a multi-channel image of vectors.   Declaring
> something as multi-channel and the pixel type as vectors defined, in my
> opinion, a multi-channel image in which each channel contains a vector.
>   I'd rather not have redundant information and allow for a more
> flexible design.
>
> In the ideal world, I should determine if a given pixel type is
> representing independent variates or a mathematical vector and from
> there switch between a multi-channel of scalars or a vector pixel
> representation.   However, I am not certain that I would want to enforce
> such typing - sometimes an RGB image considers the channels
> independently and sometimes as a colorspace vector.
>
> I am open to (backward compatible) suggestions for alternatives.
> However, I do believe that multi-channel should not require a vector
> pixel type.
>
> Thanks,
> Stephen
>
> Tom Vercauteren wrote:
> > Hi all,
> >
> > I think I found a small bug in MetaImageIO (ITK 3.0.1).
> >
> > I have an mha file with the following header:
> > ObjectType = Image
> > NDims = 3
> > BinaryData = True
> > BinaryDataByteOrderMSB = False
> > CompressedData = False
> > TransformMatrix = -1 0 0 0 -1 0 0 0 1
> > Offset = 127.75 145.75 -72.25
> > CenterOfRotation = 0 0 0
> > AnatomicalOrientation = RPI
> > ElementSpacing = 1 1 1
> > DimSize = 256 256 181
> > ElementNumberOfChannels = 3
> > ElementType = MET_FLOAT
> > ElementDataFile = LOCAL
> >
> > I create an image IO using ImageIOFactory::CreateImageIO and then
> > check the pixel type. As expected I see that GetNumberOfComponents
> > returns 3 but I also get:
> > imageIO->GetPixelType() == itk::ImageIOBase::SCALAR
> >
> > I thought I would get  itk::ImageIOBase::VECTOR or
> > itk::ImageIOBase::COVARIANTVECTOR.
> >
> > Should I file a bug for that or am I missing something here?
> >
> > Best regards,
> > Tom Vercauteren
> > _______________________________________________
> > Insight-users mailing list
> > Insight-users at itk.org
> > http://www.itk.org/mailman/listinfo/insight-users
> >
>
> --
> =============================================================
> Stephen R. Aylward, Ph.D.
> Chief Medical Scientist
> Kitware, Inc. - Chapel Hill Office
> http://www.kitware.com
> Phone: (518)371-3971 x300
>