[Top][All Lists]

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

Re: [ft-devel] gamma correction demo images

From: Dave Arnold
Subject: Re: [ft-devel] gamma correction demo images
Date: Wed, 4 Nov 2015 12:22:19 -0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 11/4/2015 7:27 AM, Alexei Podtelezhnikov wrote:
On Wed, Nov 4, 2015 at 6:24 AM, Nikolaus Waxweiler <address@hidden> wrote:
Any progress, Alexei? :)
I am sitting here in total disbelief and utterly embarrassed by the
lack of gamma correction setting for text rendering in any major Linux
desktop environment. How could this happen? Pango and Qt do not do it
either. I think FreeType is to blame for the lack of support, because
everybody just trusts FreeType. We need new FT_RENDER_MODE_GAMMA.

I am also confused. It seems obvious how to do it for grayscale
rendering . But what about subpixel rendering? I mostly see
application of gamma correction per each RGB channel, which seems
totally arbitrary. See attached image for wonderful color effects on
slightly slanted lines of 1, 4/3, 5/3-pixel wide and so on. I also
found a reference of HSL lightness gamma correction, which seems more
justifiable to me. I have not tried it yet. How does alpha blending
works on subpixel level, or does it at all? Then there is LCD
filtering to deal with color fringes, which changes RGB values and
begs the question if gamma correction is even suitable after this
brutal treatment. Perhaps you can enlighten me here.

It seems to me that gamma was considered a good idea, but subpixel
rendering got in the way, and now we are all stuck.

Gamma correction is even more critical for subpixel rendering. In addition to 
all the problems noted in non-linear blending of grayscale anti-aliasing, there 
is the issue of color fringing.

I did not work on subpixel rendering in FreeType, but I assume it is similar to 
what Adobe does. Here is a brief summary.

When outlines are scan-converted, the output buffer has 3x the resolution in a 
direction perpendicular to the subpixel stripes. This is especially useful when 
the stripes are vertical, because it provides increased positional accuracy for 
vertical stems. Vertical stems are important for Latin-based text, but can't be 
fitted to integral pixel boundaries without sacrificing inter-glyph spacing.

The resulting image or density map is then passed through what I call a 
color-balanced filter. The density computed for each subpixel must be 
distributed equally to all color channels. This avoids imparting a false color 
to the final bitmap. A good color-balanced filter is a simple block filter that 
is 3 subpixels wide, but is allowed to span pixel boundaries. It is important 
to realize that the filtering step sacrifices some of the 3x higher resolution 
in order to avoid color artifacts. The filter makes the image blurrier, but the 
positioning improvement is not lost.

The resulting density map has 3 alpha values per pixel, which are typically 
left, middle and right, and map to red, green and blue color channels. Each of 
the 3 alpha values is independently used to blend one color channel. That is, 
red (or left) alpha blends the red channel of the text color with the red 
channel of the background pixel. This blending must be done in a linear color 
space! The distribution of density values by the color-balanced filter depends 
on this. In other words, the color artifacts will only cancel out if the 
blending is in a linear space. The same gamma value is commonly used for each 



reply via email to

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