If you haven't already read and completely absorbed the previous page "How Sub-Pixel Font Rendering Works" you must go there first and read that page carefully. The balance of this page assumes that you have a grasp of the concepts presented there.

If you have access to any 32-bit Windows environment (Windows 95/98/NT4, including Virtual PC on a Mac) you may also wish to have a copy of Free & Clear running as you read through this page. You will then be able to follow along with the explanations and experiment as you go.

The "Simple" Theory is a Bit too Simple?

To best understand where the basic theory of sub-pixel rendering (from the previous page) collides with reality, let's back up and look at some real world results. For the purpose of our tests we'll use the the text string: "Sample Text String" rendered in Windows 14 point Times New Roman font:

I chose that font and size deliberately because it clearly demonstrates the problems. If we convert this string into "simple" sub-pixels, the result looks like this:

As you can readily see — on any computer display device — this result has a pronounced "color fringing" problem. In order to cure this by enhancing the basic theory let's understand where the problem comes from.

As we know, the idea behind sub-pixel rendering is to use an LCD display's directly addressable sub-pixels to triple the effective horizontal resolution of the display. So, the first thing we need is a triple-width text image containing three times the rendering information. One way to do this is to render the font at triple the horizontal width into a standard black and white region, like so:

Let's take a close look at just the letter "m" in the word Sample:

When rendered at triple-horizontal resolution, the three main vertical legs of the "m" are five pixels wide. This of course becomes five sub-pixels wide once we translate these pixels back down into display sub-pixels (and it returns the triple-width text back to its normal width). The m's legs being five pixels wide when rendered at triple-width (above) shows us that the TrueType outline rendering engine would have liked to have those legs be one and two thirds of a pixel wide (5 sub-pixels) when rendered at normal resolution, but TrueType was forced to round them up to two standard pixels. And that's why the resulting "m" legs normally appear too dark. Insufficient display resolution ... which is what sub-pixel rendering promises to cure.

Okay so far ... but look what happens when we translate the triple-width pixels down into the R-G-B sub-pixels of an LCD's display panel:

Because of the non-multiple-of-three width of the m's three legs, the legs wind up being bordered on both sides by red sub-pixels! (As you can clearly see in the colored diagram above.) This explains that red glow we saw on the normal-size simple sub-pixel rendered text sample above!

Another way to look at this is that the "blackness" of the m's legs switches "off" the sub-pixel series: G-B-R-G-B. Notice that this means that TWO Greens are off and TWO blues are off, but only ONE red sub-pixel is turned off! This creates what I've termed a Local Color Imbalance. And it turns out that our eyes are very sensitive to these local color imbalances. So, since the "m" has much more "red" around it, our eyes average out the sub-pixel colors ... and we see red!

Standard whole-pixel rendering doesn't have any problem like this, since exact triples of R-G-B pixels are always treated as a whole indivisible unit. But as soon as we start treating the sub-pixels individually — which is, of course, the whole point of sub-pixel rendering — we run into the problem of Local Color Imbalance.

Yikes!  So How Do We Fix It?

It turns out that the cure is really quite simple and straightforward and only requires a small extension to our strategy. We simply spread each sub-pixel's "energy" across it and its two neighboring sub-pixels:

In other words, when a sub-pixel is "ON" we turn it on 1/3rd and we also turn its two immediately adjacent neighbors each on 1/3rd. So, instead of putting all of a single sub-pixels's visual "energy" entirely within it, we share its energy with its neighbors.

Why does this work? Since each sub-pixel's neighbor to the left and to the right will always be, by definition, its two complementary colors, this "energy sharing" has the effect of instantly "rebalancing" any local discoloration! If you think about it for a second you'll see that we're always turning a set of R-G-B (or G-B-R or B-R-G) sub-pixels on by the same amount ... thus it's impossible to have any local color imbalances!

Here's a larger sample showing a line of original "unfiltered" sub-pixels and the effect of mixing them down into filtered sub-pixels:

To state this in words: The intensity of a "filtered" sub-pixel is one third the sum of the intensities of it and its two immediate neighbors. Thus, if a sub-pixel and it's neighbors are all "on" then it will be fully on. But if it and one or two of its neighbors are off, then its resulting intensity will be 2/3rds, 1/3rd, or fully off respectively.

What's interesting about this solution is that the triple-width "positional resolution" information is still represented in the result, while keeping the local coloration perfectly balanced.

One negative side effect of this "energy sharing" is a bit of blurring of the result. But there's another trick we can perform to reduce this problem too. The blurring is caused by the neighboring sub-pixels having a little too much energy compared with the primary center sub-pixel. So what we need to is to bring the energy in the side sub-pixels down while still maintaining the local color balance.

We can do this by simply repeating the "filtering" process again ... by having each of the three first-stage recipient sub-pixels share the energy with their three neighbors! You can visualize this in a three-tier scheme like this:

If you study the diagram above and you'll see that since we're again splitting a sub-pixel's energy into three adjacent different-colored sub-pixels, the operation must retain perfect color balance. But at the same time it reduces the strength of the two immediate neighbors by giving some of their energy to the next closest pair of neighbors!

Since we're performing two sets of division by three, the resulting intensity spread has the following energy distribution:

Image processing gurus would refer to this as a five-element low-pass windowing filter with coefficients of [1/9, 2/9, 3/9, 2/9, 1/9]. You'll note that the five coefficients sum to 1.0, so that the total energy of the original center sub-pixel is fully represented by the spread-of-five.

By spreading the original sub-pixel's energy out across the closest five sub-pixels we've maintained perfect local color balance and kept the majority of the energy in the center of the spread! It's a very cool solution.

What does the result look like?

Here's the word "Sample", rendered using unfiltered sub-pixel graphics. It's shown in real size and then enlarged:

As we see, the m's vertical bars are glowing red in the real-size version — which is no surprise as we can see from the enlargement. But filtering to restore local color balance cures this completely! Here's the same sub-pixel rendered graphics after passing through the five-element low-pass filter we've just designed:

And finally, here's the original sample text string, unfiltered and filtered:

When the filtered result is viewed on an LCD (as opposed to a CRT of any sort) the result makes all this worth the trouble!

An Intuitive Approach . . .

Many (way too many) people have scolded me for saying that my sub-pixel rendered text samples DO look terrific on their Trinitron or standard CRT displays. They're upset with me because of my continued insistence that sub-pixel rendering must be viewed on an LCD panel in order for it to be effective. Well, thank goodness this "intuitive" approach explains why sub-pixel rendering does achieve substantial but not complete success on non LCD displays!

Here's a standard TrueType rendered, 12 point, Times New Roman, capital "S". This is the best we can achieve when rendering whole pixels that must be either fully "on" or fully "off" (i.e. without anti-aliasing of any sort.)

Here's the same capital "S" shown on the same grid. But this one has been rendered with three times the horizontal resolution in preparation for conversion into sub-pixel rendering technology. Please take a long moment to compare this to the first image. Notice how the pixel's positions and widths are more finely tuned in this image. Look at the first pixels (from the left) on the 2nd and 3rd lines in both diagrams. Notice how those two pixels are shifted 1/3rd of a pixel to the right when the TrueType renderer is given the opportunity with greater horizontal resolution. And push yourself back from the screen and look at the letter as a whole, noticing how much more expression of the "S" is captured in the second image.

This image takes the one above it and replaces the partially filled pixels with the proper amount of gray. Notice how when a pixel is only 1/3rd filled above we've assigned a light gray to it here, and when when a pixel is 2/3rds filled we've assigned dark grey. That's the essence of anti-aliasing. Now look again at those first pixels on the 2nd and 3rd lines in this diagram. You can see how anti-aliasing tries to show that 1/3rd shift to the right (in the image above) by spreading the pixel's "energy" out across two pixels. Our eyes will tend to "average" them together.

This image shows the full-technology, multi-level filtered, sub-pixel rendered "S" in all its glory. Perhaps the coolest way to think of this is as "colorized anti-aliasing." The thing that's so significant about colorized anti-aliasing is that because of the R-G-B sequencing of the sub-pixel elements of an LCD, the coloration actually equates to the horizontal position of the visual energy! For example, now look at those first two pixels on the 2nd and 3rd lines. They're RED and BLUE respectively. Well, since the pixel's elements are R-G-B, in the left pixel you get red by turning off the GREEN and BLUE sub-pixels. Thus the "darkness" within that pixel is biased over to the right of the pixel. In the blue pixel, you get blue by turning off the RED and GREEN sub-pixels, thus it has its "darkness" is moved to the left! This is exactly what the TrueType rendering engine was trying to achieve with its finer pixel placement.

This is the point I wanted to make about the whole sub-pixel rendering business: That it can be intuitively viewed as colorized anti-aliasing where due to the R-G-B organization of the LCD, the color of the cell results in a left-right shift which helps to further visually smooth out the resulting image.

Okay, so why does this even look better on a standard CRT??...

This diagram shows why sub-pixel rendering also works (but to a much lesser extent) on any computer display. Here the image immediately above (the full whammy sub-pixel rendered image) has just had it's coloration removed. Only the pixel's total energy is shown — not its color. The result is a simple gray scale image. And what have we got? Good old standard anti-aliasing! Notice the similarity to the third, standard anti-aliased "S" above.

So my point is ... even though CRT's (even Trinitron's) will not resolve the sub-pixel positional information contained within sub-pixel colorized anti-aliasing, they will still show the overall standard anti-aliased image ... which is way better than no anti-aliasing at all! (But it's WAY better on an LCD because of the LCD's unique ability to convert color into position!)

That's all there is to it!

My hope is that anyone who has any interest can and will implement this sub-pixel rendering technology on their display systems of choice. As you can see, it's really no big deal, and the results speak for themselves!

Thanks for your interest!