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

[Hal V. Engel]

On Thursday, January 27, 2011 01:19:28 pm Chris Murphy wrote:
> 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.

GIMP and other "smart" open source applications are already handling the 
transform to get things into the display color space.  What these don't have 
at this point, with the exception of CinePaint, is the code to tell CompICC 
that they will handle this.  What CompICC does is extends CM to everything 
else on the desktop (IE. all of the dumb apps).  But at least in theory I 
agree that it would be better to have apps that understand CM use underlaying 
system level CM support if it is available since this has a number of benefits 
such as improved performance because it will be using the GPU for this work.  
CompICC is so new that it will take some time and effort to get 
everyone/everything on the same page so that this happens.

The path forward will likely come in stages.

1. Get CompICC mature enough that it can be considered production quality.  I 
think it is fairly close to this now but it does need more testing and perhaps 
some fixes if that testing finds issues.

2. Convert existing CM aware programs to detect the presence of CompICC (or 
some other similar system level code) and issue an Opt-out.  This is a very 
simple thing to do to these apps since it leaves the CM code in these apps 
alone.  Keep in mind that these apps need the non-CompICC CM code path to run 
correctly on Windows so this will likely not be removed in the foreseeable 
future.

3. As the work can be done convert CM smart apps to use the system level CM 
path for screen output.  This will take some effort and likely will not happen 
until everyone is convinced that CompICC (or similar) is mature.  Also these 
apps will need to retain the non-CompICC CM code path for other OSes like 
Windows. 

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

I believe that CompICC is using an OpenGL shader to handle the transforms and 
OpenGL supports a number of bit depths in the following formats:

unsigned normalized 2, 4, 8 & 16 bits
signed normalized 8 & 16 bits
signed and unsigned integral 8, 16 & 32 bits
floating point 16 & 32 bits

I am not sure which of these CompICC is using but I think it is one of the 
higher bit depth formats.  In any case this should be at least one of the 16 
bit formats supported by OpenGL if not one of the 32 bit formats.  With modern 
GPU hardware I don't think that there is a significant performance penalty for 
using the high bit depth formats since most of this hardware is highly 
optimized for 32 bit floats and has been for some time now.   Also all of the 
8, 16 and 32 bit formats listed above are REQUIRED and must be supported by 
all OpenGL systems.

OpenGl also has direct built in support for sRGB, all other formats are 
assumed to be linear, but I don't know how useful this is since I am not an 
expert on OpenGL.   I think CompICC assumes that all RGB values from CM dumb 
apps are sRGB values.  So the built in sRGB support may make this more 
efficient.

> 
> 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
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc