Re: [ft] FreeType artefact
2007-10-05 07:08:54 GMT
there is no "best" value to distribute, because ideally, the "opacity levels" given in a
FreeType pixmap must be interpreted as linear color space coefficients. which means
that the distribution depends on the background and text colors you're going to use.
To be more precise to do "gamma-correct" alpha-blending with these, one would
ideally do the following:
1/ ensure that your "text" color is not gamma-corrected, call it T1 !
2/ then for each pixel do:
a/ read the background pixel value P0, assume it is in gamma-corrected space
b/ un-correct it, i.e. P1 = invgamma(P0)
c/ do a linear blending with the alpha value from the glyph pixmap, i.e. P1' = P1*(1-alpha) + alpha*T1
d/ re-correct the result: P0' = gamma(P0)
e/ write the result to the bitmap
of course, this is incredibly expensive, so there are ways to make these thing faster, but less accurate:
A/ adjust the glyph pixmap to approximate the result with linear blending in the 0 space, i.e. do
alpha' = gamma(alpha)
P0' = P0*(1-alpha') + alpha'*T0
this tends to only work well in one "direction" (i.e. white text on black, or black text on white), but not both,
and finding the right alpha adjustement can be tricky (left as an exercise to the reader)
B/ use the same technique than A, but use 3 distrinct gamma adjustements. select between them when you
know your text color. i.e. the gamma adjustment for bright white text will be different than the one for dark
black, which would be different for "gray" one.
probably eats more glyph cache, but still speedy
C/ use some sort of caching scheme to do the exact computations. this is exactly what the "ft2demos" programs
do, because the graphics library is uses uses some special cache code to do everything very fast. since in 99%
of cases, you're writing text on a solid backgroud, the values of P0, P1 and T1 do not change, so it's trivial to
implement a small 16-level caches of the results for P0', depending on alpha.
in my tests, this even beats "normal" multiplication-based linear alpha-blending on a typical PC doing everything
in software, unless you're writing on a *very* random background image.
another advantage is that all glyph images in the cache are in "uncorrected alphas", which is why you can change
the alpha in the demo programs on the fly, without re-rendering any glyph.
I recommend experimenting with these three schemes, in that order (A, B then C). Once you reach something that's good enough for you, stop there and enjoy
hope this helps,
That brings up a good question.
It's been a while since I poked around in our code that uses FreeType,
but as I recall, we render to grayscale bitmaps and use the gray levels
as an alpha value to combine the requested color with the existing
image. I've never been 100% happy with the way it looks though. Is
there a recommendation on how to distribute the alpha values? We get
back gray values of 0 for 100% transparent to 5 for totally opaque (at
least in FT 1.3 -- I'm stuck there due to lack of priority to upgrade).
Linear didn't seem to work very well. I don't know what values I'm
using now, but it seems to make narrow strokes disappear at small sizes.
Werner LEMBERG wrote:
>> I uploaded new image, so maybe it's easier to diagnose:
>> http://184.108.40.206/img/fontbug.PNG Artefact appear only if draw
>> text over background. If white background then no problems.
> Aah, we are getting nearer. It seems that the algorithm you use to
> draw on a coloured background needs some improvements. Try to play
> with different gamma values for the anti-aliased glyphs.
> I can't help further since this topic is beyond my knowledge.
> Freetype mailing list
> Freetype <at> nongnu.org
Freetype mailing list
Freetype <at> nongnu.org
_______________________________________________ Freetype mailing list Freetype <at> nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype