[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