[Insight-developers] MetaIO and vector images

Tue Mar 17 12:40:40 EDT 2009

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090317/cd9b4654/attachment.htm>