[Openicc] [ANNOUNCE] Compicc 0.8.3

[Kai-Uwe Behrmann]

Am 01.12.10, 11:21 +1100 schrieb 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.

I looked some weeks ago into some of the VESA specs. I did not yet find a 
fast and relyable way to communicate with the display about internal 1D
LUTs. If that would be in place, it makes very much sense to use VCGT 
behind the 8-bit DVI, ro whatever, bottleneck. Currently the download 
of 1D LUTs for one special monitor  costs several seconds. Nothing most 
people want to have during system start.

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

That might work. But most users have 8-bit paths to monitor and VCGT 
applies before the trasnmission.

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

Agreed, if such a Video LUT where available, the precission should be 
preserved and the conversion would behave like post LUT in ICC.

The difficulty comes at determine at profile build time the final 
configuration. I mean all is fine if the user has expertise and control.
Typical user dont have any of both. They get likely canned profiles,
which shall work out of the box.

In my personal setup its even more flacky. Nvidias twinview provides no 
standard Xorg way to setup Video LUTs independent. So a profile containing 
VCGT would be alost wrong with that. Nouveau is still no fun even with 
a workstation graphics card.

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

My experience dont backup this. If the calibration is a additional 
conversion step with the smallest set shades it must reduce the overall 
availability of shades of gray.

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

In my visual tests, and I think it works the same on the sheed, a VCGT in 
8-bit causes always banding with CompICC. Without VCGT the banding is 
greatly reduces to use all 256 shades available for the same 8-bit 
transmission.

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

The colour conversion should occure at the same >8 bit source precission.
CMMs supporting 16-bit or higher are typical used for this.
Almost any manipulation at 8-bit will cause further and visible precission 
lost.


In the end, VCGT on the host side, before transmission, is a complex 
task without easy and general style answers. We might find arguments pro 
and contra just because of the many possibilities.
IMHO to move VCGT into the monitor would be the right way to go.

> Graeme Gill.

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