[cairo] Re: Linear colorspace not a good idea

[Bill Spitzak]

Russell Shaw wrote:

> ...Isn't all colour graphics currently stored as linear light-intensity 
> luminence?

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?

Yes.

>> 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 
is better.

> 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.