opj_decompress gives error but successfully decompress in OPJ 2.1

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by m.sam...@gmail.com on 30 Jun 2014 at 8:28

Attachments:

• Sample.j2k

[GoogleCodeExporter]

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.

Original comment by antonin on 9 Jul 2014 at 5:09

[GoogleCodeExporter]

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

Original comment by antonin on 10 Jul 2014 at 9:32

[GoogleCodeExporter]

This issue was closed by revision r2875.

Original comment by antonin on 14 Jul 2014 at 7:42

• Changed state: Fixed

[GoogleCodeExporter]

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

Original comment by m.sam...@gmail.com on 22 Jul 2014 at 10:14