bugThe FreeType Project - Bugs: bug #38607, Avoiding coloration of FIR5 filter...

 
 

bug #38607: Avoiding coloration of FIR5 filter during LCD rendering

Submitted by:  None
Submitted on:  Wed 27 Mar 2013 12:38:38 PM UTC  
 
Severity: 3 - NormalItem Group: None
Status: FixedPrivacy: Public
Assigned to: Werner LEMBERG <wl>Open/Closed: Closed
Planned Release: 2.4.12

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 29 Mar 2013 06:37:11 PM UTC, comment #4:

Thanks for the text! I've committed it (with some minor additions).

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 29 Mar 2013 09:42:40 AM UTC, comment #3:

Thank you for the response!

Would it be possible to make a mention in FreeType documentation about changing the FIR5 weights when gamma-corrected rendering is being performed? This is a topic that IMHO warrants some discussion, though maybe not at API reference level, but just on some general "What is LCD rendering and why might you want it" context.

Correct rendering is probably becoming more important:

- sRGB texture support exists in modern GPU hardware. This suggests that implementations of OVER composition in hardware are now generally capable of transforming the input textures on load, and can also transform the result back to sRGB on store.

- general awareness of the problem has increased. As an example, Wayland (if it ever replaces X) supports other color spaces besides sRGB. There is at least one person running a gamma-correcting Weston right now.

I'd like some place in the documentation which discusses LCD filtering state something like this:

"FreeType generates alpha coverage maps, which are linear by nature. For instance, the value 0x80 in bitmap rerpesentation means that within numerical precision, 0x80/0xff fraction of that pixel is covered by the glyph's outline. The blending function for placing text over a background is dst = alpha * src + (1 - alpha) * dst, which is known as OVER. However, when calculating the output of the OVER operator, the source colors should first be transformed to a linear color space, then alpha blended in that space, and transformed back to the output color space.

When linear light blending is used, the default FIR5 filtering weights are no longer optimal, as they have been designed for black on white rendering while lacking gamma correction. To preserve color neutrality, weights for a FIR5 filter should be chosen according to two free parameters a and c, and the FIR weights should be [a-c, a+c, 2*a, a+c, a-c]. This formula generates equal weights for all the color primaries across the filter kernel, which makes it colorless. One suggested set of weights is [0x10, 0x50, 0x60, 0x50, 0x10], where has a value 0x30 and b value 0x20. The weights in filter may sum over 0x100, which increases coloration slightly but also improves contrast."

As to it being very unlikely that Linux text rendering gets better: it is not that unlikely given that I am currently using a version of pixman that generates text on screen with alpha correction. The patching required is quite minor -- largely you must force software paths to be used for glyph composition, in my case I simply disable cairo's access to xrender acceleration altogether, and then you hack whatever you want into pixman-glyph.c.

Anonymous
Thu 28 Mar 2013 03:43:18 PM UTC, comment #2:

Hello Antti,

All the things you mention are unfortunately well-known.

The current FIR5 filter defaults have been chosen specifically to optimize text rendering in the very common case of black on white text displayed on Linux through GTK+/Qt.

As you already know, neither XRENDER [1] nor Cairo [2] support gamma-correct alpha-blending, and it's more important to have the FreeType defaults generate glyph opacity maps that produce the best text given these constraints. In other words, final user experience trumps mathematical purity.

Besides, any graphics library that would correctly implement gamma-correct alpha blending can very trivially call FT_Library_SetLcdFilterWeights to change the values to whatever it desires/needs.

As such, I see no reason to change the FreeType defaults in the ways you suggest. Doing so would simply degrade text rendering on many Linux distributions unless they all update their graphics libraries to perform gamma-correct blending, a very unlikely event at this point.

Note that said libraries can be improved individual without modifying FreeType, as long as they also use FT_Library_SetLcdFilterWeights. This allows coexistence of gamma-correct and non-gamma-correct libraries on the same system peacefully.

- David

PS: The "ftdiff" program performs gamma-correct alpha-blending, as well as give you the ability to use a custom LCD filter for testing purpose.

[1] http://translatedby.com/you/why-linux-fonts-suck/original/
[2] https://bugs.freedesktop.org/show_bug.cgi?id=28549

(and yes, I've noticed you wrote most of these links' content).

David Turner <freetype>
Project Administrator
Wed 27 Mar 2013 12:52:44 PM UTC, comment #1:

I forgot to mention my name and contact. I am Antti S. Lankila, and you can reach me at alankila@bel.fi.

Anonymous
Wed 27 Mar 2013 12:38:38 PM UTC, original submission:

The currently chosen weights in the FIR5 filter are: [0x10, 0x40, 0x70, 0x40, 0x10]. Under gamma-corrected rendering, the use of these weights lead to coloration for two distinct reasons:

1) unequal excitation of the RGB primaries under the filter kernel.
2) clipping of the excitation of a component to 0xff because the FIR filter sums to 0x110.

The 1) problem is serious, the 2) is far less so, and in fact I do not propose fixing that. I rather propose changing the weights slightly to reduce or entirely avoid coloration. Let's investigate the cause of the coloration and what can be done about it.

Firstly, let's make the assumption that equal excitation of all RGB components results in gray colors. Furthermore, let us make the assumption that we have colorspace correcting alpha blending: that is, in the process of taking FreeType's generated bitmap, we treat it as a component-alpha mask and we blend the color primaries in linear light. So it follows that 0x80 is physically in terms of light flux representing the midpoint between foreground and background, because from FreeType's point of view, system's gamma is now 1.0.

Now with all that out of the way, let's take a look at how the FIR5 kernel filters input bitmap [0, 0, 1, 0, 0]: this is easy, as it produces the same result as the filter kernel: [0x10, 0x40, 0x70, 0x40, 0x10]. To determine the color of this bitmap, we will sum the R, G and B components contributions together. Let us assume (without loss of generality) that the first value is for R component.

Under the assumption, R's get an excitation of 0x10 + 0x40, G's get excitation 0x40 + 0x10, and B gets the lone excitation of 0x70. So in this case the result is blue, because R=G=0x50, and B=0x70! This means that use of FIR5 with gamma corrected rendering gives color-fringing glyphs.

To fix this, it is required that the two values surrounding the central point are symmetric in the middle, and together sum to the same value as the middle component. For instance, [0x10, 0x50, 0x60, 0x50, 0x10] would be this kind of kernel. In general, the kernels will be of form [a-c, a+c, 2*a, a+c, a-c], where c is a free parameter and 0 <= c <= a, and for the maximally saturating case a has the value 1/6, though a should probably be increased slightly (~ 10 %) to enhance contrast of rendering.

What about applications that ignore gamma correction? For those applications, I would suggest using kernels of the form [1/9, 2/9, 3/9, 2/9, 1/9]. This kernel is unfortunately fairly blurry, but being strictly triangular in shape, it has got the least possible difference between the neighboring components (typically displayed in sRGB, which is thought to be an approximation of "linear perception"), which means that overall it probably produces the least coloring possible.

Can gamma correction be approximated in the glyph bitmap? There is a comment above the FIR5 filter definition that suggests so. I submit it can not. The basic problem is that it depends on text color. For instance, if you want to generate approximation of 50 % pixel coverage in sRGB, your alpha value must be around 67 when the text is black and foreground is white, because the middle gray in sRGB is at rgb(188, 188, 188) and you only need 67 alpha to get from white to there. However, in the reverse color case, the correct alpha is 188, because the distance from 0 to 188 is 188. So it follows that correcting for one color requires reduction in alpha, and for the other case requires an increase in alpha. Therefore, no single correction can approximate the result UNLESS the foreground color is known, and the claim that FIR5 can do "cheap form of gamma correction" must be nonsense.

As an aside, if the foreground color is known, then a correction to alpha can be calculated, because the background can be assumed to be far away from foreground so that the text can be read in the first place, and therefore an error surface favoring the most likely cases can be computed that minimizes the error between the true gamma=1.0 blending and the gamma-ignoring component-linear alpha blending. Skia has this kind of algorithm that assumes background is 1.0-foreground in linear light, and produces a correction term. I have generalized this towards an unknown background by simply minimizing the error in terms of root mean square of error against every possible choice of background.

Applications that do gamma correction can go as far as set c=a, which of course equals the FIR3 filter. However, in general spreading the energy around a bit more and adding oversaturation to the rendering seems to produce slightly more pleasant results. For instance, with FIR3, small unhinted glyphs generally will have a lower contrast than users want, so a degree of color or shape distortion seems unavoidable.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by wl (Posted a comment)
  • -unavailable- added by freetype (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 29 Mar 2013 06:37:11 PM UTCwlStatusNone=>Fixed
      Assigned toNone=>wl
      Open/ClosedOpen=>Closed
      Planned ReleaseNone=>2.4.12

    Back to the top


    Powered by Savane 3.1-cleanup1