Alternatives to GammaCorrectionEffect
See original GitHub issueI noticed GammaCorrectionEffect
is deprecated, with the message “Set WebGLRenderer.outputEncoding to sRGBEncoding instead.”. The term “gamma” is best avoided in the context of output color space transforms, and three.js is shifting away from that, so +1 for deprecating the effect as it exists today. I also like how this library respects renderer.outputEncoding
, so a strong +1 for that feature too.
However … I think it’s still a good idea to have some way of doing color space conversions in an Effect. Users may not want color correction to be the absolute last stop of their post-processing pipeline, and there quite a few use cases for that. A simple example I’ll suggest here is the existing BrightnessContrastEffect — if you’re doing a lerp/multiplier for contrast (there are more complex methods too, with LUTs or contrast curves…), you probably want to do that in sRGB space and not Linear-sRGB. So a reasonable stack could look something like:
const pass = new EffectPass(camera, [
...
new ColorSpaceTransformEffect(THREE.LinearSRGBColorSpace, THREE.SRGBColorSpace),
new BrightnessContrastEffect(BlendFunction.NORMAL, 0.0, 0.5),
]);
In this example you don’t want an additional color space conversion after the contrast effect. I’m not completely sure how to prevent that, just setting renderer.outputEncoding = LinearEncoding
seems semantically confusing and could have side effects. Possibly EffectPass could do something clever if it sees ColorSpaceTransformEffect in the effects stack with a matching destination color space to renderer.outputEncoding
. 🤔
Issue Analytics
- State:
- Created a year ago
- Comments:6 (6 by maintainers)
Top GitHub Comments
Ohhhh that’s a huge help to know! Thank you, I’d been scratching my head over why some output didn’t look right. I’m in the rare scenario where the input is not sRGB.😱 🙏
Agreed on “automagical” being scary, especially with color spaces. I do prefer explicit configuration here as well. I think the risk I see with
renderer.outputEncoding = LinearEncoding
(in this situation) is that we actually mean “please don’t apply a color space transform when writing to the canvas” … but the final output is really sRGB, not Linear-sRGB. That feels weird but I can’t think of an actual problem at the moment, so maybe it’s fine with the.encodeOutput
option. The option could be promoted to the Pass if needed maybe, but no strong opinion at the moment.Also just a heads up that three.js is mostly switching “encoding” references to “colorSpace” references… I wouldn’t make that change quite yet, but maybe an idea for next major release.
Interesting, didn’t know that. I think
LUTEffect
also has aninputEncoding
setting which issRGBEncoding
by default since most LUTs expect sRGB input colors.It’s possible to disable output encoding via
EffectPass.fullscreenMaterial.encodeOutput = false
.That’s one option, but we should be careful with automagical features. I’d be in favor of letting the user configure things explicitly. And I’m ok with adding a
ColorSpaceTransformEffect
👍 We could explain how to use it in the doc comments and later the new manual.