The following file is rendered with a transparent red rectangle on the page when converted to pxlcolor and then to ppmraw (see attached): IA3Z3476.pdf Command lines used for testing: gshead -sDEVICE=pxlcolor -r600 -o test1.pxl ./$1 pclhead -sDEVICE=ppmraw -r600 -sOutputFile=viapxl.ppm -dNOPAUSE ./test1.pxl gshead -sDEVICE=ppmraw -r600 -o direct.ppm ./$1 I'm testing with r10243 for both GhostPCL and Ghostscript. The file may be found in the private repository in /tests_private/pdf/PDFIA1.7_SUBSET/
Created attachment 5587 [details] IA3Z3476.pdf.0.png
The pdf has some colorspace and separation directives inside. Maybe they are not treated properly. (this is currently just a guess).
Created attachment 5657 [details] The jpeg image stream extracted from the pdf I extracted the jpeg image stream from the pdf, and *it has a red tint*! But its dictionary also has a /RelativeColorimetric rendering intent to it, so it is rendered with a white background. The actual pixel value of the background is is FF 7E 7E (a shade of pink), so backgrounds colour is not white, but rendered as white because of the rendering intent. <</BitsPerComponent 8 /Width 323 /Length 150 0 R /Filter /DCTDecode /Type /XObject /Intent /RelativeColorimetric /ColorSpace 149 0 R /Height 375 /Subtype /Image /Interpolate true >>
Comment on attachment 5657 [details] The jpeg image stream extracted from the pdf image extracted from private file.
Switching back to default_copy_color() has no effect, but switching back to gx_default_begin_image() with the strictly temporary ugly hack below do give the desired output, at the expense of blowing up the file size from 1.6MB to 77Mb (almost 50x). So, if it is possible to detect images with rendering intent, a more acceptable solution would be to switch only images with rendering intent to gx_default_begin_image(); a longer-term solution would be to try to map the colors. @@ -1743,7 +1744,7 @@ pclxl_begin_image(gx_device * dev, (bits_per_pixel != 1 && bits_per_pixel != 4 && bits_per_pixel != 8 && bits_per_pixel !=24))) || format != gs_image_format_chunky || - prect + prect || 1 ) goto use_default;
Just adding more info - the problem seems to be that the image has a lab color space: 149 0 obj [ /Lab <</WhitePoint [ 0.9642 1 0.82491 ] /Range [ -128 127 -128 127 ] >> ] endobj
A simple patch like this switch the image concerned to gx_default_* - the file size still increases from 1.6MB to 77Mb. This appears to be one of the worst cases - a few other files which don't show obvious color differences changes from 0.8MB -> 9MB and 3MB-> 5MB. ========================== --- a/base/gdevpx.c +++ b/base/gdevpx.c @@ -329,7 +329,7 @@ } return !(index == gs_color_space_index_Separation || index == gs_color_space_index_Pattern || - index == gs_color_space_index_CIEICC); + index == gs_color_space_index_CIEICC || index == gs_color_space_index_CIEABC); } /* Set brush, pen, and mode for painting a path. */ ==========================
Shailesh Mistry has reported this fixed.
Yes, after all the icc-related changes, the current behavior is what the workarounds in comment 5 and comment 7 did - the color is correct but the output file size goes to 77MB-ish.
Hin Tak it is fine to create a new bug for the output file size but we'd rather this one be marked fixed. It gets confusing tracking multiple issues in a single bug.
Created attachment 10747 [details] enhancement to icc transform deep images. enhancement to icc-transform deep images. This change makes it possible to emit an image with icc-transformed pixel values. (instead of lots of little rectangles). Because of the invasive nature of the change, it is implemented as an option (with -diccTransform) which will be used for testing for while, and removed (i.e. make permanently on) later.
Michael: can you have an eye over the patch? It does the job but it is all icc related code so I'd appreciate a look.
The patch on its own improves the output file size; the size is even better together with the jpeg compression enhancement ( http://bugs.ghostscript.com/show_bug.cgi?id=691880#c6 http://bugs.ghostscript.com/attachment.cgi?id=10746&action=diff ). Since the source in this case is jpeg, jpeg output is appropriate.
output file sizes: 82259451 gs9.10 82258587 gs9.10 -dCompressMode=1 53397755 HEAD , pxlmono 79937876 pxlcolor pxlcolor -dNOINTERPOLATE 2757627 2707195 -dCompressMode=1 2707195 -dCompressMode=2 2708602 -dCompressMode=3 pxlcolor -dNOINTERPOLATE -diccTransform 1575613 ditto 1591279 1259774 1501262 pxlmono -dNOINTERPOLATE 2381021 ditto 2386277 2386277 2387684 pxlmono -dNOINTERPOLATE -diccTransform 1310671 ditto 1291743 1232060 1301744 The size difference is in fact largely due to the first page, and it is more dramatic just looking at -dLastPage=1. With -dNOINTERPOLATE, + -diccTransform, + -dcompressMode=2 pxlcolor -dLastPage=1 78734635 1538858 407276 75771 -dcompressMode=2 pxlmono -dLastPage=1 52220943 1209289 133683 74000 -dCompressMode=2 So looking at the pxlcolor output, we get a 50 x reduction doing -dNOINTERPOLATE, a further 4x doing icc transform (and RLE). and a further 5x doing jpeg compression. The original jpeg is 19121 bytes. The final is 20563 (out of the 75771), so that's roughly correct and how it should be optimally.
Patches were committed: commit 4b44b41c9b6c4a7e5ebf03b6970f9be39548443b Author: Hin-Tak Leung <hintak@ghostscript.com> Date: Wed Mar 12 15:03:58 2014 +0000 Implements PCL XL Compression Mode 2 (JPEG), and updated documentation and other support files. Bug 694282. commit 41ab485d48890ecadc3d5f74657b644f9d1a8d7f Author: Hin-Tak Leung <hintak@ghostscript.com> Date: Wed Mar 12 15:16:05 2014 +0000 pxlmono/pxlcolor: Transform deep (24-bit) images with an ICC transform to emit high-level images. Bug 690867. There was a regression with the latter and were fixed by 8ae4ee220766aa180150eafeffe4f094f1354f92 (Bug 695103). People thinking of back-porting needs all three. The new functionalities of compression mode 2 and icc-transform deep images are optional. Patch to remove -diccTransform option and some newly discovered issues are tracked in bug 695124 .