freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] gamma correction and FreeType


From: Dave Arnold
Subject: Re: [ft-devel] gamma correction and FreeType
Date: Fri, 08 Nov 2013 10:45:05 -0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

Hi Antti,

I agree that there is nothing like an analog video cable in modern displays, 
and that individual pixels are digitally addressed, but isn't there still some 
analog circuitry? It seems to me that the voltage applied to each pixel cell, 
and the electric field that rotates the crystals, must be analog. Is there a 
digital-to-analog conversion involved? I'd appreciate any references to this.

While gamma 2.2 seems like it should be correct, my experience on multiple 
devices is that a lower value works better for text. For example, there is the 
effect that another gol discussed, where white text appears too heavy at 2.2. 
I'd really like to understand that.

-Dave

On 11/7/2013 12:20 PM, Antti Lankila wrote:
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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]