[Openicc] Changing the display whitepoint using the VCGT

[Chris Murphy]

On Apr 27, 2011, at 8:12 AM, Richard Hughes wrote:

> On 26 April 2011 23:27, Chris Murphy <lists at colorremedies.com> wrote:
> 
>> So I'd say maybe not do it by default because humans do have a chromatic adaptation feature
> 
> Yes, until they are comparing two screens...

Yes, it's a problem. There are probably multiple ways to handle this but it seems like trying to get an estimate of the relative difference between the two displays might be useful, and then determine how to change both of them the least to get a satisfactory result rather than a  specific color temperature.

I think 95% of the market does not even need to understand color temperature per se, but rather the "color of white" with a "warmer-cooler" slider instead of a value in Kelvin. Most people don't understand, nor need to understand, blackbody radiators.



> 
>> And that luminance drop can be significant and a worse effect than a non-ideal white point.
> 
> True.
> 
>> With the linear vcgt the display is distinctly blue. I don't know that I'd adjust to this, maybe after a day or a week?
> 
> Most people I talk to at conferences just think the blueish is the
> "normal" and when calibrated everything looks too "gray". :-)


> 
>> I don't know why Apple does it this way, rather than analog adjustments to the panel to make the entire TRC relatively neutral.
> 
> I think software is cheaper than hardware.

Inferior results too, especially with a 6bit panel.

>> So that's a way to end up with a non-linear vcgt to try and correct for color temperature not just at the white point, but throughout the TRC.
> 
> Yup, and I don't think we can do it sensibly without a sensor (i.e. a
> colorimeter or the human eye), certainly not just from 4
> chroma-coordinates. I don't know if allowing the user to adjust the
> linear color temperature using the VCGT is such a good idea.
> 
> I've also noticed that all the generated VCGT tables in existence map
> 1:1 at the display white, i.e. even when changing the blue channel
> drastically, the VCGT still scales to linear past about 95%. I assume
> it's to avoid loosing luminance at native white. Ideas welcome.

Likely true. Although I regularly see the commercial products with colorimeters unpin the blue channel maximum and set it far lower than 100% (even as low as 70%) which of course causes a big hit to luminance.

I think for practical purposes, laptop displays are a separate category. If the white point is D65 (which it should be), and if the black point is D65 (which it might not be), and if the TRC's for RGB are the same, then you should be automatically get a D65 neutral TRC without doing anything else. The catch is some laptop display panels, like Apple's, are left in their native response except for (apparently) the white point which is pretty close to D65. Everything is like 9300K or higher, and the TRCs of the three channels are a.) different from each other, b.) are sigmoidal. So to unwind that so it could be described with a gamma function instead, I would think would be tricky. You'd need a pretty radical vcgt to do that.

Whereas if you do nothing, and go with a linear vcgt, you still can't assume the TRC is definable with a gamma function.

Based on the profile I sent you offline, it looks like the result of the vcgt Apple is applying to the particular display in this MacbookPro, it's compelling the panel's TRC to be definable by a gamma function of 2.4, rather than it's natural sigmoidal behavior. I don't know if other laptop panels behave this way - I suspect they do not because they are primarily Windows based laptops, which all assume the TRC of the display is definable with a gamma 2.2 function (or actually the sRGB curve function) which I bet means everyone but Apple laptops are doing hardware corrections for the display. So you may have a very narrow exception case for Apple laptop hardware, which could be mitigated with just a "Note:" in documentation somewhere. Let me know if it makes sense to consider that and I'll do some testing - maybe the user boots into Mac OS X, the display profile is autogenerated, they put that profile up on a network volume or USB stick, reboot to Fedora and install that profile there. Seems like it would work, but I haven't tried it.

What is reading the vcgt tag and applying that curve to the video card LUT? Is that colord's responsibility? Since what version is this possible?


Chris