[Insight-developers] MetaIO and vector images

[Bradley Lowekamp]

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.

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.



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


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