| • yung | |
| Aug 3 2010, 2:29 PM |
| F573: bug4931patch1.patch | |
| Aug 31 2010, 3:43 PM |
Channels seem not to be handled by the mitkPicFileWriter/Reader classes. The implementation of mitkImage seems to reserve the fifth dimension for the usage of channels? But even when channel data is provided, the fifth dimension is not initialized accoringly.
May the solution be to initialize the channels as fifth dimension or was there another intention behind the image concept? CCed the "old" MITK guys for their opinion.
No, this is definitely a bug.
Channels are supposed to hold different information for each voxel, like in RGB data or Doppler ultrasound.
So, they should all be read, not only the 0 one.
Attached is a first patch of our fix:
Main idea: set the channel as 5th dimension of the image. The Initialize() methods of mitkImage has been adapted accordingly. A new method GetImageData() is introduced to make Image::GetPic() work for images with more than 1 channel.
Maybe it's more reasonable to define the 5th dimension only for writing and reading the image as PIC with the PicFileWriter/PicFileReader.
I don't know the exact context of your work, but would generally not use PIC images much. Especially not if there are features missing. Aren't there other file formats which support multi-channel images?
I really often use the NRRD format for such things. It is also supported by the itk-readers and -writers. But I think (!) one intention of the "channel" implementation was to allow for different pixeltypes in the same image. This is probably not allowed in most of the image formats.
By the way: I don't know anybody who uses the channel feature. It would be good to consult Ivo regarding this issue.
(In reply to comment #3)
I don't know the exact context of your work, but would generally not use PIC
images much. Especially not if there are features missing. Aren't there other
file formats which support multi-channel images?
As Time-of-Flight imaging, where we have a corresponding distance, intensity and amplitude image per frame, is the context of the work, the multi-channel approach provided by mitk::Image seemed to be a reasonable way of efficiently storing our pixel data. While trying that we encountered this bug in the core classes of MITK.
Of course we could use other file formats but that would not fix this bug!
Suggestion: just issue a clear warning or error if someone tries to use the PicFileReader with multi-channel images. Please do not try to fix PicFileWriter or Reader code if it is avoidable.
[96da3d]: Merge branch 'bug-4931-MultiChannelPicFileHandling'
2011-12-07 16:42:56 Jan Hering [224550]
Added multiple-channel condition to PicFileWriter
[14a09a]: Merge branch 'bug-4931-MultiChannel-PicFileWriter'
2011-12-08 10:11:05 Jan Hering [35424d]
COMP Fixed filepath creation for PicFileWriterTest