| Summary: | Huffman tables with only positive values are decoded incorrectly. | ||
|---|---|---|---|
| Product: | jbig2dec | Reporter: | Justin Greer <ghostscript.com> |
| Component: | Rendering | Assignee: | Masaki Ushizaka <masaki.ushizaka> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | masaki.ushizaka |
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | All | ||
| OS: | All | ||
| Customer: | Word Size: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 691248 | ||
| Attachments: |
b689836_b1.patch
b689836_b2.patch |
||
Thanks for the patch. I don't quite follow this one. Please attach a file so I can trace through the decode. Unfortunately I don't currently have an example PDF that I can distribute. Specifically, the standard huffman tables A, B, D, K, L, M, and N don't use the lower-range line. The code used to assume that the second to last entry in the huffman table was always a lower-range line, so when it decoded values against that table line (B.4.4 and B.4.5), it would always use the method from B.4.4 (subtraction). For the tables that don't use a lower-range line, though, it should be using B.4.5 (addition) on that second-to-last line from the table. However, there's no explicit method in the code for specifying whether or not a table uses a lower-range line. It works out, though, that the only lines that use 32-bit offsets are lower-range and upper-range lines. All custom tables have a lower-range line, so the "is it 32" check works on custom tables, too. So basically we can just update the code so that it only sets the JBIG2_HUFFMAN_FLAGS_ISLOW flag on the 2nd-to-last table line if the rangelen for that line is 32. I could provide some debug info from a trace on one of the PDF files I have, if that'd help, too. Just let me know what you need. Created attachment 6247 [details]
b689836_b1.patch
I apologize for late response.
To me, this seems more like huffman table problems than decoder code. In jbig2_hufftab.h, the standard tables K, L and M do not have an entry for lower range line (L also lacks upper range line), while A, B, D and N does have lower line.
I made a patch to these tables (also includes fix for wrong RANGELEN value for table N). I don't have a file to test this issue.
I would like to ask Justin Greer to try this patch to see if it fixes problems he has.
Created attachment 6382 [details] b689836_b2.patch ubc/042_11.jb2 has been affected by this problem (bug 691248). My previous patch had a terrible mistake and this is a revised one. With this patch, now ubc/042_11.jb2 results a perfect bitmap. I need to perform some tests before I commit. By test code I committed in r11413, now I can expose the problems originally reported, plus a few more. There ware problems in standard huffman table K, L, M and N. The same test code also confirmed that b689836_b2.patch solved all the problems. It was committed in r11415. Now this issue was solved. Closing. |
Some of the huffman tables only encode positive values, and so they don't use the lower-range table line. In these cases, jbig2dec ends up subtracting HTOFFSET from RANGELOW instead of adding it. (Spec section B.4) An effective (but not completely explicit) patch is to check if the RANGELEN for the table line is 32 bits. (Only the upper/lower range lines use 32 bit offsets.) Patch: Index: jbig2_huffman.c =================================================================== --- jbig2_huffman.c (revision 464) +++ jbig2_huffman.c (working copy) @@ -361,7 +361,7 @@ /* todo: build extension tables */ if (params->HTOOB && CURTEMP == n_lines - 1) eflags |= JBIG2_HUFFMAN_FLAGS_ISOOB; - if (CURTEMP == n_lines - (params->HTOOB ? 3 : 2)) + if (CURTEMP == n_lines - (params->HTOOB ? 3 : 2) && RANGELEN == 32) eflags |= JBIG2_HUFFMAN_FLAGS_ISLOW; if (PREFLEN + RANGELEN > LOG_TABLE_SIZE_MAX) { for (j = start_j; j < end_j; j++) {