iron261 / openjpeg

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

OPJ fails to decode image that KDU manages correctly #406

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
OPJ fails to decode attached image:

[11:59:09 ~/dev/opj/git/openjpeg-build/bin] opj_decompress -i 
~/Downloads/opj_wrong_kdu_ok.jp2 -o ~/Downloads/opj_wrong_kdu_ok.jp2_opj.ppm

[INFO] Start to read j2k main header (85).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
[INFO] Header of tile 0 / 1 has been read.
Expected SOP marker
Error : expected SOP marker
Error : expected EPH marker
read: segment too long (4) with max (0) for codeblock 0 (p=0, b=1, r=5, c=1)
[ERROR] Failed to decode.
[ERROR] Failed to decode tile 1/2
[ERROR] Failed to decode the codestream in the JP2 file
ERROR -> opj_decompress: failed to decode image!

While kakadu decodes it correctly:

[12:00:15 ~/dev/opj/git/openjpeg-build/bin] kdu_expand -i 
~/Downloads/opj_wrong_kdu_ok.jp2 -o ~/Downloads/opj_wrong_kdu_ok.jp2_kdu.tif

Consumed 2 tile-part(s) from a total of 2 tile(s).
Consumed 110,407 codestream bytes (excluding any file format) = 1.179209
bits/pel.
Processed using the multi-threaded environment, with
    4 parallel threads of execution

Original issue reported on code.google.com by antonin on 1 Oct 2014 at 10:01

Attachments:

GoogleCodeExporter commented 9 years ago
First investigation shows that 16th tile-part is read beyond its end => this 
makes openjpeg start reading 17th tile-part at a wrong place, and explains why 
it does not find SOP nor EPH marker.

Original comment by antonin on 1 Oct 2014 at 10:03