sRGB textures

[Roquen]

All of this stems from the real world problem of creating an additive color display device.  It's been know (since at least the 1930s) that RGB was a terrible way to describe color.  The only reason we use RGB is because it's possible to build such a device.  A good art package allows the artist to create images with a specific target color response...but all of that information is lost if not stored in a supporting format.

[theagentd]

>_<

I understand WHY we have/need gamma correction, I'm just questioning HOW it should be done...

[princec]

Well, I think the linked articles from Spas pretty much explained exactly what to do and when to do it.

Cas

Games published by our own members! Check 'em out!

[Spasi]

I think theagentd is asking why we need to convert from gamma to linear in the shader (or sRGB sampler), instead of doing it as a preprocess or when loading the texture data. The answer lies in what I said about sRGB being a form of compression. If you perform the linear conversion ahead of time and store the result in a 8-bit-per-channel texture, you lose information. This code sample should provide enough evidence that it's true:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19

byte[] colors = new byte[256]; for ( int i = 0; i < colors.length; i++ )    colors[i] = (byte)i; for ( int i = 0; i < colors.length; i++ ) {    // 8-bit-per-channel RGB source in gamma-space   byte gammaSrc = colors[i];    // The result of texture(tex, coord) in the shader.   float gammaSample = (gammaSrc & 0xFF) / 255.0f;    // The RGB value in linear-space, converted in the shader or through sRGB sampling.   float gammaValue = (float)Math.pow(gammaSample, 2.2);    // 8-bit-per-channel RGB source in linear-space   byte linearSrc = (byte)(gammaValue * 255.0);    // The result of texture(tex, coord) in the shader.   float linearValue = (linearSrc & 0xFF) / 255.0f;    System.out.println(gammaValue + " - " + linearValue); }

If you run it and inspect the output, you'll see that every value is different except the two extremes, 0.0 and 1.0. More importantly, sampling the linear-space texture results in the first 20 or so values being clipped at 0.0.

And why the f*ck does monitors expect inverse gamma data? That makes just as much sense as saying that you have to add Pi to each color channel or multiply each channel by 10 or something just because "the monitor expects it". Maybe I'm just being stupid... ._.

They expect inverse gamma data because every piece of visual information ever made, whether it's photographs, textures, videos or even subpixel font antialiasing, has been designed with gamma output in mind. With good reason too. It couldn't have been Pi, or 10x, or anything else, because the gamma curve emulates the light and color response in human eyes. It makes perfect sense and helps computer systems get the most quality out of only 8 bits of information per color channel.

[theagentd]

Thanks Spasi. I think that cleared it up a bit, but I'm still skeptical. I'll just have to do as my artist says then. xd

[Spasi]

I was doing some tests and something important came up. When going from 8bit gamma to fp linear and back, the correct behavior is to round instead of truncating:

1   2   3   4   5   6

byte src = ... double d = Math.pow((src & 0xFF) / 255.0, 2.2); // This is wrong byte trg = (byte)(Math.pow(d, 1.0 / 2.2) * 255.0); // This is correct byte trg = (byte)Math.round(Math.pow(d, 1.0 / 2.2) * 255.0);

So if you use Riven's code above, the last line should be:

1	return (int)Math.round(Math.pow((x+y+z+w) * 0.25f, 1.0 / gamma) * 255.0);

Without rounding, a gamma-to-linear-to-gamma conversion of a 0-255 gradient will differ in 65 places and 24 gradient steps will be lost.