Re: [ft-devel] gamma correction and FreeType

[Antti Lankila]

Dave Arnold <address@hidden> kirjoitti 7.11.2013 kello 20.02:

> The first is something I call "effective gamma". We first encountered this 
> back in the era of CRT displays. Unlike image data, text is mostly edges. The 
> area covered by stems is on the order of a pixel wide. If you look at text as 
> a video signal, it is very high frequency—often close to the limit of the 
> display device. Rather than seeing a vertical stem as a perfect square wave, 
> the video electronics tend to round it off and reduce its amplitude slightly. 
> Both of these effects move the active signal closer to the middle of the 
> gamma curve, where the curve is flatter. This has the effect of reducing the 
> gamma at high frequencies. Everything in the signal path contributes to this. 
> Even video cables could make a significant difference in the appearance of 
> text. I know less about the electronics in an LCD but, empirically, the 
> effect seems to still be present.

Interesting, but I remain unconvinced. There is no reason to expect such an 
effect in modern LCD displays. The transmission from GPU to screen is digital, 
there is no image scaling, and thus every pixel and indeed every subpixel is 
individually addressable and completely independent.

> The second reason is that not all text rendering systems are able to provide 
> the stem darkening technology to compensate for the loss of contrast at small 
> sizes. This is particularly challenging, given the way that TrueType hints 
> work. For example, both Windows XP and Android chose gamma 1.4 as a default 
> for text blending. It's not as accurate as a higher gamma, but it doesn't 
> lose as much contrast as gamma 2.2. So, designing for gamma 1.8 rather than 
> 2.2 will work better if the system gamma turns out to be 1.4.

I’m pretty sure almost any system’s gamma is as close to 2.2 as they can 
manage. And you can measure it too, if you just draw a couple of test pictures. 
A gamma of 1.4 will make sRGB-intended colors appear severely distorted, and 
the effect should be obvious even to a casual observer.

In other words, I do not believe that this reasoning above makes sense. Gamma 
2.2 or sRGB proper should be the design target because these displays are what 
we have, not 1.8 or 1.4 gamma systems. If you think you have such a system, I 
would encourage you to measure the gamma value through test pictures.

> Both of these arguments pertain mostly to grayscale antialiasing. For 
> subpixel rendering, I agree that you will see more color fringing at 1.4. 
> Some people are more sensitive to this than others. I know several people who 
> never could get used to ClearType on Windows XP.

Indeed, because subpixel rendering is fairly sensitive to any gamma related 
error that distorts the photon flux from a particular screen area. In my 
experience, errors of about 10 % are acceptable, but anything more looks bad. 
This brings the interesting special case of gamma 2.0 in range, which may be 
useful for approximating applications. For instance, I’ve seen game engines 
estimate sRGB color space through taking the square root of the color vector.

— 
Antti