[Insight-developers] MetaIO and vector images

Tue Mar 17 13:14:05 EDT 2009

Cool thing is that MetaIO code is shared between ITK and VTK.   There
is a single common repository and any change made there is
automatically spread to ITK and VTK.

So, compatibility between ITK and VTK should no longer be an issue.

Thanks,
Stephen

On Tue, Mar 17, 2009 at 12:40 PM, Karthik Krishnan
<karthik.krishnan at kitware.com> wrote:
> In case any change is made, I would also request that one verifies that a
> vtkMetaImageReader can read the metaimages written by ITK and vice-versa.
>
> A lot of people including us take these formats between applications based
> on the two toolkits and .VTK and .MHD are the two file-formats that enable
> that interchange.
>
> Thanks
> --
> karthik
>
> 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.
>> 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
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ITK FAQ at:
>> http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>
>

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