Editor: Background textures (PNG, JPG, ...) should assume sRGB

[donmccurdy]

Description

Originally reported in:

https://discourse.threejs.org/t/scene-texture-background-is-lighter-than-image-used/38362

It appears that the editor currently assumes background textures use the working color space, LinearSRGBColorSpace. That's probably correct for .exr or .hdr textures, but it's unlikely that non-HDR textures in PNG/JPG/WebP/AVIF/... formats will be linear. We should assume that these formats are sRGB, like material.map.

The incorrect (lighter) output in the issue report is the result expected if we set background.colorSpace to NoColorSpace or LinearSRGBColorSpace, when it should be SRGBColorSpace.

I've checked that fog and tone mapping are not involved in this case. We can get the same result by doing a linear-to-sRGB conversion on the already-srgb input:

oiiotool -i ~/Downloads/background.jpeg --iscolorspace lin_srgb --colorconvert lin_srgb srgb -o ~/Downloads/background_srgb_oetf.jpeg

Reproduction steps

1. add background texture to Editor (see link)
2. observe lighter background than expected

Code

n/a

Live example

n/a

Screenshots

Expected

Actual

Version

r174

Device

No response

Browser

No response

OS

No response

[Mugen87]

There are a couple of strategies to fix this issue.

• Evaluate the file extension although that assumption might be incorrect. E.g. UltraHDR files are JPGs.
• Add a select box that specifies the color space of the background texture.
• Or alternatively a select box that allows to choose between HDR or SDR.

I vote for option 2.

[donmccurdy]

If we know from context (scene.background) that it's a color texture, then I think a solid default choice would be sRGB for 8-bit textures and Linear-sRGB for >=16-bit textures. If we want to do (2) as well that's even better.

I would avoid the HDR/SDR terms in this UI, I think they're too ambiguous.