[Openicc] Re: Hello *and* (was): LINUX, Gutenprint / CUPS / Color policies

[Robert L Krawitz]

   From: Chris Murphy <lists at colorremedies.com>
   Date: Thu, 12 May 2005 10:52:34 -0600

   On May 11, 2005, at 11:43 PM, Graeme Gill wrote:

   > In the tagged view of color, every element that handles color data
   > has some mechanism available to convert from the colorspace the data
   > is in, to the colorspace that processing element needs it in to do  
   > its job.
   > This conversion could be handled almost transparently by other
   > OS elements, or might be quite explicit within the print driver.
   > A printer driver (in the broad sense) has a primary job of seeing
   > that the graphic information it is given, is transformed into a
   > form suitable for the printing device. Making sure (by whatever
   > underlying mechanism) that the color space is correct for the
   > printer is fundamental.

   A driver ensuring conversion from pixels to commands to produce
   droplets in a reasonably consistent, predictable and logical manner
   is fundamental. Colorimetric accuracy is not.

That's easy -- just produce linear amounts of ink between 0 and 65535
for each input color :-)

There's more to it than that -- if the input is RGB, black generation
needs to be done in a reasonable way, and presumably you want good
linearization, and generation of extra inks if needed.  Things like
that are exactly what we have to figure out.

   No print drivers from the major manufacturers perform color  
   management with a particular print job containing multiple source  
   profiles. On both platforms, this is deferred to the operating system  
   to manage with input from the printer driver based on print dialog  
   settings.

I wasn't aware that either Linux or BSD did any color management in
the OS :-)
	     
	     In-driver color management is limited to black box color  
   management with an assumed source space and destination space of some  
   kind, along with the various ink limiting and black generation they  
   choose to use for each paper type. I  haven't heard a compelling  
   argument for making printer drivers more sophisticated in this  
   regard. More complexity means more points for failure, and  
   differences in behavior from printer to printer, and that doesn't  
   help anyone. They are already complicated enough, and lacking  
   sufficient documentation on Mac OS X, at least, that the CMS isn't  
   getting correct information from the driver and thus the whole  
   shebang is busted. Putting more dependency on successful outcomes on  
   driver developers, I think, will only make the problem worse.

Again, remember that there's at least one driver developer on this
list (me), and hopefully there are folks from the other major free
source printer driver projects (HPIJS, Omni) here too.  I joined the
list explicitly to work out what to do with color management in
Gutenprint 5.2.  We wanted to get color management into 5.0, but we
never did figure out the right thing to do, and it's probably just as
well we didn't do something, because it probably would have been
wrong.  So the right people are here to do something about 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