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 

And voila - a perceptually linear gradient.

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:

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:

The difference is subtle, but look at both gradients and ask yourself: which seems to have more detail? Which is more balanced?

Even though the first gradient is more linear in terms of physical brightness, the second one looks more linear.

I find this counter-intuitive. But where intuition fails, ratio may help; and there is indeed a rational explanation: Visual perception is non-linear.

In Vulkan, if you can use an sRGB format for your swapchain image, then you don’t have to manually correct for sRGB gamma. your pixels will be automatically stored in non-linear sRGB, and displayed linearly on-screen. this is great for encoding the highest amount of perceptual colour contrast detail using limited amount of bits (sRGB formats are usually about 8 bit per channel).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

vec3 srgb_eotf(in const vec3 c) {
    bvec3 cutoff = lessThan(c, vec3(0.04045));
    vec3 lower = c/vec3(12.92);
    vec3 higher = pow((c + vec3(0.055))/vec3(1.055), vec3(2.4));
    return mix(higher, lower, cutoff);
}

void main () {
    vec3 color = vec3(uv.x);
    outFragColor = vec4(srgb_eotf(color),1);
}

And voila:

Thank you sticking around past the end credits. Here’s an extra bit of information that might come in handy at a cgi pub quiz one day: