[Devel] Gamma correction for anti-aliasing

[Vincent Caron]

Hello,

  I'm currently investigating on font AA and trying to reverse engineer
the nice work from MS and Apple on the subject. FreeType gives you the
exact pixel coverage value, but there's still a non-trivial work to do
before choosing the actual pixel color and intensity. It involves the
screen characteristics (CRT and LCD are very different wrt AA),
environment (lighting) and the user (both global eye perception model
and per-individual characteristics).

I didn't mention sampling theory, it's there, but its application tells
you that you should display your font color with an intensity
proportionnal to the pixel coverage value. As far as I could check,
Shannon fans will correct me if I'm wrong. We just have to use the
'right intensity space' : screen-related, eye-related, linear,
non-linear or whatsoever. It's definitively not the linear framebuffer
space (even on gamma-aware platforms like Mac). Hence the whole point
about screen properties, environment and user.

It seems that both screen (emitters) and eye (receptors) have a
gamma-curve response. So you finally end up to model the whole path from
your video card RAMDAC output to your optical nerve input as
'gamma-correctable'. Charles Poynton tells a good part of the story :
http://www.inforamp.net/~poynton/ , his gamma FAQ is great.

Now MS has two user settings concerning font AA (only available on XP):

 - you can toggle ClearType(r)(c)(tm) on/off : of great help for LCD
screens. The LCD situation is actually remarkable : regular AA (gray
shades) looks awful (pixels are too big and too close), while ClearType
is a tremendous improvement upon CRT itself (it triples the resolution
along one direction). Several friends reported to have a much better
font experience on their laptop with WinXP than on their CRT. ClearType
seems to help on CRT too. I'll leave this subject for later :)

 - you can change the 'font gamma'. It seems to be our holy grail. Look
at http://www.microsoft.com/typography/cleartype/ctpref.htm , these are
different rendering of the same text with a different font gamma (the
value is hidden in the HTML code). I've extracted some color histograms
on these pictures, and figures show that MS uses a classical
x^(1/font_gamma) correcting curve (I mean _exactly_, I have a
spreadsheet to proove it :)). However they do not sample gray shades
linearly in [0..255], and there are still some secret recipes to find
here. Last detail, the Win2K/XP TrueType rasterizer uses 16 gray shades,
while the 95 family uses 7.

I've been collecting these info for some time as a background task, and
I'll make a document to summarize my findings. There's actually already
one, but I find it ackward, and it was written a month ago
(http://zerodeux.net/ft/aa/). My ideas tend to get cleaner now :)

--

Now for the fun part. You might have heard about the GRAYS_USE_GAMMA
hack in 'src/smooth/ftgrays.c'. The author was (instinctively?) right,
it does improve AA visual comfort. I implemented a true gamma correction
in 'ftstring' to play a little further with it (patch attached). With a
gamma between 2.0 and 2.1, I'll get an extremely close result to a Win2K
output ('xmag' was _the_ tool :)). I mean it is visually indiscernable.

If you want to do some testing, here are some useful infos :

- don't compile FreeType with GRAYS_USE_GAMMA !

- 'g' to toggle gamma correction on/off, F9/F10 to change the gamma
value

- match resolution : Windows resolution is available from the 'Display
properties', 'Advanced' button. As a default, it is 96dpi. It might be
another value if you have a theme or selection with 'small' or 'big'
fonts. Use the '-r' option of ftstring.

- use gasp info : Windows does not hint or do AA on all font sizes, it
relies on hints embedded in TrueType files (gasp tables). Some samples :

 arial.ttf
  0 - 6   smoothed
  7 - 13  hinted
  14+     hinted + smoothed

 tahoma.ttf
  0 - 6   smoothed
  7 - 12  hinted
  13+     hinted + smoothed

- use wordpad to display 'The lazy fox ...'. Windows font sizes are
exposed as points, this is really the 'ppem' parameter of ftstring.

I did my testing with Arial (14pt) and Tahoma (13pt). Besides the very
good matching after gamma correction, I'm impressed by the pixel
matching : hinting, kerning and such are just right (I'm using the
bytecode interpreter) ! Congrats to the authors ...

BTW, I only have a remote access to a MacOSX box, coold a Mac user
report his/her experience ?

--

Now, you'll say that it's maybe too long a mail for a stupid gamma
table. Maybe true actually, that's my didactic inclination :). My point
is to know how to improve font rendering. Understanding the details
about the gamma trick is only part of the process, now I'll try to
understand the other things MS or Apple got right. I would be very
grateful for any info on the topic, remarks on this e-mail, etc.

The practical conclusion(s) :

- What about an interface to set this gamma value in FreeType ? I'm
actually not sure if it's FreeType job's : it advertises that it
provides exact pixel coverage value, and that's it. But I guess it
should capitalize some subtile knowledge like this gamma trick. Anyway,
I don't know where to plug that setting. Waiting for David's thoughts.

  NB: for the FPU-impaired, I guess that the pow() call can be replaced
by something elegant, given that we're linearly sampling the x^constant
function along x (there must be an incremental trick with
integer-friendly operations).

- In order to really improve TrueType font rendering in applications,
the last step is to support gasp tables. When turning on AA under KDE or
Mozilla,  AA seems a little blurry and incomfortable. The gamma
correction is the first half of the answer, gasp is the second half. KDE
as a UI tends to use fonts in the 10-12pt range, precisely where most
gasp tables will tell you _not_ to use AA. I asked some Windows and Mac
users to look at KDE screenshots with AA, and they globally told me that
'it sucked' (apply standard inter-community moderation ratio here :)).
IMHO they're kinda right.

Now I already talked about that gasp table issue
(http://www.freetype.org/pipermail/devel/2002-April/003133.html). I'm
supposed to propose a FT_Get_Gasp_Mode(face)-like interface, and I think
I will do this in a few days, unless someone is faster than me :).

End of utterly long mail.

ftstring-gamma.patch
Description: Text Data