Too much compressed data

[malaterre]

I can reproduce a failure to decompress using CharLS 1.1 (issue is present in CharLS 1.0), this is originally a bug tracked in Debian. With the reference jls, I can get JpegLsDecodeStream to return TooMuchCompressedData:

(gdb) 
297     ByteStreamInfo outputInfo = FromByteArray(outputBuffer.data(), outputBuffer.size());
(gdb) 
298     err = JpegLsDecodeStream(outputInfo, compressedByteStream, &info);
(gdb) 
299     if (err != OK)
(gdb) p err
$1 = TooMuchCompressedData

[malaterre]

The dataset are available as DICOM files using either:

• http://gdcm.sourceforge.net/thingies/JPEG_LS_InvalidEscapeSequence_COM_padding.dcm

or

• http://gdcm.sourceforge.net/thingies/JPEG_LS_InvalidEscapeSequence.dcm

The first version is the original form, the second one is a simplified one where I removed manually the COM marker (some implementation could not process the COM marker). But the image bitstream is bitwise identical.

Using gdcmraw one can quickly generate a pure JPEG-LS stream:

eg.:

$ gdcmraw JPEG_LS_InvalidEscapeSequence_COM_padding.dcm JPEG_LS_InvalidEscapeSequence_COM_padding.jls

I've simplified the second dataset in place, here are the new md5sum:

$ md5sum *.dcm
d7b95e7d3335614b462a7a063c1b02a9  JPEG_LS_InvalidEscapeSequence.dcm
299df0175ea4d3ab1f02651f88ffe9f3  JPEG_LS_InvalidEscapeSequence_COM_padding.dcm

[malaterre]

The good news is that I can reproduce it with release 1.0, 1.1 and git master. One should pay attention that charlstest -decodetopnm uses inverted UNIX convention (issue #19).

Also on the good side, the output produced by 1.1 and git/master are identical:

$ ./charlstest -decodetopnm JPEG_LS_InvalidEscapeSequence_COM_padding.jls tt.pgm
$ md5sum tt.pgm 
596da5bc228ea42784f9780517e071d3  tt.pgm

[vbaderks]

Hi,

This JPEG-LS image has been compressed with DicomObjects: 6.35.0.67. This can be seen as the JPEG-LS stream has a JPEG comment marker segment (xFFFE) with the text: "Compressed by DicomObjects: 6.35.0.67".

CharLS detects that when all pixels are decoded, there are still 2 bits not decoded and will report this as a failure. This problem can be caused by a failure in the encoding process (DicomObjects library) or the decoding process (CharLS).

Do you have access to the original uncompressed image?

Note: the original loco binaries cannot handle JPEG comment markers, so I am currently not able to use another tool to decode the image.

[malaterre]

@vbaderks If you check my earliest post you'll find a link to a stripped down version:

• http://gdcm.sourceforge.net/thingies/JPEG_LS_InvalidEscapeSequence.dcm

It does not contains a COM marker, so it may be simplier for you.

[malaterre]

This appear to be a bug in the JPEG-LS stream itself. CharLS does properly report the error as 'TooMuchCompressedData', so there is not much one can do. This is up to the application decoding the stream to decide whether or not to accept an error of type 'TooMuchCompressedData'. For reference the corrected stream is at:

• http://gdcm.sourceforge.net/thingies/JPEG_LS_InvalidEscapeSequence_Correct.dcm