[Insight-developers] MetaIO and vector images

Tue Mar 17 13:12:42 EDT 2009

On Tue, Mar 17, 2009 at 12:26 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> These changes are not arbitrary, nor are they not sufficiently motivated. I
> had two scenarios  where this caused me problems:
> I have a little program frame work which uses runtime information
> to determine type information. It simply calls
> ImageFileReader->GenerateOutputInformation() and then looks at the
> NumberOfComponents, PixelType, and ComponentType to determine the best pixel
> type to use. Many other file formats set the PixelType appropriately, yet
> for MetaIO I must ignore it's pixel type, and check the NumberOfComponents
> instead. The behavior and meaning of this pixel information should perhaps
> be better defined, but I see multi-component scalars as a non-sensical bug.

That is your opinion.  I consider a "vector of floats" to have an
element type of "float" and not to have an element type of "vector of
floats."

> Secondly, there is a problem with the streaming/pasting code, which I wrote,
> and it was based on certain assumptions about the
> pixel descriptor variables. Before pasting beings, it verifies that the
> pixels in the file are of the same type as the what is to be written along
> with other meta data. To verify the type, it compares NumberOfComponents,
> PixelType, and ComponentType. As proposed in the bug report #3 will fix
> this. But simply removing the PixelType illustrates the bug in MetaIO.
> Stating the problem another, there does not exist any multi-component pixel
> type  which writing will have the same  NumberOfComponents, PixelType, and
> ComponentType information when read back.

PixelType != ElementType

Are suggesting that sometimes you want to create a vector of floats
and other times you want to create an array of floats?   We could add
a new variable for that.   Its absence would default to the current
behavior of vector of floats.

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.

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