[Public WebGL] WEBGL_compressed_texture_s3tc_srgb

Kenneth Russell [email protected]
Thu Jun 16 18:35:53 PDT 2016

On Tue, Jun 14, 2016 at 7:37 AM, Christophe Riccio <
[email protected]> wrote:

> 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 GL_COMPRESSED_TEXTURE_FORMATS
> but I also expect the extension string to be present.

OK. Sounds good. The conformance test for this extension will / should
assert that all of the tokens are present in the COMPRESSED_TEXTURE_FORMATS
list, like the non-SRGB S3TC extension.


> @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/20160616/7ec25fc6/attachment.html>

More information about the public_webgl mailing list