[Openicc] [ANNOUNCE] Compicc 0.8.3

[Kai-Uwe Behrmann]

Am 30.11.10, 23:17 +1100 schrieb Graeme Gill:
> Kai-Uwe Behrmann wrote:
>> Am 30.11.10, 22:27 +1100 schrieb Graeme Gill:
>>> Kai-Uwe Behrmann wrote:
>>>> Exactly. But is not this kind of hardware going nearly completely away?
>>>> I mean most computer to monitor paths are D/D.
>>> 
>>> I would not assume so. Display port makes > 8 bit/component paths more
>>> common again, and potentially the VCGT might be sent to the monitors
>>> internal 1D LUTs, which are typically much better than 8 bits.
>> 
>> VCGT has no advantage with DP and > 8 bit/component.
>
> Why do you say that ? I certainly don't agree this is true.

>> Putting VCGT into
>> the monitors LUTs would be great to come. But the one existing device I
>> know of on Linux is extremly slow for that feature.
>
> I'm not sure why that should be relevant. It's not like the display
> profile changes frequently.

The typical usage is to setup the ICC profile at session start. That 
still is the right time to upload VCGT to the graphics card or verify the 
monitor internal LUTs. Every session start is rather frequent in my eyes. 
I try to start CompICC reasonable quick and casu minimal delay. VCGT to 
monitor upload would be a multiplier for longer times in that race.

>> Still, for most users with traditional 8-bit per component paths VCGT
>> means only: no software can render to the full available precission,
>> e.g. 180 instead of 255 levels of gray. So it increases just banding for
>> no benefit compared to a situation without a colour server.
>
> I don't see how your color server changes this situation to be any better.

It does. For apps working in the 8-bit domain, alias sRGB, it remains the 
same. On the other side for application like RAW convertors, painting 
applications, medical data displaying or OpenGL the source is very likely 
16-bit or higher.
For instance Compiz itself works in the 16-bit per channel domain. Getting 
ride of VCGT means practical lesser banding for these mentioned 
applications.

> If the display is rather non-linear, then if you combine the VCGT into
> the profile transform, the output of the color server into the 8 bit frame
> buffer will be in that non-linear space, causing the same banding as an 8 bit
> output hardware Lut. But if the the VCGT is loaded into 1D Luts after the
> frame buffer, and the hardware Luts and data path to the display are better
> than 8 bits, you will be able to get less banding because the frame buffer
> will be in a more visually linear space.

Calibration makes to me sense if:
* calibration is done in higher precission and after normal rendering
* no CIE referenced colour conversion, like ICC, is available

With the colour server, as implemented in CompICC, both is not true. My 
graphics card outputs 8- or 10-bit per channel to the monitor. A VCGT does 
not change that or help in any way. Access of the monitor internal LUTs is 
beside the profiling stage forbiddingly slow.
CompICC does provide a ICC compatible colour conversion. So I see no 
advantage in using VCGT in that scenario.

About the point of the framebuffer being in a visual more linear space,
I guess it would be more pleasing and result in more realistic behaviour 
to perform compositing in a real linear space and not a visual linear 
space. But that seems very slowly coming to developers and users. 
Currently for pure desktop effects I think its sufficient and reasonable 
simple to operate in whatever native monitor colour space.

All what CompICC tries to provide is a colour wise consistent desktop 
appearance combined with the highest quality for applications which demand 
that. For the second goal a late colour binding is still the only relyable 
rendering path and as outlined above I recommend without 1D LUT VCGT in 
the graphics cards.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org