v2 fails to decode image which 1.5.0 (and earlier) manages.

[GoogleCodeExporter]

We use libopenjpeg to handle JP2K images for MuPDF. Until now we've been using 
1.5, and many files decode successfully with warnings such as:

  warning: openjpeg warning: SOT marker inconsistency in tile 0: tile-part index greater (5) than number of tile-parts (5)

Now, having upgraded to 2.0, we see:

  warning: openjpeg error: In SOT marker, TPSot (5) is not valid regards to the current number of tile-part (5), giving up

and the whole image decode is abandoned.

An example image is attached.

Is there some way to restore the old behaviour please? This is a serious 
regression for us. Acrobat displays the images with no suggestion that anything 
might be wrong. This happens for 264 files out of a test set of 11454 (few have 
Jp2K files, so this is a larger proportion than you might expect).

I have tested on both windows and unix using both 2.0.0 and the head of SVN.

Thanks,

Robin

Original issue reported on code.google.com by robinwat...@googlemail.com on 7 Jan 2013 at 6:29

Attachments:

• img0.j2k

[GoogleCodeExporter]

We have been tracking this issue in our bugs database as:

  http://bugs.ghostscript.com/show_bug.cgi?id=693540

and we have had a submission. "mhfan at ustc.edu" suggests that a simple fix is 
to change opj_j2k_read_sot so that if an explicit number of parts is given, we 
always just add 1 to it.

diff --git a/src/lib/openjp2/j2k.c b/src/lib/openjp2/j2k.c
index 3b439fc..b280d40 100644
--- a/src/lib/openjp2/j2k.c
+++ b/src/lib/openjp2/j2k.c
@@ -3972,6 +3972,7 @@ OPJ_BOOL opj_j2k_read_sot ( opj_j2k_t *p_j2k,
                                         return OPJ_FALSE;
                                 }
                         }
+                       ++l_num_parts;  // XXX:
                         l_tcp->m_nb_tile_parts = l_num_parts;
                 }

This does indeed seem to solve it for that file. We are testing on a wider set 
of examples now.

Original comment by andr...@ghostscript.com on 24 Jan 2013 at 4:47

[GoogleCodeExporter]

Hi,

I have checked your file and it seems not respect the norm because in SOT 
marker we should have the right number of tile-part of the tile (read from 
TNsot value).

In the norm (ISO/IEC 15444-1 : 2002) we can read thr following:
TNsot: Number of tile-parts of a tile in the codestream. Two values are 
allowed: the correct number of tile-parts for that tile and zero. A zero value 
indicates that the number of tile-parts of this tile is not specified in this 
tile-part.

Your file indicate five tile-parts but seems to have 6 tile-parts which is not 
coherent. Moreover we begin our tile decoding when we detect that we have all 
tile-part needed (here 5). So the last one will be at least ignored.

I will try to find a patch to ignore nicely this last tile part and not launch 
an error.

Which encoder you use ?

Mickaël

Original comment by savmick...@gmail.com on 3 Feb 2013 at 6:14

[GoogleCodeExporter]

> Which encoder you use?

I am not using an encoder myself - this is a file that has come handed down to 
me as a test file. I have many such examples, all of which specify 'n' and then 
have parts 0,1,2,...n.

I am sure it's an out of spec file, but it would be nice to decode the files 
properly.

The best patch I've found so far was suggested in comment 2 of the following 
bug:

  http://bugs.ghostscript.com/show_bug.cgi?id=693540#c2

Based on what you say, I'd expect this to give problems when decoding 'in spec' 
files, as the nth tile part will never arrive. But I see no such problems...

Thanks,

Robin.

Original comment by andr...@ghostscript.com on 6 Feb 2013 at 5:42

[GoogleCodeExporter]

Hi,
please check with the last revision. 
Winfried provide an useful patch.
Mickaël
(related to issue 202 and issue 206)

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

[GoogleCodeExporter]

Seems to be working ok now. The colour does not seems right at least they do 
not match kakadu.

Original comment by mathieu.malaterre on 24 Feb 2014 at 9:20

[GoogleCodeExporter]

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

• Added labels: Milestone-Release2.1, Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

This issue was updated by revision r2490.

Original comment by mathieu.malaterre on 26 Feb 2014 at 5:12

[GoogleCodeExporter]

This issue was closed by revision r2491.

Original comment by mathieu.malaterre on 26 Feb 2014 at 5:13

• Changed state: Fixed