dcmcjpeg crashes when loadAllDataIntoMemory is called

[popu]

Issue is on
OFCondition DcmPixelData::loadAllDataIntoMemory(void)
{
if (current == repListEnd)
return DcmElement::loadAllDataIntoMemory();
else
return (*current)->pixSeq->loadAllDataIntoMemory();
}

as it looks like (*current)->pixSeq is NULL. Any suggestions? I'm having this issue with one image type only, YBR uncompressed ...
Thx

[popu]

Debugging project, issue could be related to the fact that image has multiple pixel data tags present, one pixel data containing actual pixel data while the other is part of a private tag sequence, looks like a smaller version of current image, like a preview, this private sequence + pixel data it contains could be the problem ...

[Jörg Riesmeier]

Could you please send an anonymized version of this DICOM image to dicom/at/offis/dot/de. Thanks.

[popu]

Could you please send an anonymized version of this DICOM image to dicom/at/offis/dot/de. Thanks.

Image is a US, so is a little hard to anonymize as screen contains patient name; anyway in order to anonymize other data from file, is there anything I could use in dcmtk for this?
thx

[Jörg Riesmeier]

You could e.g. use dcmodify (for the header data).

[popu]

You could e.g. use dcmodify (for the header data).

Image sent, e-mail subject "dcmcjpeg crashes when loadAllDataIntoMemory is called". I had to change pixel data, first 200 rows from 640x480 as those lines had some patient / md information
thx

[popu]

Private tag data looks to be a thumbnail, containing jpeg stream ... dicom file is uncompressed, so this could be the problem, compressed & uncompressed put toghether in same dicom file... private tag I'm talking about is 9,1110

[Marco Eichelberg]

The crash is caused by the icon image in private sequence (0009,1110) (private creator is "GEIIS"). The DICOM file is encoded in an uncompressed transfer syntax, but the pixel data within that private sequence seem to contain JPEG compressed data, which violates DICOM encoding rules. If one encodes (7fe0,0010), one has to comply with DICOM transfer syntax rules even if that is within a private sequence.

The current DCMTK snapshot does not crash, but complains about insufficient data and refuses to compress the image, which is the right thing to do here - if we would compress the image, then the icon might end up using a different encoding (transfer syntax) than the main dataset, which would more than confuse most readers.

[popu]

The crash is caused by the icon image in private sequence (0009,1110) (private creator is "GEIIS"). The DICOM file is encoded in an uncompressed transfer syntax, but the pixel data within that private sequence seem to contain JPEG compressed data, which violates DICOM encoding rules. If one encodes (7fe0,0010), one has to comply with DICOM transfer syntax rules even if that is within a private sequence.

The current DCMTK snapshot does not crash, but complains about insufficient data and refuses to compress the image, which is the right thing to do here - if we would compress the image, then the icon might end up using a different encoding (transfer syntax) than the main dataset, which would more than confuse most readers.

Thx for your feedback, there are lots of implementations for DICOM each and everyone is doing own way, don't know why people don't respect the "standard" word. What do you think would be the best way for getting over this, just remove private sequence as it doesn't respect the standard anyway...?

[popu]

The crash is caused by the icon image in private sequence (0009,1110) (private creator is "GEIIS"). The DICOM file is encoded in an uncompressed transfer syntax, but the pixel data within that private sequence seem to contain JPEG compressed data, which violates DICOM encoding rules. If one encodes (7fe0,0010), one has to comply with DICOM transfer syntax rules even if that is within a private sequence.

The current DCMTK snapshot does not crash, but complains about insufficient data and refuses to compress the image, which is the right thing to do here - if we would compress the image, then the icon might end up using a different encoding (transfer syntax) than the main dataset, which would more than confuse most readers.

Marco would you point out what I have to change in version dcmtk-3.5.4 in order to avoid crash while calling loadAllDataIntoMemory? I have version 3.5.4, working in windows and is a little hard to look for differences between what I have and snapshot you said has the fix.
Thx

[Marco Eichelberg]

No, I cannot say. There have been hundreds of modifications since 3.5.4 release and I have not really checked which one fixes this particular problem.

[Per]

If you do find the fix, or make one yourself, please let the rest of us know. There are actually people out there who have to run the stable release