Color correction and debanding function incorrectly when HDR 2D is enabled

[allenwp]

Tested versions

• Reproducible in v4.2.stable.official [46dc277], v4.4.1.stable.official [49a5bc7], and current master

System information

Godot v4.2.stable - Windows 10.0.26100 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 980 Ti (NVIDIA; 32.0.15.6109) - 13th Gen Intel(R) Core(TM) i7-13700K (24 Threads)

Issue description

It seems that the HDR 2D project setting causes nonlinear sRGB encoding to not be applied before the Environment color correction effect and the Debanding project setting (rendering/anti_aliasing/quality/use_debanding) are applied. This appears to cause some issues:

Color Correction

If I apply the template 1D gradient and 3D LUT textures to a scene, I get a small change in original scene colour, but when HDR 2D is enabled I get much more significant and unexpected change in scene colour.

LUT Applied	HDR 2D Disabled	HDR 2D Enabled
None (Original Scene)
1D gradient template
3D LUT template

So let's say I use the color correction to adjust my scene by loading a screenshot of my game into an image editor and perform a colour replacement on the blue sky to make all blue colours yellowish orange:

HDR 2D Disabled	HDR 2D Enabled

As seen in the above screenshots, the HDR 2D project setting prevents my color correction adjustment from being applied correctly.

(Originally, I reported this in #107682, but it appears better to separate these into two separate issues.)

Debanding

Another issue with the same root cause can be seen in the Debanding project setting (rendering/anti_aliasing/quality/use_debanding):

Zoomed in portion of above screenshot:

This issue is best seen with the lights turned out: extra noise that does not help with debanding is added to the image because the debanding is applied to a linear-encoded value instead of the expected nonlinear sRGB encoded value. The debanding function can be seen to assume an 8-bit quantization, in our case to nonlinear sRGB, at this line of the function that divides by 255.0. This is obviously a minor issue, but the behaviour with HDR 2D enabled is not the intended behaviour of this debanding function.

Steps to reproduce

• Enable debanding or apply a Color Correction adjustment
• Enable and disable HDR 2D to see there is an unexpected difference in the rendered image

Minimal reproduction project (MRP)

color-correction-debanding-hdr2d.zip

Discussion of solutions

Solving the debanding issue is pretty trivial: debanding should simply only ever be applied directly before quantization.

For color correction, one extremely simple solution that has an impact on performance is to simply apply nonlinear sRGB encoding before color correction and convert back to linear encoding before returning from the tonemapping shader. For reference, I've implemented a quick prototype in a branch of my fork. In the case of color correction and HDR 2D being enabled, this will apply clamping to [0, 1] that wasn't there before -- but I think it makes sense to have this clamping if you're using color correction.

[beicause]

One extremely simple solution that resolves both issues but has an impact on performance is to simply apply nonlinear sRGB encoding before color correction and debanding and convert back to linear encoding before returning from the tonemapping shader

This seems like a good way. Since LUT relies on srgb for lookup, convert to srgb is necessary.

godot/servers/rendering/renderer_rd/renderer_scene_render_rd.cpp

Line 677 in e45cc68

tonemap.color_correction_texture = texture_storage->texture_get_rd_texture(environment_get_color_correction(p_render_data->environment));

Maybe we can get a srgb view of color correction texture if hdr 2d is enabled, which can avoid converting the result back to linear

[allenwp]

When HDR 2D is enabled, I think that the Debanding function should be applied in the blit shader just after this line:

godot/servers/rendering/renderer_rd/shaders/blit.glsl

Line 120 in 5abed52

color.rgb = linear_to_srgb(color.rgb); // Regular linear -> SRGB conversion.

I haven’t tested this, but conceptually this is where this dither function was originally designed to be placed, according to the slides from Valve. This should be a better approach than converting to/from nonlinear sRGB encoding in the tonemap shader. Applying dither in the tonemap shader only makes sense when quantization is happening immediately after.

[allenwp]

I've updated my proof of concept fix to simply apply dithering in blit just before quantization and it works well, but has performance implications, especially for HDR 2D.

Maybe we can get a srgb view of color correction texture if hdr 2d is enabled, which can avoid converting the result back to linear

This is beyond my current understanding of the codebase, so please feel free to look into this approach or any other approach that will be higher performance than what I have in my proof of concept branch.

Edit: Opened a PR: #107782