[reshade] add inverse tonemapping options

[MrLixm]

A simple thing I thought about : the notion of tonemapping is not new in video game and games have been using "tonemapping" for a pretty long time. In big AAA games most of the time you an be sure the displayed result has received some kind of "tonemapping".

This is something we could ideally try to remove because it should be AgX job. Even though applying the tonemapper would lead no magic result, it could allow to perhaps retrieve data in a closer state that what expect AgX.

So the idea would be to implement a new option to select a popular tonemapper transform, and to apply its inverse on the image. Just after the IDT.

resources

• https://github.com/Zackin5/Filmic-Tonemapping-ReShade

[nullfrctl]

Honestly, my man, I get that the whole point is to use AgX, but this specific thing is more suited for an ACES-based workflow.

ACES includes inverse ODTs, AgX doesn't. Simple as that.

There will be no way to get real HDR data back from AgX using a different curve because you can't do a roundtrip. With ACES, you apply the inverse sRGB ODT; apply the ACEScct CSC; grade in ACEScct; go back to ACES AP0; apply the forward sRGB ODT.

If you want a ready-made implementation, you can see reference code in my aces-hlsl project.

[MrLixm]

Hello, thank you for your feedback but I'm not sure you understood the idea I was suggesting.
The goal here is to try to get the most open-domain image data possible (==HDR) out of a closed-domain image data (==SDR), the last one being what we got as input out of ReShade.

The logic is that the game engine have access to this open-domain data, and that usually go through a tonemapping process to produce closed-domain image data (what ReSahde got as input). If we know that tonemapping operation and manage to revert it, we could in theory get back that initial open-domain data.
Of course the catch is that we will not fully recover it even if we perfectly know the tonemapping operations they applied but it's worth a try.

This caveat also apply to the method you are mentioning.
In the following demo I am exporting an ACES2065-1 exr, with the ACES ODT applied, to a 16bit tiff, then reading that tiff and applying the inverse ODT as suggested, and performing a difference with the original.
You can see directly that even without boosting the difference there is quite some data that is lost.

[nullfrctl]

Yeah, I get that there will be a big difference.

However, the difference will equate to naught because we are already outputting to this closed-domain: it's imperceptible, a perceptual roundtrip is possible.

Any inverse tone mapping operation with AgX cannot be applied meeting the criteria of a perceptual roundtrip, because AgX has no official inverse ODT.

[MrLixm]

because AgX has no official inverse ODT

yes and ? not sure I get your point. I never intended to inverse AgX.
Only inverse other famous "tonemappers".

[nullfrctl]

What I'm trying to say is, implementing an inverse tone mapping operation will change the look even with default/passthrough settings. And the domain they are outputting is unknowable, at least with ACES, it's specified and standardized.

[MrLixm]

will change the look

the look of what ? the final game you see with AgX applied ? In that case yes that is expected and intended I guess.

And the domain they are outputting is unknowable

I agree but the goal here is to try to find a "best guess" out of it, to see if it can improve the final rendering. Maybe it will not but it's worth trying.

at least with ACES, it's specified and standardized.

Sorry but I still don't see what ACES has to do here, except that it's potentially a "tonemapper" that one game could use.