Re: Fonts looking washed out with newer freetype versions

[Peter Grandi]

>> That "pale/'washed out'" may depend with on the gamma
>> adjustment you apply to the generated pixmaps when rendering
>> them on the target.

> Has the value for the gamma adjustment been changed in FreeType after
> version 2.6.1?

AFAIK Freetype does not do gamma adjustment, you do it when
writing the application code. Many applications don't do it, so
anti-aliased glyphs look usually fuzzier on light backgrounds
than on dark backgrounds, and since it seems most developers
have dark backgrounds they don't feel a need for adjusting
gamma.

https://freetype.org/freetype2/docs/tutorial/step1.html

“Once you have a bitmapped glyph image, you can access it directly
through glyph->bitmap (a simple descriptor for bitmaps or pixmaps), and
position it through glyph->bitmap_left and glyph->bitmap_top. For
optimal rendering on a screen the bitmap should be used as an alpha
channel in linear blending with gamma correction.”

https://lwn.net/Articles/669024/

“On low-DPI screens most of us are sadly stuck with, the situation is
different. The pixels are too large for most of the details of a glyph
and shades of gray are the norm rather than the exception.

This is relevant because all our screens have a second problem: they are
not linear. 1 + 1 is not 2. Twice the value does not result in twice the
brightness. When a pixel is only 50% covered, the coverage map says 50%
black, and this translates to a pixel value of 128 when you use 8 bits
per channel (0-255).  However, this does not translate to 50% brightness
for that pixel on our sRGB and gamma 2.2 screens.

Due to their non-linearity, they dwell longer in the darks and only a
pixel value of about 186 results in 50% brightness – 128 ends up too
dark on both bright and dark backgrounds.

The net result is that dark text looks burnt-out, pixely and blotchy on
bright background, bright text too frail on dark backgrounds, and
colored text on colored background (for example, red on green) seems to
have dark halos or ‘dirt’ around it.

The situation is especially ugly for diagonal stems like in glyph ‘w’,
where the quality of FreeType's anti-aliasing depends on the correct
display of grays. On high-DPI screens where smaller, fully black pixels
reign supreme, this doesn't matter, but on our low-DPI screens with all
the gray shades, it does. 0% and 100% brightness are the same things in
linear and non-linear space, just all the shades in-between are not.

The correct way of rendering a glyph image on a surface is to alpha
blend it onto the surface in linear space and then apply gamma
correction to translate the linear coverage map to something that is
correct for our screens.

No toolkit in the Linux ecosystem does it by default, even though Qt5
and Skia can and will do it on other platforms. Windows and Mac OS X do
it natively. This procedure is especially important if glyphs should be
subpixel-rendered (ClearType and Mac OS X) with as few color fringes as
possible.”