No subject

alpha blending can be performed as linear blend between color values in sRGB
space. This is only true if the sRGB space maps linearly to physical intensity
("screen space") of the pixel on the display surface, in other words, only when
gamma is 1.0. When it is not 1.0, it is necessary to raise the color component
to the gamma, then perform blending linearly, and then raise to 1/gamma to get
back to sRGB space.

Typical monitors use gamma values from 1.8 to 2.2, and therefore all alpha
blending operations should, in principle, compensate for gamma. However, that
may be unacceptably slow, so a compromise might be to fix only text, where this
problem matters most. In addition, the difference between 1.8 or 2.2 to 2.0 is
not very large, indicating that it may be acceptable to treat the gamma value
as fixed constant, rather than user-specified variable.

To demonstrate the screen space alpha blending, I have made another page which
works as a measuring tool for display system's gamma value:

http://bel.fi/~alankila/lcd/gamma.html

it is based on the color blending idea which is used on the LCD test page to
show how fonts can be put on screen without color fringing artifacts. For
instance, on the leftmost blocks calibrated for gamma 2.0, the middle square is
0xb4b4b4 in color. This is because the light intensity midpoint between 0x000
and 0xfff is not 0x888, but it is actually given by:

desired_intensity^(1/gamma) = 0.5^(1/2.0) = 0.707,

which mapped to 0 .. 255 range gives 0.707 * 255 = 0xb4.

This provides the clue to understanding why Linux results on the
green-on-violet text seem much too dark. The combination of 0xf0f and 0x0f0
tends to produce the value 0x888 when gamma is being ignored, but it is much
too dark. The same problem is responsible for the color fringing in the other
cases as well, of course.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.