Notes on Gamma

Summary

Gamma is a blight, a curse, and utterly annoying. Ever since somebody told me that RGB colours need to be Gamma corrected, RGB colours were spoilt for me. Gamma does to digital colour what kerning does to typography. This post is an attempt to get even with Gamma. Lost Innocence Because, you see, only once I became fully aware of Gamma, things really started to fall apart. In my pre-gamma-aware innocence, I must have done some things right. Let me show what I mean: Here, I generate a linear gradient using a GLSL fragment shader. Say, drawing a full-screen quad using this shader code snippet: 1 2 vec3 color = vec3(uv.x); // increase brightness linearly with x-axis outFragColor = vec4(color, 1); // output to RGB swapchain image glsl And voila - a perceptually linear gradient. A perceptually linear gradient, innocently created But now, let’s get clever about this: We notice that we’re actually drawing to an sRGB monitor (most desktop monitors are, nowadays), so we should probably use an sRGB image for the swapchain (these are the most common 8bpc (read: “bits per channel”) swapchain image formats in Vulkan). Thus we somehow need to convert our RGB colours to sRGB. The most elegant way to do this is to use an image attachment with an sRGB format, which (at least in Vulkan) does the conversion automatically and precisely on texel save. If we draw the same shader as before, but now into an sRGB swapchain the swapchain image’s non-linear rRGB encoding should correct the sRGB monitor gamma. The gradient’s brightness values (as measured by a brigthness meter) should now increase linearly on-screen. They do. That should look like a linear gradient, right? Wrong. Instead, we get this: A perfectly ’linear’ gradient This doesn’t look linear: shades don’t seem to claim equal space. Instead, it looks as if dark shades are too bright, while bright shades wash out. Here’s what I’d expected to see: A perceptually linear gradient The difference is subtle, but look at both gradients an...