[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb

On Tue, Jun 14, 2016 at 12:55 PM, Kirill Dmitrenko <dmikis@yandex-team.ru> wrote:
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.