CMAP: MTYP == 0 (direct use) not handled properly

[GoogleCodeExporter]

The attached file appears blurred in openjpeg-2.0 because the final tile part 
is higher than expected and so opj_j2k_read_sot exits too early.

I have attached a patch to resolve this.

Original issue reported on code.google.com by slmis...@gmail.com on 6 Sep 2013 at 10:04

Attachments:

• blur.patch
• Bug691816.pdf

[GoogleCodeExporter]

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

• Added labels: Milestone-Release2.1

[GoogleCodeExporter]

I've -painfully- extracted the JP2 file from the attached PDF file, see 
issue235.jp2. If I did it correctly the file is reported to be buggy as per 
kakadu point of view:

$ kdu_expand -i issue235.jp2 -o issue235.tiff
Error in Kakadu File Format Support:
JPX source contains a codestream with a palette (pclr) box, but no component
mapping (cmap) box.  This illegal situation has been detected after examining
both the codestream header (chdr) box, if any, for that codestream, and the
default JP2 header (jp2h) box, if any.

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

• Added labels: Priority-Low
• Removed labels: Priority-Medium

Attachments:

• issue235.jp2

[GoogleCodeExporter]

Ok looks like there is a colormap in another PDF/XObject. Could someone please 
extract the actual JP2 file from this PDF ?

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

[GoogleCodeExporter]

FYI, I followed instructions from: 
http://blog.idrsolutions.com/2011/07/extract-raw-jpeg-images-from-a-pdf-file/

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

[GoogleCodeExporter]

Original bug report is at: http://bugs.ghostscript.com/show_bug.cgi?id=691816

Original comment by mathieu.malaterre on 4 Mar 2014 at 1:16

[GoogleCodeExporter]

cmap box is actually a toplevel box instead of being a subbox, hence kakadu is 
failing to decode it properly.

Original comment by mathieu.malaterre on 4 Mar 2014 at 1:21

[GoogleCodeExporter]

One need to change the size of the ihdr box from 827 to 847 to correct the 
file, and have cmap be a subbox instead of toplevel.

Original comment by mathieu.malaterre on 4 Mar 2014 at 1:32

Attachments:

• issue235_cmapsubbox.jp2

[GoogleCodeExporter]

With current r2573, here is what I get:

$ make opj_decompress && ./bin/opj_decompress -i /tmp/issue235_cmapsubbox.jp2 
-o bla.tif
[ 84%] Built target openjp2
[100%] Built target opj_decompress

[INFO] Start to read j2k main header (925).
[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.
[INFO] Tile 1/2 has been decoded.
[INFO] Image data has been updated with tile 1.

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

[ERROR] Component 0 is mapped twice.
[ERROR] Component 0 is mapped twice.
[ERROR] Component 1 doesn't have a mapping.
[ERROR] Component 2 doesn't have a mapping.
ERROR -> opj_decompress: failed to decode image!

While kakadu seems happy about this file.

Original comment by mathieu.malaterre on 4 Mar 2014 at 1:35

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 5 Mar 2014 at 8:38

• Changed title: CMAP: MTYP == 0 (direct use) not handled properly
• Changed state: Started

[GoogleCodeExporter]

This issue was updated by revision r2577.

Original comment by mathieu.malaterre on 5 Mar 2014 at 9:45

[GoogleCodeExporter]

Steps:

$ kdu_transcode -i issue235_cmapsubbox.jp2 -o issue235_cmapsubbox.j2k

-> kakadu and openjpeg produce the exact same output (bitwise).

Original comment by mathieu.malaterre on 12 Mar 2014 at 4:25

[GoogleCodeExporter]

Need to check which bit plane (R,G,B) is causing the issue.

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

[GoogleCodeExporter]

For reference:

$ kdu_expand -i issue235_cmapsubbox.jp2 -o red.kdu.pgm,grn.kdu.pgm,blu.kdu.pgm
$ kdu_transcode -i issue235_cmapsubbox.jp2 -o issue235_cmapsubbox.j2k
$ kdu_expand -i issue235_cmapsubbox.j2k -o issue235_cmapsubbox.j2k.pgm
$ crc32 issue235_cmapsubbox.j2k.pgm
66b73a0b
$ crc32 red.kdu.pgm grn.kdu.pgm blu.kdu.pgm
e1d8ac31    red.kdu.pgm
66b73a0b    grn.kdu.pgm
66b73a0b    blu.kdu.pgm

Original comment by mathieu.malaterre on 13 Mar 2014 at 9:51

[GoogleCodeExporter]

This issue was updated by revision r2705.

Original comment by mathieu.malaterre on 13 Mar 2014 at 9:57

[GoogleCodeExporter]

This issue was updated by revision r2707.

Original comment by mathieu.malaterre on 13 Mar 2014 at 10:35

[GoogleCodeExporter]

If one activate code from r2707. The openjpeg behave oddly and does not produce 
the same output image whether it is contained in a JP2 or in a J2K container.

$ opj_decompress -i issue235_cmapsubbox.j2k -o issue235_cmapsubbox.j2k.pgm
$ mv /tmp/0.raw /tmp/0.j2k.raw
$ opj_decompress -i issue235_cmapsubbox.jp2 -o issue235_cmapsubbox.jp2.ppm
$ crc32 /tmp/0*.raw
16be4dd0    /tmp/0.j2k.raw
9e822ba3    /tmp/0.raw

Original comment by mathieu.malaterre on 13 Mar 2014 at 10:37

[GoogleCodeExporter]

@mathieu,

I think this is the exact same thing as Issue 447, can you have a look at that ?
IMHO, there's nothing wrong with MTYP == 0 at r2949. Same output as kakadu 
(with cmap in jp2h & issue 254 patch)
The blurred sub-issue is issue 254.

Original comment by m.darb...@gmail.com on 6 Dec 2014 at 11:05