[Public WebGL] WEBGL_compressed_texture_s3tc_srgb

Florian Bösch [email protected]
Tue Jun 14 04:07:02 PDT 2016

On Tue, Jun 14, 2016 at 12:55 PM, Kirill Dmitrenko <[email protected]>

> I know what gamma correction is and why it exists:) But one thing is
> missing in your argument: between a buffer an WebGL app's rendering to and
> screen an user looks at there's a browser or, to be more accurate, a
> compositor. And it may expect WebGL buffer to be linear to do, for example,
> blending or scaling. Also it's not specified whether the compositor itself
> corrects it's output.
I think you're correct that it is not specified. As far as I know the
reason it is not specified, is because all inputs the browser takes in
(#color values, images, videos) are in gamma space, and it operates on
those values in gamma space for compositing and blending. I.e. Browsers are
gamma ignorant, they do no conversion whatsoever.

sRGB textures store their values in sRGB color/gamma space. When you write
to these textures (gl_FragColor assignement) you deliver linear values, and
if you fetch values from them (texture2D lookup) you get linear space.

Therefore if you render your scene into an sRGB framebuffer object attached
texture, and then subsequently blit this texture to screen, you read out
linear values, and you need to manually re-encode those values to sRGB
again, the main advantage is that linear interpolation and blending in an
sRGB texture is performed after colorspace/gamma conversion, and so is
physically more correct.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20160614/795d5580/attachment.html>

More information about the public_webgl mailing list