freetype-devel
[Top][All Lists]
Advanced

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

Re: [ft-devel] [08/08] gamma correction issues with FreeType


From: Antti Lankila
Subject: Re: [ft-devel] [08/08] gamma correction issues with FreeType
Date: Tue, 29 Oct 2013 11:46:53 +0200


Werner LEMBERG <address@hidden> kirjoitti 29.10.2013 kello 11.00:


[Please reply to the list, CCing Antti.]


For what it's worth: by testing I too found out that the common 2.2
gamma correction was way too much, visually.  After testing, I
concluded that it looked best around 1.4, and after I found out that
it's exactly how Windows was calibrated by default too, I realized
it's the best average value.  But that's pretty far from 2.2 so I
don't quite understand where that popular 2.2 gamma comes from.

On my GNU/Linux box, I use a gamma of 1.8 for my display, which works
quite fine and is not too bright...  So may value 2.2 is intended to
compensate uncorrected displays.

I’m handicapped by not knowing the context, but I can answer the simple question about gamma 2.2. This value is a good approximation of the sRGB component value to linear photon flux mapping. As a general rule, all monitors are supposed to follow the sRGB standard, and when they do, lazy programmers tend to state that such a system has a gamma value of 2.2.

I have a gamma measurement page which can be used to estimate your system’s gamma: https://bel.fi/alankila/lcd/gamma.html

In my experience, the match with 2.2 is very good on Apple laptops, which come with color calibrated displays by default. Especially with LCDs it is very important that your viewing angle is good, because energy is often dispersed unevenly but in such a way that if viewed at directly perpendicular angle, it should appear correct.

A problem I have however is that a small or average sizes, at low
PPI, most popular fonts have stems slightly thinner than a full
pixel, & thus text can look too light.

Hmm, if the energy gets distributed evenly (this is, the gamma is
correct), this shouldn't be a problem since the gray values of, say,
two 50%/50% lit pixels sums up to 100% as if it were a single black
pixel.

That’s the theory. However, human eyes are apparently not quite linear themselves, and the loss of contrast can be disconcerting, even if the average light energy radiated from the region would be correct. This sort of problem is best solved through hinting, or adjusting the font 1/64th pixel offset so that an important feature aligns with the pixel grid, or somehow deforming the outline with mapping such that most features will align to the pixel grid.


For the record, I dislike the subject of this thread. FreeType is not the problem. The problem is actually with how everyone treats FreeType’s output.

— 
Antti

reply via email to

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