[Openicc] [ANNOUNCE] Compicc 0.8.3

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

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

Graeme Gill.