freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] gamma correction and FreeType


From: Dave Arnold
Subject: Re: [ft-devel] gamma correction and FreeType
Date: Fri, 01 Nov 2013 14:53:49 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

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:
  1. get the background pixel and convert to a linear space
  2. get the foreground pixel (text color) and convert to a linear space
  3. combine the two colors in linear proportion to the text density (alpha value) for the pixel
  4. convert the result back to the system color space
Steps 1,2 and 4 can be done with lookup tables, to sufficient accuracy.

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]