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

[Hal V. Engel]

On Monday 11 February 2008 09:58:35 Chris Murphy wrote:
> 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. 

I have yet to see a serious hardware standards proposal for the PC to display 
communications link that will support more than 8 bits/channel with the 
highest resolution displays that are in use today.  Almost all of the new 
hardware standards proposals dealing with the communications link to the 
monitor that are currently on the table are there because the vendors want to 
add more security for DRM (IE. they are calling us thieves) not because they 
are concerned about the bit depth of the color representation or achieving 
higher resolutions.

As an example VESA has been working on the DisplayPort standard which supports 
a wide range of bit depths up to the max bandwidth of the connection.   They 
just recently released version 1.1 of that standard and there are a few 
displays with a DisplayPort connections but currently no video cards support 
this.   But total bandwidth is only slightly more than HDMI/DVI at 10.8 
Gbit/sec compared to 10.2 Gbit/sec (dual channel).  With high end 30 inch 
displays (keep in mind that there are higher resolution displays available) 
DisplayPort maxes out at 10bpc and with higher resolution displays we are 
back to 8bpc and there is a limit to how much resolution can be supported 
even at 8bpc.  

Of course on lower resolution displays it would be possible to do 12bpc, 14bpc 
or even 16bpc using DisplayPort but it appears to me that DisplayPort is 
already obsolescent even before the first video cards that support it are 
released.  In spite of this DisplayPort may drive development of support for 
higher display bit depths in the software layers above the display hardware 
(IE. windowing systems, video card drivers and applications) if it is 
accepted by consumers and if the display hardware actually supports these 
higher bit depths. 

> Displays 
> themselves already have internal LUTs with that precision. 

The Eizo displays have internal LUTs of 10bpc and 12 bpc depending on the 
model.  In addition these LUTs are exposed via the USB HID Monitor Controls 
interface.  These monitors also come with calibration/profiling software that 
will calibrate the internal LUTs to user specified values (gamma, white 
point, white level and black level are supported).  Of course it only runs on 
some operating systems and would be of little or limited use for most on this 
list.  But these are also very high end expensive monitors that I don't think 
are representative of monitors that most users have.

The LUTs on video cards are generally 16bpc resolution and are used to do a 
8bpc to 16 bpc transform before sending the data to the DAC.  The reason that 
Eizo is using 10 and 12 bit LUTs is because they are doing a transform from 
the 8bpc they are getting from the computer to the 10bpc or 12bpc resolution 
of the panel.   If you think about it you will always need more bit depth in 
a LUT than your input data stream if the LUT is to serve a useful purpose.   
So having a 12bpc input stream to a display that uses a 12bpc LUT basically 
make the display LUTs useless although using 12bpc display LUTs with a 10bpc 
input would still be useful.

> The limits 
> are video card, drivers, and connection. 

Because of DRM I don't expect this to change anytime soon and we currently do 
not have the hardware available that supports these higher bit depths.  Some 
of the newer Nvidia GPUs (the 8xxx series) do support 10 bpc internally 
(maybe other vendors do as well?) but unless you are using an analog 
connection to the monitor this is wasted as far as I can tell.  In addition 
it is unclear to me if any monitors using DisplayPort connectors will 
actually support more that 8bpc in actual use (anyone know?). 

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


Actually this is one of those chicken and egg things.  Why would the OS (in 
the general sense since with X11 systems we are really talking about the 
windowing system and video drivers and not the OS - kernel - for the most 
part) be upgraded to handle hardware that does not exist?  Since this type of 
feature is likely to show up in high end hardware first and since there will 
likely be an extended period before this hardware becomes common I would 
expect that there would be a gradual migration of the software layers to 
support this new hardware over time. 

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

I agree with this.

snip

> 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 am not so sure that the "mental gymnastics" involved in integrating color 
management into an app are really "major".  There clearly is a learning curve 
but this is typical anytime an application uses a new technology.  But I 
think you are right that handling basic transforms from general purpose 
applications to the display device should be a given that is handled by the 
windowing system and that non-color critical apps should not have to deal 
with this directly. 

Hal