Gamma correction brightens world-- but only *slightly*

[wolfboyft]

After a long mental slog trying to understand gamma correction and how it works in LÖVE, I sort-of do and nearly managed to apply it correctly. [thread title].

I have a system where material colours are all mixed together (converted into and back out from linear space for the mixing) from their json values and sent to a noise shader.

Here is the gamma correction use in my noise shader: https://github.com/wolfboyft/Alive/blob ... e.glsl#L24

Placing print(colourR) here shows the same value from the material's json, at least if I remove the interpolation between dead and alive grass colours: https://github.com/wolfboyft/Alive/blob ... g.lua#L117 which means that the colour that is sent to the attribute is fine.

Placing a canvas export here (using my boilerplate lib's takeScreenshot) shows the slightly-brightened grass, and if drawSprite is made to draw a circle with 0.5 gray, it shows 0.5 gray in GIMP: https://github.com/wolfboyft/Alive/blob ... g.lua#L214

before:
after:

I wouldn't be surprised if I haven't put in enough information, so please tell me what else you would like me to point you to or tell you about in the source code.

[ReFreezed]

Gamma correction tend to make the result brighter. Are you sure it's not correct?

[wolfboyft]

Gamma correction tend to make the result brighter. Are you sure it's not correct?

Well I was barely doing any calculation on the lighting that could end up brighter. It was all multiplication by one for bright daytime.
My understanding, and what I implemented, is enabling gamma correction changes the process such that you have an sRGB->linear linear->sRGB pair of conversions either side of any colour mixing. I wasn't actually doing any colour mixing at the time that would change the results depending on whether the conversions are there.

[ReFreezed]

I did some testing in the code. In the shader, changing

Code: Select all

love_Canvases[0] = vec4(fragmentColour.rgb * noise, fragmentColour.a);

to

Code: Select all

love_Canvases[0] = fragmentColour;

reveals that the output color is the same no matter if gamma correction is enabled or not (the ground is a bright green), so the gamma correction on VertexColor is working. The multiplication with the noise makes the color darker, and is the blending operation being done here. With gamma correction off the image is significantly darker than if it's on (as I would expect). I don't know why your "before" image is as bright as it is. Did you change any parameters affecting the noise between the two images?

Maybe you actually want to do the noise calculations in sRGB space?

Code: Select all

float noise = Texel(noiseTexture, noisePos / noiseTextureSize).r;
noise = unGammaCorrectColor(noise); // Added line.
noise = noise * 2.0 - 1.0; // To [-1, 1]
noise *= contrast;
noise += brightness * 2.0 - 1.0;
noise = noise / 2.0 + 0.5; // Back to [0, 1]
noise = gammaCorrectColor(noise); // Added line.

This keeps the final brightness the same. I think it's a bit confusing what the 'contrast' and 'brightness' variables actually represent in these calculations. I would ignorantly say they are simply artistic parameters - not related to any physical properties of light or anything.

(Note that I'm relatively new to gamma correction too.)

[wolfboyft]

I think I am definitely supposed to do the noise brightness/contrast calculations in linear space. But now that you mention it, I think those are the calculations that are different due to sRGB->linear conversions, I think I found my answer. I think the current code is correct, and the old noise parameters were for an incorrect pipeline. Thank you very much for your input.