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

[Graeme Gill]

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.