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

[Hal V Engel]

On Monday 18 April 2005 06:12 pm, Michael Sweet wrote:
> Hal V Engel wrote:
> > ...
> > This is exactly the point that I was trying to get across.  This is not
> > about users that don't have exacting color output requirements.  I am
> > sure that most of those users are perfectly happy with how this works
> > now.
>
> The currently available open source drivers are capable of excellent
> quality, but configuring the drivers for optimal quality is something
> that many users just aren't up to.  On the ease-of-use scale, the HP
> IJS drivers are among the easiest and the most limited from a color
> management standpoint, and Gimp-print/Gutenprint is by far the most
> difficult to use and very advanced from a color management standpoint.

Again from my point of view Gimp-print/Gutenprint does not have color 
management.  Sorry but that is the way I see it.  Gimp-print/Gutenprint does 
have good color output with standard ink sets but is totally off base and 
requires extensive tweaks and manually applied custom profiles to get close 
with 3rd party inks such as archival inks from MediaStreet.  

I think some of us are confusing getting fairly good colors on printed output 
with color management.  Color management is an end to end process and it is 
about how consistant the colors are all the way through that end to end 
process.   Printing is just one of the possible last steps in the process. 
This is something that is very difficult for those who have not worked in a 
ICC based work flow to visualize and understand.  

For me it starts in the field when I am shooting photos and ends when the 
output comes off the printer.  It is part of every step in the work flow in 
between.   When the image comes out of the printer I want and expect it to 
look almost exactly like the scene in my view finder did when I tripped the 
shutter. ICC is a necessary thread that runs through and connects everything 
in the work flow that gives me at least a fighting chance that that will 
actually happen.  I have now gotten to the point were it happens for me most 
of the time.  Gimp-print/Gutenprint does not support that thread at this 
time.  So to say it has it has color management is erroneous.

I don't want the above to be taken in the wrong way as there are many that 
don't understand what color management means.  One major example is Microsoft 
which claims that Windows supports color management.  They even have places 
where the user can install ICC profiles for the display and printers.  But if 
you try to work with this stuff you find out that it simply does not work the 
way it should.    In most cases users figure this out only after working very 
hard trying to make it work.  Many give up out of frustration having never 
gotten it to work thinking that this color management stuff is BS.  
Eventually some users figure out that what Microsoft is calling CM is really 
a bunch of junk that was thrown together in a hurry by someone in Redmond who 
had no idea what he was doing and that to do CM on Windows you must do 
everything manually.  For Windows users there  are a few applications that 
are CM aware and that allow the user to do what is needed to implement a 
manual work flow (Photoshop, Vuescan, Silverfast AI).  There are now rumors 
that they are doing a major rewrite of the CM systems for Longhorn.  Could 
this be because they messed up bad the first time? 

>
>  > We are
> >
> > talking about the needs of those users that have very exacting color
> > management requirements.  Photographers, artists and graphics
> > professionals not Joe user who is printing an Open Office document. 
> > These are two totally different sets of users with totally different
> > requirements.
>
> Certainly a user that only prints text documents from OpenOffice has
> lower expectations and requirements than a professional, but *all*
> users want color management that works whether they are printing
> line graphs or pictures from their digital camera.
>
> The difference is that the professional typically knows what ICC is,
> owns hardware and software to general color profiles, and wants to
> use them in their workflow.  Joe user doesn't care how it gets done
> and wants things to work out of the box.
>
> Since ICC can provide a solution for both kinds of users, and we
> want to support both Joe user and Jane professional, then we
> should address both users with the same core technology!
>

I agree that using ICC based CM is the best approach for both types of users.  
I only said that the needs of advanced users were significantly different 
from other users.  I am concerned that we will end up with a Windows like 
solution where there is a general purpose profile that is installed in the 
"driver" (in the CUPS ppd file in our case which hopefully will work 
correctly unlike Windows) and if you want really good output you have to 
resort to manual printing work flows to buy pass the "driver" CM.  There are 
a number of problems with this approach.

1. It makes it very difficult if not impossible for an expert to configure the 
system to do it's absolute best for non-experts.

2. It makes expert users who would most benefit from being able to setup a 
fully automated CM work flow use a manual work flows which:

  A. Greatly increases the difficultly of doing CM on an ongoing basis.

  B. Increases the probability that the user will make mistakes while working 
through the work flow.

  C. Significantly increases the amount of effort needed to setup a working CM 
work flow.

  D. Require more training for other users that will need to use the advanced 
workflow to get the results they want/need.  There are users that may never 
understand how to use the advanced work flow.

3. It makes CM less accessable to intermediate users who likely would find a 
manual process too burdensome but who would derive significant benefits from 
using a full blown CM if it were more accessable.
 
>  > ...
> >
> > A symlink from where and to what?
>
> Again, beyond the scope of CUPS, however the CUPS profile directory
> is /usr/share/cups/profiles.  I envision a symlink from ~/.profiles
> (which contains all of a user's profiles) to
> /usr/share/cups/profiles/username.
>
>  > How do I specify that for printer W
> >
> > (meaning a specific physical printer), at resolution X, on paper Y, with
> > dithering algorithm Z, ink set A.... that this is the correct profile and
> > rendering intent to use with a symlink?  I must have that level of
> > control or this does not do the job.  This is a high level requirement
> > and I don't care how it is implemented but I don't see how this is
> > possible with a synlink. Perhaps you could spell this out for me so that
> > I understand how this would work.
>
> CUPS 1.2 will allow you to specify a profile filename to use with a
> job.  It is up to you to name your profiles so you know which
> printer, media, and other settings apply to each profile, or have a
> smart UI which reads this info from the ICC profile and displays it
> for the user (or does the selection for them automatically...)

So the symlink makes the users custom profiles available to CUPS which still 
leaves the work flow issues unresolved.  Got it.

My concern here likely is not a CUPS issue but rather more of a UI issue.  I 
would like to be able to "package" (for lack of a better term) printer 
settings information for a specific print configuration up in a way that 
makes it accessable to users of all abilities.  And to administratively have 
the ability to make that printer settings "package" available to all users or 
selected users.  The printer settings "package" would contain a set of driver 
settings and CM information such as profile, rendering intent and black point 
compensation flag.  

So how might this be done?  This is just one possibility that perhaps could be 
kicked around some.  Visualize the gimp-print plug-in The GIMP uses.  In that 
plug-in you can create a "logical printer" that ".. can be used to name a 
collection of settings you wish to remember for future use."  Now add a few 
new fields such as ICC printer profile, rendering intent, black point 
compensation and the ability to make the driver always handle the data the 
same way and the hooks to pass the CM information through to CUPS and you are 
most of the way there.  In fact this is all that is needed for single user 
workstations assuming that we are only concerned with printed output from 
apps that use the gimp-print plug-in. 

For multi user systems you would add the following.  Give administrators the 
ability to lock down the settings for a "logical printer" and make this 
available to other users on the system.  Then add the ability to make the 
print dialog that uses these "logical printers" the default system print GUI.   
Assuming that this correctly interfaces to CUPS to handle CM you have a 
solution to the printing work flow problem that provides for both expert and 
normal users. 

This would allow administrators to set up general purpose and draft "logical 
printers" for things like printing OO documents that would use the generic 
CUPS CM and perhaps print at lower resolutions...  But also setup special 
"logical printers" that would use customized CM settings with custom profiles 
for printing photos or other high quality output.  All users on a system 
would then have access to the very highest quality output when they needed 
it.  In a way that made it totally transparant to them that they were in fact 
using something that was customized and different.  It would also make these 
capabilities available from every application not just CM aware apps.

Adding the additional fields to the plug-in would be easy and I suspect that 
setting it up to pass the addition arguments to CUPS would not be very 
difficult.  In fact I would be willing to bet dollars to donuts that Robert 
or one of his people could have this done in short order if they decided to.  
But putting together the multi user administrative stuff could be a real 
challenge since there are likely all kinds of issues that would need to be 
resolved.

I guess that I just added two new requirements for the CUPS interface.  The 
ability to receive and for CUPS to handle rendering intent and black point 
compensation.  Sorry but these will be needed in the long run.  Maybe these 
could be added in CUPS 1.2.1?

By the way when will CUPS 1.2 be released for us non-Mac users?

Hal