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