[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb



14.06.2016, 10:08, "Florian Bösch" <pyalot@gmail.com>:
I think your proposal is important, but I'd like to comment on the other thing you said.
 
On Mon, Jun 13, 2016 at 9:46 PM, Christophe Riccio <christophe.riccio@unity3d.com> wrote:
This is pretty unfortunate because it makes supporting linear rendering more complicated than it should
 
All output ultimately written to gl_FragColor (when no framebuffer is bound) is in gamma space (which typically means sRGB gamma).
 
If you're referring to WebGL (and WebGL 2 for that matter), is there any info backing this statement? Because it seems to be not specified in either spec, and, moreover, browsers seem to threat image data differently (both recieved from a server and rendered with WebGL). There was an endeavour to specify browsers behaviour regarding gamma correction on decoding images for textures and compositing WebGL content to a page. But as far as I can tell, it has never gotten anywhere.
 
To put simply, there is no way to reliably tell, will the browser gamma correct your output for you of should you do it yourself.
 
You can gamma encode your colors prior to writing to gl_FragColor, and both simple gamma or sRGB are implementable in GLSL easily and the overhead on any device is negible. The one thing you cannot do in this fashion is blending  (which can take the form of alpha blending, additive blending, subtractive blending and blending due to anti-aliasing). Multiplicative blending is possible however (at least for simple gamma) because a = (b*c)^2 = b^2 * c^2.
 
Rendering to an sRGB (compressed or not) texture takes your rendering out of the frontbuffer and puts it in a framebuffer object. In the framebuffer object, you have no MSAA (at least in WebGL 1.0). So a source of blending artifacts (MSAA) falls away. That leaves other blending artifacts for which linear space might be beneficial, and for that it is a good choice. But you've still given up MSAA, which in the scheme of things, is probably the bigger loss than having blending artifacts.
 
In WebGL 2.0 you will not suffer from this, because you can instantiate a framebuffer object with MSAA. However, due to support levels, you will have to support WebGL 1.0 for a fairly long while, and so the problem for WebGL 1.0 remains. A possible solution would be to backport the necessary extensions to get MSAA'ed framebuffer objects in WebGL 1.0 (although their introduction is likely to also lag behind in implementation for most vendors, so it's dubious if the support level of such an extension would be any better than the support level of WebGL 2.0).
 
Regardless of these consideration, sRGB is not HDR (it's in fact slightly worse than LDR, too, because of narrow gamut clamping of that colorspace). In many use-cases of linear space rendering, you might have a need for an HDR color representation in a source or intermediate texture. The only form of HDR color representation that currently works with blending and anti-aliasing and in linear space artifact free are floating point textures (which may carry prohibitive bandwidth/performance impacts, especially on mobiles).
 
Alternatives to floating point are schemes such as LogLuv, RGBE, RGBM, etc. They vary in tradeoffs, but they all share the common characteristic that they have blending artifacts. What they also share with floating point textures is that they're not compressed. Although you can shove LDR content into compressed sRGB textures, this will not work well for HDR content, because the high dynamic range will make block-encodings much more visible.
 
What is currently completely lacking in any way, shape or form, both in WebGL 1 and WebGL 2, would be a format that can:
  • Do HDR
  • Is correctly blendable
  • Is correctly interpolatable
  • Can be rendered to
  • Can be compressed
  • Can be rendered to when compressed
  • Can have MSAA
I don't know what that should be, or how it would look, but I'd really like to have it :)
 
 
 
 
--
Kirill Dmitrenko
Yandex Maps Team