[Insight-developers] MetaIO and vector images

Tue Mar 17 16:33:39 EDT 2009

Cool.

Nice example.

On Tue, Mar 17, 2009 at 2:36 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Restating the problem again: itkImageIOBase describes pixels with the
> NumberOfComponents, PixelType, and ComponentType variables, where as
> MetaImage uses NumberOfChannels and ElementType. What is in question is the
> mapping between the two, and the lack of symmetry in this mapping where
> there should be.
> Consider the writing of an image of type Image< Vector< float, 3> >. The
> ImageIOBase::SetPixelType will configure MetaImage pixel information with
> the following:
> SetNumberOfComponents(3);
> SetPixelType(ImageIOBase::VECTOR);
> SetComponentType(float);
> Then MetaImageIO will configure the MetaIO library to write a header
> containing the following:
> NumberOfChannels = 3
> ElementType = MET_FLOAT
> Now if we try to read the file MetaImageIO will configure it's self with the
> following:
> NumberOfComponents = 3;
> PixelType = ImageIOBase::SCALAR;
> ComponentType = float;

Agreed - the way it is interpreted by ITK is wrong.   The PixelType
set internal to ITK should be VECTOR, not scalar.    I mistakenly
thought you were suggesting that the way it was being written was
wrong and should be changed to write the file as MET_FLOAT_ARRAY.
Sorry - my mistake.

> Adding a new variable to the file format to explicitly specify the PixelType
> (Vector, FixedArray, RGB, RGBA, Offset, Matrix) would be very useful! It
> could perhaps even make the writing an injective or one-to-one operation,
> there by not loosing any pixel information in the process.

I think this would be useful.   Always wanted to do this.   It is
backward compatible.   Almost like a suggestion of how the image
should be read.   Would make distinguishing RGB vs generic
multi-valued images easier to deal with.

The idea behind MET_*_ARRAY, btw, was to allow arrays (and MET*MATRIX)
as elements.  This is implemented when a single tag can be assigned
multiple values (e.g., DimSize) - compare this with scalar tags (e.g.,
NDims).    That is, DimSize is MET_UINT_ARRAY while NDims is MET_UINT.
     That is, a MET_*_ARRAY and a MET_*_MATRIX, like all MET_*, should
describe what is reference via a tag.    We have a metaArray class
that derives from metaForm.   We also have (in a private stash) a
metaMatrix class that also derives from metaForm.      When trying to
come up with a consistent view of a Form, Matrix, Array, and
multi-channel image, we decided that a channel was the "tag" level of
an image.    metaMatrix, Array, and Form do adhere to this concept.
I fear that we never completed refactoring the image to support this
concept.  The fault is actually that we never provided a method for
writing images with vectors of vectors at their pixels.   So, an image
of element type MET_*_ARRAY (or MET_*_MATRIX) should never be created.

I hope this helps,
s

>
>
> Changing the meaning of
>
> NumberOfChannels = 3
> ElementType = MET_CHAR
>
> is really not feasible.   This has meant and always will mean a vector
> of chars of length 3.    This is how we must read it.   This is how we
> must write it.   Doing otherwise will break the wrath of the people
> who have been using this format for over a decade.
>
>
> But currently it is being interpreted by MetaImageIO as a SCALAR of 3
> floats, as illustrated above. I expected it to be interpreted to ImageIO as
> perhaps VECTOR of 3 floats.
> As Karthilk pointed out, I am not proposing any changes to the MetaIO
> library just itkMetaImageIO. As for compatibility VTK treats META_FLOAT and
> META_FLOAT_ARRAY as the same thing. So again I am unclear about the
> difference of these two MetaIO defined element types and their usage.
>
> s
>
> s
>
>
>
> On Mar 17, 2009, at 10:32 AM, Stephen Aylward wrote:
>
> Please do not make that change.
>
> You are making an arbitrary change that is not motivated by need and
>
> that breaks backward compatibility.
>
> In your bug report you write:
>
> --- snip ---
>
> ElementNumberOfChannels = 3
>
> ElementType = MET_UCHAR
>
> When this is read, MetaIO interprets the file with a pixel type of
>
> scalar and number of components of 3. This seems like an odd
>
> ambiguity.
>
> --- snip ---
>
> This in no way seems odd or ambiguous.  What you are suggesting is
>
> ambiguous because the same notion will be repeated twice in the data -
>
> a user will have to change the number of channels and the element type
>
> to indicate an array.   The current solution indicates an array by
>
> simply changing the number of elements.   Having a single method for
>
> indicating an array reduces the chance on inconsistencies developing.
>
> A single method is good, make since. But currently in the ImageIO, there
>
> is redundancy in the 3 variables which describe the pixel and a
>
> multi-component scalar does not make sense! The ImageIOBase::SetPixelType,
>
> does not use this combination either. If the PixelType is not known then
>
> there is the unkown type.
>
> Additionally, your change is not consistent with the notion of
>
> elementType - you are mixing the concept of element type with pixel
>
> type.   They are not the same.
>
> You are right I don't fully understand the interpretation of elementType in
>
> the MetaIO file format. But it is the translation of MetaIO pixel
>
> information to ITK pixel information that I think needs to be addressed
>
> because it is buggy.
>
>
> Additionally, your suggestion eliminates the possibility of storing a
>
> multi-channel file with vector data in each channel.
>
> Is itkMetaImageIO currently capable of writing or reading this? This
>
> actually further confuses me  on the meaning of element type. I simply
>
> changed the ElementType to MET_UCHAR_ARRAY, and it read and identified it as
>
> a vector pixel type. This lead me to the conclusion it should have been
>
> written as such.
>
>
> The current implementation is more general.
>
> Additionally, you are breaking breaking backward compatibility...the
>
> change you are suggesting is going to produce images that cannot be
>
> read by programs compiled with previous versions of the library.
>
> No, they can be read. Currently MetaImageIO::ReadInformation switches on
>
> both MET_* and MET_*_ARRAY, and if it is an array element type, then it
>
> set's it to a vector pixel type. Also itkImageFileReader currently ignores
>
> the PixelType when reading, because ImageFileReader is template over the
>
> pixel type.
>
> I have implemented #1 and #3 from the Bug report and all test pass in ITK.
>
> Thanks,
>
> Brad
>
>
>
> Why do you want to do this?
>
> s
>
> On Tue, Mar 17, 2009 at 10:11 AM, Bradley Lowekamp
>
> <blowekamp at mail.nih.gov> wrote:
>
> Hello,
>
> This is in regards to the following bug I encountered:
>
> http://www.itk.org/Bug/view.php?id=8732
>
> Does anyone see any problems with changing MetaIO so that when it writes
>
> multi components  pixel types, that it writes them an array type ie
>
> ElementType = META_UCHAR_ARRAY. This is just a change to itkMetaImageIO
>
> class, and not the library.
>
> I am also still trying to figure out what it mean's to be a scalar pixel
>
> type, with multiple components. This is how the reader would currently
>
> report written vector images.
>
> Brad
>
> ========================================================
>
> Bradley Lowekamp
>
> Lockheed Martin Contractor for
>
> Office of High Performance Computing and Communications
>
> National Library of Medicine
>
> blowekamp at mail.nih.gov
>
>
>
>
>
> --
>
> Stephen R. Aylward, Ph.D.
>
> Chief Medical Scientist
>
> Kitware, Inc. - North Carolina Office
>
> http://www.kitware.com
>
> (518) 371-3971 x300
>
> ========================================================
>
> Bradley Lowekamp
>
> Lockheed Martin Contractor for
>
> Office of High Performance Computing and Communications
>
> National Library of Medicine
>
> blowekamp at mail.nih.gov
>
>
>
>
>
> --
> Stephen R. Aylward, Ph.D.
> Chief Medical Scientist
> Kitware, Inc. - North Carolina Office
> http://www.kitware.com
> (518) 371-3971 x300
>
> ========================================================
>
> Bradley Lowekamp
>
> Lockheed Martin Contractor for
>
> Office of High Performance Computing and Communications
>
> National Library of Medicine
>
> blowekamp at mail.nih.gov
>
>

-- 
Stephen R. Aylward, Ph.D.
Chief Medical Scientist
Kitware, Inc. - North Carolina Office
http://www.kitware.com
(518) 371-3971 x300