Re: [ft-devel] gamma correction and FreeType

[another gol]

It could indeed be that today's monitors don't have a logarithmic gamma curve, but something more complex. Maybe a test pattern for various levels would tell. And indeed, if I look at a pure gradient, both the lower & the higher 10% stand out, so it could indeed be some S shape.

To make it worse, tablet generally feature auto-brightness, & whether it's done by multiplication or shifting, it will still mess up the curve, unless it's done linearly which I doubt.

So perhaps that "2.2 gamma" standard should be re-evaluated, maybe gamma correction isn't as simple today & transfer functions are more complex.

On Fri, Nov 8, 2013 at 7:12 PM, Dave Arnold <address@hidden> wrote:

I've attached a simple line pattern that I use to get a rough idea of display gamma on various devices.

For my laptop screen, at my normal viewing angle and distance, I measure 2.8 at the top, 1.6 at the bottom and 2.2 in the middle. LCDs have always varied with viewing angle, some technologies more than others. Luckily, the exact gamma is not too critical.

I agree that your 1.4 image looks more balanced in weight than your 2.2 image. When I repeat this test with my tools, I find that 1.4 and 1.8 are pretty close, while 2.2 (like yours) tends to make the white text too heavy. (By the way, I don't know how to extract your images from the google docs page, so I'm just relying on what Firefox does on my display.)

I've noticed this effect with white text before, and don't completely understand it. Some have argued that it is a visual perception issue. That could be. Another idea is that it results from a display transfer function that is not close enough to a pure power function. The physics of a CRT naturally generate a transfer function that is close to a power curve. But the physics of an LCD naturally generate a transfer function that looks like an 'S' curve, flat at both top and bottom. I understand that display manufacturers use electronics to modify this to get a better match to sRGB (which is very close to a power curve). But the closeness of the match varies and is never perfect. The greatest errors are close to the top end (white).

I agree in theory that gamma correction should make the weight of black text and white text appear the same. But this is only one of many goals. Smoother curves and diagonals is another goal, as is cancellation of color in subpixel rendering. I believe that there is a single "gamma" function that will do all of these at the same time, because it is primarily a physics problem.

Thanks.

-Dave

On 11/7/2013 10:29 AM, another gol wrote:

Still, IMHO gamma correction shouldn't be about the look, but the -weight-.

I mean, the goal behind proper gamma correction is that black text on white has the same weight as white text on black. I don't know how your monitors are calibrated, but on the ones I have here, this (1.4) looks like more or less equal weighting
https://docs.google.com/file/d/0B6Cr7wjQ2EPudk1uV01NWjRjc2c/edit?usp=sharing

while this (2.2) doesn't at all
https://docs.google.com/file/d/0B6Cr7wjQ2EPuZWpMYWl4T2ZobzQ/edit?usp=sharing

It could be that all of my monitors have a 1.4 gamma, but really, I never saw it looking wrong on any monitor, & there must be a reason Windows defaults to 1.4. I strongly suspect that the 2.2 standard gamma is either a myth or an old truth that doesn't apply anymore.

As for color fringing, reducing it is the role of the filter, and this one only goes horizontally, I don't think that color fringing should be a factor when picking gamma correction.If there's too much color fringing, you can still enlarge the blur filter, it's always a tradeoff between sharpness & color fringing.

On Thu, Nov 7, 2013 at 7:02 PM, Dave Arnold <address@hidden> wrote:

You are correct that gamma 2.2 is a better approximation to sRGB. I agree with using that gamma for large area regions. But there are two reasons why I prefer gamma 1.8 for text.

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.

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.

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.

-Dave

On 11/6/2013 11:47 AM, Antti Lankila wrote:

Dave Arnold <address@hidden> kirjoitti 6.11.2013 kello 20.43:

Hi Antti,
I've attached an image comparing darkened gamma 1.8 to darkened gamma 2.2. The differences between 1.8 and 2.2 are much more subtle than those between 1.0 and 1.8.

Yeah, there’s admittedly not much difference. I was just curious because in theory gamma 2.2 is more correct when it comes to approximating the behavior of the sRGB color space. If the rendering was based on subpixels, there might be perceptibly more color fringing at small sizes.

—
Antti

_______________________________________________
Freetype-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype-devel