[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.
- [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 <=
- [ft-devel] [07/08] gamma correction issues with FreeType, Werner LEMBERG, 2013/10/29
- [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