[Openicc] LINUX, Gutenprint / CUPS / Color policies

[Robert L Krawitz]

   Date: Thu, 14 Apr 2005 21:20:09 -0400
   From: Michael Sweet <mike at easysw.com>

   Robert L Krawitz wrote:
   > ...
   > Except that it's very hard to pass arbitrarily complex data (ICC
   > profiles or linearization curves) through CUPS to the driver.  So if
   > someone puts a lot of effort into creating good linearization curves,
   > it's going to be very hard to actually use them.

   You want to pass arbitrarily large device profiles as job options.

Exactly.

   CUPS supports IPP attributes with opaque data (bytes) and/or arrays
   of data which are passed to the driver.  The maximum size of any
   single value is 65535 bytes, and the maximum number of values in an
   array is 2^31-1...

I think even we can live with that.  At worst, we represent curves as
arrays.

   > Yes, but if there's only an 8-bit data path between CUPS and the
   > driver (as is the case right now) there is an to doing the color
   > management in the driver: greater precision.

   Sure, but you've already run into limitations with that approach,
   namely the difficulty in passing parameters and the hardcoding of
   profiles into the driver.

Yup.

   Also, CUPS, ESP Ghostscript, and MacOS X will all include 16-bit
   support very soon, long before there is a "standard" defined here...

   > ...
   > basically agree to disagree.  Commercial RIP's aren't particularly
   > simple when you really want to tune them, from what I understand.
   > ...

   My experience with commercial RIPs (mainly EFI stuff) is that they
   don't provide knobs for tuning.  You pick resolution, media, and
   CMYK emulation, and they do the rest.  Some provide options for
   overall CMYK densities, but you can't pass in your own custom
   profiles - they have to be applied by the application prior to
   printing.

The screen shots I've seen in Real World Color Management show all
kinds of knobs for controlling GCR/UCR, curves, etc.

   I'm not arguing that we duplicate or depend on this interface, but
   understand that a lot of people use "dumb" CMYK-based workflows so
   we still need to support that kind of usage...

I agree.

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