Alternatives to GammaCorrectionEffect

I 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. 🤔

[donmccurdy]

I think LUTEffect also has an inputEncoding setting which is sRGBEncoding by default since most LUTs expect sRGB input colors…

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.😱 🙏

…That’s one option, but we should be careful with automagical features.

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.

[vanruesc]

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

Interesting, didn’t know that. I think LUTEffect also has an inputEncoding setting which is sRGBEncoding by default since most LUTs expect sRGB input colors.

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.

It’s possible to disable output encoding via EffectPass.fullscreenMaterial.encodeOutput = false.

Possibly EffectPass could do something clever if it sees ColorSpaceTransformEffect

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.