dcmdjpeg unexpected behaivour

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
realvgm
Posts: 2
Joined: Mon, 2022-09-26, 08:45

dcmdjpeg unexpected behaivour

#1 Post by realvgm »

Hi;

We have a DICOM object, and when we try to open it with MicroDicom, the displayed image is not correct.

Is a compressed DICOM with this DICOM elements:
(0002,0010) UI =JPEGLossless:Non-hierarchical-1stOrderPrediction # 22, 1 TransferSyntaxUID
(0028,0100) US 16 # 2, 1 BitsAllocated
(0028,0101) US 16 # 2, 1 BitsStored
(0028,0102) US 15 # 2, 1 HighBit

When we uncompress using the DCMTKs (dcmdjpeg.exe), we get a DICOM object with these DICOM elements:
(0002,0010) UI =LittleEndianExplicit # 20, 1 TransferSyntaxUID
(0028,0100) US 16 # 2, 1 BitsAllocated
(0028,0101) US 12 # 2, 1 BitsStored
(0028,0102) US 11 # 2, 1 HighBit

Then, when we try to open it with MicroDicom, the displayed image is not correct.

We don't understand why "BitsStored" pass from 16 to 12. And that's the point. If we modify the uncompressed DICOM, and edit to put BitsStored=16 and HighBit=15, the image is showed properly with MicroDicom.

We attach the compressed DICOM object, in case someone can help us understand what happens with this object (https://drive.google.com/file/d/139e2Or ... share_link).


Thank you and take care.

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1437
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

Re: dcmdjpeg unexpected behaivour

#2 Post by Marco Eichelberg »

Interesting case. The reason why dcmdjpeg adjusts Bits Stored to 12 is because the JPEG bitstream indicates that it uses 12 bits per pixel:

Code: Select all

        JPEG_SOF_Parameters:
                 SamplePrecision = 12
                 nLines = 1298
                 nSamplesPerLine = 912
                 nComponentsInFrame = 1
                 component 0
                         ComponentIdentifier = 1
                         HorizontalSamplingFactor = 1
                         VerticalSamplingFactor = 1
                         QuantizationTableDestinationSelector = 0
The DICOM standard states (in Part 4, section 8.2.1):
When decompressing, should the characteristics explicitly specified in the compressed data stream (e.g., spatial subsampling or number of components or planar configuration) be inconsistent with those specified in the DICOM Data Elements, those explicitly specified in the compressed data stream should be used to control the decompression.

Accordingly, dcmdjpeg "prefers" the information from the JPEG bitstream and adjusts Bits Stored to 12 and High Bit to 11, the highest possible values for a bitstream with 12 bits/pixel.

The surprising part is that after decompression, the pixel data actually contains pixel values that are larger than possible with 12 bits:

Code: Select all

(7fe0,0010) OW ca7e\ca03\c8fa\c69b\c48d\c4c9\c38f\c1b8\c288\c19a\c079\c043\c2b4... # 2367552, 1 PixelData
In hexadecimal, 12-bit numbers in the format used by dcmdump always start with a zero, values like "ca7e" should not be possible.
So my guess is that the JPEG bitstream in this image has a defective "start of frame" segment indicating 12 bits/pixel when in reality 16 bits/pixel are present. It is rather surprising that the JPEG decoder manages to correctly process this bitstream, but apparently it does.

Unfortunately there is no option in dcmdjpeg that would disable the automatic adjustment of Bits Stored / High Bit. I will add that as a feature request to DCMTK, but cannot say how quickly it might get implemented.

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 1 guest