HI @donmccurdy no problem you got terms wrong; it’s a very confusing subject and there seems to be a lot of wrong information on internet about it that makes it even more confusing.
It’s too much to explain everything here, but in short: a color model, like RGB or CMY, is a description of how colors are made. For RGB we use primaries red, green and blue to do that. So in a color model on internet we say that #000 is black, #FFF is white, #F00 is red and so on. These are numeric values for all possibilities inside that specific color MODEL. #F00 is the redest red in the model, #0F0 the greenest green and #00F the bluest blue. But that’s all we know.
So a color 0x4285f4 doesn’t tell how that color really looks like.
We still don’t know how white looks like, how red the redest red is, the greenest green and the bluest blue, and with that all values in between and mixed. A lot of developer think that #FFF is absolutely white… but you have all kinds of whites. There is no real white. The same goes for red, green and blue. So a color Model is relative, because we don’t know the absolute values for them to describe them.
Without that definition (the color space), these color hex-values look different on different screens. Eventhough the digital values are exactly the same, the device doesn’t know how to translate them into real colors.
That’s why we need color spaces. They describe how to translate these values into real colors. For this we need to define the exact definition of all three primaries in a CIE reference space and also define what we call white. Therefore we call a color space absolute. And if we display the same color values on a different device that supports the color space the image is in, the colors should (idealy) be the same.
With a color space applied now we do know how 0x4285f4 really looks like, because it is defined.
For internet this color space is from the beginning sRGB. But there is a transition going on for browsers being able to support more (wider) color spaces with much more color definition in it, so we can have ‘purer’ primary colors.
I did a dive in on the matter of color on internet according to use/no-use of color spaces to find out if css-color, svg-color and webgl-colors have a color space attached. And it seems they do.
I found, among others, this great article from webkit: https://webkit.org/blog/6682/improving-color-on-the-web/
Just like images also css-colors, svg-colors and webgl-colors are in sRGB color space, so absolute. That also means that these values are already gamma corrected. Or at least they should be, 'cause they are in sRGB space and sRGB means that they have a transfer function (gamma correction) applied.
So that could explain why the vertex colors I use are right if I leave gammaOutput on false and wrong if I apply a transfer function to gamma correct it. Although the resulting colors look too dark to me when I compare it to images I find on the matter of color on wikipedia, which I take seriously because these people write on the matter themselves, so I’m not fully convinced.
So to go back to threejs… I don’t know about the core of WebGL like you guys do, so 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.
So it looks like webGL and canvas are always in the sRGB color space. If that’s true it means that there’s no way we can work linear in webGL. And if that’s the case than making textures linear at import doesn’t make any sense and putting the renderer to enable gammaCorrection is always wrong, because everything is already is sRGB color space and so already gamma-corrected. So if webGL always works in sRGB the whole renderer.gammaOutput and renderer.gammaFactor thing arn’t working as supposed to do. And a conversion at importing images should only be needed if we import images which are not in sRGB color space. To make them sRGB. But again, maybe there is a setting in webGL to make webGL work in linear space. But I couldn’t find anything about that so far.
And than we have CSS-colors and SVG-colors. CSS-colors and SVG-colors seems to be two different modules. CSS-colors are in sRGB space and so are SVG-colors.
But they are working on CSS Colors level 4 and that has some real interesting additions to apply other colors spaces!!
Read this: https://www.w3.org/TR/css-color-4/#sRGB
There will be a setting to set a full html-document in a different color space. And there will be even a css way of importing custom color profiles! So that means we could work in all existing color spaces!
Next to this we can define a color to be in a special color space. And there will be even media queries to check for color space support on that browser/device, also within the element so we can load different pictures for different color spaces. Also SVG has (already) some support for different colorspaces, but version 2 seems to take years to finally be implemented.
Anyway, this will be a huge improvement on internet and it’s the next big step to go to visual quality after the web changed to high-definition/retina/hi-resolution screens.
So to conclude: I’m not sure if the vertexcolors are right, because they look much brighter on examples online, but it seems like webGL is doing everything in sRGB already and so gamma-correction at the renderer should be never needed as far as I can find information about it at least in webGL 1. And if that’s true it means that working linear isn’t possible, just because and are always in sRGB color space.
Food for thought…