If you do lighting calculations in a pixel shader, you may encounter the issue of gamma encoding. Instead of providing my own breakdown of this, I’d rather just link to one or two sites that give a better and more thorough explanation than I could. This one, for example.
Mainly, though not exclusively, this concerns images that you might use as textures in 3D scenes. These image files generally use an encoding scheme that allows them to store more, or more relevant, information than they otherwise would. In certain instances, this image data has to be decoded appropriately when it’s manipulated in algorithms.
I was looking for a simple way to test my understanding of the issues involved. The screenshot is what I came up with. I’m checking that my pixel shader handles the attenuation of a light source correctly, which necessarily implies that gamma encoding or decoding is taken into account. We are told that light attenuates in proportion to the square of the distance from a light source (the intensity is inversely proportional to the square of the distance). So I placed a point light at a distance of 1.414 in front of the checkerboard pattern. If you’re a mathematically inclined person, you probably recognize that 1.414 approximates the square root of 2. What this means is that the white light reflected from a white square on the checkerboard should be only half as bright as the light right at the source. So I would expect not a full white value of RGB (255, 255, 255) but only half of that. However, for the reasons explained in the linked article at Figure 12, the color at the white square, when it leaves my pixel shader, is not RGB (128, 128, 128) but closer to RGB (187, 187, 187). This should indicate that the image data is being manipulated properly by the shader.
