[Insight-developers] MetaIO and vector images

Tue Mar 17 13:20:37 EDT 2009

Thanks Stephen.

I was just making sure since Brad explicitly states that this is "a change
to itkMetaImageIO class, and not the library".

Thanks
--
karthik

On Tue, Mar 17, 2009 at 1:14 PM, Stephen Aylward <
Stephen.Aylward at kitware.com> wrote:

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