Itk: Add pixel type support to GDCMImageIO

[zivy]

Not sure if this is a bug or feature request. I am trying to read a segmentation file, liver.dcm, available from the dcmqi repo. This throws an exception with error message of "Unhandled PixelFormat". GDCM itself is able to successfully read this file.

@fedorov, @pieper,
Any input with respect to reading a DICOM stored segmentation as an ITK label image appreciated. I am aware that it is possible that a voxel has multiple labels or fractional values and that the segmentation file may not have the same spatial sampling or extent as the referenced image.

I am thinking of the simplified situation where each voxel has a single label and the spacing/size are encoded in the DICOM segmentation file. Should ITK be able to directly read such a multi-label segmentation, as if it were reading an image?

[fedorov]

@zivy you mentioned dcmqi, so I assume you are familiar with how it works - it generates a separate ITK image for each label contained in the DICOM SEG, where the geometry of each of the images is fully defined by the DICOM SEG. Would it be possible for the ITK reader to return an array of images, in a similar way?

I am thinking of the simplified situation where each voxel has a single label and the spacing/size are encoded in the DICOM segmentation file. Should ITK be able to directly read such a multi-label segmentation, as if it were reading an image?

Yes, I think this would be practical, and better than throwing the error, and it is indeed the case that most segmentations do not have overlapping segments. But it will remain the case that overlapping segments situation would need to be detected.

IMHO no matter what is the initial implementation, it would be good to plan it in such a way that does not preclude support for overlapping segments in the future.

[pieper]

It would be great to have ITK support dicom SEG natively. It shouldn't be too difficult, especially if you use dcmtk and then use dcmqi as a dependency.

[zivy]

@fedorov,

Thanks for the input. What I want to do is read a segmentation the same way as reading an image, returning multiple images would break the ImageIO framework. To make it compatible with image reading I would propose that it return a multi-channel (vector pixel) image, where each channel corresponds to a label.

[issakomi]

SINGLEBIT pixel type was recently added to GDCMImageIO, please try master,
s. https://github.com/InsightSoftwareConsortium/ITK/pull/2010

[issakomi]

Please note that GDCMImageIO doesn't check geometry of multi-frame images, it reads shared group and 1st frame of per-frame group, so it works if frames have same orientation, are equidistant and correctly sorted. But it is applicable to all multi-frame images, not to above PR. It were not so difficult to add such checks and to give a warning, not sure such PR were welcome.

[fedorov]

What I want to do is read a segmentation the same way as reading an image, returning multiple images would break the ImageIO framework.

And I assume it would not be feasible to have a multi-step read process, where you first get the number of segments, and then request read of a single segment at a time?

I would propose that it return a multi-channel (vector pixel) image, where each channel corresponds to a label

This will probably work, but can be very inefficient in some cases, since your vector image would need to span the bounding box of all segments included.

[zivy]

@fedorov,
You're right with respect to the inefficiency of a vector pixel type, wasn't thinking it through. It should probably return a LabelMap image which is designed for efficient storage of labels.

[dzenanz]

@zivy itk::ImageFileReader returns the kind of image with which it was instantiated (the template parameter). And user controls that.

[blowekamp]

itk::ImageFileReader returns the kind of image with which it was instantiated (the template parameter). And user controls that.

The ImageFileReader does not support LabelMaps as a type, and there is no support for RLE encoded buffers in the ImageIO classes as far as I know. There is the RLEImage remote module, that is relevant here, but I don't have experience with.

There may be a need for an new/alternative/modified ImageFileReader class which presents the a list of Images in a file. Perhaps after UpdateOutputInformation is called. And allows the selection of one of them ( perhaps defaulting to the first ).

Relevant here is also file formats which store multi-resolution/pyramid images. There has not been a good way to select which resolution of image is loaded with the ITK interface. Some formats (like TIFF) readily support multiple image in the file, sometimes for a thumbnails too.

[dzenanz]

RLEImage works only if it is being accessed via iterators and GetPixel/SetPixel. There is no GetBufferPointer which readers are probably using.

[fedorov]

there is no support for RLE encoded buffers

Why is this important?