"gamma correction" name as opposed to linear-to-sRGB

The conversion from sRGB to linear is approximated here with:

// sRGB to linear approximation
// see http://chilliant.blogspot.com/2012/08/srgb-approximations-for-hlsl.html
vec4 SRGBtoLINEAR(vec4 srgbIn)
{
    return vec4(pow(srgbIn.xyz, vec3(u_Gamma)), srgbIn.w);
}

The normal approximation uses 2.2 as the gamma, but this viewer allows the user to change this value as u_Gamma, without making it clear that it’s meant to be a transfer function approximation value as opposed to artistic discretion.

Later, the color needs to be transformed back the other way, from linear back to sRGB. The function to do this is called gamma correction, with some comments reinforcing the idea that this is meant to be artistic discretion, when really it is being used as an approximation of a transfer function.

// Gamma Correction in Computer Graphics
// see https://www.teamten.com/lawrence/graphics/gamma/
vec3 gammaCorrection(vec3 color)
{
    return pow(color, vec3(1.0 / u_Gamma));
}

I propose that gammaCorrection should be renamed to LINEARtoSRGB or similar, with comments updated accordingly. Further I propose that the user should not have control over the existing u_Gamma value, at least in these transfer function approximations. (There could be a different debate over whether an artistic gamma correction is desired, separately from these transfer functions).

/cc KhronosGroup/glTF#1609

[lexaknyazev]

Performing sRGB-to-linear conversion in a fragment shader is technically wrong because it would happen after filtering. The proper way is to use hardware conversion that is available with EXT_sRGB or WebGL 2.0. Also, it cannot be configurable (at least in this direction).

[bghgary]

Babylon.js has the same issue as @lexaknyazev pointed out here. I’m all for fixing it here and in Babylon.js, but it’s likely not going to make a big impact on the visuals.