Bug 691760 - In black color space of the "cups" output device color images are inversed or incorrectly rendered
In black color space of the "cups" output device color images are inversed or...
Product: Ghostscript
Classification: Unclassified
Component: CUPS driver
PC Linux
: P4 major
Assigned To: Michael Vrhel
Bug traffic
: 691845 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2010-11-09 12:00 PST by Till Kamppeter
Modified: 2011-01-07 08:33 PST (History)
4 users (show)

See Also:
Word Size: ---

PostScript sample file (577.18 KB, application/postscript)
2010-11-09 12:00 PST, Till Kamppeter
PDF sample file (262.39 KB, application/pdf)
2010-11-09 12:02 PST, Till Kamppeter

Note You need to log in before you can comment on or make changes to this bug.
Description Till Kamppeter 2010-11-09 12:00:47 PST
Created attachment 6879 [details]
PostScript sample file

If the input document (PDF or PostScript) contains color images and the "cups" output device is used with cupsColorSpace set to 3 (black, reverse grayscale), 4 (CMY), 5 (YMC), or 17 (RGBW, RGB plus white) embedded images appear reversed/negative in the resulting CUPS raster output (black gets white and white gets black). Text, vector graphics, and monochrome/grayscale images are rendered correctly.

cupsColorSpace set to 2 (RGBA, RGB plus alpha) does not render the color images at all and replaces them by checkerboard patterns.

With cupsColorSpace set to 7 (YMCK), 8 (KCMY), or 9 (KCMYcm) the red graph on the first page comes out in blue.

With cupsColorSpace set to 0 (RGB), 1 (W, Luminance), or 6 (CMYK) the output is OK.

To reproduce, run a command line like this on the attached files:

cat C09-original-20101109.pdf | gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -I/usr/share/cups/fonts -sMediaClass=Standard -sMediaType=Plain -r720x720 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842  -dcupsBitsPerColor=8 -dcupsColorSpace=4 -scupsPageSizeName=A4 -c -f -_ > out.raster 2> log

The problem occurs with current SVN state (and probably also with 9.00), with 8.71 the output is correct. So the problem seens to be a consequence of the newly introduced color management.

To visualize the results use rasterview from


The problem got originally reported here:

Comment 1 Till Kamppeter 2010-11-09 12:02:03 PST
Created attachment 6880 [details]
PDF sample file
Comment 2 Till Kamppeter 2010-11-09 12:03:31 PST
The sample files are from bug 691733.
Comment 3 Till Kamppeter 2010-11-09 12:05:11 PST
Assigning to Michael Vrhel as this needs to get checked by a color management expert.
Comment 4 Michael Vrhel 2010-11-19 22:20:13 PST
So here is the issue.  With these color spaces, in the current code it is going to be required for one to specify an appropriate destination ICC profile.   If a device color space is not specified then a default type is going to be assumed based upon the number of channels.  For example with RGBW, we are going to end up using a destination ICC profile, which is default_CMYK.icc.  That obviously is not going to work.  One could specify a 4CLR ICC profile that has the properties that are required and all would work fine.  

One possibility is for me to make the default case a bit more sophisticated and have it only use the gray, RGB and CMYK default profiles in cases where the device is as specified.  Specialty xCLR destination profiles would need to be generated for these funny color models specified by CUPs.  I need to spend a little time thinking about this as the profiles would need to be mapping from CIELAB to the process colorants.  For cases like CMY YMC, inverted K the process of generating a profile that gave OK results would be easy.  For KCMYcm RGBW the process is not as clear.  Generally KCMYcm is really only seen in the printers embedded code where there is a transform from CMYK to CcMmYK.  I have designed solutions for this in real printers but it is very printer specific.  It would really fall on the user of this device to specify an ICC profile so that we know HOW to map to KCMYcm for that device.  RGBW is used in projectors and I probably could come up with something, but it would not really be related to a real physical device and so I don't know how it would be of use to anyone.  If someone had such a device they would determine the mapping for that device and specify it to ghostscript.
Comment 5 Michael Vrhel 2010-12-17 22:01:28 PST
*** Bug 691845 has been marked as a duplicate of this bug. ***
Comment 6 Michael Vrhel 2011-01-07 03:40:19 PST
I have identified the issue.  When we process color, 16bit or interpolated images we usually take advantage of the CMM to do all our color management and have it operate on line buffers as a whole, which is much more efficient than the old way which involved multiple conversions to various data types.  Unfortunately, if the device has non-standard color mapping procs then we can't do the CMM method, or it certainly loses its advantage.   I am currently working on a solution that detects the presence of "special" color mapping procs, in which case we will go to the old style methods.
Comment 7 Michael Vrhel 2011-01-07 04:50:43 PST
This should be fixed with rev 12005.  Please test Till.
Comment 8 Till Kamppeter 2011-01-07 08:33:25 PST
I have tested all color spaces with the command line of the initial posting and also the following command line (launch_leaflet.pdf from bug #688495)

cat launch_leaflet.pdf | gs -dPARANOIDSAFER -dNOPAUSE -dBATCH -sDEVICE=cups -dcupsColorSpace=17 -dcupsBitsPerColor=8 -sOutputICCProfile="default_cmyk.icc" -sstdout=%stderr -sOutputFile=%stdout -_ > out.raster

and the output displayed with rasterview looks correct now.