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

[Chris Murphy]

Graeme Gill graeme at argyllcms.com
Tue May 10 20:00:25 PDT 2005


> 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 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.

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.

So today, you are essentially guaranteed that Photoshop and the  
driver will use different profiles - and you'll get an unwanted  
conversion. There are new APIs that will supposedly fix this, but new  
drivers have to be written using the new APIs. I'm not entirely clear  
on how the new APIs are going to work, but my understanding is that  
a.) #2 won't happen anymore; and b.) the profile ColorSync is going  
to use as destination will be made available to the sending  
application, and it will tag the data with that profile. Thus you  
will have source=destination and no conversion. But the custom  
profile is still not used to tag the spool file. Thus, the metadata  
is somewhere between "less accurate" and "totally inaccurate" because  
it's entirely possible to use a semi-gloss media with behavior  
completely unlike Premium Luster, yet have a custom profile that  
accounts for this.

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.

No, instead we have a convoluted system of lying, and random number  
generators on Mac OS X where the dog the pig and the pony have to do  
a square dance under a full moon in order for the right sequence of  
settings to occur to get the right thing to happen. Apple's  
documentation for how all of this stuff works is exceptionally poor  
(lesson #1 which I think the open source community has learned is a  
road to disaster) yet they expect application developers, users, and  
print driver vendors to all do specific things in order for the right  
thing to happen. There's way too much dependency and complexity, in  
my view.



> 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.
>

That implies two locations for settings. I won't buy that.

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.



Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
-------------------------------------------------------------
Co-author "Real World Color Management, 2nd Edition"
Published by PeachPit Press (ISBN 0-321-26722-2)