Re: [Devel] Freetype2 & gamma correction

[Billy Biggs]

  I've recently been experimenting with gamma correct text and problems
that occur when you're not gamma correct.  One really telling example is
text in motion.  In the following example, I show text in motion with
glyphs rendered using freetype's coverage renderer, and then positioned
subpixelly using linear interpolation:

  http://vektor.theorem.ca/graphics/gammamotion.tar.gz

  You can give the program a size parameter, a point size of 12 is the
default, but you can see how the effects are still visible at sizes of
14 or 15 ('gammamotion 14').  Hit 'p' to pause or unpause the text.

  Basically, without gamma correction the text is extremely uneven, and
waves very badly when in motion, whereas if you compensate for gamma,
the text is smooth.  I use the srgb standard intensity to voltage
calculation.

Keith Packard (address@hidden):

> Around 23 o'clock on Mar 28, Matthijs Melchior wrote:
> 
> > Despite all the positive noise I saw, I did not like the way the
> > text looked, it was rather uneven...
> 
> This situation is not caused by gamma, but a separate effect caused by
> the the gaussian nature of CRT pixels.  To adjust for this effect, you
> want to artificially increase the apparent pixel coverage for areas
> partially covered by the glyph.  This appears similar to "gamma"
> correctly, but in reality is unrelated.

  I don't really buy this.  Using integration as a filter, regardless of
whether your pixels are square or gaussian, is still a bad filter.  I
don't think it's worth approximating something that still isn't ideal.
Better to ditch using the coverage calculation for a wider filter, in my
opinion.

  For a good example of where your method and the whole analytic pixel
coverage method breaks down is my application, tvtime.  I render text on
top of live video using freetype:

  http://tvtime.sourceforge.net/screenshots/25-feb-03-simpsons.jpg

  We render to an XVideo buffer which is scaled by the hardware, and on
older machines, we can sometimes end up rendering to really weird pixel
aspect ratios, like 320x576 or 480x480, and have the video card scale it
up to a 4:3 image.  In these cases, I think we start to expose the flaws
in using pixel coverage, and even worse would be your proposed gaussian
hack.  I have yet to generate some good examples where analytic coverage
causes visibly horrible aliasing, but I bet I can find some.

> > The ideal situation would be that freetype automatically ajusts to
> > the gamma setting of the output device it is using.
> 
> This won't work because FreeType doesn't know what colors are involved
> and the values needed are different when rendering light text on a
> dark background compared to rendering dark text on a light background.
> 
> The right place to adjust the intensity mapping is down in the
> rendering code.

  I agree completely.  In my opinion, the gamma code in ftgrays.c should
be removed to avoid confusion.

-- 
Billy Biggs
address@hidden