[Public WebGL] Re: sRGB textures

Florian Bösch [email protected]
Thu Dec 20 02:12:53 PST 2012


The extension proposal is now online, please review it and note any changes
you desire:
http://www.khronos.org/registry/webgl/extensions/proposals/EXT_sRGB/


On Sun, Dec 16, 2012 at 2:06 PM, Florian Bösch <[email protected]> wrote:

> *Motivation*
>
> It is widely acknowledged that it's important to perform calculations to
> do with radiance in linear space:
> http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html
>
> 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 channel.
>    - 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 switched.
>
> 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).
>
> *Specifications*
>
>    - 2002: Direct3D 9.0:
>    http://msdn.microsoft.com/en-us/library/windows/desktop/bb173460(v=vs.85).aspx
>    - 2007: OpenGL Extension for textures:
>    http://www.opengl.org/registry/specs/EXT/texture_sRGB.txt
>    - 2008: OpenGL Extension for framebuffers:
>    http://www.opengl.org/registry/specs/ARB/framebuffer_sRGB.txt
>    - 2011: OpenGL ES Extension for framebuffers/textures:
>    http://www.khronos.org/registry/gles/extensions/EXT/EXT_sRGB.txt
>    - 2012: OpenGL ES 3.0 core textures: 3.8.16 sRGB texture color
>    conversion
>    http://www.khronos.org/registry/gles/specs/3.0/es_spec_3.0.0.pdf
>    - 2012: OpenGL ES 3.0 core framebuffers: 4.1.8 sRGB Conversion
>    http://www.khronos.org/registry/gles/specs/3.0/es_spec_3.0.0.pdf
>
> *Support*
>
>    - Direct3D *99.43%* (Direct3D 9 or above)
>    http://store.steampowered.com/hwsurvey
>    - OpenGL* 63%* (framebuffer&texture EXTs)
>    http://feedback.wildfiregames.com/report/opengl/
>    - OpenGL ES: *94 of 783* devices http://www.glbenchmark.com/result.jsp ,
>    full list http://codeflow.org/download/EXT_sRGB.txt
>
> *Mirror Extension Proposal*
> https://github.com/KhronosGroup/WebGL/pull/112
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20121220/9bf1d25e/attachment.html>


More information about the public_webgl mailing list