freetype-devel
[Top][All Lists]
Advanced

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

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


From: Werner LEMBERG
Subject: [ft-devel] [06/08] gamma correction issues with FreeType
Date: Tue, 29 Oct 2013 05:51:08 +0100 (CET)

Werner Lemberg answered to Octoploid:

  > > I also wonder which operating system or application Octoploid is
  > > using...
  > > I'm running a stock Linux system (Gentoo).
  >
  > Then it is probably worth a bug report...
  >
  > > I wonder which component is responsible for this issue?
  >
  > Good question.  My knowledge is very poor regarding such details.

  See the following bug report (from the same guy who wrote
  https://bel.fi/alankila/lcd/):

    https://bugs.freedesktop.org/show_bug.cgi?id=28549

Octoploid then contacted Antti Lankila and got this answer:

  > Now I've noticed that you've recently added support for sRGB
  > surfaces to pixman.  And this seems to be exactly the feature that
  > could fix the issue described above.
  >
  > My question is: What is missing to hook this functionality up
  > automatically?  Does for example Cairo need to be patched to call
  > PIXMAN_a8r8g8b8_sRGB in certain places?

  Here are 3 ideas I’ve been thinking about.

  1. The ideal solution is that everyone is colorspace aware, so for
  instance if people are targeting sRGB display they would be running
  on sRGB framebuffer/canvas/what-have-you.  To accomplish this,
  people would have to use appropriate surface types wherever they are
  loading images from disk, or defining a pen color, or when composing
  imagery on a buffer, and so on.  By my experience, this is a
  complicated thing to get across, as very few people seem to
  understand the notion of color spaces and what they mean.

  2. Since pixman now has a glyph drawing function, it may be possible
  to simply force everyone to always use it, and do sRGB blending hack
  in that function.  This makes text alpha blending special, and
  different from, generic image alpha blending.  People may be
  accepting to the notion that there’s something magical about text
  and this function handles the magic and the end result will look
  good.  However, the implementation will probably always run in
  software unless people start adding sRGB surface blend features into
  GPU drivers.

  3. The least ideal solution, but one that I personally think could
  be easiest to get working, and which requires no hacks in the lower
  level of graphics acceleration / driver pipeline, is to use a
  technique I elaborated here:

    https://bel.fi/alankila/lcd/alpcor.html

  The idea of alpha correction is that if you know the foreground
  color of the glyphs, we can make the assumption that background is
  such that text will be discernible if drawn on the background.
  Thus, we pull a magic trick and state ”if foreground is light,
  background is probably dark”, and with this knowledge we can improve
  the alpha value provided by FreeType such that the replacement alpha
  will give sRGB-like blended result.

  To employ this magic trick requires two things: 1) access to the
  component-alpha mask; 2) knowledge of the color that text will be
  rendered with.  So, if you have access to the component-alpha mask,
  you can select one of the 256 alpha correction tables based on the
  foreground’s component value and replace that component’s alpha with
  whatever value the table gives.  Do 3 separate table look ups for
  all 3 components, and you have replaced the ca mask with
  alpha-corrected ca mask.  The upshot should be that the expected
  error from linear alpha blending shrinks by a factor of 4 or so,
  though there are (very rare) color combinations which will be made
  worse.

  I prototyped the rendering with JavaScript, which has full sRGB
  blending and alpha corrected blending implementations, along with
  whatever the browser happens to natively do which varies by
  platform.

    https://bel.fi/alankila/lcd/index.html

  I also ran it experimentally on my linux desktop for a while, by
  throwing cairo's hardware acceleration away and running a modified
  pixman whose glyph composing functions were adjusted:

    https://bel.fi/alankila/lcd/lwnu.png
    https://bel.fi/alankila/lcd/lwns.png
    https://bel.fi/alankila/lcd/lwn.png

  Shown here are three examples from unhinted, slight to fully hinted
  rendering using the new freetype when it came out.  Generally the
  point here is to observe the lack of color fringing in all
  circumstances, and the overall lighter tone of the text.

  In order to use the more feasible alpha correction, a few things are
  required.

  Firstly, glyph caches are no good, because the alpha mask of a glyph
  will vary by foreground color.  As I’ve seen it, most places do not
  expect that alpha mask changes by foreground, and that information
  simply isn’t available in the routines that prepare the alpha mask.
  (I also think that we should move to subpixel-precise glyph
  layouting and not snap glyphs to pixel grid width.) Secondly, the
  foreground is not always clearly defined, it may simply be a generic
  blend between two bitmap surfaces or something such.

  A rendering library called Skia has some kind of alpha correction
  machinery in it.  I saw code which seemed to assume that the
  background is always the inverse of the foreground, and calculate
  the ”correct” alpha for that.  This is great for color combinations
  that use the extremes of the component range, because the result is
  actually fully correct.  For all the other color pairs, however, it
  may be better to use a numerical optimization strategy as I have
  done.

reply via email to

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