[Openicc] Oyranos - proof of concept

[Kai-Uwe Behrmann]

Am 11.05.05, 23:18 -0600 schrieb Chris Murphy:

> Kai-Uwe Behrmann ku.b at gmx.de
> Fri Apr 22 12:34:37 PDT 2005
> 
> > The smaller matrix profiles are prefered by current CMS's. They are about
> > 1-6kB. But I expect the CLUT become desireable for modern LCD's. Please
> > can one of the profiling experts correct me if I am wrong here.
> 
> In theory, if we had well behaved flat panel displays, a matrix profile works
> just as well. My experience has been that table-based display profile cause
> profile-induced posterization that's noticeable in gradients.
> 
> However, displays that aren't so well behaved require more effort to calibrate
> in terms of gray balance and a reasonable white point which translates into a
> more aggressive curve in the video card DAC LUT. This can cause
> calibration-induced posterization.

It is clearly observable with rising contrasts ( > 1:250 ).
 
> If we had full system level display compensation, we could avoid video-card
> based calibration altogether and simply profile the display using table-based
> ICC profile rather than matrix, and compensate for its peculiarities with
> brute force. That's a little expensive until we can dump all of these
> conversions onto the video card (which I believe is on the way).

Does you talk about something like the approach in Tiger to use the GPU 
for colour transformations?
There is enough headroom to play with many kind of manipulations. The 
bottleneck there will be the 8-bit path to the display. While a linear 
8-bit path is today a good thing (except the CG220). It is stoped at the 
videocard exit.

> In the meantime, what I'm really enamored with are the Eizo flat panel
> displays that allow calibration to be done in their internal 10-bit to 14-bit
> DAC LUT, which is in the display itself. The video card LUT remains linear,
> and the higher bit depth of the curve applied in the display itself translates
> into far smoother gradients. Thus far I'm finding I prefer matrix profiles for
> these displays, but they are quite well behaved once calibrated this way.

Yes, thats clearly a interessting solution till >= 10-bit can been sent 
directly to a monitor. The drawback for Linux is the unsupported 
propriarity protocol there. 

> As the market is transitioning from CRT to LCD, I think we're in for a bumpy
> ride. We also have wide gamut displays on the way and HDR displays coming too.
> This could likely translate into wider disparity in behavior among displays
> out in the world compared to the CRT days, which means a greater dependence on
> DDC (or equivalent) to build profiles on-the-fly, and on display compensation.
> Sending existing internet images (as a simple example) to such a display will
> result in very apparent oversaturation; so we're going to need display
> compensation in even simple applications like web browsers. It will be
> interesting to see how all of this plays out—I expect on Windows and Mac OS to
> move to full display compensation powered by the video card, eventually.
> 
> 
> Chris Murphy
> Color Remedies (TM)
> www.colorremedies.com/realworldcolor
> ---------------------------------------------------------
> Co-author "Real World Color Management, 2nd Ed"
> Published by PeachPit Press (ISBN 0-321-26722-2)
> 

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name