View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008732ITKpublic2009-03-12 10:122009-11-12 10:43
ReporterBradley Lowekamp 
Assigned ToBradley Lowekamp 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in VersionITK-3-14 
Summary0008732: MetaIO writes all multicomponent types as scalars types
DescriptionIn MetaImageIO::Write method the component type can never be set to an ARRAY type. For example if one writes an image with Vector<unsigned char, 3> pixel type. It will be written with:

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.

This is problematic in two cases I have encountered:

1) When the runtime information from MetaImageIO is used to determine the best pixel type to use at runtime.

2) When pasting the pixel type is checked, and this inconsistency, generates an exception


TagsNo tags attached.
Resolution Date
Sprint
Sprint Status
Attached Files

 Relationships

  Notes
(0015668)
Bradley Lowekamp (developer)
2009-03-12 10:42
edited on: 2009-03-17 12:15

 I see three partial solutions to the problem.

1) Modify MetaImageIO::Write to set the appropriate array element type when there are multiple components.

2) Modify MetaImageIO::Read to interpret any multi-components as a vector

3) Modify MetaImageIO::GetActualNumberOfSplitsForWriting to only check NumberOfComponents and Component type, and NOT check PixelType.

I think that # 2 and # 3 should be done.
ERROR: I really intended to say #1 and 0000003
(0015713)
Stephen Aylward (developer)
2009-03-17 10:35

 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.

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.

Additionally, your suggestion eliminates the possibility of storing a
multi-channel file with vector data in each channel.

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.

Make the change to the tests for pixel type - don't consider element type to be pixel type - consider number of channels and element type to define the pixel type. Yes, every multi-channel image should be an image of vectors. Furthermore, if elementtype is set to an _ARRAY then the image is an image of vectors of vectors.

s
(0015736)
Bradley Lowekamp (developer)
2009-03-19 14:16

 From the developers list:


On Tue, Mar 17, 2009 at 2:36 PM, Bradley Lowekamp wrote:
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;


On Mar 17, 2009, at 4:33 PM, Stephen Aylward wrote:
Agreed - the way it is interpreted by ITK is wrong. The PixelType
set internal to ITK should be VECTOR, not scalar. I mistakenly
thought you were suggesting that the way it was being written was
wrong and should be changed to write the file as MET_FLOAT_ARRAY.
Sorry - my mistake.
(0015811)
Bradley Lowekamp (developer)
2009-03-27 11:07

 Options 2 and 3 were implemented.

Committed fix:
http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/IO/itkMetaImageIO.cxx.diff?cvsroot=Insight&r1=1.94&r2=1.95 [^]

Committed test:
http://public.kitware.com/cgi-bin/viewcvs.cgi/Testing/Code/IO/itkVectorImageReadWriteTest.cxx.diff?cvsroot=Insight&r1=1.3&r2=1.4 [^]
(0015898)
Bradley Lowekamp (developer)
2009-04-03 10:34

 Changes resolve the problem

 Issue History
Date Modified Username Field Change
2009-03-12 10:12 Bradley Lowekamp New Issue
2009-03-12 10:42 Bradley Lowekamp Note Added: 0015668
2009-03-12 10:42 Bradley Lowekamp Note Edited: 0015668
2009-03-17 10:18 Bradley Lowekamp Note Edited: 0015668
2009-03-17 10:35 Stephen Aylward Note Added: 0015713
2009-03-17 12:15 Bradley Lowekamp Note Edited: 0015668
2009-03-18 09:39 Bradley Lowekamp Status new => assigned
2009-03-18 09:39 Bradley Lowekamp Assigned To => Bradley Lowekamp
2009-03-19 14:16 Bradley Lowekamp Note Added: 0015736
2009-03-19 14:16 Bradley Lowekamp Status assigned => confirmed
2009-03-27 11:07 Bradley Lowekamp Note Added: 0015811
2009-04-03 10:34 Bradley Lowekamp Note Added: 0015898
2009-04-03 10:34 Bradley Lowekamp Status confirmed => resolved
2009-04-03 10:34 Bradley Lowekamp Resolution open => fixed
2009-11-12 10:43 Bradley Lowekamp Status resolved => closed
2009-11-12 10:43 Bradley Lowekamp Fixed in Version => ITK-3-14

Copyright © 2000 - 2018 MantisBT Team