Re: [ft-devel] gamma correction demo images

[Dave Arnold]

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.
>
> Regards,
> Alexei
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 
channel.

Thanks.

-Dave