DCMTK

Bug #369
Description
Status: fixed? probably better not to(2010-11-02)
Michi's work on the new lossless encoder

The YCbCr pictures cabinf69.dio and cabinf75.dio are especially surprising, with a Pixel Representation of 0. Turning off colorspace conversion while decompressing nevertheless still yields the correct picture. Perhaps they are both 16bit YCbCr images that function as 8bit images.

==== JR's Comment ====

The problem doesn't seem (directly) to be related with 'BitsAllocated=16', rather with 'BitsStored=13'. A 16/16bit image in particular would also be decompressed successfully in "True Lossless" mode with default options (example: 'cabinet/cabinf97.dcm').

Images with 'BitsStored=12' (and 'BitsAllocated=16') don't work at the moment, for instance 'cabinet/cabinf98.dcm'. Decoding results in 'precision=16'!?

==== Supplement JR ====

The problem seems to be in 'ycc_rgb_convert()', for instance when calculating 'range_limit[]' and 'Cxxtab[]'. The latter produces values which are outside the permitted range (0..8191 at 13bits). As a result in the above condition you will get a green image (R and B 0). When 'BitsStored=16' is set, the image is basically there, but it's still green! :-)

The input values 'y', 'cb' and 'cr' seem to at least work (their values are as expected). Put these into the resulting image and change the colour model in the DICOM-image from "RGB" to "YBR_FULL" and the result is also correct (this corresponds to the behaviour of EDC_never)

Possible workaround: when 'BitsStored < BitsAllocated' and 'isYBR == OFTrue' use the colourspace conversion 'EDC_never' (basically don't use colourspace conversion) and output a warning to the logger. Not a perfect solution but it's better than outputting something clearly wrong.

Current "solution": a warnung is emitted and additionally a tip in Debug-Mode on how to work around the defective colourspace conversion. See Commit.

Note: When this bug is closed, the corresponding integration test case "dcmjpeg_regression_decode_color_space_conversion" should also be adapted.