[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ft-devel] [07/08] gamma correction issues with FreeType
From: |
Werner LEMBERG |
Subject: |
[ft-devel] [07/08] gamma correction issues with FreeType |
Date: |
Tue, 29 Oct 2013 05:51:56 +0100 (CET) |
From Dave Arnold, answering Antti Lankila:
The references you each gave are good. I generally agree they state
the theory correctly. My only disagreement is with hinting, which I
believe is a separate issue from blending.
Here are a few more comments.
I agree that one solution would be to work entirely in a linear
color space, but there are competing reasons for using a
perceptually efficient space like sRGB. As was pointed out, the
linear space would require more bits per pixel.
The proper calculation needs 3 values, the text
density/coverage/alpha value, the foreground color and the
background color. FreeType is in the business of supplying only the
first value. Using that value properly is the business of the
graphics system. So the problem cannot be solved in FreeType.
The most common problem I've encountered is not knowing the
background color. This is what happens when rendering text into a
"transparent" buffer, which will be composited much later.
Octoploid has described a good compromise ("trick") that can be used
when the foreground color is known. Namely, assume the background
color can be guessed, and hack the alpha values. This has the
potential to get the most common cases correct, for example white on
black and black on white. Mid-tone colors will not be correct,
however. (My favorite "worst case" test is red text on medium
green.) I helped implement such a "linear blending heuristic" for
Flash. I think a similar approach may be used in Android.
You are also correct about such a heuristic interacting with the
cache. One approach is to add the text color to the cache key, when
it is known. This is not too bad if you first quantize by luminance
to only a few values. A second approach is to adjust the alpha
values post-cache. The adjustment is usually a table lookup and is
faster than rendering a glyph, so most of the cache benefit is
preserved.
The issues for subpixel rendering are a little more
complicated. This type of LCD rendering requires a "color balanced
filter" where the basis of the filter must have equal parts of red
green and blue in order to cancel out color fringing. Linear
blending is a second requirement, because without it, the colors
will not cancel.
While displays are usually calibrated to sRGB (approx. gamma 2.2) I
have found that the *effective* gamma for high-frequency elements
like glyph stems is lower. We've used 1.8 as a design target. The
default of 1.4 used by some Windows systems and Android is probably
acceptable.
While linear blending solves a number of rendering quality issues,
one major side effect is that small black-on-white text becomes
lighter. This loss of contrast is a serious problem and I believe
it has led some implementers to decide that the darker black text
that comes from blending with gamma 1.0 is worth it. However, this
is truly a "poor man's darkening". The text may be on average
darker, but the effect is non-uniform. Only mid-tone pixels are
affected; black and white pixels do not change. This non-uniformity
produces perceived distortions, such as jagged curves, and "ropey"
diagonal lines and uneven vertical stem widths. And the effects are
the same on white text, but in the opposite direction. The
darkening in the Adobe CFF rasterizer is applied to the outline, so
it is uniform and is independent of color. It is a much better
solution to the problem.
For cases where linear blending will not be used on the text, black
text may be "double darkened"—once by the "poor man's" method, and
once by the CFF rasterizer. White text may be improved slightly,
but black text is more common. In these cases, I recommend turning
off darkening with "no-stem-darkening" and FT_Property_Set. And
file a bug against the graphics system :-) .
- [ft-devel] [00/08] gamma correction issues with FreeType, Werner LEMBERG, 2013/10/29
- [ft-devel] [01/08] gamma correction issues with FreeType, Werner LEMBERG, 2013/10/29
- [ft-devel] [02/08] gamma correction issues with FreeType, Werner LEMBERG, 2013/10/29
- [ft-devel] [03/08] gamma correction issues with FreeType, Werner LEMBERG, 2013/10/29
- [ft-devel] [04/08] gamma correction issues with FreeType, Werner LEMBERG, 2013/10/29
- [ft-devel] [05/08] gamma correction issues with FreeType, Werner LEMBERG, 2013/10/29
- [ft-devel] [06/08] gamma correction issues with FreeType, Werner LEMBERG, 2013/10/29
- [ft-devel] [07/08] gamma correction issues with FreeType,
Werner LEMBERG <=
- [ft-devel] [08/08] gamma correction issues with FreeType, Werner LEMBERG, 2013/10/29
- Message not available
- Re: [ft-devel] [08/08] gamma correction issues with FreeType, Werner LEMBERG, 2013/10/29
- Re: [ft-devel] [08/08] gamma correction issues with FreeType, Antti Lankila, 2013/10/29
- Re: [ft-devel] gamma correction and FreeType (was: gamma correction issues with FreeType), Werner LEMBERG, 2013/10/29
- Re: [ft-devel] [08/08] gamma correction issues with FreeType, another gol, 2013/10/29
- Re: [ft-devel] [02/08] gamma correction issues with FreeType, Werner LEMBERG, 2013/10/29