image looks black after converting to jpeg2klossy format

[Ricky Yang]

Hello,

@ J. Riesmeier

I want to use dcmcjp2k to convert DICOM file from
1.2.840.10008.5.1.4.1.1.1 -> 1.2.840.10008.1.2.4.91

After running the following command, the 1.lossy does not look good, it looks whole image is black. Can you figure out why? Could you provide me your email address so I can send the 1_uncompressed.dcm to you so you can verify the issue? Thank you!

1_uncompressed.dcm 9813KB
1_lossy.dcm 3KB


-> dcmcjp2k --version
$dcmtk: dcmcjp2k_e v3.6.2 2017-07-14 $

-> dcmcjp2k -v --encode-lossy --uid-never 1_uncompressed.dcm 1_lossy.dcm
I: --DCMJP2K: $dcmtk: dcmcjp2k_e v3.6.2 2017-07-14 $
I: --Copyright (C)2004-2011, OFFIS e.V.
I:
I: reading input file 1_uncompressed.dcm
I: Convert DICOM file to compressed transfer syntax
I: Output transfer syntax JPEG 2000 (Lossless or Lossy) can be written
I: creating output file 1_lossy.dcm
I: conversion successful

[Marco Eichelberg]

Actually, after compression, the image should appear completely white, since the color model is MONOCHROME1 and the pixel data, after decompression, consists of zeroes.
The problem is caused by the ModalityLUTSequence attribute in the original image, which contains incorrect values. Here's the relevant part of dcmdump's output:

Code: Select all

(0028,0100) US 16                                       #   2, 1 BitsAllocated
(0028,0101) US 10                                       #   2, 1 BitsStored
(0028,0102) US 9                                        #   2, 1 HighBit
(0028,0103) US 0                                        #   2, 1 PixelRepresentation
(0028,2110) CS [00]                                     #   2, 1 LossyImageCompression
(0028,3000) SQ (Sequence with explicit length #=1)      # 5828, 1 ModalityLUTSequence
  (fffe,e000) na (Item with explicit length #=5)          # 5820, 1 Item
    (0028,0000) UL 5808                                     #   4, 1 GenericGroupLength
    (0028,3002) US 2881\65296\16                            #   6, 3 LUTDescriptor
    (0028,3003) LO [CRTLUT]                                 #   6, 1 LUTExplanation
    (0028,3004) LO [OD]                                     #   2, 1 ModalityLUTType
    (0028,3006) US 0\0\1\1\1\2\2\2\3\3\4\4\4\5\5\5\6\6\6\7\7\7\8\8\9\9\9\10\10\10\11... # 5762,2881 LUTData
  (fffe,e00d) na (ItemDelimitationItem for re-encoding)   #   0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) #   0, 0 SequenceDelimitationItem

The image has BitsStored=10, which means that raw pixel values are in the range 0..1023. The Modality LUT Sequence then defines a look-up table that should be applied to these raw values. Since a look-up table may contain "jumps", it must be applied before we apply lossy compression. According to the LUT descriptor, the table has 2881 entries (which makes absolutely no sense since we can only have 1024 different raw pixel values), and the all raw values that are less or equal to 65296 should be mapped to the first LUT entry, which has a value of 0. Effectively that means that all pixel values are mapped to zero, and that causes the completely blank image. If you simply remove the Modality LUT Sequence (dcmodify -e ModalityLUTSequence <filename>), you will see that the problem disappears. Normally, the LUT is used in CR images to apply a kind of gamma correction that maps optical densities or photon count to so-called presentation values, so without it the image might look less than perfect. However, with this totally broken LUT I see no alternative (other than fixing the device that produces the faulty images).

[Ricky Yang]

Marco Eichelberg

Thank you very much for your detailed answer, and I tried your solution, it works!

I really appreciate your time and help!

Thank you again!