BRDF LUT uses the sRGB format, by design?

The textures seem to be loaded using the following formats:

textures/brdfLUT.png  ->sRGB
models/DamagedHelmet/glTF/Default_emissive.jpg  ->sRGB
models/DamagedHelmet/glTF/Default_normal.jpg  ->RGBA
models/DamagedHelmet/glTF/Default_AO.jpg  ->RGBA
models/DamagedHelmet/glTF/Default_albedo.jpg  ->sRGB
models/DamagedHelmet/glTF/Default_metalRoughness.jpg  ->RGBA

the BRDF lookup table seems to be using the sRGB color space. Is this by design?

[snagy]

@emackey In your case where you’re computing it in a shader and putting it into a texture, you shouldn’t be converting from sRGB unless you’re calculating the values in sRGB space or converting before you store them in a texture (you might have reason to do this if you want to take advantage of sRGB’s adjusted precision). Glancing at your code, I don’t think you’re doing either of those.

IIRC, the BRDF LUT from IBLBaker is in sRGB. I don’t remember how I determined this, so I could definitely be wrong here.

[emackey]

I’ve been wondering this too. @snagy Would you be willing to comment? In particular:

https://github.com/KhronosGroup/glTF-WebGL-PBR/blob/0d1a32003253067ab98e6aaca9e8028028a4ef65/shaders/pbr-frag.glsl#L150

Is this conversion simply because the PNG behind this is stored in sRGB?

In Cesium I have a branch open where I’ve applied the Linear/sRGB conversions. But I didn’t apply this conversion on the BRDF LUT, because in Cesium it is computed in a shader. I think this makes my dev branch have much more “rim lighting” than master, and of course adding the conversion puts it back the way it was. I’m trying to figure out if the conversion is supposed to be there, even for textures that have been computed as opposed to read in.