Re: [ft-devel] gamma correction and FreeType

[another gol]

True that converting to/from linear is usually done using lookup tables.

Even though I try to avoid lookup tables these days, the problem is that most API/tools out there work on 8bit RGB(A). Usually you convert 8bit to 16bit, work on that, then 16bit back to 8bit. But for this to be lossless, the conversion to linear has to involve a little linear ramp for the first few levels, otherwise 2 8bit values will be converted to the same 16bit value.

It's sad because these days, on x86's, working on 16 or even 32bit (even float) RGBA buffers is very efficient (especially since dithering is only needed once at the end), & a good GUI would work entirely on 16 or 32bit buffers & only convert at the very end. But it would then have troubles interfacing with most APIs, so 8bit is still the norm.

On Fri, Nov 1, 2013 at 10:53 PM, Dave Arnold <address@hidden> wrote:

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

_______________________________________________
Freetype-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/freetype-devel