[Openicc] Introduction / Gutenprint

[Robert L Krawitz]

   Date: Sun, 10 Apr 2005 02:31:08 +0200
   From: Gerhard Fuernkranz <nospam456 at gmx.de>

   Robert L Krawitz schrieb:

   >The harder problem is when your application simply
   >generates Postscript and hands it off to CUPS (or
   >LPRng, or whatever).

   Actually I see one more problem in this context:

   So far, only color management in the gimp-print driver has been
   considered. But if the driver performs color management, how does
   it cooperate with the PostScript color management?

   PostScript level 2 and 3 define color management functionality, and
   any PostScript document may legally use it, for instance CIE-based
   color spaces, which are of course expected to be rendered correctly
   by a "PostScript level 3 printer" (i.e. ghostscript + driver +
   printer in our case). IMO particularly color managed applications
   which produce PostScript or PDF output may likely use these
   particular PostScript or PDF features.

   Ghostscript does support the PostScript level 2+3 color management
   features (color space arrays, color rendering dictionaries,
   CIE-based color spaces, remapping of device color spaces to
   CIE-based color spaces, ...), but in order that ghostscript's PS
   color management works as specified in the PLRM, my understanding
   is that all color transformations need to be carried out _by
   ghostscript_ (and not in the driver), and gs eventually sends only
   the final DeviceCMYK values (or whatever ProcessColorModel is used)
   to the driver. Of course this also requires, that a CRD for the
   printer (that's more or less the PostScript equivalent of the
   printer's ICC profile), and maybe also transfer functions (for
   device linearization), need to be passed (as PostScript program) to
   ghostscript, together with the document being printed.

Part of the rub is what the "final DeviceCMYK" values are.  They're
always going to be interpreted somehow by the driver, since inkjets
aren't continuous-tone devices and all that.

It sounds like what you're really suggesting here is that the driver
provide good linearized output, and ICC profiles or whatnot be applied
in Ghostscript.  That's fine, but if Ghostscript is delivering 8-bit
data to the driver, it means that a fair bit of information is getting
lost because the profile won't be a 1-1 mapping.  If Ghostscript
outputs 16-bit data that issue goes away.

   Btw, though ghostscript's CIE-based color rendering basically works 
   pretty well, I'm still not fully convinced with the quality. The color 
   rendering quality of gs 8.xx seems to be _much_ better than gs 7.xx, but 
   applying ICC profiles directly to an image (with LCMS or Argyll) and 
   sending the resulting DeviceCMYK image as PS file to ghostscript gives 
   IMO still better results, than ghostscript't CIE-based color 
   transformations.

To summarize what I think I'm hearing:

1) Linearization should be performed in the driver.

2) Device ICC profiling should be done in a layer between the driver
   and the application (Ghostscript for applications that generate
   Postscript, or libgutenprintui for applications that use the UI
   provided by Gutenprint).

Do people agree with this?

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton