[Pixman] sRGB processing for pixman

[Bill Spitzak]

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.