The standard visualization for the Mandelbrot set (which is used here) colors pi...

anon4 · on July 11, 2015

A quick, very pedantic note - the images don't show colouring based on linear distance. The problem is that your monitor works in non-linear colourspace - sRGB, while the image is generated in linear RGB but not converted to sRGB afterwards. If you want to show proper colours, you need to convert the final value from RGB to sRGB. For people writing shaders, here are two handy functions I keep around:

    vec3 srgb_from_rgb(vec3 rgb) {
        vec3 a = vec3(0.055, 0.055, 0.055);
        vec3 ap1 = vec3(1.0, 1.0, 1.0) + a;
        vec3 g = vec3(2.4, 2.4, 2.4);
        vec3 ginv = 1.0 / g;
        vec3 select = step(vec3(0.0031308, 0.0031308, 0.0031308), rgb);
        vec3 lo = rgb * 12.92;
        vec3 hi = ap1 * pow(rgb, ginv) - a;
        return mix(lo, hi, select);
    }

    vec3 rgb_from_srgb(vec3 srgb) {
        vec3 a = vec3(0.055, 0.055, 0.055);
        vec3 ap1 = vec3(1.0, 1.0, 1.0) + a;
        vec3 g = vec3(2.4, 2.4, 2.4);
        vec3 select = step(vec3(0.04045, 0.04045, 0.04045), srgb);
        vec3 lo = srgb / 12.92;
        vec3 hi = pow((srgb + a) / ap1, g);
        return mix(lo, hi, select);
    }

They don't have any measurable performance impact, as far as I can tell.

Edit: comparison between non-colourspace-corrected and colourspace-corrected versions of the shadertoy link http://www.screenshotcomparison.com/comparison/134695

panic · on July 11, 2015

It's not pedantic -- interpolation in linear space makes a major difference! It doesn't look like this shader is meant to show distance directly, though: it's taking a fourth root and some other things:

    // do some soft coloring based on distance
    d = clamp( 8.0*d/zoo, 0.0, 1.0 );
    d = pow( d, 0.25 );
    vec3 col = vec3( d );

anon4 · on July 12, 2015

I'm calling it pedantic, because as far as I can see nobody cares outside of people doing movie VFX and the like, where it is actually really really important that you get it right. Your GUI for example doesn't care - elements are blended assuming a linear colourspace, which means that all font rendering is just slightly off. Even Apple don't care to make their blur effects correct - see https://www.youtube.com/watch?v=LKnqECcg6Gw . Even photoshop doesn't do it correctly by default. Almost everybody is perfectly happy treating the values as linear colour intensity.

The bottom line is that sRGB is hideously hard to work in. You really want to only use it for storage and only if you really must. It's an optimisation to allow you better range on the low end, at the expense of the high intensity end, to match human colour vision. However, that means using 48bit RGB and that's not a price everyone wants to pay. People who do professional graphics work simply use 32bit floats per colour channel - 128bit RGBA, or even 192bit RGBRaGaBa (separate alpha for each channel) and have workstations with 32 or 64GB of RAM. However, your normal everyday GUI application needs to run on a phone with about 1GB of RAM. Or going back farther, it has to run on an Intel 486 with 16MB of RAM. That kind of explains where the culture of "just treat it as linear, it's not that wrong" came from :) .