[Public WebGL] EXT_sRGB

Conor Dickinson [email protected]
Thu Feb 2 13:29:15 PST 2012


I realized from your responses that I was not very clear  in my original
email  about what I am working on. I am currently developing a top quality
WebGL game renderer aimed to deliver nearly cutting edge graphics.  Because
it is for a game it also needs to be *fast*, hence I am using techniques
developed for and used by triple-A console and PC titles.

1. Floating point textures and framebuffers are unacceptable from a
performance standpoint; the framebuffer read/write speed is atrocious and
floating point textures dramatically increase the rate of texture cache
misses, especially compared to DXT compressed sRGB textures.

2. sRGB acts as a perceptual based compression scheme, it is the only way
that color values are acceptable in byte textures.  Linear values stored in
bytes have way too much banding, especially compressed.
http://altdevblogaday.com/2011/06/02/yet-another-post-about-gamma-correction/

3. The performance impact of manual conversion from sRGB textures and back
to sRGB framebuffer in the shaders is not negligible, that is 3 pow
instructions per texture and 3 pow instructions at the end.  And, as
Thatcher mentioned, there is no way to manually to sRGB expansion before
texture filtering or during alpha blending.  I am currently doing the
manual conversion and it definitely does not look as good or run as well as
using the hardware support in OpenGL or DirectX.

4. Even when making an HDR renderer, LDR sRGB textures are still useful for
storing pretty much all surface properties aside from lightmaps.

5. I am not targeting mobile devices, and while I understand the goal of
keeping the WebGL core spec in line with mobile capabilities, sRGB is
an *extension
*and therefore it is acceptable to not be supported everywhere.  The
performance characteristics of mobile GPUs is such that I would want a
different rendering path for those devices anyway.  On the desktop
computers without sRGB support I am fine with having a fallback path in my
shaders, those devices will not support all the fancy rendering effects so
I don't care about visual quality as much in that case.


Conor Dickinson
railGun 3D


On Thu, Feb 2, 2012 at 8:15 AM, Florian Bösch <[email protected]> wrote:

> On Thu, Feb 2, 2012 at 4:56 PM, Thatcher Ulrich <[email protected]> wrote:
> > FYI the sRGB extensions are preferred, to avoid banding.
> Assuming you want to squeeze your stuff into byte textures, sure sRGB
> would be better but:
> - sRGB is not yet supported by any mobile device whatsoever
> - sRGB is supported by about 45% of PCs.
>
> The performance impact of converting between colorspaces yourself is
> negligible. The precision (and respective loss of) is not negligible,
> but your mileage in manual conversion may vary, and in some cases
> linear bytes as transport format would probably be better.
>
> A particular use-case of high-quality physical based renderers is HDR
> computations (tone mapping, bloom blurs etc.), which is where neither
> linear byte values nor sRGB will be of any practical use (without
> massive banding). That is because you need to store HDR values which
> can have magnitudes of channels 50x brighter than 1, and many times
> fainter than 1/255th. In these cases you will have no other choice
> than to use floating point textures.
>
> When comparing sRGB back/forth conversions between linear and gamma
> versus actually using linear space 32-bit floats, floats win hands
> down in quality as well.
>
> Floating point texture support is present on:
> - 321 mobile devices
> - 65% of PCs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120202/7c78378d/attachment.html>


More information about the public_webgl mailing list