WebGLRenderer: Avoid default color space conversion.

[takahirox]

Related issue: #21318, #21323, #21324

Description

This PR is an alternative of #21323 and #21324, and resolves #21318. Please refer to them for the detail of this change.

[mrdoob]

Thanks!

[Mugen87]

@mrdoob I wonder if UNPACK_COLORSPACE_CONVERSION_WEBGL was the root cause for #20786. Maybe RGBM files can now be loaded correctly on iOS even with TextureLoader 🤔 ?

TBH, UNPACK_COLORSPACE_CONVERSION_WEBGL confused me quite a bit. I'm surprised that color textures with encoding set to sRGBEncoding were decoded from srgb to linear not twice in the past.

The WebGL standard also mentions that it is up to the browser if a color space conversion is applied on how the conversion is implemented. Sounds quite unreliable. One reason more to disable it.

[lexaknyazev]

were decoded from srgb to linear not twice in the past

AFAIR, all that setting does is comparing the image file profile (when present) with some "system default" profile (e.g. sRGB), performing color-matching, and (re)encoding corrected values (usually to 8-bit sRGB).

[Mugen87]

Related issue: https://stackoverflow.com/questions/22679494/three-js-normal-map-rendering-differently-windows-mac

[Mugen87]

AFAIR, all that setting does is comparing the image file profile (when present) with some "system default" profile (e.g. sRGB), performing color-matching, and (re)encoding corrected values (usually to 8-bit sRGB).

Okay, that would at least explain why the sRGB decode works as expected in the past. But the stackoverflow thread and the RGBM issue on iOS seems to be related to UNPACK_COLORSPACE_CONVERSION_WEBGL.

[Mugen87]

The following fiddle is the RGBM example with the dev build and TextureLoader. Can somebody with an iOS device check if the same banding occurs like in #20786?

https://jsfiddle.net/6hjtzy8x/

[mrdoob]

Okay, found the reason Safari is broken: e7ba155
And after fixing that I get this on Safari/macOS:
https://mrdoob-sandbox.glitch.me/webgl_loader_texture_rgbm.html

[Mugen87]

Okay, then #20786 is indeed unrelated to UNPACK_COLORSPACE_CONVERSION_WEBGL. After some more testing, it's about premultiplying alpha which behaves differently on iOS. So we definitely need a custom RGBM loader.

[mrdoob]

@Mugen87 It's worth noting that Safari Technical Preview seem to have this issue fixed:

So I guess we'd just need the workaround until summer?

[Mugen87]

Yes, probably. Maybe revisiting this issue in second half of 2021?

[takahirox]

Does anyone here know if embedded custom color space is often used in practical? I'm curious to know how much this change affects the existing Three.js applications. And this is a breaking change so I'm going to write a note that we recommend pre apply the transformation in Migration guide.

[lexaknyazev]

Based on my experience, here are the most often cases:

• a regular sRGB profile embedded just in case (safe to ignore on the web);
• a wide gamut profile is embedded in screenshots taken on P3 displays on macOS (ignoring it leads to compressing image colors);
• photos not prepared for web (may contain anything);
• images authored for printing (may even use CMYK for pixel values).

[takahirox]

Thanks for the explanation. It sounds like to me that embedded extra image information is beyond the use of web 3D and avoid default color space conversion and request pre apply the color transformation may be a good direction as Web based 3D engine for portability and performance.

I added the note to Migration Guide. Please feel free to reword it because English is not my first language.