Hi, Problem resolved. In our code there is one piece where we read not-allowed to read memory block. This caused FT artefact! So after fixing this bug all artefact gone. Thank you, guys Chan
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Turner Sent: Friday, October 05, 2007 2:09 PM To: Dave Williss Cc: freetype@nongnu.org Subject: Re: [ft] FreeType artefact 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, - David 2007/9/28, Dave Williss <[EMAIL PROTECTED]>: 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://66.232.119.162/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. > > > Werner > > > _______________________________________________ > Freetype mailing list > Freetype@nongnu.org > http://lists.nongnu.org/mailman/listinfo/freetype > > > _______________________________________________ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
_______________________________________________ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
