search

xinxinlx / openjpeg

Automatically exported from code.google.com/p/openjpeg
Other
0 stars 0 forks source link

opj_decompress gives error but successfully decompress in OPJ 2.1 #366

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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:

GoogleCodeExporter commented 9 years ago 
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