[Openicc] Linux CM ideology, was: meta data in test chart

[Chris Murphy]

I am a subject changer.


On Jan 27, 2011, at 1:59 AM, Kai-Uwe Behrmann wrote:

> Am 26.01.11, 14:05 -0700 schrieb Chris Murphy:
>> 6. Where is Linux going? What's the end game for color on the platform? Is the idea to eventually color manage every pixel? Is it going to be an opt-in or opt-out system? Deciding this makes a big difference on what language to use in GUI options, to how you allow applications to either opt-in or opt-out of color management on the platform. I'm not sure what this ideology is yet.
> 
> Managing every pixel is not easy with the curret stack. Too many
> component authors do not care and control is not possible at all. Opt-in would mean colour management is only for experts. We are working toward CM by default for non experts. I conclude we are targeting at a opt-out system.

To me, opt-out means color management happens unless the application says no. 

To do this for the printing pipline, it's straightforward, we've already discussed it: untagged is assumed to be sRGB, tagged objects have their profiles honored, conversions happen directly from sRGB or tagged space to output device space, and by default. GhostScript easily makes this possible now. We don't even need much of a user interface, except for the user to choose the output device profile and rendering intent. Any application that does not want color management to happen needs an "off switch" tag to insert into the PDF print spool file, similar to what we need for what I'm calling the "Graeme Options": All Off; ICC Off + Calibration On which appear in the print driver, in the Printer Profiles pop-up menu so that people can't choose conflicting settings. In this manner, user can ask for these behaviors, and the application can ask for them too. That's opt-out.

To do this for the display pipeline means much the same thing, but by default it would necessarily mean color managing every pixel at the window server level. (The window server is the functional equivalent of GhostScript.) Otherwise it's instantly opt-in, where only certain applications do display compensation.

Opt-in for display compensation. Opt-out for print pipeline. Doesn't this seem like problem?

> 
> For display colour management there is a very long tradition to just say sRGB everywhere. Interessted applications can show more than normalised sRGB by opting out of server side CM and do correction on their own. The CompICC display colour server and the belonging proposals support this.


I'm a bit confused. I don't think it's a good idea to have the window server doing some display compensation for "dumb applications" and then having other smart applications opt-out and do their own display compensation that's different. I would think if you're going to go to the effort of creating a window server that can do any sort of display compensation, you will find engineers (say from GIMP) who will help with that effort and optimize it, rather than having to build their own display compensation routines.

We do have the issue of what compositing space to use in any event. The window server could have cascading compositing spaces tied to hardware performance, automatically configurable with perhaps a simple "Better" and "Faster" option as a system level option. The cheapest option is Display RGB 8bpc, so that there's only one conversion to the compositing space, and no conversion leaving it. Simply go direct to display. But 8bpc Display RGB is a low quality option for professionals, which is why I was advocating 16bpc float and 32bpc float options, contingent on hardware. In that case there's a conversion into the composite space, and then one coming out of it for display. But the precision level avoids quality loss for pretty much all kinds of content.

Obviously most of this is up to the engineers who'd be involved.


> Gutenprint people for a long time wanted to improve colour through ICC conversion by default. The need to comply to the PDF standard seems a further hint for this direction to go.

Fine. That seems straightforward and with minimal GUI changes. And I like the idea of ICC by default. That will reduce a LOT of driver and workflow confusion by users. It's one of the great mysteries to me that Apple and Microsoft capitulated and allowed non-ICC proprietary printing to be the default on both of their platforms.


Chris Murphy