[cairo-bugs] [Bug 28549] Gamma-corrected alpha blending for text output

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28549

--- Comment #1 from Bill Spitzak <spitzak at gmail.com> 2010-06-15 11:13:23 PDT ---
I did a lot of work with gamma correction (though I normally call it 
"linear" as the numbers are in a linear relationship with light). A few 
corrections:

First gamma correction is much MORE useful for thick filled shapes. Text 
and thin lines are actually the problem cases, not the best ones as you 
claim. I believe Cairo should do gamma correct antialising of all 
shapes, and would prefer lines be attacked before letters if necessary.

There is a HUGE problem that for thin lines and text, users expect the 
reverse to be perceptually inverted, not light-inverted. Linear 
white-on-black letters look much too thin compared to the same image 
drawn black-on-white. This is not an antialising issue, users actually 
accept negative film of such text as being the correct reverse image, 
despite being on a medium with a large gamma correction.

In addition the same font and lines drawn black-on-white looks much to 
thin when drawn gamma-corrected (drawn white-on-black looks thicker but 
appears to be less objectionable to users, as your demo shows). Windows 
solution, judging by your screen shots, appears to be to disable 
antialising of black-on-white by turning up the hinting excessively, I 
think this looks like crap and would prefer a different approach. 
Unfortunatly black-on-white text is far more common than any other so 
solutions may involve strategic thickening of letters and lines before 
rendering so the gamma-corrected output looks the same weight as the 
non-corrected output, and also so inverse images seem perceptually linear.

Another problem is ARGB image composites. It definitely looks FAR better 
when gamma corrected, adding images looks precisely like a double 
exposure, for instance, and rendered antialised edges of objects 
composite correctly. The problem is that a huge number of ARGB images 
are simply "painted to composite correctly" when done in gamma space, 
and identifying these is very difficult. One idea is to add 
linear-correct compositing as new operations, leaving OVER etc, as they 
are. This is ugly because now there is a different operation for images 
than for other Cairo drawing (assuming we want gamma correction to be 
the default). Alternative is to analyze the image and identify sharp 
edges which want gamma correction, but leave large partially-transparent 
areas alone. Another alternative is to just do it but people are going 
to bitch because their output looks different than Windows.

I am unsure if there is a good solution other than making 
gamma-correction be a new set of composite operations and not making 
them the default. Then at least programs can know when they are 
requesting this. I would not do the Windows crap output of text.

Implementation can be done by just assuming gamma is 2.0. This is plenty 
close enough, well below the threshold of other errors in the hardware 
and perceptual environment. It has the advantage that the gamma 
calculation is x^2 or sqrt(x), meaning that expressions can often be 
simplified greatly. A tiny lookup table for sqrt() for all 8-bit values 
might help.

My pages on gamma correct blending:

http://mysite.verizon.net/spitzak/conversion/index.html

Page describing when gamma correction does not work, including screen 
shot of reversed text showing the weight problems:

http://mysite.verizon.net/spitzak/conversion/notlinear.html

Bill Spitzak

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.