|
Notes |
|
|
(0015668)
|
|
Bradley Lowekamp
|
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
|
|
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
|
|
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
|
|
2009-03-27 11:07
|
|
|
|
|
(0015898)
|
|
Bradley Lowekamp
|
|
2009-04-03 10:34
|
|
|
Changes resolve the problem |
|