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 <b style="font-style:italic">fast</b>, hence I am using techniques developed for and used by triple-A console and PC titles.<div>
<br></div><div>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.</div>
<div><br></div><div>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.  <a href="http://altdevblogaday.com/2011/06/02/yet-another-post-about-gamma-correction/">http://altdevblogaday.com/2011/06/02/yet-another-post-about-gamma-correction/</a></div>
<div><br></div><div>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.</div>
<div><br></div><div>4. Even when making an HDR renderer, LDR sRGB textures are still useful for storing pretty much all surface properties aside from lightmaps.</div><div><br></div><div>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 <i>extension </i>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.</div>
<div><br></div><div><br></div><div>Conor Dickinson</div><div>railGun 3D</div><div><br><br><div class="gmail_quote">On Thu, Feb 2, 2012 at 8:15 AM, Florian Bösch <span dir="ltr"><<a href="mailto:pyalot@gmail.com">pyalot@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, Feb 2, 2012 at 4:56 PM, Thatcher Ulrich <<a href="mailto:tu@tulrich.com">tu@tulrich.com</a>> wrote:<br>

> FYI the sRGB extensions are preferred, to avoid banding.<br>
</div>Assuming you want to squeeze your stuff into byte textures, sure sRGB<br>
would be better but:<br>
- sRGB is not yet supported by any mobile device whatsoever<br>
- sRGB is supported by about 45% of PCs.<br>
<br>
The performance impact of converting between colorspaces yourself is<br>
negligible. The precision (and respective loss of) is not negligible,<br>
but your mileage in manual conversion may vary, and in some cases<br>
linear bytes as transport format would probably be better.<br>
<br>
A particular use-case of high-quality physical based renderers is HDR<br>
computations (tone mapping, bloom blurs etc.), which is where neither<br>
linear byte values nor sRGB will be of any practical use (without<br>
massive banding). That is because you need to store HDR values which<br>
can have magnitudes of channels 50x brighter than 1, and many times<br>
fainter than 1/255th. In these cases you will have no other choice<br>
than to use floating point textures.<br>
<br>
When comparing sRGB back/forth conversions between linear and gamma<br>
versus actually using linear space 32-bit floats, floats win hands<br>
down in quality as well.<br>
<br>
Floating point texture support is present on:<br>
- 321 mobile devices<br>
- 65% of PCs<br>
</blockquote></div><br></div>