[Public WebGL] WEBGL_compressed_texture_s3tc_srgb

Florian Bösch [email protected]
Wed Jun 15 03:00:53 PDT 2016

On Wed, Jun 15, 2016 at 11:45 AM, Mark Callow <[email protected]> wrote:

> On Jun 15, 2016, at 5:23 PM, Florian Bösch <[email protected]> wrote:
>> the values will be compressed to non-linear before being written to the
>> framebuffer.
> Otherwise they are written as is.
> This is incorrect. You need to distinguish between framebuffers, and
> framebuffer objects.
> It is correct and you do not need to distinguish between framebuffers and
> FBOs. Both default framebuffers created with an EGL 1.5 setting for
> as color attachment will have a FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING of
> sRGB.
It is incorrect to throw them together for a simple reason. EGL defines
that sRGB framebuffers values are read out in sRGB space. This would extend
to a browser as well being a "compositor". However WebGL 1/2 do not have
explicit framebuffer setup, so the point is moot, to the browser the front
framebuffer is never sRGB. An sRGB texture (such as you would attach to a
framebuffer object) however is always read out on lookup as linear. So even
if you somehow managed to smuggle an sRGB texture as the frontbuffer to the
Browser (which you can't), it would use texture2D to lookup that texture
upon compositing, and would get linear values. The browser being colorspace
agnostic, would then just straight pipe the linear space into everything
else it composits with, which is in nonlinear space, which is incorrect.

If you ever where to support sRGB front buffers in WebGL, the browser would
have to re-encode the linearly read out value from the sRGB texture it uses
as a stand-in for a frontbuffer from the WebGL context explicitely into
sRGB space again manually (the OS isn't going to help him any with that).
As it stands, that capability does not exist, and so the application
programmer has to do that job, and the job is identical, perform a
re-encode to sRGB from the linear value read out from the sRGB texture and
blit it as non-linear value onto the WebGL front buffer. This is why the
distinction matters. Because the browser (or the application programmer)
can only emulate (manually) EGL agnostic behavior, with a non colorspace
agnostic bitmap surface. This is a problem you do not have in native EGL
because EGL is specified to be agnostic, so a native programmer doesn't
have to care.

If you do not make this distinction clearly, and correctly, you will end up
with garbage in your WebGL frontbuffer.

>> The canvas color space proposal together with sRGB rendering support is
>> intended to resolve these and other color space issues.
> It will not solve the underlying issue that everything that gets sent to a
> display is sent to the display in sRGB, because the display is forced to
> accept sRGB only because that's how it came into existence.
> One of the drivers for the proposal is support of HDR and wide gamut
> displays. It is no longer true that everything sent to a display is sRGB.
To my knowledge this is still the case throughout the entire stack (display
IC, wire protocol, GPU, driver, OS and application). That does not mean
that wide gamut displays do not exist, but what gets shunted to them always
goes trough the limited straw of sRGB and 8bbc precision.

All applications that stretches their contrast across the range of
available values (0 - 255) always use the maximum available gamut of the
display device, regardless of what that is. The result just doesn't match
of course (but wide gamut displays are advertised to the consumer as
"prettier" and that's in fact how they look, regardless if it's a faithful
reproduction, consumers don't seem to care much about that, even though we
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20160615/76ca9288/attachment.html>

More information about the public_webgl mailing list