Open kpreid opened 2 years ago
Yeah, this is an extension normally. I’m not sure how to do that correctly in the WebGL backend.
Gah. I had sloppily assumed that this situation had improved in the years since I initially noticed that WebGL said nothing about color spaces…
It would be nice if luminance
could communicate “not supported; manage it yourself”. (Though doing that naively in the compile-time style would require parameterizing PipelineState
with the Backend
.)
In case anyone else has the same momentary confusion I did: I heard that EXT_sRGB
was moved to core in WebGL 2, but as far as I can tell, this only lets you ask for sRGB encoded storage in renderbuffers, which are for offscreen rendering and don't affect the canvas.
(Also, the whole idea of asking for sRGB is only an approximation to the ideal result, which would be asking for conversion from linear to whatever color space the browser thinks is best — since browsers are already aware of monitor color profiles for rendering images and this could produce better results than an intermediate sRGB step. But, there doesn't seem to be any motion towards having a standard for that, and it seems like the general expectation is that canvas pixels are sRGB in either type of canvas.)
enable_srgb(true)
has no effect on rendering when using the WebGL2 backend. It has the expected effect when using the gl33 backend.A quick text search suggests that the problem is lack of corresponding code to enable/disable the
FRAMEBUFFER_SRGB
state in luminance-webgl.