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

[Chris Murphy]

Graeme Gill graeme at argyllcms.com
Wed May 11 19:28:58 PDT 2005

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

One lesson is that if operating systems provide color management that 
isn't sophisticated enough for a particular application (or an entire 
class of applications as is the case here), then it's self evident the 
developer will code features they deem necessary directly into the 
application.

Another lesson, is that OS's should provide a means for applications to 
do fancy, proprietary color matching, through a "pass through" feature 
that ensures such application data untouched by OS-level color 
management.

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

There is such a system in both Windows and OS X. It just doesn't work 
on OS X because the manufacturer drivers don't specify the correct 
profile ID which correlates driver settings to a particular profile set 
in the ColorSync Utility. That there are so few drivers that do this 
correctly makes me wonder if the documentation or existing API's in Mac 
OS X are the stumbling block, rather than some almost universal 
"problem" with 3rd party print driver developers.


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

I don't fully understand the question. The manufacturer can choose any 
combination of driver settings they want, and distill that into a 
ProfileID. The actual profile associated with that ID is selected in 
the ColorSync Utility as "sub-devices" to the primary device (there's a 
term for this I'm sure, but I don't know what it is off hand). For 
example, Epson registers a media type for each printer, that matches 
all of the media types supported for that printer. If they wanted to, 
they could register based on media type setting as well as resolution 
(a different ProfileID for resolution *and* media type), but they 
don't. This is also not user changeable.

The problem is that these so called "tioga" drivers aren't reporting 
the Profile ID for actual media type settings, and if ColorSync in the 
driver is selected, only the ProfileID for the default registered 
"sub-device" gets used regardless of driver settings.


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

I'm inclined to not dump solutions to the problem where the problem is 
already occurring - on the driver. Asking developers to put in yet 
another mode, and the parsing needed to determine whether or not that 
mode should be used or not, when they aren't doing the correct thing 
now isn't going to get us anywhere, IMO. I don't know this for sure, 
but I strongly suspect the problems are the result of poor 
documentation. Hey, it works on Windows, fancy that.

Plus, this solution requires not only a change to drivers but a change 
to applications. This will take another 18 months before the APIs are 
in place and months after that for new applications and drivers to 
appear. That's why I like *simple* solutions.

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

I do not believe the driver should be determining whether or not to 
convert a file at all. This arbitration should be done by the OS. All 
the OS needs to know is whether the application has already prematched 
the data, or not.  If it has, do nothing. If it hasn't, then boolean 
conditions apply to determine if and how to color manage the print file 
(based in part on print dialog settings), and then finally rasterizing 
and sending it off to the driver for whatever its going to do 
(proprietary color management or not, resampling, sharpening, 
screening, etc.)

I'm no developer but I'm guessing the specific part of the OS that 
would do this arbitration is the the one that consumes the spool file, 
which contains all of this information in it. At least on OS X, this 
would be the cgpdftoraster filter which is reading the spool file 
(which is PDF-based in OS X).

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

Yes, that's expected in a PDF/X-3 model - such as for soft proofing. 
The output intent is the assumed source for the prematched data in the 
spool file (which in this context is all /DeviceRGB); and the 
destination profile is the display profile. For hard proofing you'd 
substituted some other output device profile for the destination - but 
this functionality of hard proofing or redirecting print jobs to some 
other printer isn't presented to the user with built in UI. (You can 
get the same end result using Quartz filters, but that's another 
conversation.)


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

I'm not suggesting a fix for something that can't be fixed by anyone 
other than the OS vendor. I'm suggesting that the OS vendor shouldn't 
sit on their laurels, not providing what is now considered a basic 
color management function: black point compensation. That the drivers 
are broken, and Mac OS X provides no interface to access rendering 
intents when printing (it's left up to the application sending the 
print job) means there is a place for a "don't do anything" approach. 
I'm definitely not suggesting getting rid of that. Quite the contrary. 
I just don't like how Apple has decided to provide us a "pass through" 
option for prematched data, which mandates the app send untagged data, 
the OS improperly tagging the spool file with Generic RGB (bogus source 
profile) and claiming a bogus destination profile for the printer (also 
Generic RGB) in order to get a null transform. It's not quite a Rube 
Goldberg contraption.


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

Interesting you bring this up because we've had a regression in that 
area of Mac OS X from OS 9 as well. If you selected a 3rd party CMM as 
the preferred CMM, it would be used short of an application preference 
for something else - for any conversion including printing. On OS X, 
the Apple CMM is hardwired for printing - so if you use a 3rd party CMM 
for on-screen previewing you'd like get a different result in print.

And in 10.4, we no longer have a UI for the user to even select a 3rd 
party CMM, because that UI was removed.

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

At this point that's a lot of wishful thinking: no UI in OS X for that 
anymore, Apple CMM hardwired for printing, and Adobe CMM is not 
expected to be available as a plug-in CMM. Besides, I'm not even 
convinced that black point compensation is even happening in ACE anyway 
because in Adobe applications you can use black point compensation with 
any CMM, not just theirs.


Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
---------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"
Published by PeachPit Press (ISBN 0-321-26722-2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 9061 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/openicc/attachments/20050511/4714a2ce/attachment.bin