[Openicc] [ANNOUNCE] Compicc 0.8.3

[Graeme Gill]

Kai-Uwe Behrmann wrote:
> 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.

That sounds like a system organisation issue. If there is
a way of setting up and tracking what video lut values are
set at system boot, there would be no need to check them
each time you start a session.

> 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 you're working in a >8 bit frame buffer, that's fine, append
the VCGT to the overall color transform. But are you sure it really
is a 16 bit frame buffer, and that the OpenGL is not simply being
rendered in 16 bit and then mapped to the usual 8 bit frame buffer
used to refresh the screen ? If the former is the case, are there
65536 entries for each Video LUT ? If there are only 256 entries,
then you are still squeezing through 8 bits...

> Calibration makes to me sense if:
> * calibration is done in higher precission and after normal rendering

This is usually the case, because it is 1D rather than 3D. It's much
more feasible to characterise things to high precision in 1D rather
than 3D.

> * no CIE referenced colour conversion, like ICC, is available

That isn't the point. The point is that it's hard to sample and model
a 3D function with a reasonable number of samples, and you get a noticeably
better 3D model from a limited number of samples if the device is well behaved.
Calibration ensures that the device is well behaved.

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

It's more complicated than that. A properly organised rendering pipeline
specifies the blending space. It may be different to both the input and
device space. For instance, for correct anti-aliasing, the blend
space should be linear light. The PDF and XPS PDL's both have fairly
complex approaches to addressing this issue.

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

Only if you can guarantee that the frame buffer is really >8 bit.

Graeme Gill.