Bug 226391

Summary: colorimage gives wrong picture
Product: Ghostscript Reporter: Jack Moffitt <jack>
Component: PDF WriterAssignee: Alex Cherepanov <alex>
Status: NOTIFIED FIXED    
Severity: normal CC: jackie.rosen
Priority: P2    
Version: master   
Hardware: All   
OS: All   
Customer: Word Size: ---

Description Jack Moffitt 2000-12-19 15:03:29 UTC
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 1 L. Peter Deutsch 2000-12-31 10:11:21 UTC
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 2 Jack Moffitt 2001-01-30 14:13:28 UTC
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 3 Jack Moffitt 2001-01-30 18:45:46 UTC
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 4 Alex Cherepanov 2001-03-20 07:37:42 UTC
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 5 Alex Cherepanov 2001-03-23 20:27:43 UTC
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.