About linearity and gamma correction

[BlackMojito]

Hi All,

I've looked into the source code of Texture and I did not find any code which allowed loading texture directly in sRGB. I could not find them in the default.fragment.fx either something which handled the linearity. The only thing I've seen was converting the output to linear space if applying image processing afterwards. 

Another question is that do we have a built-in gamma correction effect? I know it's simple to implement but I'd rather use the built-in one if existing

BTW, should I still apply the gamma correction if I apply tone mapping before it? I am not familiar with the tone mappers and not sure if gamma correction has already been baked in them...

[BitOfGold]

I researched this a little bit, but could not find the place where srgb->linear and linear->srgb display space conversions happen in Babylon.
Maybe it is somewhere, maybe all is done in SRGB display space (which kind of works, but not correct)

in webGL 2, there is a way to load textures with automatic srgb-> linear correction like this:

gl.texImage2D(
    gl.TEXTURE_2D,
    0, // Level of details
    gl.SRGB8, // Format
    gl.RGB,
    gl.UNSIGNED_BYTE, // Size of each channel
    image
);

 

Here is the texture creation, babylon do not do this automatic correction for sure:
https://github.com/BabylonJS/Babylon.js/blob/8f752185e4cfd962ebf687dd25bb4f1ebaa32a46/src/Engine/babylon.engine.ts#L3112

let internalFormat = format ? this._getInternalFormat(format) : ((extension === ".jpg") ? gl.RGB : gl.RGBA);

gl.texImage2D(gl.TEXTURE_2D, 0, internalFormat, internalFormat, gl.UNSIGNED_BYTE, img);

But elsewhere maybe?!
 

[BitOfGold]

A little more research:
https://playground.babylonjs.com/#T23QTP#6

This shows a png image (which is in SRGB as nearly all other png and jpg images on the web)
The browser loads and correctly shows this on the upper right.
It is displayed correctly, because the 0,255 rgb values (stripes) look the same luminance as the 187 (middle grey) value. (In linear, 128 would be the middle grey value)

On the boxes, the same texture is loaded on to a emissive texture (black diffuse) and a diffuse texture.
Standard materials.
The emissive texture should look correctly too IF the texture is loaded from SRGB, corrected to linear RGB values, light calculated (no change because it is an emissive texture), and then corrected back to SRGB (display space)
It should look correctly without SRGB correction at all, because the input is srgb and the outout is srgb too.

Edited: It looks correctly now with good monitor settings.
So, it kind of works without SRGB/linear and linear/SRGB corection, so I think everything is done in display space.
 

[BlackMojito]

1 hour ago, BitOfGold said:

A little more research:
https://playground.babylonjs.com/#T23QTP#6

This shows a png image (which is in SRGB as nearly all other png and jpg images on the web)
The browser loads and correctly shows this on the upper right.
It is displayed correctly, because the 0,255 rgb values (stripes) look the same luminance as the 187 (middle grey) value. (In linear, 128 would be the middle grey value)

On the boxes, the same texture is loaded on to a emissive texture (black diffuse) and a diffuse texture.
Standard materials.
The emissive texture should look correctly too IF the texture is loaded from SRGB, corrected to linear RGB values, light calculated (no change because it is an emissive texture), and then corrected back to SRGB (display space)
It should look correctly without SRGB correction at all, because the input is srgb and the outout is srgb too.

Edited: It looks correctly now with good monitor settings.
So, it kind of works without SRGB/linear and linear/SRGB corection, so I think everything is done in display space.
 

Yeah but it is quite weird though as there is no "pow 2.2" in the StandardMaterial's shader either. Where is the correction done then?

[BitOfGold]

I think no correction done in standard material, at all.
That's not really a problem, theese are only values. SRGB in, SRGB out = works.

You have to convert and output srgb value in every shader material, that's all.
And I don't really know if this works in PBR - but I think it's working, most workflows output SRGB maps.
 

[Sebavan]

Correct, In the standard no correction is applied and gamma to gamma workarounds it.

In the pbr material Most of the texture fetched will be converted to linear space before using in the equation and then converted back to gamma before display. As the texture sRGB is not available everywhere we do it manually to ensure a cross browser/device consistent result. 

The function are available in the Helpers include. and the textures themselves have a flag isGamma helpfull to know that for instance the env hdr texture are stored in a linear way.

[BlackMojito]

3 hours ago, Sebavan said:

Correct, In the standard no correction is applied and gamma to gamma workarounds it.

In the pbr material Most of the texture fetched will be converted to linear space before using in the equation and then converted back to gamma before display. As the texture sRGB is not available everywhere we do it manually to ensure a cross browser/device consistent result. 

The function are available in the Helpers include. and the textures themselves have a flag isGamma helpfull to know that for instance the env hdr texture are stored in a linear way.

Hi Sebavan, where can I find the "then converted back to gamma before display" stuff?

[Sebavan]

It is part of the imageProcessing which is applied in the PBR here: https://github.com/BabylonJS/Babylon.js/blob/master/src/Shaders/ShadersInclude/imageProcessingFunctions.fx#L85

This is in here because imageProcessing can be applied either during the main pass or through post process to increase perf.