opj_decompress gives error but successfully decompress in OPJ 2.1

[gcode-importer]

Originally reported on Google Code with ID 366

The attached "Sample.j2k" file (extracted from a medical image file) fails to decode
with the binaries (Windows x86) related to OpenJPEG v2.0.0:

openjpeg-2.0.0-win32-x86\bin\opj_decompress -i Sample.j2k -o OutputFile.png

[INFO] Start to read j2k main header (0).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
[INFO] Psot value of the current tile-part is equal to zero, we assuming it is the
last tile-part of the codestream.
[INFO] Header of tile 0 / 0 has been read.
[ERROR] Stream too short, expected SOT

On the other side, with the binaries (Windows x86) related to OpenJPEG v2.1.0 the error
always appears, but then the decompression goes on and an apparently-correct PNG output
file is generated:

openjpeg-2.1.0-win32-x86\bin\opj_decompress -i Sample.j2k -o OutputFile.png

[INFO] Start to read j2k main header (0).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
[INFO] Psot value of the current tile-part is equal to zero, we assuming it is the
last tile-part of the codestream.
[INFO] Header of tile 0 / 0 has been read.
[ERROR] Stream too short, expected SOT
[INFO] Tile 1/1 has been decoded.
[INFO] Image data has been updated with tile 1.
[INFO] Generated Outfile OutputFile.png

If the codestream stored in my "Sample.j2k" is "defective / non-compliant" then OPJ
shall fail. On the other side, if the codestream is compliant, then OPJ shall successfully
decompress, without raising the "Stream too short, expected SOT" error.

Reported by m.sambin on 2014-06-30 08:28:55

---

- _Attachment: [Sample.j2k](https://storage.googleapis.com/google-code-attachments/openjpeg/issue-366/comment-0/Sample.j2k)_

[gcode-importer]

Quick investigation :
The file is non-compliant because of a spare 0-byte located after the EOC (FFD9). Without
this last byte, everything works fine.

Since rev2317, openjpeg has a mechanism to overcome this kind of corruption. Weird
thing is that OPJ2.0 is beyond r2317 and should work on this file too.

Anyway, we should indeed at least change the ERROR to a WARNING as the corruption can
be fixed.

Reported by detonin on 2014-07-09 17:09:03

[gcode-importer]

I'm curious : which program did you use to generate Sample.j2k ?

Reported by detonin on 2014-07-10 09:32:59

[gcode-importer]

This issue was closed by revision r2875.

Reported by detonin on 2014-07-14 07:42:58

• Status changed: Fixed

[gcode-importer]

Hi antonin,

sorry for the delay in answering: I've been away for a couple of weeks.
As written in my original post, this j2k file was extracted from a medical image file
(DICOM). The j2k portion was extracted by my own code.
However, once you told me that the issue was an extra trailing '0' byte, then a suspect
came to my mind: probably my code extracting the j2k portion from the DICOM file did
not consider that in DICOM the value of every data element may be padded to reach even
length. Hence, that extra '0' trailing byte may actually be DICOM padding, and not
part of the j2k codestream. I will modify a bit my code to take this into account,
and I will then check if it will work even with older OpenJPEG versions.

In all cases, good to know that OpenJPEG is now able to tolerate that extra trailing
byte.

Thanks a lot for shedding some light on this issue.

Regards,

Marco

Reported by m.sambin on 2014-07-22 22:14:15