[Openicc] Gutenprint team requests CM-off for a print queue be provided as a maintained engineering facility.

[Michael Sweet]

Chris,

On May 11, 2012, at 9:43 AM, Chris Murphy wrote:
> ...
> The problems on Mac OS are very specific:
> 
> 1.  /DeviceRGB is banned and ipso facto this demands the insertion of bogus tags in order to achieve the equivalent of "off" which is the null transform: an interpretive off switch, not an explicit one.

It's not that /DeviceRGB is banned, it is that /DeviceRGB is interpreted as sRGB by CoreGraphics and you need to use OutputIntents to effectively turn it off (to say that it isn't sRGB but the device RGB colorspace reported by your driver or registered by the user).  I think everyone in our team thinks this is less than optimal but is a "necessary evil" until we figure out something better to deal with the multitude of PDF files that use DeviceRGB but really mean sRGB (or some display RGB).

> 2. The SPI for applications to achieve this null transform (hopefully) is private. It's not a public API.

Correct, but it is provided by the developer relations folks to any app developer that needs it (profiling tools, professional graphics tools with built-in color management, etc.)

> 3. An overly complicated imaging and printing pipeline, in particular as it relates to color, without commensurate documentation with detailed explanations and examples.

Documentation is an issue.  Any perception of complication is a factor of the lack of documentation and the errors in implementation by driver developers (partly because of the lack of documentation and partly out of preserving previously broken behavior in order to provide consistency).

I can only say "we are working on the documentation" and on convincing vendors to not propagate broken behavior.

Fundamentally the OS X printing system supports two main kinds of color management:

1. ICC profiles - DeviceGray, DeviceRGB, and DeviceCMYK only
2. Standard colorspaces
   a. Raster drivers mainly use GenericRGB, sRGB, and AdobeRGB, selected using a PPD keyword
   b. PostScript drivers typically map sRGB, but we do color dictionaries and CIE where appropriate/necessary
   c. PDF drivers/printers are typically pass-through of whatever is in the PDF.

There is a application-level interface (that private SPI) that embeds the necessary OutputIntents to match the application output to the specific ICC profile or standard colorspace, resulting in a "null" transform needed for target printing and application color matching.

There is also a driver-level interface allowing the use of both standard color spaces and ICC profiles. The standard color spaces are typically used for regular printing of web pages, documents, and quick photos, while you go to ICC profiles when you stick in your expensive $5/sheet photo paper for that important print of your portrait of the Mona Lisa 2.0.

The critical flaw in all of this isn't the SPI (I'd like it to be public and simplified, but it *does* exist for those that need it) but the printer drivers.  Unfortunately, even if you tell the printer driver that you are doing "application color matching" or "ICC-based color matching", many of them do not turn off their own internal color matching and enhancements ("vivid color", "red eye removal", etc.) resulting in some unfortunate interactions.

Another problem with the current implementation is that ICC profiles are not tied to the options used to print the target and generate the profile.  Users will turn every knob trying to get "right color" and end up never producing consistent results.

> I see no risk of 1, or 2 occurring in any Linux distribution.
> 
> I think the OpenICC's position should mere be that: there must be a clearly, and publicly defined mechanism for disabling system level color management. 

I think that is a misnomer - color management is always there.  What you want is a way to say "treat this as device color" so that only minimal processing (e.g. floating-point to discrete values) is performed. I can't say that the way we do it on OS X is optimal since, well, it isn't, but it does clearly define which device/output colorspace is intended.  The issue is making sure that the print settings (and profile) match the document being printed (thus the complexity of the current SPI) - the application and printing system need to agree on what is being printed.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair