[Public WebGL] WEBGL_compressed_texture_s3tc_srgb

Christophe Riccio [email protected]
Tue Jun 14 07:37:58 PDT 2016

issue 22 says:
"Should the new COMPRESSED_SRGB_* formats be listed in an implementation's

@Ken, I don't know what are the specific with WebGL but my expectation is
that all the compressed formats should be included by
but I also expect the extension string to be present.

@Florian, with EXT_sRGB WebGL extension and WebGL 2.0 the conversion from
linear to sRGB should be performed systematically when the framebuffer is
sRGB, at least accoding to OpenGL ES 3.0 specification. On the default
framebuffer, well yes it's complicated and I must say I assumed that WebGL
had something... maybe something I need to investigate. HDR, MSAA is
important but it's different features so I don't want to throw these topics
in the mix, sRGB is already a heated topic enough. :)

On Tue, Jun 14, 2016 at 3:19 PM, Florian Bösch <[email protected]> wrote:

> On Tue, Jun 14, 2016 at 3:11 PM, Kirill Dmitrenko <[email protected]>
> wrote:
>> It may be logical, but, as far as I know, not entirely true
>> (unfortunately). Here's huge discussion on the matter:
>> https://www.khronos.org/webgl/public-mailing-list/archives/1009/msg00000.php.
>> I've understood from the thread that browsers interpret images differently
>> (e.g., some ignore colour profile from image file and some don't). Also
>> there is no guarantees that gamma-corrected WebGL buffer will be absolutely
>> correctly composed to a page.
> That's mostly about upload to textures, which isn't related at all to the
> output. Images may come in a variety of colorspaces (but they mostly come
> in Adobe sRGB). They may also contain information which colorspace that is,
> or they may not. Image editing programs may use those colorspace for
> de/encoding, or they may not. etc. You should be able to avoid that the
> browser does any colorspace conversion with those flags when you upload to
> textures. But that's only because image parsing libraries do usually have
> metadata parsing to find out what colorspace is claimed by the image, and
> conversion code to read it out. Anyways, not related in any way to lookup
> (texture2D) or storage on GPU (gl_FragColor).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20160614/27d18152/attachment.html>

More information about the public_webgl mailing list