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

[Werner LEMBERG]

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 :-) .