Thanks for the motivation and writing up the proposal. It's been
merged into the WebGL repo. (It looks like the extension registry at
http://www.khronos.org/registry/webgl/extensions/ is stuck again; I'll
email the webmaster.)
This particular extension presents some difficulties. It was discussed
in the past at a face-to-face meeting of the working group. The basic
problem is that the default WebGL back buffer should support sRGB, not
just user-allocated FBO attachments. This requires updates to the core
WebGL spec. Right now there's a desire to take another spec and
conformance suite snapshot, and figure out how to unblock past and
future snapshots which are hampered by one particular OpenGL driver
bug, before making more core spec changes.
There's a bunch of work queued up right now on the spec and
implementations (for example, to finalize and implement the MRT
extension) so I think we should take care of that first before pushing
forward with this extension.
On Sun, Dec 16, 2012 at 5:06 AM, Florian Bösch <firstname.lastname@example.org> wrote:
> It is widely acknowledged that it's important to perform calculations to do
> with radiance in linear space:
> If calculations for radiance are not done in linear space odd effects can
> happen, such as textures brightening on minification and being incorrectly
> summed up altogether: http://hsivonen.iki.fi/png-gamma/
> Transferring/Processing all values in linear space would be preferrable. HDR
> images (such as PNGs that use alpha as an exponent) are a one solution to
> this. However this has several drawbacks.
> Half or Single precision floating point textures are large to transfer.
> Using alpha for exponent only works with PNGs and eliminates the alpha
> Blending (also anti-aliasing) will be done in gamma space when manually
> outputting gamma corrected colors.
> Manual gamma correction is not a "drop in" solution.
> sRGB solves these issues:
> reads from sRGB textures are first converted to linear space and all
> calculations prior to handoff to the fragment program (mipmapping,
> anisotropy, linear interpolation etc.) are done in linear space.
> writes to sRGB textures are treated as being in linear space encoding to
> sRGB space happens after fragment program evaluation and blending.
> Shaders need not be modified for gamma, merely texture formats have to be
> sRGB also has these drawbacks:
> repeated de/encoding can introduce its own banding
> sRGB assumes consumer grade CRT monitors gamut
> Apple systems are not (by default) configured to run in sRGB space.
> mipmap generation is not supported
> does not support compressed textures (ES extension restriction, desktop
> defines sRGB for compressed textures).
> 2002: Direct3D 9.0:
> 2007: OpenGL Extension for textures:
> 2008: OpenGL Extension for framebuffers:
> 2011: OpenGL ES Extension for framebuffers/textures:
> 2012: OpenGL ES 3.0 core textures: 3.8.16 sRGB texture color conversion
> 2012: OpenGL ES 3.0 core framebuffers: 4.1.8 sRGB Conversion
> Direct3D 99.43% (Direct3D 9 or above) http://store.steampowered.com/hwsurvey
> OpenGL 63% (framebuffer&texture EXTs)
> OpenGL ES: 94 of 783 devices http://www.glbenchmark.com/result.jsp , full
> list http://codeflow.org/download/EXT_sRGB.txt
> Mirror Extension Proposal