RE: [ft] FreeType artefact
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
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
Re: [ft] FreeType artefact
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
Re: [ft] FreeType artefact
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
Re: [ft] FreeType artefact
I call 2 functions to draw text: [...] For detailed studying I need something which compiles out of the box, and which doesn't use a graphics system. Please use the `example1.c' file from the FreeType tutorial as a template. Werner ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
[ft] FreeType artefact
Hi, I use FreeType in my application (Windows XP). It seems to work well at begining, but after few minutes of using the software text become very low quality. You can see bad and good text here: http://66.232.119.162/img/fontbug.PNG Please advice what's wrong? Same code produce different text quality. Thanks Chan ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] FreeType artefact
I use FreeType in my application (Windows XP). It seems to work well at begining, but after few minutes of using the software text become very low quality. You can see bad and good text here: http://66.232.119.162/img/fontbug.PNG Please advice what's wrong? Same code produce different text quality. Code snippet, please, which explicitly demonstrates the problem. It's very unlikely that this is a bug in FreeType... Werner ___ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype
Re: [ft] FreeType artefact
It looks to me like the text was rendered at the smaller size and then later zoomed up using a nearest-neighbor algorithm. I would look at the rescaling of the bitmap. Buu Hao Tran wrote: Hi, I use FreeType in my application (Windows XP). It seems to work well at begining, but after few minutes of using the software text become very low quality. You can see bad and good text here: http://66.232.119.162/img/fontbug.PNG Please advice what's wrong? Same code produce different text quality. Thanks Chan ___ 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
