Originally reported by: pasco@users.sourceforge.net The PostScript code below should generate a 6x6 pixel color image with pixels of colors: RRRRRR RGGGGR RGBBGR RGBBGR RGGGGR RRRRRR where R=Red, G=Green, B=Blue However, when converted to PDF with ps2pdf.bat and then displayed with Acrobat Reader 4.05 (all on Windows NT 4.0 platform), the displayed image looks like this RROORR RKGGKR OGBBGO OGBBGO RKGGKR RROORR where, additionally, O=Orange, K=Black. In other words, the Red Blue primaries seem to be correct, but the Green is misplaced. Here is the source code: ------------------------- %!PS-Adobe-3.0 EPSF-3.0 %%BoundingBox: 72 162 540 630 /picstr 18 string def gsave 72 630 translate 468 468 scale 6 6 8 [6 0 0 -6 0 0] {currentfile picstr readhexstring pop} false 3 colorimage FE0000FE0000FE0000FE0000FE0000FE0000 FE000000FE0000FE0000FE0000FE00FE0000 FE000000FE000000FE0000FE00FE00FE0000 FE000000FE000000FE0000FE00FE00FE0000 FE000000FE0000FE0000FE0000FE00FE0000 FE0000FE0000FE0000FE0000FE0000FE0000 grestore showpage --------------- Comments? - Rich
Comment originally by lpd@users.sourceforge.net Like Acrobat Distiller, pdfwrite attempts to compress color images. The default compression method is "auto", meaning that pdfwrite is supposed to look at the image data and decide whether to use JPEG compression (which is good for photos, but may distort colors slightly) or Flate compression (which compresses less well, but does not distort colors). Unfortunately, pdfwrite currently always uses JPEG compression. Acrobat Reader further distorts colors by applying undocumented adjustments that it believes will make the colors on the screen look more like those that a printer might produce. pdfwrite needs to be changed to use a reasonable algorithm for deciding between JPEG and Flate compression, probably based on sharp vs. smooth color transitions in the image; in case of uncertainty, it should use Flate. At the very least, it should certainly use Flate compression if the input image has relatively few pixels in it (less than 16x16, perhaps).
Comment originally by nobody@users.sourceforge.net The resolution of the green channel is being halved. I believe that's a feature of jpeg compression, not a requirement. Maybe there's a parameter that will stop this, anyone know?
Comment originally by nobody@users.sourceforge.net I assumed correctly, try: << /ColorImageDict << /HSamples [1 1 1] /VSamples [1 1 1] /ColorTransform 1 >> >> setdistillerparams then again, on an image like this, you should just use Flate...
Comment originally by alexcher@users.sourceforge.net Logged In: YES user_id=65750 JPEG compression is disabled for images smaller that 64 pixels in any dimension. See the attached patch. A complete solution requires buffering of the whole image and analysis of the content. It is scheduled after release of GS 7.0. Buffering also helps to deal with image streams that end prematurely. The problem is moved to doc/Issues.htm
Comment originally by alexcher@users.sourceforge.net Logged In: YES user_id=65750 AutoFilter.* options now select lossless compression for the image smaller than 64 pixels in any dimension. Fixed in HEAD and GS_6_5 branches.