[Openicc] [Gimp-print-devel] [Printing-architecture] Colour

[Chris Murphy]

It depends entirely on how it's implemented.

All driver dialogs on Windows and Mac OS (not sure about Linux, but I suspect it's the same) are not the actual driver itself, merely the OS drawing those features on-screen. The user makes the settings, including a "No Color Management" option. But that selection does NOT directly communicate with the driver. It's capture metadata that the operating system includes into a print spool file (and/or corresponding job ticket file). Later, that print spool file and included metadata with the captured driver settings, is passed onto the manufacturer's print driver and interpreted - i.e. you get the "Off" LUT instead of an sRGB LUT or Adobe RGB LUT.

So that's already a "smart" or "automatic" mechanism, because there is no direct mechanism anyway.

Further, on Mac OS X for some time now, there is no explicit off switch for ColorSync. Apple requires multiple square dances with a dog, a pig, and a pony, under a full moon, in order to get ColorSync to piss off. ColorSync is only turned off through null transforms. Only when the source profile for content is identical to the destination profile, is ColorSync disabled.

In order to make this work, Apple has a rather convoluted mechanism for certain applications to request, NOT the disabling of ColorSync, but to get the current canned manufacturer profile registered for a particular print mode. The application must then bogusly tag objects with that profile, in order to achieve this null transform.

And as we are seeing with the clusterf8ck.com situation we've got going on with Mac OS X, newer Epson drivers, and Photoshop, we've got ColorSync converting ICC profile targets. And if we recall history, we've had all kinds of problems with Mac OS X and printing color reliably.

In my view, Apple made a colossal mistake by attempting to follow a PDF/X-3 like format for their print spool file format, but then deciding to go on a vendetta against DeviceRGB which is a rather important color space in  PDF/X-3 to explicitly indicate such content should not be color managed if the content is sent to the device it was intended for. Instead, Apple is double tagging the PDF spool file: first the individual objects are aways being tagged, instead of say prematched data and profile targets being set to DeviceRGB, and then yet again with an OutputIntent profile.

Now, the OutputIntent tag should always be set to something. That indicates the intended output space, and for prematched data can be used to soft proof the print job before it goes to the printer. But in the case of calibration/characterization/prematching, the color space for those objects should be DeviceRGB (I am referring to desktop inkjet printers, treated as RGB output devices). But Apple has banished DeviceRGB and disallows any specialized applications from using it. Instead, they require the object to be tagged with a profile, and for the OutputIntent to also be set with the same profile. If an application does not submit a source profile for its content, the OS will assume a color space and tag that data when the PDF spool file is written to disk. So there is no way around this. (Generic RGB is what's used on 10.5 and older, sRGB on 10.6 and newer).

Apple has argued that untagged data is evil. Yet the great thing about PDF/X-3 (or X-4 or X-5) is that DeviceRGB is special because it is an explicit indication that content to the intended device is not to be color managed, but it still has an implicit source profile. And that's the OutputIntent. So DeviceRGB isn't untagged.

The problem is, driver vendors who don't get their print modes and associate profiles, and default profiles, registered correctly with the OS for some reason. It's been an on-going problem. Canon had the problem and seems to have fixed it. HP had the problem, and seems to have fixed it. Epson had the problem, and sometimes gets it fixed, and them sometimes (like now) regresses back to broken behavior. When they don't work correctly, it can mean ColorSync will become invited to the party when it wasn't asked to, but more importantly when we don't want it to: calibration/characterization/prematching.

So, a user selectable off switch we do not have. And we don't even really have a developer off switch either, but rather an indirect means of doing this through a convoluted, and unreliable, null transform dependency.

If the architecture is designed correctly to fail safe, instead of fail chaos,we would not need a driver option for Off (No Color Management). That option, is a big fat lie anyway. Obviously color management of some sort is required because inkjet printers do not have merely three inks comprised of red, green and blue.

The primary use case, 99% is for users who simply want to get a decent print. I agree with Michael Sweet that there are too many color options in all drivers and that needs to be reduced. It's another matter entirely though, if printer manufacturers would accept the idea of losing their proprietary color matching being stripped entirely, in favor of only an ICC based solution. I certainly have no problems with this in theory, but I do see why those manufacturers depend on it, given the continuing inconsistencies we have even on one operating system, version to version, let alone among platforms.


Chris Murphy


On Nov 13, 2009, at 9:25 AM, Graeme Gill wrote:

> edmund ronald wrote:
>> Actually, the only color mode I cannot live without is "No Color
>> Management", which can also be called "Application Color Management"
> 
> I've got to say that talk of removing "No Color Management"
> makes me uneasy from a support and diagnostic point of view.
> It's far too easy for "smart" or "automatic" stuff to be
> doing the wrong thing, particularly in color management,
> and some mechanism to diagnose such workflow problems
> is essential.
> 
> 
> 	Graeme Gill.
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc