[Openicc] Questions about color pickers and graphics libraries under LINUX

[Chris Murphy]

On Feb 11, 2008, at 10:52 AM, Bob Friesenhahn wrote:
> If the display was capable of resolving the required colors, then  
> the OS could certainly help.

No it can't. Even if we had greater than 10bpc to the display we  
don't have full blown display compensation on any operating system.  
And despite the limitation of 8bpc, which is necessity, it is NOT a  
pre-requisite to system wide display compensation.

The OS is behind the curve in this respect. It would not take very  
long to get to a 10bpc or 12bpc path to the display. Displays  
themselves already have internal LUTs with that precision. The limits  
are video card, drivers, and connection. That's also more readily  
resolvable than all of the bits of an operating system that need to  
be updated to handle a higher bit pipeline.

I'm just asking for display compensation within the limits we have  
now for 8bpc. Obviously I want improvements through the whole  
pipeline for higher bit depth, but not having it now is a piss poor  
excuse for why the OS doesn't do display compensation system wide.

>   The interface to LCD panels is still only 8 bit.  Assuming that  
> the internal LCD panel drivers are capable of sufficient resolution  
> (it seems that most/all are still 8 bits or less), it makes the  
> most sense to load a LUT directly into the display device which  
> correctly translates from the computer provided levels (e.g.  
> "sRGB") to the LCD stimulus levels.

That's fine when it comes to compelling a display to have a  
particular TRC, and high-end displays allow for this today.

But as for display compensation and color transforms, that is  
completely insufficient. What's being displayed at any given time  
comes from multiple source color spaces and potentially different  
dynamic ranges. It's not just sRGB to display transforms that need to  
be done.

We may have a dozen images on-screen at the same time that have 6  
different source spaces, and 6 which are untagged and should be  
assumed to be sRGB? A single LUT in the display can't do this.

How do we display HDR images on an LDR display?

How do we display LDR images on an HDR display?

HOw do we display a mix of such images on an LDR and HDR display?


>   * Use something other than "sRGB" interface levels in order to
>     improve the "impedance match" between the computer and the display
>     so that every computer specified level has a better chance of
>     resulting in a discrete panel level.
>
> Note that all of these are attempting to address deficiencies in  
> the LCD display device so it behaves better (is calibrated) rather  
> than attempting to color manage the display.

Both are needed. If the UI is completely neutral, then calibration to  
a particular TRC is sufficient for basic color management of the UI  
without needing to do display compensation. (But as we have different  
ambient light levels and different display white luminance levels,  
these are things that could only be compensated by CAM at the OS  
level. That is more advanced and while I'd like to get there someday  
this is not what I'm asking for now.)

But as for compensating for wide gamut displays with something as  
simple as a web browser, I'm seeing FireFox folks having to put  
themselves through major mental gymnastics to get color management  
integrated into the web browser and it should not have to be this  
complicated for them. And then when there's another project, they  
will have to do all that integration again. It seems really stupid  
and inefficient.

> I just ran across this interesting page http://www.techmind.org/ 
> lcd/ which talks about LCD panel drivers and provides test patterns  
> so that you can see what type of panel refresh your LCD uses.  Mine  
> seems to be of the "Line-paired RGB sub-pixel dot-inversion" type.

Cool.

Chris