RLE on RGB not supported?

[tclune]

I have completed a set of file conversions using dcmtk. Starting from palettized color or RLE-encoded palettized color, we convert to any of the following: baseline JPEG, uncompressed RGB or palettized color, or RLE RGB or palettized color. The only conversion that fails is going to RGB RLE. I have tried unpacking the palettized color to triplets and to planar color, and neither works with RLE. When I try to choose the RLE lossless DcmXfer syntax for the dataset's representation, canWriteXfer() returns false. The RGB data, output as explicit little-endian data seems to be correct in all particulars and appears to have all the required tags filled out properly. There is no problem displaying the data on any of a variety of viewers. Is it possible that RGB RLE is not supported in the toolkit? If it is supported, is there something that comes to mind on why this might be failing for me? TIA.

[Marco Eichelberg]

Have you correctly registered the RLE codecs in your application?
See declarations of DcmRLEEncoderRegistration::registerCodecs() and DcmRLEDecoderRegistration::registerCodecs() in module dcmdata.

[tclune]

It's the same registration as for the palette color images, which have no problem getting rle compressed. Even more confusing to me, if I just output the palettized-to-rgb image as an explicit little-endian file, and then feed that into dcmcrle.exe, it will convert without problem. I presume that I can take that as evidence that I have done the intermediate conversion from palettized to rgb data properly. But, if I just try to output the modified DcmDataset data directly without creating an intermediate file, I get the failure in the canWriteXfer() call.

[tclune]

Found it! I was following an example program (diquant.cxx) in the way that I created the pixel data element. That example uses DcmPolymorphOBOW as the class to create, with the argument DCM_PixelData. This is WRONG!!! If you do this, and then call canWriteXfer(), it uses the wrong canWriteXfer() method. You need to use the DcmPixelData class' method for that. So you need to new a DcmPixelData instance in order to have the right method.

[Marco Eichelberg]

Yes, that explains the problem. The quantization code in diquant.cc predates class DcmPixelData (which is actually derived from DcmPolymorphOBOW and adds extra code needed for managing compressed transfer syntaxes). Since the quantization code only ever works on uncompressed images, this is fine, but for your case you indeed need class DcmPixelData.