|
From: | another gol |
Subject: | Re: [ft-devel] gamma correction and FreeType |
Date: | Sat, 2 Nov 2013 04:07:18 +0100 |
Hi Werner,
Yes, Beat Stamm has supplied a great deal of interesting detail.
I don't think it is practical to change the system color space; too many things depend on the assumption of sRGB. You might consider changing the color space of a single application (e.g., to a linear space) but you'd have to convert back to a system color space before placing images in the frame buffer. The graphics chip settings Beat Stamm is talking about affect the global system display. I think it is best used for monitor calibration to a standard color space.
Anti-aliased text can be produced for any color space. It is simply the case that the blending of foreground and background ought to be done in a linear space. In general:
Steps 1,2 and 4 can be done with lookup tables, to sufficient accuracy.
- get the background pixel and convert to a linear space
- get the foreground pixel (text color) and convert to a linear space
- combine the two colors in linear proportion to the text density (alpha value) for the pixel
- convert the result back to the system color space
The gamma value that Windows uses for this blending is store in the registry. GDI uses a single value, but DirectWrite uses a value per display, and has separate 32- and 64-bit registry keys.
TrueType fonts would produce very similar results when it comes to blending gamma, as would any antialiased graphics. That's an important point: any antialias blending should use linear blending. That includes line art. Text is not unique, it just tends to have more edges.
One difference with TrueType is that stem darkening of glyph outlines would interact with the hints in a totally different way than CFF.
-Dave
On 10/31/2013 10:31 PM, Werner LEMBERG wrote:
Dave, thanks a lot for your good demonstration images!I believe column 3 is what we want to achieve.Yes, indeed! By the way, here is another page which goes into great detail on gamma correction and TrueType font rendering: http://www.beatstamm.com/typography/RTRCh5.htm#Sec3 It might be interesting to see your tests applied to common TrueType fonts also. Beat Stamm writes about GDI ClearType: In Windows, text rendered in full-pixel anti-aliasing is displayed with a gamma correction done in software and using a gamma value of about 2.3 – to determine this γ value, I displayed a gray ramp in Word, inspected the RGB value of middle gray as rendered (189), solved L = V(1/γ) (the formula for γ correction, as opposed to γ response) for γ, and substituted the normalized inspected gray value (189/255) for L while setting V to 0.5 (half the normalized voltage should yield middle gray). Thus γ = log(V)/log(L) = log(0.5)/log(189/255) ≅ 2.314. This gamma correction appears to be in addition to what my premium graphics chip wants to do. If I “under-correct” gamma on my graphics chip, all my photos look too dark in their midtones, but text rendered in full-pixel anti-aliasing looks more natural. If I “correct” gamma for my photos, text rendered in full-pixel anti-aliasing looks “washed out.” Windows (GDI) does not have any provisions to adjust or defeat the software gamma correction of full-pixel anti-aliasing (“standard font smoothing”). So it seems that similar problems are affecting even major platforms... Werner
_______________________________________________
Freetype-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype-devel
[Prev in Thread] | Current Thread | [Next in Thread] |