What's this about gammaFactor?

[Friksel]

@looeee

Could you post your sources? The actual WebGL spec doesn’t have anything to say about color spaces.

I already did post it in a previous post here. It’s by webkit about webGL. It’s written in 2016, but it obviously talks about css, svg, webGL 1 and canvas and looks like it’s still pretty present today, at least on the webGL 1 part. This was the link I posted: Webkit: Improving color on the web

The article states:

While CSS handles most of the presentation of an HTML document, there is still one important area which is outside its scope: the canvas element. Both 2D and WebGL canvases assume they operate within the sRGB color space. This means that even on wide-gamut displays, you won’t be able to create a canvas that exercises the full range of color.

I’m not into the core of webGL and I can’t find much info about using color spaces in webGL neither like you. But I’d say webkit is a pretty decent and reliable source. What I do know is how color spaces work, because I put a lot of time last weeks/months deep diving into the matter. And know that the sRGB color space is especially created for internet by Microsoft and HP those days. I also found that both CSS colors as well as SVG colors are already in the sRGB color space. And using sRGB also influences the gamma transfer function which so using sRGB should also mean that all colors used in the browser would be gamma corrected already. So all your stylesheet-colors should be already in sRGB and thus will be gamma-corrected at the end.

So my conclusion so far is that everything in the browser is working with sRGB and that colors will be gamma corrected and browsers expect our images to be in sRGB and already gamma corrected.

The question is now how about webGL. According to the article both 2D canvas as well as webGL (at least v1) are assuming everything to be in sRGB. So that fits with how the rest of the browser handles images. So logical conclusion to me would be that all colors in webGL (at least v1) are working exactly like colors in css and svg, so in sRGB color space. So that they will be gamma corrected by the system automatically. Always. Probably at the stage of rendering writing frames to the canvas.

So than again the conclusion would be that everything is already taken care of on the output. So colors will be in the right sRGB color space with gamma-correction applied, and images are assumed to be in sRGB already and thus gamma corrected already. And according to that article that would also mean that every internal working inside webGL would be in sRGB too and so threejs don’t need to worry about gamma-correction. Not on the input, nor on the output. But again, there’s not much info about how color spaces are implemented exactly on internet.

Yesterday I did another search and found some info of people trying to work linear with Unity on webGL 1. The answer they get was that Unity wan’t able to work linearly with webGL. But I found another source on a Unity Blog that’s writing about that linear support is there now in webGL 2. So this seem to confirm my believe that webGL 1 always works in sRGB and isn’t able to work in linear space. And it would also explain why we can’t find much info on the subject of using color spaces in webGL 1.

So I still have the idea that threejs’s input and output gamma settings are unnececary and they seem to cause behaviour we don’t want. Like applying another gamma correction, although the system probably already does that automatically on itself, probably at renderstage at the end. Just like the rest of the browser does. And that makes sense to me logically. Otherwise webGL would work completely different than the rest of the browser and we should at least know about a setting in webGL to set it to linear or some color space right? So I believe the article of webGL already says it and is still relevant on webGL 1 today.

@donmccurdy

Just like images also css-colors, svg-colors and webgl-colors are in sRGB color space, so absolute.

… I don’t know if there is some setting in webGL to go around the sRGB color space and work linear, but what I find doing a deep search and reading some articles is that webGL is always sRGB. But I’m not sure.

WebGL 1.0 does not have low-level color space settings like more modern graphics APIs, but in practice, libraries like three.js apply gamma correction in shader code and work in linear anyway. There are limitations to that approach (e.g. with precision and compressed textures, I believe?) but nonetheless linear rendering is possible. Setting gammaOutput=true enables per-pixel output gamma correction.

I don’t believe this is true. It looks like Unity wasn’t able to work linearly at first because they relied on webGL1 and they are able to work linear only from webGL 2. Next to this the webkit article says browsers are assuming everything is in sRGB space. It could be indeed that webGL 1 is chosing to convert images automatically to linear space and works linear. But than 1) the gammaInput-property of threejs would be usesless, because it ALWAYS assumes images are in sRGB. And 2) than the gammaOutput-property of threejs would be not needed either, because webGL HAS TO convert everything to sRGB at the end, because everything else on the page works in sRGB and you can’t have multiple color spaces on the same page. Everything should be rendered (at least anno 2018) to the same color space at the end and that’s sRGB in 99.9% of all browsers, because sRGB has the widest support, is meant for internet in the first place and almost all consumer-monitors can’t handle other color spaces.

@donmccurdy

In most cases you can tell the GPU to do [color correction] for you… Most APIs controlling GPUs can be set to automatically apply the proper sRGB conversions when values are read from textures or written to the color buffer. … If you do need to apply sRGB manually, there is a standard conversion equation …

Were did you find this? Is it about webGL 1?
I can’t really tell what they say exactly, but it’s true that we don’t need to have sRGB conversion functions if what I think is true. Because all colors will go through some lookup-table to apply gamma-correction (like css colors and svg colors, maybe they even share the same codebase internally in the browser?) and the webkit-article says that images are assumed to be in sRGB (so gamma-corrected) already, so there’s no need for us to manually apply any conversion to or from sRGB. They only time you could want to convert is when you want to use textures which don’t have the sRGB color space and gamma correction applied, so when images come from another color space, have another gamma transfer function applied, or are linear. So to me this makes sense.