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.
_______________________________________________
Pixman mailing list
Pixman@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pixman
