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.
dcmdjpeg unexpected behaivour
Moderator: Moderator Team
-
- OFFIS DICOM Team
- Posts: 1444
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
Re: dcmdjpeg unexpected behaivour
Interesting case. The reason why dcmdjpeg adjusts Bits Stored to 12 is because the JPEG bitstream indicates that it uses 12 bits per pixel:
The DICOM standard states (in Part 4, section 8.2.1):
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:
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.
Code: Select all
JPEG_SOF_Parameters:
SamplePrecision = 12
nLines = 1298
nSamplesPerLine = 912
nComponentsInFrame = 1
component 0
ComponentIdentifier = 1
HorizontalSamplingFactor = 1
VerticalSamplingFactor = 1
QuantizationTableDestinationSelector = 0
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
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.
Who is online
Users browsing this forum: Baidu [Spider], Bing [Bot], Google [Bot] and 1 guest