A problem with sRGB for line art is that drawing an inverted drawing
will not look correct to users. White lines and text will look much too
thin, while black lines and text look thicker. This appears to be
because humans invert images in perceptual space. It is possible this
could be compensated for by adjusting font weights and line widths
depending on the current fg/bg colors so they always look perceptually
the same thickness.
Other than that sRGB is usually a win, as your demo shows composites
look better and directly-calculated antialiasing works right.
I have never seen images stored as described in the paper. In all cases
the red is multiplied by whatever number is in the file for the alpha.
So if "red" and "alpha" are the true linear values, the file either has
this:
red^(1/2.2)*alpha, alpha (probably more common)
or:
(red * alpha)^(1/2.2), alpha^(1/2.2)
The paper appears to describe:
(red * alpha)^(1/2.2), alpha
Estimating the gamma as 2 is easily close enough considering all the
other unknowns and the fact that data has been rounded to 8 bits, and it
does make the resulting compositing functions much simpler so they can
be done without lookup tables.
OpenGL also supports sRGB compositing, and exactly how it does it should
be investigated and copied if it makes any sense, since only that way
could Cairo use it for acceleration on a gl backend.
On 06/09/2012 04:16 AM, Antti S. Lankila wrote:
Hello everyone,
I have worked out a tentative patch to pixman which adds capability for
processing images in sRGB color space. This is still somewhat a
work-in-progress, but the basic functionality should be there.
_______________________________________________
Pixman mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pixman
