Lossless jpeg decoding in nema.org DICOM files

Question

I wrote a jpeg compressor / decompressor a few years ago that can process files without loss or loss of jpeg. It works well, but does not always correctly decode jpeg streams in DICOM files.

I know jpeg well, but I know little about DICOM. Lossless jpeg in DICOM cannot conform to jpeg ISO standard. There must be some kind of modification, either hardcoded or changed by a parameter somewhere in the DICOM file outside the jpeg file stream.

My code fails in most DICOM sample files (compsamples_jpeg.tar) at ftp://medical.nema.org/MEDICAL/Dicom/DataSets/WG04/

Here, when I decrypt the first lossless jpeg (IMAGES \ JPLL \ CT1_JPLL) in this set:

decoded image dicom

The left image is rendered from my code, the DICOM online reader is displayed on the right: www (dot) ofoct (dot) com (slash) viewer (slash) dicom-viewer-online (dot) html

(x) MedCon, an open source DICOM reader, fails in the same pixel as my code, so I'm not the only one who has this problem. xmedcon dot sourceforge dot net

I read that byte of jpeg by byte byte, drew a huffman tree and computed the huffman codes with pencil and paper, and my code does exactly what it should do. Here are the Huffman codes:

• 0 00
• 4 01
• 3 100
• 5 101
• 1100
• 2 1101
• 6 1110
• 7 11110
• 8 111110
• 9 1111110
• 12 11111110
• 11 111111110
• 10 1111111110
• 15 11111111110

Here is the compressed data after the SOS marker:

• ff 00 de 0c 00 (00 after ff is a byte)
• 11111111 11011110 00001100 00000000
• 11111111110 si = 15
• 111100000110000 diff = 30768

In online viewing mode, the first pixel value is -3024. If this is correct, the first diff value should be -3024, but it is not.

After that, my code correctly decodes about 2/5 of the image, but then decodes the wildly inaccurate diff value:

• d2 a1 fe ff 00 e0 (00 after ff - byte)

• 1010111 10100001 11111110 11111111 11100000

• 101 si = 5

• 01111 diff = -16
• 01 si = 4
• 0000 diff = -15
• 111111110 si = 11 ????
• 11111111111 diff = 2047

If you look at the image decoded by the online viewer, there is no radical change in pixel intensity in this place, so the value si = 11 cannot be correct.

I'm sure I have a good understanding of jpeg, but jpeg streams in DICOM don't seem to follow the jpeg standard. What extensions / changes are made to jpeg streams when they are embedded in DICOM files?

Answer 1

DICOM defines the use of ISO 10918 in exactly the same way as it is written, so there is nothing surprising in using lossless JPEG in DICOM images, except for questions of reinterpreting the unsigned output of the decoded bit stream as signed (depending on the Pixel Representation) and applying Rescale Slope and Intercept to decoded “stored pixel values” to all “values” that the viewer can communicate (for example, as Hounsfield Units), as described by Paolo. Or, to put it another way, do not rely on the “pixel values” reported by the viewer as the same as the direct output of the decoded bit stream.

For reference, here are the sections in DICOM that address the use of 10918 in general:

http://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_8.2.html#sect_8.2.1 http://dicom.nema.org/medical/dicom/current/output/chtml /part05/sect_A.4.html#sect_A.4.1

DICOM encoders can split individual compressed frames into separate fragments, as is the case with this sample, which intentionally uses fragmentation to verify decoding capabilities. I expect you to know this and have taken care to compile the bitstream through the borders of the fragment (i.e. remove element tags of a fixed length between fragments):

http://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_A.4.html

Although some encoders may be wrong, I don’t think that this is the case for IMAGES \ JPLL \ CT1_JPLL in the NEMA sample dataset that I created many years ago using the Stanford PVRG codec.

My own decoder (minimal as is) at http://www.dclunie.com/pixelmed/software/codec/ has no problem with this. The source is available, so if you want to recompile it with some debugging messages turned on to track each decoded value, the value of the input signal to predict, restart at the beginning of each line, etc., To compare with your own logic, feel free to.

Finally, since lossless JPEG is rarely used outside of DICOM, it may be difficult for you to get other samples for testing. One such source that comes to mind is USM digitized mammography (medical, but not DICOM), at http://marathon.csee.usf.edu/Mammography/Database.html .

David

PS. I checked which XMedCon codec is using at https://sourceforge.net/projects/xmedcon/ and seems to be using some copy of Cornell's lossless code; therefore, it may be vulnerable to the same error described in the message mentioned by BitBank ( https://groups.google.com/forum/#!topic/comp.protocols.dicom/Yl5GkZ8ggOE ) or some other error. I did not try to decrypt the source code to see.

Answer 2

The first pixel value is really -3024, as the dicom online viewer shows:

You correctly decode the first amplitude as 30768, but the first pixel has a predictor set to zero, and therefore its real value is 32768 + 30768 = 63536. This value is unsigned.

Now the pixel presentation tag says that the file values ​​are in the complement b2 (signed), so when we use the most significant bit as a sign, the value becomes -2000.

When we apply the value in the zoom scaling intercept tag (-1024), the value of the first pixel becomes -3024.

However, my codec does not find any 2047 amplitude near line 179, so perhaps your codec is somehow not synchronizing: the loss of synchronization is also visible in the following lines (they are all shifted to the right).