Bug 691816 - JPX Decode provides RGB with Luratech when Indexed is expected
Summary: JPX Decode provides RGB with Luratech when Indexed is expected
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: JPX/JBIG2 encode/decode (show other bugs)
Version: master
Hardware: PC Windows 7
: P1 normal
Assignee: Alex Cherepanov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-03 20:55 UTC by Ray Johnston
Modified: 2011-10-02 02:35 UTC (History)
0 users

See Also:
Customer: 532
Word Size: ---


Attachments
Page-8-flag-AC50A122.pdf (24.55 KB, application/pdf)
2010-12-03 20:55 UTC, Ray Johnston
Details
patch (5.04 KB, patch)
2010-12-05 02:33 UTC, Alex Cherepanov
Details | Diff
patch (7.20 KB, patch)
2010-12-06 16:33 UTC, Alex Cherepanov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ray Johnston 2010-12-03 20:55:33 UTC
Created attachment 6990 [details]
Page-8-flag-AC50A122.pdf

The attached PDF has an image with ColorSpace /Indexed with DeviceRGB as the
base space, but the image_render_mono is getting data that looks like it is
RGB (triplets such as 7a 2e 1e 7a 2e 1e ...) as can be seen with a debug
build using -ZB

Note this requires building with Luratech. If using recent MSVC, the following
patch to psi/msvc32.mak is needed to build:

-!if $(MSVC_VERSION) <= 7
+!if $(MSVC_VERSION) <= 9
 JPX_CFLAGS=-DUSE_LWF_JP2 -DWIN32 -DNO_ASSEMBLY
 !else

This is an urgent issue for the customer.

I will be looking into this as well and will post any findings here.
Comment 1 Ray Johnston 2010-12-03 21:36:23 UTC
The following HACK gives the correct image, and shows that we _are_ getting
RGB from the luratech decoder:

*** Resource/Init/pdf_draw.ps   Mon Nov 29 08:56:38 2010
--- pdf_draw.ps Fri Dec 03 13:34:26 2010
***************
*** 1411,1416 ****
--- 1411,1420 ----
        //last-ditch-bpc-csp exec

        dup /ColorSpace oknown {
+         ColorSpace 0 get /Indexed eq {
+           % For luratech decoder, we get the decoded data, not the index ???
+           /ColorSpace ColorSpace 1 get def
+         } if
          % Propagate known color space to the filter
          /ColorSpace currentdict /ColorSpace get //add-to-last-param exec
        } if

This is _NOT_ a solution, just a hint in case it helps.
Comment 2 Alex Cherepanov 2010-12-03 22:20:18 UTC
Currently both Jasper and Luratech expand indexed color spaces.
I see that this can conflict with the color space in PDF file.
Comment 3 Alex Cherepanov 2010-12-05 02:33:52 UTC
Created attachment 7005 [details]
patch

Don't expand indexed color space in Luratech JPX decoder when PDF
color space is /Indexed. Jasper already does this.
Comment 4 Ray Johnston 2010-12-05 20:14:10 UTC
Testing the patch with the customer's code...

BTW, the sjpx_luratech.h patch needs a minor style fix (missing */ at end of line)

+    bool image_is_indexed;      /* image is indexed, needs decoding
+                                /*  if colorspace != gs_jpx_cs_indexed */
Comment 5 Alex Cherepanov 2010-12-06 16:33:17 UTC
Created attachment 7007 [details]
patch

Bring Luratech decoder up to the level of Jasper decoder.
1. Don't expand indexed colors when the PDF expects an indexed color space.
   Fix rendering of the sample file attached.
2. Recognize indexed CMYK color space and accept the palettes that are shorter
   than 256 colors. Fix comparefiles/Bug689362.pdf
3. Fix memory corruption that happened with 4-bit-per-pixel grayscale image
   and pack the nibbles by PS rules. Fix comparefiles/690174.diff

Luratech now renders every file in our test suite correctly.
We don't have tests for low values of bits per plane.
Comment 6 Alex Cherepanov 2010-12-06 16:34:37 UTC
s/690174.diff/Bug690174.pdf/
Comment 7 Alex Cherepanov 2010-12-06 16:40:47 UTC
The patch has been committed as a rev. 11936.