<blockquote>
  <p>What methods are used for sub-pixel anti-aliasing that give such good results?</p>
</blockquote>

<p>You simply rasterize the letters as if they were 3x as wide.</p>

<p>The results differ in the way you rasterize the curves, most notably what kind of anti-aliasing/sampling scheme does it use and whether it makes use of <a href="https://en.wikipedia.org/wiki/Font_hinting" rel="nofollow">font hinting</a>. For great overview see <a href="http://www.antigrain.com/research/font_rasterization/" rel="nofollow">Texts Rasterization Exposures</a> by Anti-Grain Geometry (IIRC this is what Chromium/PDFium uses) or <a href="https://en.wikipedia.org/wiki/Subpixel_rendering" rel="nofollow">Subpixel rendering</a> on Wikipedia.</p>

<p>What the attached image goes, I don't believe it has anything to do with sub-pixel rendering. It could be anything: wrong <a href="https://en.wikipedia.org/wiki/Pixel_geometry" rel="nofollow">pixel geometry</a>, wrong gamma, wrong color space conversion, ...</p>

CC BY-SA 3.0
2015-08-10T12:01:41.727Z
I would expect problems with pixel geometry, gamma or colour space conversion to show up as colour distortion at arbitrary points in the image, rather than the regular cycle seen in the question's image. The fact that it cycles horizontally between exaggerated colour antialiasing and pure greyscale antialiasing hints that the first application of antialiasing was performed at a different scale.
trichoplax is on Codidact now
CC BY-SA 3.0
2015-08-10T12:16:59.983Z
I don't have the full explanation, as the distortion does not seem to be aligned between the different rows of text, but it does seem the problem is related to sub-pixel rendering of already rasterised text rather than vector text.
trichoplax is on Codidact now
CC BY-SA 3.0
2015-08-10T12:39:48.860Z
@trichoplax What I try to say is that I doubt there an issue with Anti-Grain's sub-pixel rendering. Instead I would guess the input gets mangled earlier than it enters the rasterizer. Or later, but not in the rasterizer itself.
Ecir Hana
CC BY-SA 3.0
2015-08-10T12:46:31.897Z
Yes I think the sub-pixel rendering is being applied correctly, but when applied to pre-rasterised text it is not possible to give a good result. I don't think that the renderer is broken, I just think it is being fed the wrong kind of text.
trichoplax is on Codidact now
CC BY-SA 3.0
2015-08-10T10:38:50.383Z
2015-08-10T10:38:50.383Z
Ecir Hana
<p>I'm not sure what happens there. Looking at the rendering of "considerations" in your example, the "cons" looks like what you get when you do crude sub pixel anti-aliasing, without applying the necessary "fix up" to make it look good. But then the "der" in the same word looks like there's no sub-pixel anti-aliasing.</p>

<p>You can find a good article about how good looking sub-pixel anti-aliasing works here <a href="https://www.grc.com/ct/ctwhat.htm" rel="nofollow noreferrer">https://www.grc.com/ct/ctwhat.htm</a> and for the "fix up" part here <a href="https://www.grc.com/ct/freeandclear.htm" rel="nofollow noreferrer">https://www.grc.com/ct/freeandclear.htm</a> and here <a href="https://www.grc.com/ct/cttech.htm" rel="nofollow noreferrer">https://www.grc.com/ct/cttech.htm</a></p>

<p>What it comes down to is: if you just compute the R/G/B intensities by calculating the covered area for each sub-pixel, the resulting color fringes are very ugly/irritating. To fix it you have to apply a horizontal blur/low-pass filter to the sub-pixel image. The result is an image that's less sharp but also has far less saturated colors. I.e. something like your "Check you" example.</p>

CC BY-SA 4.0
2019-04-21T01:30:51.013Z
2019-04-21T01:40:39.120Z
2019-04-21T01:40:39.120Z
pgroke
<p>I recently had an <a href="https://superuser.com/q/930036/264276">issue with sub-pixel anti-aliasing of text</a>, which produces very harsh colours and made me wonder how it is meant to be done properly:</p>

<blockquote>
  <p><a href="https://i.sstatic.net/SQWSI.png" rel="noreferrer"><img src="https://i.sstatic.net/SQWSI.png" alt="enter image description here"></a></p>
</blockquote>

<p>I've drawn some cases of a black tile covering thirds of pixels below.</p>

<p><a href="https://i.sstatic.net/CE16y.png" rel="noreferrer"><img src="https://i.sstatic.net/CE16y.png" alt="enter image description here"></a></p>

<p>The colours match the ones I'm seeing, however when I look at properly antialiased text, the result is not nearly as bright and distracting:</p>

<blockquote>
  <p><img src="https://i.sstatic.net/4Vrfz.png" alt="from www.lagom.nl"></p>
</blockquote>

<p>I assume there has to be a balance between a good light intensity and the right colour. What methods are used for sub-pixel anti-aliasing that give such good results?</p>

<hr>

<p><em>Update:</em></p>

<p>I've rendered a white teapot to an image with 3x width and with multisampling. Below I compare averaging every 3 pixels with assigning each to RGB. The colours still seem overly bright in some cases (especially compared to the example above from <a href="http://www.lagom.nl/lcd-test/subpixel.php" rel="noreferrer">here</a>), not that my phone captures them well.</p>

<p><a href="https://i.sstatic.net/19ABb.png" rel="noreferrer"><img src="https://i.sstatic.net/19ABb.png" alt="enter image description here"></a><a href="https://i.sstatic.net/RE5Jv.png" rel="noreferrer"><img src="https://i.sstatic.net/RE5Jv.png" alt="enter image description here"></a></p>

<p><a href="https://i.sstatic.net/BZxjL.png" rel="noreferrer"><img src="https://i.sstatic.net/BZxjL.png" alt="enter image description here"></a><a href="https://i.sstatic.net/WT6ci.png" rel="noreferrer"><img src="https://i.sstatic.net/WT6ci.png" alt="enter image description here"></a></p>

<p><a href="https://i.sstatic.net/qveN5m.png" rel="noreferrer"><img src="https://i.sstatic.net/qveN5m.png" alt="enter image description here"></a><a href="https://i.sstatic.net/wPGG7m.png" rel="noreferrer"><img src="https://i.sstatic.net/wPGG7m.png" alt="enter image description here"></a>
<sup>OK, so my monitor needs a little dusting</sup></p>

CC BY-SA 4.0
2021-03-30T13:07:07.227Z
As I currently understand it, there are two steps. You did the first step by stretching horizontally the path, before rasterizing it and horizontally shrink it into RGB pixel. The second step that you are missing is to apply a horizontal block filter. That is y[i] = 0.3*x[i-1] + 0x4*x[i] + 0.3*x[i+1]. You may change the coefficients 0.3 and 0.4. What is required is that the sum is 1. You could use 0.25 and 0.5 witch can be implemented with a simple shift. This filtering is applied on each color component RGB. You could also apply it on the stretched image.
chmike
CC BY-SA 4.0
2021-03-31T07:36:21.293Z
You would apply the filtering on the freshly rasterized gray image, and then group 3 gray values into 1 RGB value.
chmike
CC BY-SA 3.0
2016-08-06T22:23:25.930Z
I personally would guess that the garish result is taking the subpixel samples further apart than the nice result, which means that there's a more dramatic difference in coverage and therefore brightness.
porglezomp
CC BY-SA 3.0
2015-08-10T09:58:22.040Z
I believe that some screens have a different layout of the primary colours. Have you viewed your results on different types of screen?
trichoplax is on Codidact now
CC BY-SA 3.0
2015-08-10T10:02:22.253Z
@trichoplax no, but I'm confident both my monitors are RGB. Also here I'm more interested in how subpixel antialiasing techniques are meant to work than a fix for my issue.
jozxyqk
CC BY-SA 3.0
2015-08-10T10:06:17.063Z
I didn't mean different primary colours, I just meant that the red, green and blue are arranged in different geometric patterns, so your algorithm would need to know which pattern is being used in order to give good results.
trichoplax is on Codidact now
CC BY-SA 3.0
2015-08-10T10:06:48.327Z
[This image](https://en.wikipedia.org/wiki/Subpixel_rendering#/media/File:Pixel_geometry_01_Pengo.jpg) shows how varied the arrangement of subpixels can be.
trichoplax is on Codidact now
CC BY-SA 3.0
2015-08-10T10:09:22.740Z
Incidentally, I like the question and I'm interested to see the answers, but I can't upvote until midnight...
trichoplax is on Codidact now
CC BY-SA 3.0
2015-08-10T10:09:51.153Z
@trichoplax yes, sorry I should have clarified, both monitors have pixels split into thirds in R-G-B order from left to right as in [this photo](https://i.sstatic.net/SZl3W.png).
jozxyqk
CC BY-SA 3.0
2015-08-10T10:14:26.257Z
To a certain extent, italic text will have less noticeable colour fringes since the sloping lines don't allow the same colour to be present for more than a few consecutive pixels vertically.
trichoplax is on Codidact now
CC BY-SA 3.0
2015-08-10T10:30:46.243Z
Hopefully someone with knowledge of this can confirm, but my guess is that the first image has been antialiased at the pixel level first, and then that antialiased image has been antialiased again at the subpixel level. You can see areas where the original antialiasing aligns with whole pixels and has no colour fringes, despite clearly having variations in brightness due to the initial antialiasing, and areas where it does not align resulting in flat colour fringes, rather than the graduated colour fringes in the last image. It appears to be a scaled rasterised font, rather than a vector font.
trichoplax is on Codidact now
<antialiasing>
Sub-pixel antialiasing rules
jozxyqk
# Sub-pixel antialiasing rules

(Asked by: username_0 on 2015-08-10)

I recently had an [issue with sub-pixel anti-aliasing of text](https://superuser.com/q/930036/264276), which produces very harsh colours and made me wonder how it is meant to be done properly:

> [![enter image description here](https://i.sstatic.net/SQWSI.png)](https://i.sstatic.net/SQWSI.png)

I've drawn some cases of a black tile covering thirds of pixels below.

[![enter image description here](https://i.sstatic.net/CE16y.png)](https://i.sstatic.net/CE16y.png)

The colours match the ones I'm seeing, however when I look at properly antialiased text, the result is not nearly as bright and distracting:

> ![from www.lagom.nl](https://i.sstatic.net/4Vrfz.png)

I assume there has to be a balance between a good light intensity and the right colour. What methods are used for sub-pixel anti-aliasing that give such good results?

---

*Update:*

I've rendered a white teapot to an image with 3x width and with multisampling. Below I compare averaging every 3 pixels with assigning each to RGB. The colours still seem overly bright in some cases (especially compared to the example above from [here](http://www.lagom.nl/lcd-test/subpixel.php)), not that my phone captures them well.

[![enter image description here](https://i.sstatic.net/19ABb.png)](https://i.sstatic.net/19ABb.png)[![enter image description here](https://i.sstatic.net/RE5Jv.png)](https://i.sstatic.net/RE5Jv.png)

[![enter image description here](https://i.sstatic.net/BZxjL.png)](https://i.sstatic.net/BZxjL.png)[![enter image description here](https://i.sstatic.net/WT6ci.png)](https://i.sstatic.net/WT6ci.png)

[![enter image description here](https://i.sstatic.net/qveN5m.png)](https://i.sstatic.net/qveN5m.png)[![enter image description here](https://i.sstatic.net/wPGG7m.png)](https://i.sstatic.net/wPGG7m.png)
OK, so my monitor needs a little dusting

**Tags:** antialiasing

> **Comments:**
> **username_3**: I believe that some screens have a different layout of the primary colours. Have you viewed your results on different types of screen?  
> **username_0**: @username_3 no, but I'm confident both my monitors are RGB. Also here I'm more interested in how subpixel antialiasing techniques are meant to work than a fix for my issue.  
> **username_3**: I didn't mean different primary colours, I just meant that the red, green and blue are arranged in different geometric patterns, so your algorithm would need to know which pattern is being used in order to give good results.  
> **username_3**: [This image](https://en.wikipedia.org/wiki/Subpixel_rendering#/media/File:Pixel_geometry_01_Pengo.jpg) shows how varied the arrangement of subpixels can be.  
> **username_3**: Incidentally, I like the question and I'm interested to see the answers, but I can't upvote until midnight...  
> **username_0**: @username_3 yes, sorry I should have clarified, both monitors have pixels split into thirds in R-G-B order from left to right as in [this photo](https://i.sstatic.net/SZl3W.png).  
> **username_3**: To a certain extent, italic text will have less noticeable colour fringes since the sloping lines don't allow the same colour to be present for more than a few consecutive pixels vertically.  
> **username_3**: Hopefully someone with knowledge of this can confirm, but my guess is that the first image has been antialiased at the pixel level first, and then that antialiased image has been antialiased again at the subpixel level. You can see areas where the original antialiasing aligns with whole pixels and has no colour fringes, despite clearly having variations in brightness due to the initial antialiasing, and areas where it does not align resulting in flat colour fringes, rather than the graduated colour fringes in the last image. It appears to be a scaled rasterised font, rather than a vector font.  
> **username_2**: I personally would guess that the garish result is taking the subpixel samples further apart than the nice result, which means that there's a more dramatic difference in coverage and therefore brightness.  
> **username_1**: As I currently understand it, there are two steps. You did the first step by stretching horizontally the path, before rasterizing it and horizontally shrink it into RGB pixel. The second step that you are missing is to apply a horizontal block filter. That is y[i] = 0.3*x[i-1] + 0x4*x[i] + 0.3*x[i+1]. You may change the coefficients 0.3 and 0.4. What is required is that the sum is 1. You could use 0.25 and 0.5 witch can be implemented with a simple shift. This filtering is applied on each color component RGB. You could also apply it on the stretched image.  
> **username_1**: You would apply the filtering on the freshly rasterized gray image, and then group 3 gray values into 1 RGB value.  

---

## 2 answers

### Answer by username_5 on 2019-04-21. Score: 4 | Accepted answer

I'm not sure what happens there. Looking at the rendering of "considerations" in your example, the "cons" looks like what you get when you do crude sub pixel anti-aliasing, without applying the necessary "fix up" to make it look good. But then the "der" in the same word looks like there's no sub-pixel anti-aliasing.

You can find a good article about how good looking sub-pixel anti-aliasing works here <https://www.grc.com/ct/ctwhat.htm> and for the "fix up" part here <https://www.grc.com/ct/freeandclear.htm> and here <https://www.grc.com/ct/cttech.htm>

What it comes down to is: if you just compute the R/G/B intensities by calculating the covered area for each sub-pixel, the resulting color fringes are very ugly/irritating. To fix it you have to apply a horizontal blur/low-pass filter to the sub-pixel image. The result is an image that's less sharp but also has far less saturated colors. I.e. something like your "Check you" example.


---

### Answer by username_4 on 2015-08-10. Score: 2

> What methods are used for sub-pixel anti-aliasing that give such good results?

You simply rasterize the letters as if they were 3x as wide.

The results differ in the way you rasterize the curves, most notably what kind of anti-aliasing/sampling scheme does it use and whether it makes use of [font hinting](https://en.wikipedia.org/wiki/Font_hinting). For great overview see [Texts Rasterization Exposures](http://www.antigrain.com/research/font_rasterization/) by Anti-Grain Geometry (IIRC this is what Chromium/PDFium uses) or [Subpixel rendering](https://en.wikipedia.org/wiki/Subpixel_rendering) on Wikipedia.

What the attached image goes, I don't believe it has anything to do with sub-pixel rendering. It could be anything: wrong [pixel geometry](https://en.wikipedia.org/wiki/Pixel_geometry), wrong gamma, wrong color space conversion, ...

> **Comments:**
> **username_3**: I would expect problems with pixel geometry, gamma or colour space conversion to show up as colour distortion at arbitrary points in the image, rather than the regular cycle seen in the question's image. The fact that it cycles horizontally between exaggerated colour antialiasing and pure greyscale antialiasing hints that the first application of antialiasing was performed at a different scale.  
> **username_3**: I don't have the full explanation, as the distortion does not seem to be aligned between the different rows of text, but it does seem the problem is related to sub-pixel rendering of already rasterised text rather than vector text.  
> **username_4**: @username_3 What I try to say is that I doubt there an issue with Anti-Grain's sub-pixel rendering. Instead I would guess the input gets mangled earlier than it enters the rasterizer. Or later, but not in the rasterizer itself.  
> **username_3**: Yes I think the sub-pixel rendering is being applied correctly, but when applied to pre-rasterised text it is not possible to give a good result. I don't think that the renderer is broken, I just think it is being fed the wrong kind of text.  

---

