[cairo-bugs] [Bug 28549] Gamma-corrected alpha blending for text output
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Jun 15 11:13:25 PDT 2010
--- 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
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
My pages on gamma correct blending:
Page describing when gamma correction does not work, including screen
shot of reversed text showing the weight problems:
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
More information about the cairo-bugs