DCMCJPEG: Problem with Icon Image sequences

[Carmelo]

Hi there,

I have found an issue (or that's what it seemed to me) while using the DCMTK tool for JPEG compressing: dcmcjpeg.

The thing is that given an MG image (the problem is not focused in one image but generalized) that contain the element IconImageSequence (0088,0200), when i tried to compress it via JPEG i receive the following error message meanwhile the application crashes:

• "True lossless encoder: Can not change representation, not enough data"

If i just erase (via a HexEditor) the including IconImageSequence group (StorageGroup: 0088) it works normally and is able to compress, modify or whatever i need to do to the image. We have thought that maybe the problem came from the lengths... The set of images has Implicit VR.

thanks in advanced,
Carmelo

(PS: if you are interested i can send you one of the images from which i get this rare issue)

[Marco Eichelberg]

The crash is a bug in dcmcjpeg that has meanwhile been fixed. The error message, however, is real, and indicates that something is wrong with the pixel data within the icon image sequence. Problems like this typically appear when the pixel data within the icon image sequence has been damaged by some other application (e.g. has not been decompressed while decompressing the main dataset, so that an uncompressed image contains a JPEG bitstream in the pixel data element of the icon image sequence).

[Carmelo]

Hi Marco,

thanks for your quick answer...yes, you are right the icon image is JPEG-embedded while the main dataset is uncompressed

My answer here is, since i don't know a lot about it, is illegal to be in this situation (different encoding for different pixel data)? Shall both be of the same type (uncompressed or compressed)? As far as i knew there's no restriction about this but as I've said i don't know a lot about icon images.

cheers,
Carmelo

[Marco Eichelberg]

The normal situation is that all instances of PixelData in a DICOM object have the same representation, that is, the encoding described by the transfer syntax in which the object is encoded. Since there is only one transfer syntax, there can only be one pixel encoding.

As an exception to this rule, a DICOM CP was added some time ago that explicitly allows pixel data inside the Icon Image Sequence to be uncompressed even when the rest of the object is encoded using one of the compressed (encapsulated) transfer syntaxes. (Note: not vice versa. When the image is uncompressed, the icon must be uncompressed). This CP does not say anything about pixel data in any other place, but one can imagine that the same rule could be applied to any pixel data embedded in some sequence item, i.e. not being part of the main dataset.

The encoding of the sample image you describe, an uncompressed main image with a compressed icon, is absolutely illegal because there is no identifier (transfer syntax UID anywhere in the object) left that would actually say which kind of encoding the icon uses.

[Carmelo]

thanks Marco

[Yves Neumann]

Hello Marco,

I have a similar problem when decompressing a JPEG image that has non-compressed Pixeldata inside an IconImageSequence. As I read here this problem is already solved for the JPEG codec. Is the solution available somewhere/somehow (I use Dcmtk 3.5.4)?

Regards,

Yves
IMAGE Information Systems Ltd.

[Marco Eichelberg]

The problem I was referring to in the original post only affected lossless compression, but not decompression. That should work in DCMTK 3.5.4, and no modifications to that part of the code have been submitted to our CVS since 3.5.4 release. If there is a problem, please submit a sample image to dicom <at> offis <dot> de and I will see what I can do for you.

[Yves Neumann]

The test file is sent to dicom <at> offis <dot> de as well as a short description of the failure. Let me know if you need more information.

I really appreciate your help, thanks.

[Jörg Riesmeier]

We checked the file. It seems that the Icon Image is stored uncompressed (64*52 = 3328 pixels) although the DICOM encoding says that the pixel data is compressed (i.e. encapsulated). After patching the DICOM file, dcmdjpeg is able to decompress the file.

[Yves Neumann]

Thanks Jörg, for the fast reply. So it was exactly what I was imagine.

But like Marco mentioned in a former post here does the added CP allow this exception (compressed data but uncompressed IconImageSequence). How should I handle those files. Actually, I need to send it to a SCP that can't handle JPEG compressed images and therefore would need to uncompress it.

How did you modify (patch) the dcm file? Did you encode the pixel data inside the icon image sequence?

Thanks, Yves

[Jörg Riesmeier]

The problem is not that the pixel data for the icon image is uncompressed (this is indeed possible). However, the encoding of the pixel data inside the icon sequence is incorrect (encapsulated instead of uncompressed).

Here's the relevant dump from the original file:

Code: Select all

(0088,0200) SQ (Sequence with explicit length #=1)      # 3466, 1 IconImageSequence
  (fffe,e000) na (Item with explicit length #=9)          # 3458, 1 Item
    (0028,0002) US 1                                        #   2, 1 SamplesPerPixel
    (0028,0004) CS [MONOCHROME2]                            #  12, 1 PhotometricInterpretation
    (0028,0010) US 64                                       #   2, 1 Rows
    (0028,0011) US 52                                       #   2, 1 Columns
    (0028,0100) US 8                                        #   2, 1 BitsAllocated
    (0028,0101) US 8                                        #   2, 1 BitsStored
    (0028,0102) US 7                                        #   2, 1 HighBit
    (0028,0103) US 0                                        #   2, 1 PixelRepresentation
    (7fe0,0010) OB (PixelSequence #=2)                      # u/l, 1 PixelData
      (fffe,e000) pi 00\00\00\00                              #   4, 1 Item
      (fffe,e000) pi 0d\1a\1a\1a\1a\19\1a\19\19\19\19\19...   # 3328, 1 Item
    (fffe,e0dd) na (SequenceDelimitationItem)               #   0, 0 SequenceDelimitationItem
  (fffe,e00d) na (ItemDelimitationItem for re-encoding)   #   0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) #   0, 0 SequenceDelimitationItem

And here is the same part from the patched file:

Code: Select all

(0088,0200) SQ (Sequence with explicit length #=1)      # 3438, 1 IconImageSequence
  (fffe,e000) na (Item with explicit length #=9)          # 3430, 1 Item
    (0028,0002) US 1                                        #   2, 1 SamplesPerPixel
    (0028,0004) CS [MONOCHROME2]                            #  12, 1 PhotometricInterpretation
    (0028,0010) US 64                                       #   2, 1 Rows
    (0028,0011) US 52                                       #   2, 1 Columns
    (0028,0100) US 8                                        #   2, 1 BitsAllocated
    (0028,0101) US 8                                        #   2, 1 BitsStored
    (0028,0102) US 7                                        #   2, 1 HighBit
    (0028,0103) US 0                                        #   2, 1 PixelRepresentation
    (7fe0,0010) OB 0d\1a\1a\1a\1a\19\1a\19\19\19\19\19...   # 3328, 1 PixelData
  (fffe,e00d) na (ItemDelimitationItem for re-encoding)   #   0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) #   0, 0 SequenceDelimitationItem

[Yves Neumann]

, I did not recognize the sequence. But this really helps me out. Now I can put a workouround for those badly encapsulated files.

... and once again, many thanks to the competent OFFIS team.