[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 7:37 AM, Christophe Riccio <christophe.riccio@unity3d.com> wrote:
issue 22 says:
"Should the new COMPRESSED_SRGB_* formats be listed in an implementation's GL_COMPRESSED_TEXTURE_FORMATS list?"

@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 <pyalot@gmail.com> wrote:
On Tue, Jun 14, 2016 at 3:11 PM, Kirill Dmitrenko <dmikis@yandex-team.ru> 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).