Video textures look washed out in safari starting with version 0.152.0

[justinrhodes1]

Description

Video textures look washed out in safari with mesh basic materials (Version 16.3/18614.4.6.1.6). In Chrome the texture colors look fine. Setting the texture colorspace to SRGBColorSpace doesn't seem to make any difference.

Related to the changes in color management in version 0.152.0.

Live example

• codesandbox example

Screenshots

Safari

Chrome

Version

0.155.0

[Mugen87]

I can reproduce on macOS 13.4.1 with Safari 16.5.2. It seems the texture indeed ignores the SRGBColorSpace definition. Enhancing the built-on shader with a manual sRGB decode seems to fix the issue:

https://codesandbox.io/s/white-snow-77vjd8?file=/src/index.ts:744-1348

Is SRGB8_APLHA8 broken for video textures in WebKit?

[Mugen87]

https://threejs.org/examples/webgl_video_panorama_equirectangular shows the same issue.

FF is fine, btw.

[cankahya]

Any updates on this? Running into the same problem with a 360 Video – based on https://threejs.org/examples/webgl_video_panorama_equirectangular

Insights / ideas would be much appreciated.

Edit: oops, just seeing this issue was created 6h ago. Sorry, don't wanna be impatient. But +1 for this issue :)

[Mugen87]

@donmccurdy Given the broken Webkit support and #26183, I think it's best for now to revert #25752. I originally did not want to go this route but the current situation is simply not acceptable. The fact is, video textures can't be properly used in production without patching the built-in shaders like in #26516 (comment).

I also doubt that the browser vendors will soon fix their issues so we need a fix in the engine.

[Mugen87]

Insights / ideas would be much appreciated.

@cankahya Until there is a fix in the engine, use the workaround from #26516 (comment).

[justinrhodes1]

I can reproduce on macOS 13.4.1 with Safari 16.5.2. It seems the texture indeed ignores the SRGBColorSpace definition. Enhancing the built-on shader with a manual sRGB decode seems to fix the issue:

https://codesandbox.io/s/white-snow-77vjd8?file=/src/index.ts:744-1348

Is SRGB8_APLHA8 broken for video textures in WebKit?

Thanks for the quick reply. This solution will do for now! 👍

[donmccurdy]

@Mugen87 Agreed — seems like inline sRGB decoding is still necessary for video textures. 😔

[cankahya]

Insights / ideas would be much appreciated.

@cankahya Until there is a fix in the engine, use the workaround from #26516 (comment).

@Mugen87 You are my hero! Thank you, I didn't get that on the first read. Thanks for pointing that out again!! Works like a charm.

[marcofugaro]

So this is broken on Webkit, is there already a webkit issue about this?

[Mugen87]

It seems there is no bug reported yet. At least when searching for SRGB8_APLHA8.

https://bugs.webkit.org/buglist.cgi?quicksearch=SRGB8_APLHA8

[Mugen87]

I've filed a bug today: https://bugs.webkit.org/show_bug.cgi?id=259768

[cgauld]

I have a worry that there may be no performant way for browsers to implement this on their side. I suspect the issue is that the underlying video texture comes straight from the video decoding hardware. In order for the browser to perform the conversion to linear then I think the only options available to them would be:

1. do the conversion CPU-side, which would be suuuper slow
2. render the texture into another texture doing this conversion in a shader, which would also be much slower than just doing the conversion after sampling in the final fragment shader (as @Mugen87's fix does)

If they're already doing 2 then it may not incur very much any additional performance cost than there already is, but it does require the browsers to do the correct conversion in that intermediate shader.

[donmccurdy]

sRGB decoding is a standardized feature of WebGL, and works in other browsers. If there's a reason browsers cannot implement it efficiently, then the feature should be evicted from the standard. But I expect it's just a bug, lots has been changing in Webkit's WebGL implementation over the past few years.

[cgauld]

I agree for sure :-) I think the reason things might be different for video textures is that accelerated path straight from the hardware decoder. Hopefully I'm wrong and it can be implemented in a performant way :-)