Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

Ah, I forgot something.
diff --git a/include/freetype/freetype.h b/include/freetype/freetype.h
index c0e5112..de276d1 100644
--- a/include/freetype/freetype.h
+++ b/include/freetype/freetype.h
@@ -3068,7 +3068,7 @@ FT_BEGIN_HEADER
   /*   and apply gamma to get them in a linear space,  */
   /*   */
   /*2. use OVER to blend the two linear colors using the glyph pixel   */
-  /*   as the alpha value (remember, the glyph bitmap is a coverage*/
+  /*   as the alpha value (remember, the glyph bitmap is an alpha coverage*/
   /*   bitmap), and*/
   /*   */
   /*3. apply inverse gamma to the blended pixel and write it back to   */
diff --git a/include/freetype/ftlcdfil.h b/include/freetype/ftlcdfil.h
index 91facf9..a095ae5 100644
--- a/include/freetype/ftlcdfil.h
+++ b/include/freetype/ftlcdfil.h
@@ -50,7 +50,9 @@ FT_BEGIN_HEADER
*   subpixels are color pixels, using them unfiltered creates severe
*   color fringes.  Use the @FT_Library_SetLcdFilter API to specify a
*   low-pass filter, which is then applied to subpixel-rendered bitmaps
-   *   generated through @FT_Render_Glyph.
+   *   generated through @FT_Render_Glyph. The filter will sacrifice some of
+   *   the higher resolution to reduce color fringes, making the glyph image
+   *   slightly blurrier. Positional improvements will remain.
*
*   Note that no filter is active by default, and that this function is
*   *not* implemented in default builds of the library.  You need to
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Werner LEMBERG]

> Here's my promised documentation including the filter change. Please
> review.

Thanks a lot!  This is now in the git repository, please re-check.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

Thanks! :)

I've attached some minor additions for the documentation (thanks for 
formatting my comments, I didn't find a boxy-comments plugin for vim). 
And the third revision of the news post :) Comments welcome. Maybe I'll 
make comparison screenshots for the new filter. Maybe when I stop being 
lazy.
diff --git a/include/freetype/freetype.h b/include/freetype/freetype.h
index c0e5112..d224ec9 100644
--- a/include/freetype/freetype.h
+++ b/include/freetype/freetype.h
@@ -3089,7 +3089,7 @@ FT_BEGIN_HEADER
   /*gives equal weight to the three color primaries and does not   */
   /*exceed a sum of 0x100, see section @lcd_filtering.  Then the   */
   /*only difference to gray linear blending is that subpixel-rendered  */
-  /*linear blending is done 3~times per pixel. */
+  /*linear blending is done 3~times per pixel: red foreground subpixel to red background subpixel and so on for green and blue. */
   /*   */
   /**/
   /*slot:: A handle to the glyph slot containing the image to  */
diff --git a/include/freetype/ftlcdfil.h b/include/freetype/ftlcdfil.h
index 91facf9..b0da6f3 100644
--- a/include/freetype/ftlcdfil.h
+++ b/include/freetype/ftlcdfil.h
@@ -109,7 +109,7 @@ FT_BEGIN_HEADER
*   one color channel.  That is, red alpha blends the red channel of the
*   text color with the red channel of the background pixel.  The
*   distribution of density values by the color-balanced filter assumes
-   *   alpha blending is done in linear space; only then color artifacts
+   *   alpha blending is done in linear space; only then will color artifacts
*   cancel out.
*/
 
FreeType 2.6.2 ships with three interesting details for users and developers of 
rendering libraries that deal with text.

The default LCD filter for subpixel rendering has been changed
--
When you look at subpixel-rendered text, no matter if it's on some kind of 
Unix, Windows or Mac OS X, you might notice that it's slightly colored. Using 
subpixel rendering on LCD panels is a trade-off, you get three times higher 
resolution in the direction of the pixel-substripe (usually horizontal RGB) in 
exchange for color artifacts. That's why it's necessary to filter a 
subpixel-rendered glyph to reduce those color artifacts, or color-fringing, 
before putting it somewhere on the screen. The filter distributes the values of 
a subpixel to it's neighbors, sacrificing some of that higher resolution and 
making the resulting glyph image blurrier, but the positioning improvement 
remains! The ideal filter for you depends on your screen (gamma curves!), the 
capabilities of the used rendering system (linear alpha blending and gamma 
correction!!!), your vision and your taste, probably in that order.

A filter should have two properties: it should be normalized, meaning the 
values used in the filter should sum up to a figurative 1 (here: 0x100 or 256) 
and it should be color-balanced, meaning that values for one subpixel are 
equally distributed to all other subpixels of a pixel to drastically reduce 
color-fringes. 

Previously, FreeType's default LCD filter was neither normalized, nor 
color-balanced. That was a deliberate choice because there is still no 
rendering system on *nixes that does linear alpha blending and gamma correction 
by default to render glyphs correctly. Going above a filter sum of 1 increased 
contrast somewhat at the expense of slight distortions and increased 
color-fringing, so this can be seen as a hack. You might have noticed that 
thumbnails in various places on your computer that show text could be quite 
colorful. Now you know why.

The new default filter is both normalized and color-balanced. It is indeed ever 
so slightly blurrier than the previous default one, but also lacks its' 
harshness and is less color-happy. The blurriness also means higher tolerance 
for non-ideal gamma of screens (viewing angles!) and rendering sytems without 
linear alpha blending. Note that color-fringing can only be really minimized 
when the rendering system will do linear alpha blending of text.

The "light" filter that has accompanied the default one for so long stays 
unchanged: it already is normalized and color-balanced. It is sharper than the 
default one but less tolerant of uncalibrated screens and rendering systems 
without linear alpha blending, producing more color-fringes.

(S)light hinting will invoke the native hinter if possible
--
In the past, setting "slight" hinting via fontconfig or configuration GUIs 
meant that native hints within a font were ignored and FreeType's autohinter 
would analyze the font on the fly and automatically do what the font designer 
would have to do at 

Re: [ft-devel] gamma correction demo images

[Werner LEMBERG]

> Ah, I forgot something.

Thanks!  Applied, with some modifications (I don't like future tense
in documentation).


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

I'm currently running Dave's filter on my crappy laptop screen, will
see how it goes.


Quick status report: I find Dave's filter quite pleasing actually on 
both crappy laptop screen and my calibrated entry-level Eizo monitor. 
It's fuzzier than the current default filter, yeah, but some of the 
harshness and color of it is also gone. And: it oddly reminds me of how 
text looks on Mac OS X. Dave, where did you lift this thing? :P


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

Here's my promised documentation including the filter change. Please review.
>From b1d0881d06bda44f090053dc90cd2a6a75271799 Mon Sep 17 00:00:00 2001
From: Nikolaus Waxweiler 
Date: Fri, 27 Nov 2015 19:26:00 +0100
Subject: [PATCH] Change default LCD filter to normalized, color-balanced;
 Documentation

---
 include/freetype/freetype.h |  80 --
 include/freetype/ftautoh.h  |  41 +-
 include/freetype/ftlcdfil.h | 102 +---
 src/base/ftlcdfil.c |   6 +--
 4 files changed, 155 insertions(+), 74 deletions(-)

diff --git a/include/freetype/freetype.h b/include/freetype/freetype.h
index c239f1b..382c715 100644
--- a/include/freetype/freetype.h
+++ b/include/freetype/freetype.h
@@ -2828,9 +2828,13 @@ FT_BEGIN_HEADER
* @FT_LOAD_TARGET_MONO instead.
*
*   FT_LOAD_TARGET_LIGHT ::
-   * A lighter hinting algorithm for non-monochrome modes.  Many
-   * generated glyphs are more fuzzy but better resemble its original
-   * shape.  A bit like rendering on Mac OS~X.
+   * A lighter hinting algorithm for gray-level modes.  Many generated
+   * glyphs are fuzzier but better resemble their original shape.  This is
+   * achieved by snapping glyphs to the pixel grid only vertically (Y-axis),
+   * as is done by Microsoft's ClearType and Adobe's proprietary font
+   * renderer.  This preserves inter-glyph spacing in horizontal text.  The
+   * snapping is done either by the native font driver if the driver itself
+   * and the font support it or by the autohinter.
*
*   FT_LOAD_TARGET_MONO ::
* Strong hinting algorithm that should only be used for monochrome
@@ -2937,7 +2941,9 @@ FT_BEGIN_HEADER
   /*field in the @FT_GlyphSlotRec structure gives the format of the*/
   /*returned bitmap.   */
   /*   */
-  /*All modes except @FT_RENDER_MODE_MONO use 256 levels of opacity.   */
+  /*All modes except @FT_RENDER_MODE_MONO use 256 levels of opacity as */
+  /*in coverage. Use linear alpha blending and gamma correction to */
+  /*correctly render non-monochrome glyph bitmaps onto a surface, see @FT_Render_Glyph.*/
   /*   */
   /*   */
   /*FT_RENDER_MODE_NORMAL ::   */
@@ -3006,6 +3012,72 @@ FT_BEGIN_HEADER
   /*Convert a given glyph image to a bitmap.  It does so by inspecting */
   /*the glyph image format, finding the relevant renderer, and */
   /*invoking it.   */
+  /*
+   *When FreeType outputs a bitmap of a glyph, it really outputs an alpha
+   *coverage map. If a pixel is completely covered by a filled-in outline,
+   *the bitmap will contain 0xFF at that pixel, meaning that 0xFF/0xFF
+   *fraction of that pixel is covered, meaning the pixel is 100% black (or
+   *0% bright). If a pixel is only 50% covered (e.g. 0x80), the pixel is
+   *made 50% black (50% bright or a middle shade of grey) and 0% covered
+   *means 0% black (100% bright or white).
+   *
+   *On high-DPI screens like on smartphones and tablets, the pixels are so
+   *small that their chance of being completely covered and therefore
+   *completely black are fairly good. On the low-DPI screens, the situation
+   *is different. The pixels are too large for most of the details of a
+   *glyph and shades of gray are the norm rather than the exception.
+   *
+   *This is relevant because all our screens have a second problem: they
+   *are not linear. 1 + 1 is not 2. Twice the value does not result in
+   *twice the brightness. When a pixel is only 50% covered, the coverage
+   *map says 50% black, and this translates to a pixel value of 128 when
+   *you use 8 bits per channel (0-255). However, this does not translate to
+   *50% brightness for that pixel on our sRGB and gamma 2.2 screens. Due to
+   *their non-linearity, they dwell longer in the darks and only a pixel
+   *value of about 186 results in 50% brightness -- 128 ends up too dark on
+   *both bright and dark backgrounds. The net result is that dark text
+   *looks burnt-out, pixely and blotchy on bright background, bright text
+   *too frail on dark backgrounds and colored text (e.g. red) on colored
+   *background (e.g. green) seems to have dark halos or "dirt" around it.
+   *The situation is especially ugly for diagonal stems like in 'w' where
+   *the quality of FreeType's anti-aliasing depends on the correct display
+   *of grays. On high-DPI screens where smaller, fully black pixels reign
+   *supreme, this doesn't 

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

This ;) (Comments on my comments welcome -- still not sure what to do
about e.g. the color-balancing formula)

2015-11-26 20:54 GMT+01:00 Werner LEMBERG :
>>> This sounds like a good compromise, thanks.
>>>
>>> Can we all agree on this filter as the default for `light_filter'?
>>>
>>> Alexei, what value should `default_filter' have?
>>
>> Please leave the light one alone. Dave's filter should be default.
>
> So *what* shall I change?
>
>
> Werner
>
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
From e9b3098dbbcfe7a313982cb47ab8689eb331e2df Mon Sep 17 00:00:00 2001
From: Nikolaus Waxweiler 
Date: Thu, 26 Nov 2015 22:52:19 +0100
Subject: [PATCH] Change default LCD filter to normalized, color-balanced

---
 include/freetype/ftlcdfil.h | 39 +--
 src/base/ftlcdfil.c |  6 ++
 2 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/include/freetype/ftlcdfil.h b/include/freetype/ftlcdfil.h
index 3a62528..eb48513 100644
--- a/include/freetype/ftlcdfil.h
+++ b/include/freetype/ftlcdfil.h
@@ -69,28 +69,28 @@ FT_BEGIN_HEADER
*   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 (as given by FT_LCD_FILTER_DEFAULT) 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
+   *   To preserve color neutrality and reduce color fringing to a
+   *   minimum, 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
+   *   across the filter kernel, which makes it colorless or
+   *   color-balanced.  One possible set of weights is
*
*   {
* [0x10, 0x50, 0x60, 0x50, 0x10],
*   }
*
-   *   where `a' has value 0x30 and `c' value 0x20.  The weights in filter
-   *   may have a sum larger than 0x100, which increases coloration slightly
-   *   but also improves contrast.
+   *   where `a' has value 0x30 and `c' value 0x20, however the sum goes
+   *   above 0x100, leading to non-linearities and increased
+   *   color-fringing. This can be used to increase contrast at the cost
+   *   of colorfulness, but stem darkening achieves contrast much better if
+   *   the rendering system can do linear alpha blending and gamma
+   *   correction.
*/
 
 
@@ -111,10 +111,21 @@ FT_BEGIN_HEADER
* The default filter reduces color fringes considerably, at the cost
* of a slight blurriness in the output.
*
+   * It is a normalized and color-balanced five-tap filter that is more
+   * forgiving to screens with non-ideal gamma curves and viewing
+   * angles. Note that while color-fringing is reduced, it can only be
+   * minimized by using linear alpha blending and gamma correction to
+   * render glyphs onto surfaces.
+   *
*   FT_LCD_FILTER_LIGHT ::
-   * The light filter is a variant that produces less blurriness at the
-   * cost of slightly more color fringes than the default one.  It might
-   * be better, depending on taste, your monitor, or your personal vision.
+   * The light filter is a variant that is sharper at the cost of
+   * slightly more color fringes than the default one.
+   *
+   * It is a normalized and color-balanced three-tap filter that is less
+   * forgiving to screens with non-ideal gamma curves and viewing
+   * angles. This filter works best when the rendering system uses
+   * linear alpha blending and gamma correction to render glyphs onto
+   * surfaces.
*
*   FT_LCD_FILTER_LEGACY ::
* This filter corresponds to the original libXft color filter.  It
diff --git a/src/base/ftlcdfil.c b/src/base/ftlcdfil.c
index b50383c..5ee7e0a 100644
--- a/src/base/ftlcdfil.c
+++ b/src/base/ftlcdfil.c
@@ -305,12 +305,10 @@
   FT_Library_SetLcdFilter( FT_Librarylibrary,
FT_LcdFilter  filter )
   {
+static const FT_Byte  default_filter[5] =
+{ 0x08, 0x4d, 0x56, 0x4d, 0x08 };
 static const FT_Byte  light_filter[5] =
 { 0x00, 0x55, 0x56, 0x55, 0x00 };
-/* the values here sum up to a value larger than 256, */
-/* providing a cheap gamma correction */
-static const 

Re: [ft-devel] gamma correction demo images

[Werner LEMBERG]

>> This sounds like a good compromise, thanks.
>>
>> Can we all agree on this filter as the default for `light_filter'?
>>
>> Alexei, what value should `default_filter' have?
>
> Please leave the light one alone. Dave's filter should be default.

So *what* shall I change?


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Alexei Podtelezhnikov]

On Thu, Nov 26, 2015 at 4:57 PM, Nikolaus Waxweiler  wrote:
> This ;) (Comments on my comments welcome -- still not sure what to do
> about e.g. the color-balancing formula)
>
Thank you. This is good enough. I would however remove any suggestion
of non-normalized filters, which are combinations of normalized ones
and scaling. Whoever wants to scale brightness can do it themselves at
their own pleasure/risk.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

> Please leave the light one alone. Dave's filter should be default.

That's what I thought, too. I will update the documentation on Friday
hopefully, am abroad right now and forgot to take my working directory
with me ;)

I'm currently running Dave's filter on my crappy laptop screen, will
see how it goes.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Werner LEMBERG]

> It is true that the 5-wide filters (e.g., [0x8, 0x4D, 0x56, 0x4D,
> 0x8] that are color balanced are not quite as sharp.  However, I
> found empirically they produce less color fringing on a slightly
> uncalibrated display.  [...]

This sounds like a good compromise, thanks.

Can we all agree on this filter as the default for `light_filter'?

Alexei, what value should `default_filter' have?


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Werner LEMBERG]

>> I did some experimentation with my crazy patterns.  I firmly
>> believe now that simple box filter aka FT_LCD_FILTER_LIGHT is not
>> just good but in fact the best in reducing color fringes IFF used
>> with correct gamma.  All color-balanced filters with gamma
>> eliminate color fringes completely, but the box filter is obviously
>> the least blurry of them all.  So I reached the same conclusion as
>> this paper:
>> http://scien.stanford.edu/jfsite/Papers/ImageRendering/Displays/Xu_Farrell_Matskewich_Wandell_final.pdf
>
> Interesting paper, although I know too little about the science
> behind it to comment on how valid these results are on a wide range
> of screens.  The paper itself states that numbers may vary
> significantly between displays and viewing conditions.
>
> Here's a comparison of the paper's filter to FT's light filter:
> http://postimg.org/image/mxc6oa6mv/full/ (no stem darkening).  The
> paper's filter appears slightly sharper or more contrasty on my
> monitor but also slightly more colorful than FT's light filter.
>
> Werner, Dave, what's your opinion on this?  I would like to change
> the documentation of ftlcdfil.h to note that stem darkening is
> better than filters going over 0x100 and update the filter
> recommendation to the light filter for now.  Also, where does the
> [a-c, a+c, 2a, a+c, a-c] formula come from?  Is the "[a b c b a]
> where 2a+2b+c=1" formula newer?  I could include the paper's filter
> in the documentation and sprinkle it with some source citations.
>
> [1]: [a, b, c, b, a] where a = 0.0, b = 0.3, c = 1 - 2a - 2b = [0,
> 0.3, 0.4, 0.3, 0] =~ [0x00, 0x4D, 0x66, 0x4D, 0x00] with slight
> rounding errors ;)

David, please help answering this – my knowledge is too limited
here :-)


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

The next release of ftstring will also perform blending of basic
colors. You will be able to cycle though colors by pressing space. So
ftstring will be the first of freetype demo tools to demonstrate
importance of gamma correction in eliminating dirty appearance of
fonts.


Nice! :)


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Alexei Podtelezhnikov]

On Sun, Nov 22, 2015 at 7:49 AM, Nikolaus Waxweiler  wrote:
> And, uh, is the light filter color balanced?

Yes, it is almost perfectly color balanced. This means that color
contributions are equal, i.e., b + a  = c in filter [a b c b a]. This
is what is imposed when people specify filters as  [a-c, a+c, 2a, a+c,
a-c]. The light filter { 0x00, 0x55, 0x56, 0x55, 0x00 } is indeed
almost perfectly color balanced and normalized, which is what we need.

Freetype's default filter { 0x10, 0x40, 0x70, 0x40, 0x10 } is neither
balanced nor normalized. The comment speaks about "cheap gamma
correction" through inflating the resulting values and clipping them
above 1. This is very wrong! You never should apply any gamma to alpha
channel to begin with. For the white-on-black text the effect would be
opposite of gamma correction if anything.

There you go, the lack of proper gamma correction results in a bad
filter being chosen as default.

Alexei

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Alexei Podtelezhnikov]

On Fri, Nov 13, 2015 at 11:20 AM, Alexei Podtelezhnikov
 wrote:
>> Any progress, Alexei? :)
>
> Next release of freetype-demo tools will have starting gamma value of 1.8.

The next release of ftstring will also perform blending of basic
colors. You will be able to cycle though colors by pressing space. So
ftstring will be the first of freetype demo tools to demonstrate
importance of gamma correction in eliminating dirty appearance of
fonts.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

And, uh, is the light filter color balanced?

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

Interesting paper, although I know too little about the science behind 
it to comment on how valid these results are on a wide range of screens. 
The paper itself states that numbers may vary significantly between 
displays and viewing conditions.


Here's a comparison of the paper's filter to FT's light filter: 
http://postimg.org/image/mxc6oa6mv/full/ (no stem darkening). The 
paper's filter appears slightly sharper or more contrasty on my monitor 
but also slightly more colorful than FT's light filter.


Werner, Dave, what's your opinion on this? I would like to change the 
documentation of ftlcdfil.h to note that stem darkening is better than 
filters going over 0x100 and update the filter recommendation to the 
light filter for now. Also, where does the [a-c, a+c, 2a, a+c, a-c] 
formula come from? Is the "[a b c b a] where 2a+2b+c=1" formula newer? I 
could include the paper's filter in the documentation and sprinkle it 
with some source citations.


[1]: [a, b, c, b, a] where a = 0.0, b = 0.3, c = 1 - 2a - 2b = [0, 0.3, 
0.4, 0.3, 0] =~ [0x00, 0x4D, 0x66, 0x4D, 0x00] with slight rounding 
errors ;)


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

I did not work on subpixel rendering in FreeType, but I assume it is
similar to what Adobe does. Here is a brief summary.


I'm currently writing up the documentation for ftautoh.h, do I 
understand correctly that the steps for linear alpha blending and gamma 
correction of gray and subpixel-rendered glyphs are exactly the same? 
Meaning:
1. Take the foreground and background colors (e.g., in sRGB space) and 
apply gamma to get them in a linear space.
2. Blend the two linear colors using the alpha value from the glyph's 
coverage bitmap
3. Apply inverse gamma (e.g. 1.8) to the blended pixel and write it back 
to the image.



The density computed for each subpixel must be distributed equally to
all color channels.


Werner, 
http://freetype.org/freetype2/docs/reference/ft2-lcd_filtering.html 
suggests [0x10, 0x50, 0x60, 0x50, 0x10] as a possible LCD filter to use 
when doing LAB+GC. Is this correct and does what Dave suggests here? The 
sum seems to go above 0x100? And if it is, would it make a good 
candidate for a new FT_LCD_FILTER_EQUAL_WEIGHT that LAB+GC-enabled libs 
can set?


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

Yes, the only difference in blending is that subpixel mode does it 3
times per pixel.


Okay, thanks :)


The filter is color-balanced, but not normalized. Values above 0x100
will have to be clamped and this non-linearity causes distortion and
adds to color fringing. Stem darkening is the better way to increase
contrast.


So I tried to find two values that sum to 0x100:

>>> def f(a,c):
...  return [a - c, a + c, 2 * a, a + c, a - c]
...
>>> [(a,c) for a in range(0x100) for c in range(0x100) if a > c and 
sum(f(a, c)) == 0x100]

[]

So, uh, what am I missing? I found some values that sum to 0xFC but I 
want 0x100 :(


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Dave Arnold]

Yes, the only difference in blending is that subpixel mode does it 3 times per 
pixel.

The filter is color-balanced, but not normalized. Values above 0x100 will have 
to be clamped and this non-linearity causes distortion and adds to color 
fringing. Stem darkening is the better way to increase contrast.


From: freetype-devel-bounces+darnold=adobe@nongnu.org 
<freetype-devel-bounces+darnold=adobe@nongnu.org> on behalf of Nikolaus 
Waxweiler <madig...@gmail.com>
Sent: Friday, November 20, 2015 10:08 AM
To: freetype-devel@nongnu.org
Subject: Re: [ft-devel] gamma correction demo images

> I did not work on subpixel rendering in FreeType, but I assume it is
> similar to what Adobe does. Here is a brief summary.

I'm currently writing up the documentation for ftautoh.h, do I
understand correctly that the steps for linear alpha blending and gamma
correction of gray and subpixel-rendered glyphs are exactly the same?
Meaning:
1. Take the foreground and background colors (e.g., in sRGB space) and
apply gamma to get them in a linear space.
2. Blend the two linear colors using the alpha value from the glyph's
coverage bitmap
3. Apply inverse gamma (e.g. 1.8) to the blended pixel and write it back
to the image.

> The density computed for each subpixel must be distributed equally to
> all color channels.

Werner,
http://freetype.org/freetype2/docs/reference/ft2-lcd_filtering.html
suggests [0x10, 0x50, 0x60, 0x50, 0x10] as a possible LCD filter to use
when doing LAB+GC. Is this correct and does what Dave suggests here? The
sum seems to go above 0x100? And if it is, would it make a good
candidate for a new FT_LCD_FILTER_EQUAL_WEIGHT that LAB+GC-enabled libs
can set?

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Alexei Podtelezhnikov]

On Fri, Nov 20, 2015 at 2:46 PM, Nikolaus Waxweiler  wrote:
>> The filter is color-balanced, but not normalized. Values above 0x100
>> will have to be clamped and this non-linearity causes distortion and
>> adds to color fringing. Stem darkening is the better way to increase
>> contrast.
>
>
> So I tried to find two values that sum to 0x100:
>
 def f(a,c):
> ...  return [a - c, a + c, 2 * a, a + c, a - c]

I did some experimentation with my crazy patterns. I firmly believe
now that simple box filter aka FT_LCD_FILTER_LIGHT is not just good
but in fact the best in reducing color fringes IFF used with correct
gamma. All color-balances filters with gamma eliminate color fringes
completely, but the box filter is obviously the least blurry of them
all. So I reached the same conclusion as this paper:
http://scien.stanford.edu/jfsite/Papers/ImageRendering/Displays/Xu_Farrell_Matskewich_Wandell_final.pdf
. Some day soon I will write a blog about the details of my
experiments.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

Good, thanks :) Then I'll work on stem darkening soon.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Alexei Podtelezhnikov]

> Any progress, Alexei? :)

Next release of freetype-demo tools will have starting gamma value of 1.8.
http://git.savannah.gnu.org/cgit/freetype/freetype2-demos.git/commit/?id=b48a54c1499debc39e73c1b024064ecb6d24d29e

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Dave Arnold]

On 11/4/2015 7:27 AM, Alexei Podtelezhnikov wrote:

On Wed, Nov 4, 2015 at 6:24 AM, Nikolaus Waxweiler  wrote:

Any progress, Alexei? :)

I am sitting here in total disbelief and utterly embarrassed by the
lack of gamma correction setting for text rendering in any major Linux
desktop environment. How could this happen? Pango and Qt do not do it
either. I think FreeType is to blame for the lack of support, because
everybody just trusts FreeType. We need new FT_RENDER_MODE_GAMMA.

I am also confused. It seems obvious how to do it for grayscale
rendering . But what about subpixel rendering? I mostly see
application of gamma correction per each RGB channel, which seems
totally arbitrary. See attached image for wonderful color effects on
slightly slanted lines of 1, 4/3, 5/3-pixel wide and so on. I also
found a reference of HSL lightness gamma correction, which seems more
justifiable to me. I have not tried it yet. How does alpha blending
works on subpixel level, or does it at all? Then there is LCD
filtering to deal with color fringes, which changes RGB values and
begs the question if gamma correction is even suitable after this
brutal treatment. Perhaps you can enlighten me here.

It seems to me that gamma was considered a good idea, but subpixel
rendering got in the way, and now we are all stuck.

Regards,
Alexei

Gamma correction is even more critical for subpixel rendering. In addition to 
all the problems noted in non-linear blending of grayscale anti-aliasing, there 
is the issue of color fringing.

I did not work on subpixel rendering in FreeType, but I assume it is similar to 
what Adobe does. Here is a brief summary.

When outlines are scan-converted, the output buffer has 3x the resolution in a 
direction perpendicular to the subpixel stripes. This is especially useful when 
the stripes are vertical, because it provides increased positional accuracy for 
vertical stems. Vertical stems are important for Latin-based text, but can't be 
fitted to integral pixel boundaries without sacrificing inter-glyph spacing.

The resulting image or density map is then passed through what I call a 
color-balanced filter. The density computed for each subpixel must be 
distributed equally to all color channels. This avoids imparting a false color 
to the final bitmap. A good color-balanced filter is a simple block filter that 
is 3 subpixels wide, but is allowed to span pixel boundaries. It is important 
to realize that the filtering step sacrifices some of the 3x higher resolution 
in order to avoid color artifacts. The filter makes the image blurrier, but the 
positioning improvement is not lost.

The resulting density map has 3 alpha values per pixel, which are typically 
left, middle and right, and map to red, green and blue color channels. Each of 
the 3 alpha values is independently used to blend one color channel. That is, 
red (or left) alpha blends the red channel of the text color with the red 
channel of the background pixel. This blending must be done in a linear color 
space! The distribution of density values by the color-balanced filter depends 
on this. In other words, the color artifacts will only cancel out if the 
blending is in a linear space. The same gamma value is commonly used for each 
channel.

Thanks.

-Dave

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

Any progress, Alexei? :)

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Alexei Podtelezhnikov]

On Wed, Nov 4, 2015 at 6:24 AM, Nikolaus Waxweiler  wrote:
> Any progress, Alexei? :)

I am sitting here in total disbelief and utterly embarrassed by the
lack of gamma correction setting for text rendering in any major Linux
desktop environment. How could this happen? Pango and Qt do not do it
either. I think FreeType is to blame for the lack of support, because
everybody just trusts FreeType. We need new FT_RENDER_MODE_GAMMA.

I am also confused. It seems obvious how to do it for grayscale
rendering . But what about subpixel rendering? I mostly see
application of gamma correction per each RGB channel, which seems
totally arbitrary. See attached image for wonderful color effects on
slightly slanted lines of 1, 4/3, 5/3-pixel wide and so on. I also
found a reference of HSL lightness gamma correction, which seems more
justifiable to me. I have not tried it yet. How does alpha blending
works on subpixel level, or does it at all? Then there is LCD
filtering to deal with color fringes, which changes RGB values and
begs the question if gamma correction is even suitable after this
brutal treatment. Perhaps you can enlighten me here.

It seems to me that gamma was considered a good idea, but subpixel
rendering got in the way, and now we are all stuck.

Regards,
Alexei
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Christian Demmer]

On Tue, 27 Oct 2015 23:25:02 -0400, Alexei Podtelezhnikov wrote:
> Please reply with your value for survey purposes.

Eizo SX2262W, MacOS X 10.8: about 2.2

Chris

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Behdad Esfahbod]

On 15-10-27 08:25 PM, Alexei Podtelezhnikov wrote:
> On Mon, Oct 26, 2015 at 10:26 AM, Alexei Podtelezhnikov
>  wrote:
>> On Sun, Oct 25, 2015 at 2:35 PM, Nikolaus Waxweiler  
>> wrote:
>>> The world needs more linear alpha blending and gamma correction. Spread the 
>>> gospel!
>>
>> What would be best default value though?
> 
> Attached is a much better image to calibrate you gamma correction. You

Excellent!

> do not need any additional software, just look where the moiré pattern
> vanishes. On 5 displays in my disposal today I got values ranging from
> 1.6 to 2.4.
> 
> Please reply with your value for survey purposes.

On Lenovo Thinkpad X1 Carbon Gen 3 retina I get 1.6.

> Thank you,
> Alexei
> 
> 
> 
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel
> 

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

On my Eizo EV2736 with a color profile, the moire pattern is least 
visible between 2.2 and 2.4.


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Dave Arnold]

On 10/28/2015 5:57 AM, Behdad Esfahbod wrote:

On 15-10-27 08:25 PM, Alexei Podtelezhnikov wrote:

On Mon, Oct 26, 2015 at 10:26 AM, Alexei Podtelezhnikov
 wrote:

On Sun, Oct 25, 2015 at 2:35 PM, Nikolaus Waxweiler  wrote:

The world needs more linear alpha blending and gamma correction. Spread the 
gospel!

What would be best default value though?

Attached is a much better image to calibrate you gamma correction. You

Excellent!


do not need any additional software, just look where the moiré pattern
vanishes. On 5 displays in my disposal today I got values ranging from
1.6 to 2.4.

Please reply with your value for survey purposes.

On Lenovo Thinkpad X1 Carbon Gen 3 retina I get 1.6.



Nice test pattern.

Please keep in mind that LCD displays have a dependency on viewing angle. This 
depends on the LCD technology and tends to be greater with higher resolution 
displays. This can cause the region of least pattern on Alexei's image to 
follow a slanted line from top to bottom. You should try to report the values 
at the angles you use most.

-Dave


___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Markus Trippelsdorf]

On 2015.10.27 at 23:25 -0400, Alexei Podtelezhnikov wrote:
> Attached is a much better image to calibrate you gamma correction. You
> do not need any additional software, just look where the moiré pattern
> vanishes. On 5 displays in my disposal today I got values ranging from
> 1.6 to 2.4.

On a TN monitor in portrait mode the value will change as you move your
head from left to right...

I think David once wrote that 1.8 is a good compromise and I can confirm
this.

-- 
Markus

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Alexei Podtelezhnikov]

On Mon, Oct 26, 2015 at 10:26 AM, Alexei Podtelezhnikov
 wrote:
> What would be best default value though? David Turner argued
> that it is gamma = 1.4
> (http://lists.nongnu.org/archive/html/freetype-devel/2004-06/msg00022.html).
> David Arnold also thinks that is lower than 2.2, perhaps 1.8.

The attached image can be used to calibrate gamma correction. You just
need a program that can apply gamma correction, e.g., GIMP. Without
any correction (gamma = 1.0) the image should produce a visible moiré
pattern. With correct gamma applied, you should not see any pattern.

Gamma = 1.8 works best for me. What is your gamma correction? Please
reply for survey purposes.

Than you,
Alexei
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Alexei Podtelezhnikov]

On Mon, Oct 26, 2015 at 10:26 AM, Alexei Podtelezhnikov
 wrote:
> On Sun, Oct 25, 2015 at 2:35 PM, Nikolaus Waxweiler  
> wrote:
>> The world needs more linear alpha blending and gamma correction. Spread the 
>> gospel!
>
> What would be best default value though?

Attached is a much better image to calibrate you gamma correction. You
do not need any additional software, just look where the moiré pattern
vanishes. On 5 displays in my disposal today I got values ranging from
1.6 to 2.4.

Please reply with your value for survey purposes.

Thank you,
Alexei
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Tom Bishop, Wenlin Institute]

It's about 1.65 on my MacBook Pro (Retina, 13-inch, Late 2013, Intel Iris 1536 
MB).

Tom

> On Oct 27, 2015, at 11:25 PM, Alexei Podtelezhnikov  
> wrote:
> 
> On Mon, Oct 26, 2015 at 10:26 AM, Alexei Podtelezhnikov
>  wrote:
>> On Sun, Oct 25, 2015 at 2:35 PM, Nikolaus Waxweiler  
>> wrote:
>>> The world needs more linear alpha blending and gamma correction. Spread the 
>>> gospel!
>> 
>> What would be best default value though?
> 
> Attached is a much better image to calibrate you gamma correction. You
> do not need any additional software, just look where the moiré pattern
> vanishes. On 5 displays in my disposal today I got values ranging from
> 1.6 to 2.4.
> 
> Please reply with your value for survey purposes.
> 
> Thank you,
> Alexei
> ___
> Freetype-devel mailing list
> Freetype-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/freetype-devel


Wenlin Institute, Inc. SPC (a Social Purpose Corporation)
文林研究所社会目的公司
Software for Learning Chinese
E-mail: wen...@wenlin.com Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)
☯




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Werner LEMBERG]

> Attached is a much better image to calibrate you gamma correction.

Nice!

> You do not need any additional software, just look where the moiré
> pattern vanishes. On 5 displays in my disposal today I got values
> ranging from 1.6 to 2.4.

For my GNU/Linux box running KDE 4.14.9, I've set the desktop to a
gamma value of 1.6; looking at your image I get a value of 2.0.


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Werner LEMBERG]

> We can start with changing the default gamma value in ftsting
> (defaults to 2.0) and ftview (defaults to 1.0).  They have always
> been examples for the rest of the world.  I hope Werner does not
> mind this change.

Please proceed!  Right now I'm only passively reading your very
interesting e-mail exchange, still working on bug reports...


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Alexei Podtelezhnikov]

On Sun, Oct 25, 2015 at 2:35 PM, Nikolaus Waxweiler  wrote:
> The world needs more linear alpha blending and gamma correction. Spread the 
> gospel!

We can start with changing the default gamma value in ftsting
(defaults to 2.0) and ftview (defaults to 1.0). They have always been
examples for the rest of the world. I hope Werner does not mind this
change. What would be best default value though? David Turner argued
that it is gamma = 1.4
(http://lists.nongnu.org/archive/html/freetype-devel/2004-06/msg00022.html).
David Arnold also thinks that is lower than 2.2, perhaps 1.8.

I think we can answer this question more precisely. We need a
synthetic font with the following glyphs: a single very thin near
vertical line and a series of the same lines next to each other. The
waving affect should produce something like Moiré pattern in the later
unless correct gamma is used. We can calibrate gamma correction.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] gamma correction demo images

[Nikolaus Waxweiler]

Welcome to the One True Belief, brother. The world needs more linear alpha 
blending and gamma correction. Spead the gospel!

The effect is also nicely visible at 40ppem with all the other glyphs -- they 
just look smoother overall.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel