[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Linear-to-sRGB conversion to the drawing buffer using sRGB extension

Thanks for the requests. We're aware of the need for sRGB on the backbuffer - it's one of Christophe's requests for Unity's linear rendering pipeline as well. In Chrome, color correct rendering is in progress, so we should be able to start working on it pretty soon.

On Mon, Jul 17, 2017 at 7:06 AM Mr F <arthur@playcanvas.com> wrote:
Kai, this is amazing. I really wish it would be supported in more browsers, and the same thing for PVRTC and ETC. Another thing that would be great is to have some kind of WebGL context creation flag that would enable sRGB on the default backbuffer.

On 17 July 2017 at 16:16, Kai Ninomiya <kainino@google.com> wrote:
It's unfortunate that we can't rely on DXT on all platforms. However, Christophe Riccio and I worked on the extension for this use case:
It should be available on Chrome on all desktop platforms at this point.

Of course, more sRGB support may be needed for other compressed textures. If this is something that you would find useful, please let us know.


On Mon, Jul 17, 2017 at 12:49 AM Mr F <arthur@playcanvas.com> wrote:
WebGL 2 seems better sRGB-wise (no extensions needed). However, the only sRGB readable texture format are SRGB8 and SRGB8_ALPHA8... and that means no DXT/PVRTC/ETC/whatever, so it's still useless if you care about memory.

On 16 July 2017 at 12:43, Florian Bösch <pyalot@gmail.com> wrote:
The way this is done is that with the original sRGB extension you can specify the pixel format of framebuffer that is being drawn to. Unfortunately WebGL only exposes the FBO portion of that functionality, because WebGL lacks a way to precisely specify the framebuffer that it draws to.

If you wanted to add that functionality to WebGL you're going to run into a problem that the browsers compositor is not operating in linear space. The canvas is an FBO attached texture, and if it where to be in sRGB format, the compositor would attempt to read out the color, get linear, and splat that to screen unmodified. So if you where to add a way to specify the canvas framebuffer, you also need to touch up the browsers compositor to do the right thing (either re-encode to sRGB or whatever colorspace it uses when it reads from sRGB, or use an sRGB framebuffer itself and let the window compositor do the right thing).

So long story short is, there's presently no way to do it in WebGL, and adding a way may turn out to be more complex than assumed, so what you've got to do is re-encode the linear value manually to sRGB for output. Though the enclosing browser may use a different colorspace and sRGB may not be the right colorspace to output (we also lack color management in WebGL, but I digress).

On Sat, Jul 15, 2017 at 5:14 PM, Oskar Skrinjar <oskar@scientificiv.com> wrote:


I have a question to those who know how to use sRGB extension with WebGL 1.

When I use an image as a texture, if I specify the texture to be sRGB, it seems that it works properly, since the pixel color values get smaller in the fragment shader and if I directly display that texture using a full screen quad, I get a darker version of the image, which should be the case. Thus, the fragment shader gets the colors in the linear space and then I can do processing in the linear space.

I have problems going back from linear values to sRGB values at the end of the processing pipeline, i.e. when I want to render the final result to the drawing buffer. If I directly render the linear color values into the drawing buffer the displayed image looks darker, as expected. Since it is not possible to specify that the drawing buffer does linear-to-sRGB conversion, I tried to use an FBO for that purpose.

If I create an FBO with an sRGB texture as COLOR ATTACHMENT 0, then rendering linear colors into that FBO seems to work properly. E.g. when I write inside the fragment shader a gray value of 54 (R=54, G=54,B=54) into the FBO and then use pixelRead to check the stored value, the stored value in the FBO is (127,127,127), which should be the case. Thus, that FBO stores colors in the sRGB space, as expected.

What I do not know how to do is displaying the content of that FBO to the screen. If I do a “transfer pass”, i.e. use the FBO’s color attachment texture as an input, and read it from a fragment shader and then write the color values into the drawing buffer I end up with linear values. This is because that color attachment texture is sRGB and reading it from a fragment shader converts the values from the sRGB to linear space and the resulting image is darker. Of course, I could do linear-to-sRGB conversion inside the fragment shader, but that is what the sRGB extension should somehow do.

Could someone refer me to examples or explain how to convert linear color values into sRGB color values that end up in the drawing buffer using the sRGB extension. Any help will be appreciated.



Oskar Skrinjar, PhD
Scientific Imaging and Visualization, LLC
Website: http://www.scientificiv.com
Email: oskar@scientificiv.com
Phone: 404 863 2371

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature