From kbr...@ Tue Jun 7 18:14:01 2016 From: kbr...@ (Kenneth Russell) Date: Tue, 7 Jun 2016 18:14:01 -0700 Subject: [Public WebGL] Proposal: remove TIMESTAMP_EXT functionality from WebGL's EXT_disjoint_timer_query wrapper Message-ID: WebGL community, In this discussion on webgl-dev-list: https://groups.google.com/d/topic/webgl-dev-list/Q5tYioJqBmw/discussion Developers have started using WebGL's wrapper for the EXT_disjoint_timer_query extension and have found that the TIMESTAMP_EXT queries aren't working well. Specifically, they're not implementable on either Windows or Mac OS X. Consequently, in Chrome, they return 0 on all platforms, and Chrome reports 0 bits for the QUERY_COUNTER_BITS_EXT query against timestamps. Elapsed time queries are portable, and are the recommended way to gather timing information on the GPU. It was suggested to simply remove support for timestamp queries. In concrete terms, this would mean: - Removing the TIMESTAMP_EXT enum, and its effects on getParameter() and getQueryEXT(). - Removing the queryCounterEXT method. Any thoughts on this proposal? This extension was only introduced recently and is probably not widely used yet, so the risk of breaking content is low. Thanks, -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Wed Jun 8 00:40:24 2016 From: dmi...@ (Kirill Dmitrenko) Date: Wed, 08 Jun 2016 10:40:24 +0300 Subject: [Public WebGL] Proposal: remove TIMESTAMP_EXT functionality from WebGL's EXT_disjoint_timer_query wrapper In-Reply-To: References: Message-ID: <2287601465371624@webcorp02g.yandex-team.ru> An HTML attachment was scrubbed... URL: From pya...@ Wed Jun 8 01:16:07 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 8 Jun 2016 10:16:07 +0200 Subject: [Public WebGL] Proposal: remove TIMESTAMP_EXT functionality from WebGL's EXT_disjoint_timer_query wrapper In-Reply-To: <2287601465371624@webcorp02g.yandex-team.ru> References: <2287601465371624@webcorp02g.yandex-team.ru> Message-ID: Build a performance picture of a frame where both deltas between two checkpoints, as well as the absolute time of each checkpoint is available (i.e. timestamps) is useful. It is possible to emulate/shim timestamp queries purely in JS. This would not be desirable for the usual reasons. I'm against removing the TIMESTAMP_EXT functionality for the following reasons: - Precision bits are available to indicate not only precision but also support. Those bits are there for exactly that reason. - Timestamp functionality is useful - In the absence of platform native or browser emulated timestamp functionality, the precision bits can be used by those wishing to have timestamp functionality to plug in a pure JS shim. - In the absence of platform support, browsers may emulate timestamps with a non JS shim (that would probably be better than a JS shim) and they can communicate this via the precision bits. - Removing timestamp functionality removes the adapative upgrade/emulation as described above, and forces everybody in need of timestamps, to rely purely on shimming it in JS, forever, which is undesirable. On Wed, Jun 8, 2016 at 3:14 AM, Kenneth Russell wrote: > > Developers have started using WebGL's wrapper for the > EXT_disjoint_timer_query extension and have found that the TIMESTAMP_EXT > queries aren't working well. > That timestamp queries will be problematic has been known since before the extension was exposed. It is also what the precision bits are intended for. Elapsed time queries are portable, and are the recommended way to gather > timing information on the GPU. And they can be used by an UA, if so desired, to emulate timestamps and indicate that support with the precision bits. not widely used yet, so the risk of breaking content is low. I object to the removal not because of legacy breakage but because a useful feature will be doomed to be JS-shimmed forever for those who need it. On Wed, Jun 8, 2016 at 9:40 AM, Kirill Dmitrenko wrote: > Well, as I've written on webgl-dev-list, the fact that Chromium won't > support TIMESTAMP_EXT renders it pretty much useless. > It is useful, where it works. And it can be shimmed in JS, if the precision indicates non support. > There is little to no sense to write one code for platforms that have > timestamps and another one for ones that don't. > Yes there is, it's called a "shim". > Especially considering absence of a way to feature-detect noop timestamps. > You can query the precision bits to figure out if timestamps are supported. > If implementers don't want to support TIMESTAMP_EXT due to technical > difficulties we should drop it from the extension spec. > The extension specification is intentionally extensible in its ability to indicate support in the precision bits, so in order that emulations (in drivers, UAs or JS) can be appropriately offered and the best implementation rules over the next best. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jun 8 03:21:02 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 8 Jun 2016 12:21:02 +0200 Subject: [Public WebGL] Proposal: remove TIMESTAMP_EXT functionality from WebGL's EXT_disjoint_timer_query wrapper In-Reply-To: References: <2287601465371624@webcorp02g.yandex-team.ru> Message-ID: It should also be noted that although timer queries are not part of OpenGL ES 2.0, 3.0, 3.1 or 3.2 core profiles, they are part of OpenGL 4.0, 4.1, 4.2, 4.3, 4.4, 4.5 and Vulkan 1.0, including TIMESTAMP and precision queries. It is to be expected that OpenGL ES 4.0 will include elapsed and timestamp queries in its core profile. It is also the case that TIMESTAMP queries are the only queries supported in Direct3D 12, and that elapsed queries are emulated on Direct3D via timestamps. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Jun 8 14:43:03 2016 From: kbr...@ (Kenneth Russell) Date: Wed, 8 Jun 2016 14:43:03 -0700 Subject: [Public WebGL] Proposal: remove TIMESTAMP_EXT functionality from WebGL's EXT_disjoint_timer_query wrapper In-Reply-To: References: <2287601465371624@webcorp02g.yandex-team.ru> Message-ID: OK. Thanks Florian for pointing this out. I'll drop the request to remove TIMESTAMP queries, under the assumption that they may be necessary in the future. Kirill, please adjust your code to query for the number of bits in TIMESTAMP queries, and choose your implementation strategy based on that. -Ken On Wed, Jun 8, 2016 at 3:21 AM, Florian B?sch wrote: > It should also be noted that although timer queries are not part of OpenGL > ES 2.0, 3.0, 3.1 or 3.2 core profiles, they are part of OpenGL 4.0, 4.1, > 4.2, 4.3, 4.4, 4.5 and Vulkan 1.0, including TIMESTAMP and precision > queries. It is to be expected that OpenGL ES 4.0 will include elapsed and > timestamp queries in its core profile. It is also the case that TIMESTAMP > queries are the only queries supported in Direct3D 12, and that elapsed > queries are emulated on Direct3D via timestamps. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jun 8 15:24:29 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Thu, 9 Jun 2016 00:24:29 +0200 Subject: [Public WebGL] Proposal: remove TIMESTAMP_EXT functionality from WebGL's EXT_disjoint_timer_query wrapper In-Reply-To: References: <2287601465371624@webcorp02g.yandex-team.ru> Message-ID: Maybe non-formative language could be added to the specification in the examples section that illustrates how to use the precision bits. On Wed, Jun 8, 2016 at 11:43 PM, Kenneth Russell wrote: > OK. Thanks Florian for pointing this out. I'll drop the request to remove > TIMESTAMP queries, under the assumption that they may be necessary in the > future. > > Kirill, please adjust your code to query for the number of bits in > TIMESTAMP queries, and choose your implementation strategy based on that. > > -Ken > > > On Wed, Jun 8, 2016 at 3:21 AM, Florian B?sch wrote: > >> It should also be noted that although timer queries are not part of >> OpenGL ES 2.0, 3.0, 3.1 or 3.2 core profiles, they are part of OpenGL 4.0, >> 4.1, 4.2, 4.3, 4.4, 4.5 and Vulkan 1.0, including TIMESTAMP and precision >> queries. It is to be expected that OpenGL ES 4.0 will include elapsed and >> timestamp queries in its core profile. It is also the case that TIMESTAMP >> queries are the only queries supported in Direct3D 12, and that elapsed >> queries are emulated on Direct3D via timestamps. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Jun 8 17:02:43 2016 From: kbr...@ (Kenneth Russell) Date: Wed, 8 Jun 2016 17:02:43 -0700 Subject: [Public WebGL] Proposal: remove TIMESTAMP_EXT functionality from WebGL's EXT_disjoint_timer_query wrapper In-Reply-To: References: <2287601465371624@webcorp02g.yandex-team.ru> Message-ID: Thanks, good suggestion. https://github.com/KhronosGroup/WebGL/pull/1759 On Wed, Jun 8, 2016 at 3:24 PM, Florian B?sch wrote: > Maybe non-formative language could be added to the specification in the > examples section that illustrates how to use the precision bits. > > On Wed, Jun 8, 2016 at 11:43 PM, Kenneth Russell wrote: > >> OK. Thanks Florian for pointing this out. I'll drop the request to remove >> TIMESTAMP queries, under the assumption that they may be necessary in the >> future. >> >> Kirill, please adjust your code to query for the number of bits in >> TIMESTAMP queries, and choose your implementation strategy based on that. >> >> -Ken >> >> >> On Wed, Jun 8, 2016 at 3:21 AM, Florian B?sch wrote: >> >>> It should also be noted that although timer queries are not part of >>> OpenGL ES 2.0, 3.0, 3.1 or 3.2 core profiles, they are part of OpenGL 4.0, >>> 4.1, 4.2, 4.3, 4.4, 4.5 and Vulkan 1.0, including TIMESTAMP and precision >>> queries. It is to be expected that OpenGL ES 4.0 will include elapsed and >>> timestamp queries in its core profile. It is also the case that TIMESTAMP >>> queries are the only queries supported in Direct3D 12, and that elapsed >>> queries are emulated on Direct3D via timestamps. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Thu Jun 9 02:33:03 2016 From: dmi...@ (Kirill Dmitrenko) Date: Thu, 09 Jun 2016 12:33:03 +0300 Subject: [Public WebGL] Proposal: remove TIMESTAMP_EXT functionality from WebGL's EXT_disjoint_timer_query wrapper In-Reply-To: References: <2287601465371624@webcorp02g.yandex-team.ru> Message-ID: <772361465464783@webcorp01e.yandex-team.ru> An HTML attachment was scrubbed... URL: From kbr...@ Fri Jun 10 17:06:39 2016 From: kbr...@ (Kenneth Russell) Date: Fri, 10 Jun 2016 17:06:39 -0700 Subject: [Public WebGL] Call for demos and participation: SIGGRAPH 2016 WebGL and glTF BOF Message-ID: [cross-posted to webgl-dev-list] WebGL community, Khronos will host a joint WebGL and glTF BOF at SIGGRAPH 2016 and we would like to invite you all to participate! Date: Wednesday, July 27, 2016 Time: 1:00 PM - 2:30 PM Location: Ballroom A Hilton Anaheim 777 W. Convention Way Anaheim, CA The format of the BOF will be a series of lightning talks, followed by Q&A. If you have a leading edge WebGL demonstration to share with the community, please email me directly to be added to the agenda. Khronos will host an after-party later in the evening, as well as many other BOFs throughout the day. For more details, please see: https://www.khronos.org/news/events/2016-siggraph Looking forward to seeing you there! -Ken -------------- next part -------------- An HTML attachment was scrubbed... URL: From chr...@ Mon Jun 13 12:46:41 2016 From: chr...@ (Christophe Riccio) Date: Mon, 13 Jun 2016 21:46:41 +0200 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb Message-ID: Hi community! I ran on a case where DXT textures are supported, sRGB textures are supported but sRGB DXT textures are not supported. This is pretty unfortunate because it makes supporting linear rendering more complicated than it should while hardware that support both DXT textures and sRGB textures should actually support sRGB DXT textures. As a result, I wrote a proposal (including more details!) for which I would enjoy reviews and feedback. Thanks! Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Jun 13 15:51:56 2016 From: kbr...@ (Kenneth Russell) Date: Mon, 13 Jun 2016 15:51:56 -0700 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: Message-ID: Thanks Christophe for putting together this proposal. It can be viewed at https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_compressed_texture_s3tc_srgb/ . It looks good overall. One minor question: in the underlying EXT_sRGB extension spec: https://www.opengl.org/registry/specs/EXT/texture_sRGB.txt issue 22 says: "Should the new COMPRESSED_SRGB_* formats be listed in an implementation's GL_COMPRESSED_TEXTURE_FORMATS list?" I think the behavior defined in your proposal -- adding these formats to that list -- is better than that defined by the native extension, but do you think there's any compatibility risk? Thanks, -Ken On Mon, Jun 13, 2016 at 12:46 PM, Christophe Riccio < christophe.riccio...@> wrote: > Hi community! > > I ran on a case where DXT textures are supported, sRGB textures are > supported but sRGB DXT textures are not supported. > > This is pretty unfortunate because it makes supporting linear rendering > more complicated > than it should while hardware that support both DXT textures and sRGB > textures should actually support sRGB DXT textures. > > As a result, I wrote a proposal > (including more > details!) for which I would enjoy reviews and feedback. > > Thanks! > Christophe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Jun 14 00:06:00 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 14 Jun 2016 09:06:00 +0200 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: Message-ID: I think your proposal is important, but I'd like to comment on the other thing you said. On Mon, Jun 13, 2016 at 9:46 PM, Christophe Riccio < christophe.riccio...@> wrote: > > This is pretty unfortunate because it makes supporting linear rendering > more complicated > than it should > All output ultimately written to gl_FragColor (when no framebuffer is bound) is in gamma space (which typically means sRGB gamma). You can gamma encode your colors prior to writing to gl_FragColor, and both simple gamma or sRGB are implementable in GLSL easily and the overhead on any device is negible. The one thing you cannot do in this fashion is blending (which can take the form of alpha blending, additive blending, subtractive blending and blending due to anti-aliasing). Multiplicative blending is possible however (at least for simple gamma) because a = (b*c)^2 = b^2 * c^2. Rendering to an sRGB (compressed or not) texture takes your rendering out of the frontbuffer and puts it in a framebuffer object. In the framebuffer object, you have no MSAA (at least in WebGL 1.0). So a source of blending artifacts (MSAA) falls away. That leaves other blending artifacts for which linear space might be beneficial, and for that it is a good choice. But you've still given up MSAA, which in the scheme of things, is probably the bigger loss than having blending artifacts. In WebGL 2.0 you will not suffer from this, because you can instantiate a framebuffer object with MSAA. However, due to support levels, you will have to support WebGL 1.0 for a fairly long while, and so the problem for WebGL 1.0 remains. A possible solution would be to backport the necessary extensions to get MSAA'ed framebuffer objects in WebGL 1.0 (although their introduction is likely to also lag behind in implementation for most vendors, so it's dubious if the support level of such an extension would be any better than the support level of WebGL 2.0). Regardless of these consideration, sRGB is not HDR (it's in fact slightly worse than LDR, too, because of narrow gamut clamping of that colorspace). In many use-cases of linear space rendering, you might have a need for an HDR color representation in a source or intermediate texture. The only form of HDR color representation that currently works with blending and anti-aliasing and in linear space artifact free are floating point textures (which may carry prohibitive bandwidth/performance impacts, especially on mobiles). Alternatives to floating point are schemes such as LogLuv, RGBE, RGBM, etc. They vary in tradeoffs, but they all share the common characteristic that they have blending artifacts. What they also share with floating point textures is that they're not compressed. Although you can shove LDR content into compressed sRGB textures, this will not work well for HDR content, because the high dynamic range will make block-encodings much more visible. What is currently completely lacking in any way, shape or form, both in WebGL 1 and WebGL 2, would be a format that can: - Do HDR - Is correctly blendable - Is correctly interpolatable - Can be rendered to - Can be compressed - Can be rendered to when compressed - Can have MSAA I don't know what that should be, or how it would look, but I'd really like to have it :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Tue Jun 14 02:20:49 2016 From: dmi...@ (Kirill Dmitrenko) Date: Tue, 14 Jun 2016 12:20:49 +0300 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: Message-ID: <569011465896049@webcorp02f.yandex-team.ru> An HTML attachment was scrubbed... URL: From pya...@ Tue Jun 14 03:08:44 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 14 Jun 2016 12:08:44 +0200 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: <569011465896049@webcorp02f.yandex-team.ru> References: <569011465896049@webcorp02f.yandex-team.ru> Message-ID: On Tue, Jun 14, 2016 at 11:20 AM, Kirill Dmitrenko wrote: > > If you're referring to WebGL (and WebGL 2 for that matter), is there any > info backing this statement? Because it seems to be not specified in either > spec, and, moreover, browsers seem to threat image data differently (both > recieved from a server and rendered with WebGL). There was an endeavour to > specify browsers behaviour regarding gamma correction on decoding images > for textures and compositing WebGL content to a page. But as far as I can > tell, it has never gotten anywhere. > Gamma exists for two related, but ultimately independent reasons. 1. CRT display technology (which was mankind's first display technology) used phosphorescence to produce light. To produce a picture an electron beam emitted by what is known as electron gun, was electromagnetically guided over the display panel. The electron source was cathode ray tube, which is a form of amplifying vacuum tube. These tubes (also known as triodes) have a nonlinear relationship to the voltage applied and the electrons emitted. 2. The human eye under normal lighting conditions has a response to light that is able to distinguish shades of dark easier than shades of bright. These two facts combined in a lucky union to create what is known as "gamma space". Lucky, because it allows a form of compression of the signal (be it analog or digital) where a smaller portion of the signal is used to express differences in higher luminances and more is used to express differences in lower luminances, hence improving the quality of the display, while simultaneously building the necessary "decoding" into the physics of the display device at no additional cost. Variance in gamma curves (and display gamut) became a problem however. And by 1996 Microsoft and HP in collaboration with many other industry partners introduced sRGB. A combined colorspace and gammaspace that was designed to fit CRTs of the period. This became the de-facto standard for color exchange between devices and CRTs. Due to a complete lack of the management of colorspaces and gamma curves between devices and displays, this later turned out to be a problem for alternative displays such as TFTs, which did not share the CRT inherent technical reasons for gamma and gamut, and did in fact physically surpass CRTs in luminance response, luminance accuracy and gamut reproduction considerably. However due to the fact that TFTs entered a field that was dominated by CRTs, which all serviced a de-facto standard that was below the technical abilities of the TFTs, TFTs had no choice but to adopt an (electronic) emulation of sRGB because that was the signal they got from devices. To this day there does not exist any way for displays and devices to inter-operate to discover gamma curves, gamut coverage and precision. Consequently there does not exist any way for applications to communicate those properties with the host operating system. For this reason, graphics APIs leave this property wholly unspecified, and it is implied that what you output has to be in gamma space, which most probably means sRGB. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Tue Jun 14 03:55:31 2016 From: dmi...@ (Kirill Dmitrenko) Date: Tue, 14 Jun 2016 13:55:31 +0300 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: <569011465896049@webcorp02f.yandex-team.ru> Message-ID: <497731465901731@webcorp02d.yandex-team.ru> An HTML attachment was scrubbed... URL: From pya...@ Tue Jun 14 04:07:02 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 14 Jun 2016 13:07:02 +0200 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: <497731465901731@webcorp02d.yandex-team.ru> References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> Message-ID: On Tue, Jun 14, 2016 at 12:55 PM, Kirill Dmitrenko 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmi...@ Tue Jun 14 06:11:38 2016 From: dmi...@ (Kirill Dmitrenko) Date: Tue, 14 Jun 2016 16:11:38 +0300 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> Message-ID: <535291465909898@webcorp02d.yandex-team.ru> 14.06.2016, 14:07, "Florian B?sch" : > On Tue, Jun 14, 2016 at 12:55 PM, Kirill Dmitrenko 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. 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. > 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. -- Kirill Dmitrenko Yandex Maps Team ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Jun 14 06:19:04 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Tue, 14 Jun 2016 15:19:04 +0200 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: <535291465909898@webcorp02d.yandex-team.ru> References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> <535291465909898@webcorp02d.yandex-team.ru> Message-ID: On Tue, Jun 14, 2016 at 3:11 PM, Kirill Dmitrenko 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: From chr...@ Tue Jun 14 07:37:58 2016 From: chr...@ (Christophe Riccio) Date: Tue, 14 Jun 2016 16:37:58 +0200 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> <535291465909898@webcorp02d.yandex-team.ru> Message-ID: 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. @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 wrote: > On Tue, Jun 14, 2016 at 3:11 PM, Kirill Dmitrenko > 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: From khr...@ Tue Jun 14 18:47:18 2016 From: khr...@ (Mark Callow) Date: Wed, 15 Jun 2016 10:47:18 +0900 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> <535291465909898@webcorp02d.yandex-team.ru> Message-ID: There is a canvas color space proposal under development for both WebGL and 2D canvases. It describes some of the issues with the current situation as well as a solution. The proposal is being discussed here . It is imprecise to say that gl_FragColor is in gamma space. BTW, this is the first time I have heard it called gamma space. I like to think of it as compressed or non-linear space. Values written to gl_FragColor, OpenGL ES 2 and WebGL 1, or user-defined color outputs, OpenGL ES 3 and WebGL 2, are in linear space. If the the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is SRGB then the values will be compressed to non-linear before being written to the framebuffer. Otherwise they are written as is. WebGL 1 & OpenGl ES 2 do not support sRGB rendering so the values are written as is. The framebuffer is therefore considered to hold linear data and its values should be compressed to non-linear (a.k.a. gamma corrected) by the browser or window/operating system before being sent to the display, assuming a non-linear display. Unfortunately browsers differ in how they handle this and, especially on mobile devices, it is unclear which if any OSes apply gamma correction. Only in cases where no gamma correction is applied can the values written to gl_FragColor be considered to be in non-linear space. The canvas color space proposal together with sRGB rendering support is intended to resolve these and other color space issues. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Wed Jun 15 01:23:39 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 15 Jun 2016 10:23:39 +0200 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> <535291465909898@webcorp02d.yandex-team.ru> Message-ID: On Wed, Jun 15, 2016 at 3:47 AM, Mark Callow wrote: > > There is a canvas color space proposal > under > development for both WebGL and 2D canvases. It describes some of the issues > with the current situation as well as a solution. The proposal is being > discussed here > > . > > It is imprecise to say that gl_FragColor is in gamma space. > That's correct, you will find no specification of any kind of nonlinear space in GL. Therefore the space is undefined. You will however find this: *Similarly, display of framebuffer contents on a monitor or LCD panel > (including the transformation of individual framebuffer values by such > techniques as gamma correction) is not addressed by the GL* OpenGL ES 2.0, Section 2.1. You will also find this in EGL 1.5: > EGL itself does not distinguish multiple colorspace models > Although some mentions are made to framebuffers (not objects) with the sRGB colorspace to be understood. Which is logical. However EGL contains no mechanism to discover a displays colorspace. BTW, this is the first time I have heard it called gamma space. > - http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html "capture images in gamma (nonlinear) space", though referred trough the rest of the article as "nonlinear [color] space". - https://en.wikipedia.org/wiki/Gamma_correction " converting from and to a gamma colorspace", though often used more precise, such as sRGB colorspace, etc. I like to think of it as compressed or non-linear space. > It's synonyms for the same thing: - gamma space - gamma colorspace - sRGB colorspace - nonlinear space - etc. They're all compressed. They're all nonlinear. Use whatever you like to describe them. Values written to gl_FragColor, OpenGL ES 2 and WebGL 1, or user-defined > color outputs, OpenGL ES 3 and WebGL 2, are in linear space. > They're in the space that's passed trough, which almost always is nonlinear space, however the space itself is undefined, and we assume it is nonlinear, and most likely sRGB. > If the the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is SRGB then > 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. The latter of which WebGL has, the former of which it doesn't (at least not explicitely). Framebuffers are constructs intended to communicate with the compositor/windowing system which might (but most of the time does not) have knowledge of a displays colorspace. It's therefore the case that sRGB framebuffers are interpreted correctly by the EGL specification. This provision does not in any way apply to framebuffer *objects*, which are offscreen and are interoperated with by way of a texture. This texture itself being in sRGB has some meaning, but the distinction has nothing todo with the colorspace itself. The functional difference between gl_FragColor.rgb = gamma(someColor); vs gl_FragColor.rgb = someColor (assuming an sRGB texture is attached to the framebuffer object is this): 1. Blending is defined as a mathematical operation and two weights, such as a*(1-x) + b*x (aka alpha blending). If you're adding two values in nonlinear space, the result is not the same as when you do it in linear space. An sRGB texture attached framebuffer will decode the destination nonlinear color to linear, perform blending with the source linear color, and write the result linear value to the nonlinear backing store. An ordinary texture does not do this. 2. MSAA, which uses multiple samples at primitive edges, uses a weighted average of some kind or other to compute an output color based on a destination color and a bunch of source values, based on depth coverage. This is a form of blending, and it suffers the same problem as blending (see explanation of blending problem at point #1) 3. Alpha to coverage blends between a destination and source color based on the coverage indicated by alpha, and so will suffer the same problem as blending (see point #1) The functional difference between texture2D(somesRGBtexture, uv).rgb and degamma(texture2D(ordinaryTexture).rgb) is that: - For bilinear interpolation 4 texels are consulted which are mixed (a*(1-x) + b*x) based on the fractional distance of the UV coordinate to the texel centroid. If the texture is sRGB, the consulted texels are decoded first into linear space, and then mixed. This is not the case with an ordinary texture. So the result (as explained in #1 from before) is incorrect. - Mipmapping consults two layers of a texture and mixes them together, this suffers the same problem as explained in #1 from before). - Anisotropic filtering performs additional computation (most often implemented as dFdx and dFdy independent mip-levels), and that would suffer the same problem as explained in point #1 from before. You can generalize this with a relatively simple statement. The main advantage (ideally, but not guaranteed) of sRGB textures attached to framebuffer *objects* is that: - All forms of mixing colors into and out of sRGB textures is done in the correct order of: mix -> encode -> store / lookup -> decode -> mix - All forms of manual gamma handling performs all operations in the incorrect order as in: encode -> mix -> store / lookup -> mix -> decode WebGL 1 & OpenGl ES 2 do not support sRGB rendering so the values are > written as is. > The *core* WebGL1/ES2 specifciation does not. The extension EXT_sRGB however does (and it is available in WebGL 1). The specification of this extension states that: If the currently bound texture's internal format is one of SRGB_EXT or SRGB_ALPHA_EXT the red, green, and blue components are converted from an sRGB color space to a linear color space as part of filtering described in sections 3.7.7 and 3.7.8. Any alpha component is left unchanged. Ideally, implementations should perform this color conversion on each sample prior to filtering but implementations are allowed to perform this conversion after filtering (though this post-filtering approach is inferior to converting from sRGB prior to filtering). The definitions for blending are more strict and do state that conversion has to occur in the right order. The framebuffer is therefore considered to hold linear data and its values > should be compressed to non-linear (a.k.a. gamma corrected) by the browser > or window/operating system before being sent to the display, > Incorrect. The browser operates colorspace agnostically, and truthfully, so do operating systems. There is the notion of color profile, but this is an additional user-defined transformation that cannot be queried by applications and is applied automatically regardless (and independently of) the source values colorspace, of which the OS knows nothing. > assuming a non-linear display. > There are no linear displays, see history lesson from a few messages back. > Unfortunately browsers differ in how they handle this > They do not differ, they are agnostic, which means, they're not performing any conversion. > and, especially on mobile devices, > Mobile devices are no different than any other machine in that context, they might have color profiles for their display, but they are source colorspace ignorant. > it is unclear which if any OSes apply gamma correction. > None do. Color profiles are applied (brightness, contrast, gamut, etc.), colorspace conversion on output is not. > Only in cases where no gamma correction is applied can the values written > to gl_FragColor be considered to be in non-linear space. > If gl_FragColor means a framebuffer (not an object), you will always have to apply gamma correction. There is two mechanisms for this, one of which does not exist in WebGL1 or 2. That is an sRGB framebuffer, which WebGL1 and 2 do not have. > 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. None of the wire protocols in existence to talk to monitor have any provision to discover a displays gamut and gamma. So the idea of using "the full gamut" of a display is illusory, as what's happening in practice is that a limited sRGB colorspace expressed in 8-bits per channel, gets stretched out into the displays colorspace, which leads to banding and a reduction in color precision. A true solution to this problem cannot be achieved by a new canvas specification. And in any case, the browser operates colorspace agnostically, and so does the OS, and so does the display, which in practice means the canvas colorspace is irrelevant, because it's always sRGB. -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Wed Jun 15 02:45:46 2016 From: khr...@ (Mark Callow) Date: Wed, 15 Jun 2016 18:45:46 +0900 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> <535291465909898@webcorp02d.yandex-team.ru> Message-ID: <4BA6EF6A-CA49-4280-B57D-BE85AFC6E2CF@callow.im> I don?t need the lecture and I am not going to get involved in more nitpicking. However 2 things need to be pointed out. > On Jun 15, 2016, at 5:23 PM, Florian B?sch wrote: > > > If the the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is SRGB then 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 EGL_GL_COLORSPACE of EGL_GL_COLORSPACE_SRGB and FBOs having an sRGB texture as color attachment will have a FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING of sRGB. > > > 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. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Wed Jun 15 03:00:53 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 15 Jun 2016 12:00:53 +0200 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: <4BA6EF6A-CA49-4280-B57D-BE85AFC6E2CF@callow.im> References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> <535291465909898@webcorp02d.yandex-team.ru> <4BA6EF6A-CA49-4280-B57D-BE85AFC6E2CF@callow.im> Message-ID: On Wed, Jun 15, 2016 at 11:45 AM, Mark Callow wrote: > On Jun 15, 2016, at 5:23 PM, Florian B?sch wrote: > > > >> If the the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is SRGB then >> 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 > EGL_GL_COLORSPACE of EGL_GL_COLORSPACE_SRGB and FBOs having an sRGB texture > 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 do). -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Jun 15 03:13:26 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 15 Jun 2016 12:13:26 +0200 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> <535291465909898@webcorp02d.yandex-team.ru> <4BA6EF6A-CA49-4280-B57D-BE85AFC6E2CF@callow.im> Message-ID: And I need to add, a true solution to the entire problem should be to pass a linear space 16-bit per channel luminance value to the GPU, and the GPU negotiates with the display device how that is to reproduce. It's a true solution because a LDR 16-bit per channel value is sufficiently fine-grained to avoid banding issues, and the GPU negotiating how to reproduce it on display is a transparent abstraction to the application programmer, so it's ideal to reduce complexity. On Wed, Jun 15, 2016 at 12:00 PM, Florian B?sch wrote: > On Wed, Jun 15, 2016 at 11:45 AM, Mark Callow wrote: > >> On Jun 15, 2016, at 5:23 PM, Florian B?sch wrote: >> >> >> >>> If the the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is SRGB then >>> 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 >> EGL_GL_COLORSPACE of EGL_GL_COLORSPACE_SRGB and FBOs having an sRGB texture >> 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 > do). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Wed Jun 15 03:19:03 2016 From: khr...@ (Mark Callow) Date: Wed, 15 Jun 2016 19:19:03 +0900 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> <535291465909898@webcorp02d.yandex-team.ru> <4BA6EF6A-CA49-4280-B57D-BE85AFC6E2CF@callow.im> Message-ID: <36B9B1F4-D220-47B9-B8D8-62948D6A1E37@callow.im> > On Jun 15, 2016, at 7:00 PM, Florian B?sch wrote: > > 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. A solution is for the browser to use an sRGB default framebuffer for its final output. It can use linear or sRGB textures for the canvas backing stores and page backing store as it wishes (ignoring issues of backward compatibility with the current broken situation). The GPU will convert everything to linear during compositing and back to sRGB again when writing the composited result. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From khr...@ Wed Jun 15 03:21:49 2016 From: khr...@ (Mark Callow) Date: Wed, 15 Jun 2016 19:21:49 +0900 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> <535291465909898@webcorp02d.yandex-team.ru> <4BA6EF6A-CA49-4280-B57D-BE85AFC6E2CF@callow.im> Message-ID: > On Jun 15, 2016, at 7:13 PM, Florian B?sch wrote: > > And I need to add, a true solution to the entire problem should be to pass a linear space 16-bit per channel luminance value to the GPU, and the GPU negotiates with the display device how that is to reproduce. It's a true solution because a LDR 16-bit per channel value is sufficiently fine-grained to avoid banding issues, and the GPU negotiating how to reproduce it on display is a transparent abstraction to the application programmer, so it's ideal to reduce complexity. > It seems you haven?t read at the proposal yet. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pya...@ Wed Jun 15 03:25:09 2016 From: pya...@ (=?UTF-8?Q?Florian_B=C3=B6sch?=) Date: Wed, 15 Jun 2016 12:25:09 +0200 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: <36B9B1F4-D220-47B9-B8D8-62948D6A1E37@callow.im> References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> <535291465909898@webcorp02d.yandex-team.ru> <4BA6EF6A-CA49-4280-B57D-BE85AFC6E2CF@callow.im> <36B9B1F4-D220-47B9-B8D8-62948D6A1E37@callow.im> Message-ID: On Wed, Jun 15, 2016 at 12:19 PM, Mark Callow wrote: > > A solution is for the browser to use an sRGB default framebuffer for its > final output. It can use linear or sRGB textures for the canvas backing > stores and page backing store as it wishes (ignoring issues of backward > compatibility with the current broken situation). > You cannot ignore backwards compatibility for this case. So if you want an sRGB convention for the front framebuffer for WebGL, it has to be explicit and opt-in. You could do that with context creation attributes. > The GPU will convert everything to linear during compositing and back to > sRGB again when writing the composited result. > Browsers are colorspace agnostic, if you where to define the browsers compositor as linear space, there would be all kinds of problems with color reproduction because people have tuned all their color values to work with the non linear space compositing, so that's not going to happen. The most realistic thing to happen is just that sRGB is passed trough correctly from the frontbuffer. But I need to point out, that exactly this "shunting" trough sRGB is part of the problem in color reproduction. It's better than what currently happens, sure, but it's not better than what I suggested (explicitely defining a high precision linear space frontbuffer, also as an opt-in mechanism). Although I'm aware that also puts the browsers compositor into a difficult position (because now it'd need to composit everything that way as well). -------------- next part -------------- An HTML attachment was scrubbed... URL: From khr...@ Wed Jun 15 05:57:47 2016 From: khr...@ (Mark Callow) Date: Wed, 15 Jun 2016 21:57:47 +0900 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> <535291465909898@webcorp02d.yandex-team.ru> <4BA6EF6A-CA49-4280-B57D-BE85AFC6E2CF@callow.im> <36B9B1F4-D220-47B9-B8D8-62948D6A1E37@callow.im> Message-ID: > On Jun 15, 2016, at 7:25 PM, Florian B?sch wrote: > > On Wed, Jun 15, 2016 at 12:19 PM, Mark Callow > wrote: > A solution is for the browser to use an sRGB default framebuffer for its final output. It can use linear or sRGB textures for the canvas backing stores and page backing store as it wishes (ignoring issues of backward compatibility with the current broken situation). > You cannot ignore backwards compatibility for this case. I added the parenthetical expression precisely because I know that you can?t ignore backwards compatibility. > So if you want an sRGB convention for the front framebuffer for WebGL, it has to be explicit and opt-in. You could do that with context creation attributes. Try reading the proposal. You might find that this is exactly what is proposed. > > The GPU will convert everything to linear during compositing and back to sRGB again when writing the composited result. > Browsers are colorspace agnostic, if you where to define the browsers compositor as linear space, there would be all kinds of problems with color reproduction because people have tuned all their color values to work with the non linear space compositing, so that's not going to happen. The most realistic thing to happen is just that sRGB is passed trough correctly from the frontbuffer. Hence opt-in. > > But I need to point out, that exactly this "shunting" trough sRGB is part of the problem in color reproduction. It's better than what currently happens, sure, but it's not better than what I suggested (explicitely defining a high precision linear space frontbuffer, also as an opt-in mechanism). Although I'm aware that also puts the browsers compositor into a difficult position (because now it'd need to composit everything that way as well). > For LDR displays it is sufficient to do blending in high-precision linear then encode back to sRGB for storage in the frontbuffer, exactly what most sRGB rendering capable GPUs can do today. For HDR high-precision linear is needed and that is one of the opt-in choices in the canvas colorspace proposal. Regards -Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kbr...@ Thu Jun 16 18:35:53 2016 From: kbr...@ (Kenneth Russell) Date: Thu, 16 Jun 2016 18:35:53 -0700 Subject: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb In-Reply-To: References: <569011465896049@webcorp02f.yandex-team.ru> <497731465901731@webcorp02d.yandex-team.ru> <535291465909898@webcorp02d.yandex-team.ru> Message-ID: On Tue, Jun 14, 2016 at 7:37 AM, Christophe Riccio < christophe.riccio...@> 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. -Ken > @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 wrote: > >> On Tue, Jun 14, 2016 at 3:11 PM, Kirill Dmitrenko >> 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: