[Insight-developers] MetaIO and vector images

Tue Mar 17 14:36:30 EDT 2009

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;

If in the file the ElementType is changed to MET_FLOAT_ARRAY then when  
MetaImageIO read the file it sets it's self with the following:
NumberOfComponents = 3;
PixelType = ImageIOBase::VECTOR;
ComponentType = float;

This behavior is what I expected from the beginning. I am not sure how  
the MET_*_ARRAY should be used. Reading the MetaIO wiki documentation   
does not elaborate on this issue. Could you please explain how it  
should be used in an image? Is it's uses for images depreciated/ 
undesirable?

On Mar 17, 2009, at 1:12 PM, Stephen Aylward wrote:
>
> 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."

ITK's ImageIO does not define "element type" so I am uncertain what  
you are referring to. Hopefully the above has clearly illustrated by  
perspective.

>
> PixelType != ElementType

Should the MetaIO''s ElementType be the just ImageIO's ComponentType  
then?

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

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090317/d5112aec/attachment.htm>