So just to be very explicit — this means you are trying to do a 50/50 blend of rgb(0,0,0)
and rgb(0, 127, 255)
, where the two input colors are sRGB, and you want the blending also done in sRGB space. Blending these two colors in sRGB space will produce rgb(0, 63, 127)
(sRGB). Converting them to Linear-sRGB, blending, and then converting back to sRGB will not.
To achieve this, I had to do 2 different things.
- I’ve commented out
.colorSpace = SRGBColorSpace
.- Before returning the color, I wrapped it in
convertColorSpace(result, SRGBColorSpace, LinearSRGBColorSpace)
I’d consider this a fine solution, if you feel comfortable with “why” it works. Step (1) keeps the texture in its original sRGB Space by preventing three.js from decoding it. Then step (2) applies an sRGB decode step right before the automatic three.js encode step, so the two cancel out and have no net effect. As a result, the colors basically remain in sRGB space throughout your render pipeline, all the way from input to the canvas.
Comparing methods (1) and (2), I don’t think a single color conversion is much to worry about performance-wise. If mixing colors in sRGB space is all you need to do then, either should be fine! If you need to also do some lighting or PBR, then keeping the colors mostly in the default Linear-sRGB space and switching to sRGB for specific operations (2) would generally be the best option.