DCMTK

When loading a compressed DICOM image file that contains an Icon Image Sequence with uncompressed pixel data (which is permitted in DICOM), such a dataset can be decompressed successfully with DCMTK, it can also be re-compressed to a different transfer syntax, but saving the file will then fail, as demonstrated by the following code snippet:

OFCondition cond;
DcmFileFormat dfile;

// load a compressed DICOM image file containing uncompressed icon image sequence
cond = dfile.loadFile("sample.dcm");
DcmDataset *dset = dfile.getDataset();

// decompress the compressed image, will succeed
cond = pDataset->chooseRepresentation(EXS_LittleEndianExplicit, NULL);

// compress the now uncompressed image to a different encoding, will succeed
DJ_RPLossy rp_lossy(75);
cond = pDataset->chooseRepresentation(EXS_JPEGProcess1, &rp_lossy);

// try to save the file. This will fail with return code EC_RepresentationNotFound
cond = dcmFileFormat.saveFile("output.dcm", EXS_JPEGProcess1);

A sample image is provided below. The cause of this bug is an inconsistent handling of the alwaysUnencapsulated flag in class DcmPixelData, which is ignored in DcmPixelData::chooseRepresentation() but observed in DcmPixelData::write(). This causes the icon image to be compressed despite the alwaysUnencapsulated flag being set, and the uncompressed pixel data to be deleted. When the file is saved, the write routine fails to access the uncompressed pixel data and returns the error.

The inconsistency has probably been present since initial implementation, but has become visible after commit #0e8fae86c, which fixed DCMTK issue #845.

Thanks to Carlo Pastorino for the bug report and proof of concept, reported 2026-05-08.