RealmeIP / openjpeg

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

Regression in 2.0.0 #206

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Using opj_decompress -ImgDir . -OutFor png on the attached files fails with 
2.0.0.

j2k_to_image -ImgDir . -OutFor png with 1.5.1 works.

I am using Ubuntu 12.10 64-bit.

Original issue reported on code.google.com by adrian.j...@gmail.com on 1 Jan 2013 at 12:18

Attachments:

GoogleCodeExporter commented 8 years ago
This is the output I get. The png files are not created.

Folder opened successfully

File Number 0 "image-003.jp2"
[INFO] Start to read j2k main header (123).
[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 / 2 has been read.
[INFO] Tile 1/3 has been decoded.
[INFO] Image data has been updated with tile 1.

[INFO] Header of tile 1 / 2 has been read.
[INFO] Tile 2/3 has been decoded.
[INFO] Image data has been updated with tile 2.

[INFO] Header of tile 2 / 2 has been read.
[INFO] Tile 3/3 has been decoded.
[INFO] Image data has been updated with tile 3.

[ERROR] In SOT marker, TPSot (5) is not valid regards to the current number of 
tile-part (5), giving up
[ERROR] Fail to read the current marker segment (0xff90)
[ERROR] Failed to decode the codestream in the JP2 file
ERROR -> opj_decompress: failed to decode image!

Original comment by adrian.j...@gmail.com on 1 Jan 2013 at 12:20

GoogleCodeExporter commented 8 years ago
openjpeg-1.5.2 writes in j2k.c :

if(partno >= numparts) numparts = partno + 1;

If I change in openjpeg-2.0.0 line 3972 in j2k.c:

3972: //return OPJ_FALSE;
3973: l_num_parts = l_current_part + 1;

then I get:

[ERROR] In SOT marker, TPSot (5) is not valid regards to the current number of 
tile-part (5)
[INFO] Header of tile 0 / 3 has been read.
[INFO] Tile 1/4 has been decoded.
[INFO] Image data has been updated with tile 1.
Successfully generated Outfile image-000.jp2.png

The resulting file is incorrect. openjpeg-1.5.2 writes:

[WARNING] SOT marker inconsistency in tile 0: tile-part index greater (5) than 
number of tile-parts (5)
[WARNING] SOT marker inconsistency in tile 1: tile-part index greater (5) than 
number of tile-parts (5)
[WARNING] SOT marker inconsistency in tile 2: tile-part index greater (5) than 
number of tile-parts (5)
[WARNING] SOT marker inconsistency in tile 3: tile-part index greater (5) than 
number of tile-parts (5)[INFO] tile 1 of 4
[INFO] - tiers-1 took 0.002000 s
[INFO] - dwt took 0.002000 s
[INFO] - tile decoded in 0.006000 s
[INFO] tile 2 of 4
[INFO] - tiers-1 took 0.001000 s
[INFO] - dwt took 0.001000 s
[INFO] - tile decoded in 0.002000 s
[INFO] tile 3 of 4
[INFO] - tiers-1 took 0.001000 s
[INFO] - dwt took 0.001000 s
[INFO] - tile decoded in 0.002000 s
[INFO] tile 4 of 4
[INFO] - tiers-1 took 0.000000 s
[INFO] - dwt took 0.001000 s
[INFO] - tile decoded in 0.001000 s
Successfully generated Outfile image-000.jp2.png

The resulting file is correct.

winfried

Original comment by szukw...@arcor.de on 2 Jan 2013 at 6:23

GoogleCodeExporter commented 8 years ago
related to issue 208. 
Your file seems to be not coherent with the norm.
Number of tile part in your files are outside the max number of tiles parts 
indicated by a specific key in SOT marker.
In the 2.0 this value is critical to decide if we have enough information and 
data to decode the tile. 
Mickaël  

Original comment by savmick...@gmail.com on 4 Feb 2013 at 12:50

GoogleCodeExporter commented 8 years ago
The files were extracted from PDFs. The problem for poppler is that since Adobe 
Reader can correctly display the PDFs, users expect poppler to also display the 
same PDFs.

Original comment by adrian.j...@gmail.com on 4 Feb 2013 at 2:25

GoogleCodeExporter commented 8 years ago
I also ran into the same issue with some pdfs...

the warning from 1.5.0 is annoying.
It looks like there is at least one wide-spread piece of software out there 
that generates SOT markers "out of bound by one".  This case should be covered. 
openjpeg should be able to read such files correctly (it used to be able to in 
1.5) and to extract information from them.

Unfortunately, I can't attach a copyright-free sample...

Original comment by Marc.Esp...@gmail.com on 17 Mar 2013 at 11:48

GoogleCodeExporter commented 8 years ago
Hi,
please check with the last revision. 
Winfried provide an useful patch
Mickaël
(related to issue 202 and issue 208)

Original comment by savmick...@gmail.com on 24 Mar 2013 at 10:54

GoogleCodeExporter commented 8 years ago

Original comment by mathieu.malaterre on 25 Feb 2014 at 3:31

GoogleCodeExporter commented 8 years ago
I can no longer reproduce this issue this has been fixed (maybe during issue 
202 and issue 208 work). closing.

Original comment by mathieu.malaterre on 26 Feb 2014 at 4:40