[Openicc] Print-colormanagement, application->CUPS->gutenprint

[Hal V Engel]

On Monday 18 April 2005 07:05 am, Michael Sweet wrote:
> Long answer: The driver never sees the "document colorspace" since
> it gets a rasterized version of the document in the destination
> colorspace specified through the PPD file.  An application might
> automatically choose a ColorModel in the PPD file appropriate for
> the current document (Adobe-defined values are Gray, RGB, and CMYK)
> however the driver can only use the destination colorspace (along
> with any other options the driver provides in the PPD file) as a
> hint - you won't know what the original colorspace was unless you
> parse the document yourself.

I am confused.  I just looked at the ppd file for my printer and the only 
colorspace listed is *DefaultColorSpace: RGB.  This appears to be a generic 
(non-device specific) color space.  Are you telling me that if I change this 
to point to a custom printer profile that CUPS (or what?) will do the color 
space conversion from the document color space (using the embedded ICC 
profile - for example AdobeRGB 1998) to this custom ICC profile before 
sending it to the printer?   Or is this something that is going to be 
available in an unreleased version of CUPS?

If CUPS or something else does not do device specific color space 
transformation and Gutenprint never sees the documents embedded profile 
(therefore it can not do this work) then NO color management, as I define it, 
can take place.  The most that can happen are conversions from one generic 
color space (RGB for example) to another generic colorspace (CMYK).   This is 
not color management since these generic color spaces can not by definition 
characterize the color space of a specific device.  Device specific 
characterizations (profiles) are a necessary prerequisite to color 
management.  That is the reason this list is named openICC.  We should be 
here to talk about how to implement an open ICC based color work flow 
infrastructure.   

I also had a look at my portage ebuilds for CUPS, GhostPrint, gimp-print and 
imagemagick.  Imagemagick is the only one that is dependant on LCMS or any 
other library that implements ICC CM functionality.  Imagemagick is listed as 
a dependency for gimp-print.   

Setting up printer color spaces is extremely complex.  By far the most complex 
devices that are part of the color work flow to characterize (profile).  A 
given printer could have hundreds of possible profiles since each possible 
combination of paper, ink, print resolution, dithering... (almost every 
possible driver setting other than paper size settings) requires a different 
profile to be totally correct.  In addition, each printer of the same model 
requires different profiles since these will behave differently because of 
manufacturing variations.  

In practice, I generate custom profiles for a limited number of combinations 
since these are the only ones that I use.  I suspect that most users doing 
ICC color management also only use a limited number of driver settings and 
media combinations in part to make the device characterization work as simple 
as possible as it is time consuming and requires a high level of skill.  But 
I typically have 5 or 6 profiles for each printer (not each model) at any 
given time.   I need a good way to manage these in conjunction with the 
related printer settings that go with each profile.   This needs to be simple 
to do for those who are responsible for creating and installing profiles but 
transparent to regular users.

At this point I do not think it is important what CUPS, GhostPrint or 
Gutenprint currently are doing.  What matters is what will these do once 
color management is implemented for the printer part of the ICC color work 
flow.  I think we need to go back to system design basics here.  When 
designing any system first you gather user requirements.   I believe that 
this is where we are at and until such time that we have these requirements 
in hand it will be difficult to make any progress. 

How do we go about doing that?  There are at least two subscribers to this 
list that have experience with ICC based color management.  One of these 
actually earns his living doing this work and should be considered a subject 
matter expert.  We should leverage that experience to put together a detailed 
set of user requirements.  These requirements should be at a high level and 
should not make reference to any existing systems.  I believe that once those 
requirements are understood that the design phases will not be particularly 
difficult and the way forward will be fairly apparent.

Hal