Custom tonemapping LUT: Godot `Resource` format that contains both a shader and data for LUT(s)

[MJacred]

Putting this comment into its own proposal to prevent it from becoming lost.

---

Describe the project you are working on

3D Game

Describe the problem or limitation you are having in your project

see #7263 (comment)

and this would allow using Tony McMapface tonemapping…

Tony McMapface is an artist-frendly tonemapper that tries to stay close to the input color and doesn't increase contrast or saturation, leading to a pleasant neutral look that can work as a great easy-to-use alternative to the options currently available
source

Describe the feature / enhancement and how it helps to overcome the problem or limitation

See these comments

• Add Tony McMapface as a tonemapping mode godot#97095 (comment)
• Add Tony McMapface as a tonemapping mode godot#97095 (comment)

would supersede

• Add TonyMcMapface as a tonemapping mode (or allow using custom LUTs for tonemapping) #7263

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

a rephrasing of this:

• have a single Resource format, called "GodotLUT" for simplicity, that contains both
  • a shader and
  • data for LUT texture(s)
• add a "custom tonemapping LUT" to the environment node, where the user can drop the "GodotLUT" resource

Godot could provide a GodotLUT default shader, called e.g. "GodotLUTShader", or provide this shader as an example in a Godot tutorial

At minimum, it should be possible to implement Tony McMapface

About HDR output... Maybe relevant, maybe not, depending on how things get implemented:

• Consider how this will work with HDR output, when that inevitably happens in the future. How will future colour grading (editor tools or user-provided HDR LUT, etc.), glow, etc. interact with this?
• EA Frostbite's HDR colour grading and HDR tone mapping approach has a few points that are good to keep in mind regarding how a future of HDR output might be implemented.

source: godotengine/godot#97095 (comment)

And this about HDR: godotengine/godot#107730

If this enhancement will not be used often, can it be worked around with a few lines of script?

No, as this can't be implemented by a script or shader code without modifying the engine. See below.

Is there a reason why this should be core and not an add-on in the asset library?

see #7263

[Calinou]

Out of curiosity, why do we need a specific Resource type for this? Can't we just add support for running Adjustments's color correction step before tonemapping (instead of after tonemapping like it is now)?

Regarding the shader part of this, this may be better addressed with a post-processing solution like #7849 as long as you have control of whether it runs before or after tonemapping.

[MJacred]

This proposal is based on what @allenwp commented. So I'll try to answer as I understood it:

Out of curiosity, why do we need a specific Resource type for this?

It's for sharing these custom tonemappings, as other people do it with OpenColorIO files.

Can't we just add support for running Adjustments's color correction step before tonemapping (instead of after tonemapping like it is now)?

Probably? I believe the "instead" stems from the desire to have Tony McMapface, which is a tonemapper so the idea sprung from there, and that tonemapper intends to stay as close as possible to the input colour.
Maybe it would be fine if it is put before tonemapping, and tonemapping itself could be disabled?

[allenwp]

Thanks for putting together a proposal @MJacred!

There were a lot of GDC talks back in the 2015-2019(ish?) era that suggested using a LUT texture for tonemapping, similar to Tony McMapface's approach or others. This specifically allows the developer to perform other colour correction and adjustments within the LUT texture and possibly even convolve the inverse EOTF. It allows for an "all in one" approach for SDR games that unlocks the full power of a professional colour grading tool without needing to implement it within the game engine.

Fast forward to today and some things have changed: HDR has become more commonplace (even Nintendo added HDR output support to their latest console) and a new variable "Extended Dynamic Range" paradigm has emerged. Godot will be supporting the variable EDR paradigm, which makes it easy and simple to support SDR, HDR, and everything in between and beyond.

Unfortunately, the old suggested approach for using a texture LUT for tonemapping only works with SDR output and is fundamentally incompatible with the EDR paradigm. Because of this, I no longer believe that officially supporting texture LUTs for tonemapping is the correct path forward for Godot, since these cannot be used with EDR. EDR is used heavily with mobile devices and I expect it will only grow in usage and importance in the upcoming years.

I believe it is still possible to perform custom tonemapping with a custom compositor? I'm not the one to speak on this, so maybe someone else can add some details on how to do this or what needs to be implemented to allow this. A custom engine build is always an option, but this is always implied with an open source project.

Finally, I do want to direct attention to some work I've been doing on adding more customization to tonemappers like AgX and others, which hopefully will mitigate the need for custom tonemappers in Godot. These efforts are built with the EDR paradigm in mind, so they work great with SDR and HDR: godotengine/godot#106940 and godotengine/godot#106696

[MJacred]

Thank you for the overview, @allenwp, much appreciated!
On my end, I was hoping to use Tony to preserve my input colors, as Godot does not support color profile management… If texture LUTs for tonemapping cannot be used with EDR, then this PR is unsuited for a fork and I'm back to square one.

EDIT: if it's possible with a custom compositor, and disables the selected tonemapper, then maybe… but that is beyond my current rendering abilities