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

[Graeme Gill]

Chris Murphy wrote:

> In practice Photoshop isn't doing the right thing, because in  practice 
> Apple isn't doing the right thing. :)
> 
> 1. If the end user prematches using a custom profile, and Photoshop  
> tags the spool file with that custom profile, there will always be a  
> mismatch, and you'll get a double conversion. The space the print job  
> is converted into is a canned profile which will give inferior  results 
> to the custom profile. The only way to prevent this is to go  into 
> ColorSync Utility everytime you want to print using a custom  profile, 
> and ensure you set the custom profile in there as well as in  Photoshop. 
> That's just a b.s. workflow scenario in my view. You can't  have end 
> users selecting a profile twice in order for the operating  system to 
> get out of the way, and the ColorSync Utility is buried as  well.

I get a sort of grim amusement out of all that. When ColorSync was
first announced, there was a lot of fanfare about how it was the
right thing for color management, to "build it into the operating
system". My reaction was "huh - what's color management doing in
an OS kernel ?". Of course what was happening was that Apple were
overstating the case. What they meant was that it is a good
thing if the operating system environment mandates some conventions
for handling color, and even provides some mechanisms to make it
easy for applications to comply with the conventions. It's kind of
sad that it has devolved to the point where even the simplest
conventions (what profile corresponds to what device) has broken
down. Perhaps this is Adobe's fault for not playing the game, or
perhaps it's Apple's fault for not making it possible for Adobe
to do what they want.

If it was all working properly, it should be possible to select
the target colorspace as a system output device, as well as a color profile.
You'd select Printer X in mode Y (implying a color profile for
that device, stored in some OS configuration) as the target, and
that would tag the output of Photoshop. Assuming the document was then printed
to Printer X in mode Y, the driver would notice that it didn't need
any color conversion.

> 2. If the print driver doesn't report the correct media type profile,  
> you also get a conversion. And currently most, if not all of the  Epson 
> printer drivers always report the "Standard" media profile, not  the 
> correct one. So you'd essentially always get an unwanted  conversion. Of 
> course this is an Epson problem, but the way they do  development, by 
> the time the product ships, it's obsolete. There are  no substantive 
> updates after that. So we have an entire legion of  drivers (from Canon 
> and HP even) that simply don't do the right thing.

Is it an Epson problem or an Apple problem, in that the OS API's don't
have any way for the printer driver to communicate subtlety, such as
the fact that there are multiple modes, with corresponding profiles ?

There are a couple of possible workarounds that spring to mind
for this type of problem (if the mode/profile explosion can't
be tamed or represented easily in an API). e.g. Have a printer
driver mode that doesn't do any further color conversion if the
incoming file is tagged with any of the printers profiles (ie.
ignore print mode caused profile differences). Another would be
to have system Device meta-profiles available to tag the data,
which effectively label the data "setup for Printer X", causing
the driver to not do any further color conversion on the file.

> The solution is provided very easily by the PDF/X-3 model. You can  have 
> /DeviceRGB, /DeviceCMYK, /DeviceGray data, to clearly tell the  OS and 
> driver to do no further ICC-based color management; and yet  include an 
> output intent. The output intent would be the actual  custom profile 
> used to do the conversion. That's an implicitly tagged  file. The output 
> intent is an assumed source profile for the purpose  of soft proofing 
> (or hard proofing), but is ignored when printing the  file on the actual 
> output device its intended for.

Hmm. For proofing purposes though, "DeviceRGB/CMYK/Gray" are not ignored,
but are converted from the emulated device space to the actual printer space.

> A big part of the reason why people who care about quality do  
> conversions in Photoshop in the first place is because neither  Windows 
> or Mac OS have system level APIs for black point compensation  - which 
> has been documented by Adobe and can be found in a document  at the ICC 
> web site. In my view, the OS should be responsible for  providing UI in 
> the print dialog for black point compensation and  rendering intents. 
> That way these functions are available from any  application or print 
> dialog. Apple seems to expect this only be done  in applications, which 
> quite frankly I find silly to put this burden  on every developer who 
> wants to print. There's already a ColorSync  section, provided by the 
> OS, in every print dialog, I don't see why  these settings can't be made 
> there. But I digress...
> 
> Fact is, we now have applications that prematch data, and both  Windows 
> and Mac OS are ignorant of this fact. In the future, I think  if 
> operating systems provide sufficient controls to all applications,  and 
> keep up with changes in technology, applications won't have need  to do 
> these print level conversions themselves. They can simply  submit the 
> print job with all source profiles for each object intact.

I'm not sure that would fix it. Part of the reason why people want to
pre-match data, is that they are unhappy with the OS provided mechanisms.
This probably won't change, even if the OS provided mechanisms are improved.
In theory, what was meant to accommodate this sort of wish, was that
the OS's provide the ability to plug in and select alternate CMMs.

If this worked smoothly, you could plug in the Adobe CMM, and then
rely on the print driver using it to do the exact same processing
you are doing in Photoshop manually. The plug in mechanism would
(of course) provide all the setup information (such as BPC) that
that particular CMM needed.

Graeme Gill.