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

[Hal V Engel]

On Tuesday 10 May 2005 08:00 pm, Graeme Gill wrote:
> Chris Murphy wrote:
> > driver correctly set. Choosing a color   management setting OTHER THAN
> > ColorSync in the print driver causes  the OS to use Generic RGB as the
> > destination profile. Since source is  Generic RGB, and destination is
> > Generic RGB, you get a null transform  of this prematched data. But both
> > source and destination tags are  totally bogus, and must be bogus, in
> > order for this to work (which is  why apps that prematch data, like
> > Photoshop, submit untagged data; if  they submitted tagged data, you'd
> > get an unwanted conversion by the  OS even if you explicitly do not ask
> > for one).
>
> In theory Photoshop isn't doing the right thing. If it's converting for
> the output device, it should tag it with that profile. The print driver
> will then notice that the data is already in the output devices colorspace,
> and not touch the data. The only "gotcha" is if Photoshop and the driver
> are using different profiles for the same device. In theory, an operating
> system supported CMM avoids this by having a universal place to register
> the output device profile, and both Photoshop and the device driver should
> have used this mechanism to locate the (unique) output devices profile.
>
> An alternate mechanism that could be implemented in a CMM would be to
> support meta-profiles, which would indicate something like "in the
> device color space", or "don't color correct", effectively turning
> off any subsequent color conversion. This could be more confusing
> though, since it's an exception mechanism, and causes more problems
> if the file is pipelined to other processes.
>
> I suspect that a lot of the confusion here is due to mixed conventions
> for handling un-tagged data. One convention says to assume that un-tagged
> data is a default (system or application defined) colorspace, and then
> treat it as tagged data from then on. Another convention is to assume that
> un-tagged data indicates an (unknown at that point) device colorspace,
> defined by the overall workflow, and should be passed on as un-tagged
> (maintaining the information that the data is un-tagged). A device driver
> in this convention would assume that it is connecting to the device that
> defines the colorspace of the overall workflow, and that data should be
> used "as is", and sent directly to the device.
>
> Graeme Gill.

Don't know about how this works an a Mac but on Windows the printer driver, at 
least for the printers I have used,  defaults to a setting that does not use 
the built in CMM or profiles.  In addition out of 4 or 5 color modes 
available in the driver only one of these is for the driver to do CMM with 
the installed profiles.  One other mode is an "as is" mode (at least on 
Windows) and the other modes involve the printer making automatic 
adjustments/enhancements or allowing the user to manually control how the 
image is printed (color balance, contrast and gamma/brightness) without CMM.  

My experience is that the CMM mode in the printer driver is totally borked and 
as far as I know is not used by anyone doing serious color work and because 
it is not the default more is not used by "normal" users.  In fact Epson 
specifically recommends not using the driver in this mode for those doing 
color management.   So even though Photoshop is broken with respect to CM in 
that it does not embed the device profile into the image before sending it to 
the printer I believe that this is an attempt to allow the user to manually 
control the printing CM work flow to over come these printer driver/OS 
problems.  

My printing work flow on Windows, this is the same one recommended by Epson,  
is to setup the printer driver in the "as is" mode and then handle the CM 
work in the application which in my case is Photoshop.  This works but is far 
from an ideal solution and in fact I am only using it because the printer 
driver/OS CM is broken and can not be used as it is implemented today.

Of course, we are replowing old ground and I think for the most part everyone 
here understands what the problems are on Windows and the Mac.  I also 
believe that everyone here would like to avoid these problems when CM is 
implemented in our open source projects.  To address these problems an 
overall CM framework is needed so that everyone implementing systems knows 
what they need to do to fit into the CM framework.  This requires a very 
broad spectrum of participants while beyond just those involved in 
implementing the printer subsystems and graphics applications.  So far I 
would estimate that 80% to 90% of the activity on this list has been centered 
on the printing subsystem and those involved with systems like windowing, 
desktop environments, scanners and cameras have not been engaged in this 
discussion.  But to design a CM framework we need to have these other groups 
involved.   Anyone have any ideas on what we can do to get these other groups 
involved?

By the way welcome to the list Chris.

Hal