[Pixman] sRGB processing for pixman

Bill Spitzak spitzak at gmail.com
Mon Jun 11 14:15:17 PDT 2012



Søren Sandmann wrote:

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

Good to know.

I absolutely agree the proposed format is the one that makes it easiest 
to compose srgb images.

I am worried that there will be a lot of images where the color channels 
are a*r^(1/2.2) rather than (a*r)^(1/2.2). This is because this is what 
algorithims filling with solid color often do, for instance pango's 
output. I think though the artifact will be dark edges on objects, which 
is less objectionable than the bright edges if you mistakenly assume 
what I was proposing.

In addition the proposed format is certainly what renderers working in 
linear produce, unless they accidentally gamma correct the alpha.

So I see nothing wrong with going with this format.


More information about the Pixman mailing list