[Openicc] Introduction / Gutenprint

[Robert L Krawitz]

   Date: Sun, 10 Apr 2005 16:07:24 +0200
   From: Gerhard Fuernkranz <nospam456 at gmx.de>

   Robert L Krawitz schrieb:

   >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.

   Actually I'm not really suggesting anything, because I don't know a
   satisfactory solution.

   On the one hand, I'm not fully satisfied with the quality of
   ghostscript't color rendering, and on the other hand, with
   ghostscript as is, I see no way to do it externally in the driver
   (like Gutenprint does for halftoning), without breaking PS L3
   support for CIE-based color spaces in PS documents (I'd hope, my
   understanding were wrong).

   I'm no sure, if gs output to the driver is really limited to 8bpp
   (is it?), but 8bpp is indeed a design limitation for the
   RenderTable in color rendering dictionaries. There may exists other
   RIPs which use an ICC profile instead of the CRD, but ghostscript
   as is, seems to honor strictly the PLRM regarding this issue, and
   requires a _CRD_ for color rendering (not an ICC profile).

Ghostscript does appear to offer, at least in theory, a 16-bit data
path.  How to actually use it is another matter.

   If the device color space is well linearized, I'm not sure, if the
   8-bit RenderTable is really an inacceptable limitation, since only
   the 3D grid points are quantized to 8-bit, but the interpolation
   between the grid points can of course be done with arbitrary
   precision, which should still permit smooth color gradients (if it
   is implemented carefully).

I think it would depend upon how dense the grid points are.  If you're
using a low resolution grid like 33x33x33 (which I believe I've read
is sometimes used), it's probably not all that big of a deal, because
you're not going to be all that far off relative to the low precision
of the grid.  If you were to use a higher resolution grid, I suspect
there would be a fair bit of roundoff error at certain points

   >To summarize what I think I'm hearing:
   >
   >1) Linearization should be performed in the driver.

   IMO also the generation of Cyan/LightCyan, Magenta/LightMagenta
   separations, since often simply CMYK profiles are used for CcMmYK
   printers, in this case the driver should accept CMYK input for a
   CcMmYK printer. If additionally e.g. orange and green colorants
   come into the play, a multicolor profile is likely unavoidable to
   utilize the full color gamut optimally. But of course, for CcMmYK,
   a multicolor profile could be used as well.

OK, that makes sense too.  Gutenprint performs channel splitting (my
name for cyan/light cyan) after linearization.  My own experiments
suggest that this needs to be performed with knowledge of all channels
rather than as a pure linear operation.

   Btw, does the IJS interface currently support drivers with a
   DeviceN (i.e. multicolor) ProcessColorModel?

Looking at the IJS source (gdevijs.c) in GNU Ghostscript 8.1, it
doesn't -- only DeviceGray, DeviceRGB, and DeviceCMYK.

-- 
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