[Pixman] sRGB processing for pixman

[Søren Sandmann]

Bill Spitzak <spitzak at gmail.com> writes:

> 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.

OpenGL has two extensions that deal with sRGB [1, 2]. One adds a new
texture format, which has 8 bits per component and where the texture
sampler is supposed to raise the R, G, and B (but not A) components to
2.2 before filtering. The other allows framebuffers to marked as "sRGB"
which means the R, G, and B components of the destination are raised to
2.2 before blending, and to (1/2.2) before writing back.

That means that in order to blend with premultiplied, linear colors:

     (a, ar, ag, ab),

and take advantage of these extensions at the same time, the texture
data must be encoded like this:

     (a, (ar)^(1/2.2), (ag)^(1/2.2), (ab)^(1/2.2))

In other words, exactly like the proposed new format.


Søren


[1] http://www.opengl.org/registry/specs/EXT/texture_sRGB.txt 
[2] http://www.opengl.org/registry/specs/ARB/framebuffer_sRGB.txt