[cairo] Re: Linear colorspace not a good idea
spitzak at d2.com
Tue Mar 14 12:15:17 PST 2006
Russell Shaw wrote:
> ...Isn't all colour graphics currently stored as linear light-intensity
No. Almost everything that is stored as integers is in sRGB intensity.
And it appears the majority of data stored in floating point is in sRGB,
due to people who don't understand this when writing the files, far too
many renderers convert texture maps or other images by dividing the
integer data by a constant, resulting in images that are effectively
sRGB, no matter how accurate and linear their lighting calculations are.
> To get linear intensity out the CRT vs intensity into the camera, the tube
> gamma must be the inverse of the camera gamma, so y2 = 1/y1.
I believe when television was developed, they added circuitry to the
cameras so that it's gamma was the inverse of the tube. They decided
that the receiver should be as cheap as possible and all compensation
should be in the camera. As far as I know, the electron gun is the main
non-linear part. The phosphere is linear, the amplifiers are linear, and
the D->A converters used to output from the computer to analog are linear.
> I'm not sure of "device space". Is this the nonlinear luminance data of an
> uncompensated camera?
>> First is that there is a huge supply of icons that have been designed
>> to be composited in sRGB space and will have bad edges otherwise when
>> put atop the background they are designed for.
> I'd correct any icons to assume a linear camera and CRT (y1=y2=1.0).
The problem is with partially-transparent parts. I have discoverd in my
attempts to make a linear-math compositing program that dealing with
images designed for GUI is almost impossible and I had to add switches
to composite in sRGB space.
The problem is that the stored image will try to achieve the color C
when composited atop the color B, by storing, in the same image, *many*
variations of color A and alpha a such that C=A+B(1-a) in sRGB. This is
especially true of hand-painted overlays from Photoshop, but it is also
true of many painted and CG icons edges, icons designed to be
transparent, and the output of matte-pulling functions. It does not
appear to be possible to correctly composite these images except by
converting back to sRGB and doing the sum in sRGB space.
> There's too many "programmers" clueless about gamma and there's no sense
> in propagating their mistakes.
I agree but I'm afraid it may be impossible in this case. All that will
happen is people will say "I can't use Cairo because all the edges of my
icons designed for XP look really bad."
> Black and white still looks black and white regardless of the intensity
> data being linear or nonlinear. I don't see where the difference would
> come from.
The problem is not the black and white pixels, but the 50% gray pixel
that indicates it is half-covered by the graphic. In linear space this
is correctly emitting half the light as the white pixel. Unfortunatly a
person looking at that pixel would think it is about 3/4 as bright as
the white one and thus 3/4 filled with white. Thus an antialised black
graphic looks thinner than an antialiased white graphic. The effect is
highest when the graphic is 1 or 2 pixels thick, and quickly goes to
zero when the graphic approaches 10 pixels thick.
In sRGB the 50% gray pixel, though much darker than 50% as bright as the
white one, *looks* half-filled. Now thin graphics seem to match. But as
the graphic gets thicker, the incorrect brightness becomes more
important, so by the time it is 10 pixels thick, the linear antialiasing
> Precisely define "device space". Is it linear intensity of effective
> camera gamma=1.0, or is it the nonlinear data from an uncompensated camera?
It's the non-linear data.
More information about the cairo