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: another gol
Subject: Re: [ft-devel] gamma correction and FreeType
Date: Fri, 8 Nov 2013 19:43:04 +0100

You're right about the S-shape, found a source that seems to confirm it:
http://www.eizo.com/global/library/basics/lcd_display_gamma/
Traditionally, LCD panels have featured S-shaped gamma curves, with ups and downs here and there and curves that diverge by RGB color. This phenomenon is particularly marked for dark and light tones, often appearing to the eye of the user as tone jumps, color deviations, and color breakdown.

So yes, that's probably the reason for the black/white problem. However I think it's very important, as text is typically viewed as black on white, and often as white on black.

Yet, gamma correction is generally table-based, thus it wouldn't be too hard to adapt tables for that S-shape, if an average curve could be computed.

I kinda understand why an LCD needs this S-shape btw, afterall a LCD can't produce deep black, & tweaking the bottom is probably better than chopping it. It might change again with OLEDs..

So that's it, most likely that "2.2" doesn't mean much anymore, & it's the whole transfer function that has to be re-thought.

This also explains why, when there is a problem with pure black vector artwork on white, cranking up the black to dark grey just a little generally improve edges a lot, while it's still nearly black visually.






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




reply via email to

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