Re: [Devel] Freetype2 & gamma correction

[Vincent Caron]

Keith Packard said:
> So, we really need two fixes -- one fix to adjust the partial coverage  
> values to
> accomodate the output device pixel characteristics, and a gamma  correction to
> adjust for output device luminosity behaviour.

Keith said it all, the GRAYS_USE_GAMMA is a bad hack that works by chance in a
peculiar environment, it should go away. The 'gamma code' in the ftstring demo
implements such a hack, but it's wired to the [monochrome] rendering code here 
(thus
it failed horribly when the colors were inverted).

I have implemented a gamma-corrected alpha blending to play with (in GTK+ widh 
GdkRGB,
I think I lost the code) : http://zerodeux.net/misc/ft/aa/

Basically, you do the linear interpolation in the 'gamma corrected space', so 
it goes
like :

  dest = GammaInverse( coverage * Gamma(src) + (1 - coverage) * Gamma(dest) )

I might be wrong, the hack only proved to be visibly cool in all situations :). 
And I
could tune it to produce roughly the same color histograms that does the MS 
TrueType
rasterizer for the same samples ( http://zerodeux.net/misc/ft/ms_aa/ ), by 
choosing
the right discretisation values.

Then, you must also question the notion of 'coverage', since it involves a kind 
of
filtering on the pixel. AFAIK, FreeType smooth rasterizer does a 'box 
filtering' (?).
I was wondering if it would be hard to plug a 'filtering function' on the 
current
rasterizer. Obviously, you can ask FreeType to oversample NxN and then do your 
own
pixel coverage computation for each NxN block. Does anybody have tried such an
experiment ?