Add dithering

[HybridDog]

Goal:
Add dithering to reduce banding artifacts

How does it work:
Dithering is disabled by default and can be enabled with a setting.
It is applied in the second-stage shader and uses the algorithm supplied by Calinou.

Does it resolve any reported issue?

I don't think there's an issue about this.

If not a bug fix, why is this PR needed? What usecases does it solve?

On some displays, banding is easily noticeable in Minetest.
Dithering before the quantisation to 8 bits can prevent banding artifacts
and an implementation requires only a few lines of code.

How to test

It may be difficult to see banding on some screens because 8x8x8 bit colours are already a lot possible values.

Disabled dithering (current behaviour):

Edited with GIMP to show the bands:

Enabled dithering:

Edited with GIMP to show the dithering pattern:

Please look at the pictures in 1:1 scaling or upscaled by an integer factor without interpolation, and ideally with a black background instead of the white Github page background.

[sfan5]

This is just a static dither pattern so I wouldn't call it debanding (though it does have that effect).
The effect is also very subtle, so I'm not sure if this PR is worth it.

[HybridDog]

This is just a static dither pattern so I wouldn't call it debanding (though it does have that effect).

The dithering is caused by rounding after the values are changed in a chessboard pattern. Do you have a suggestion on how I could call the setting?

The effect is also very subtle, so I'm not sure if this PR is worth it.

In my experience, banding is easy to see when the screen brightness is very high and you look at a stone node in a dim cave.
The dithering is optional and fairly simply (not very much code); nonetheless, it mitigates banding (when I test it).

[Calinou]

I don't remember seeing banding in Minetest, but the implementation looks simple enough. Out of curiosity, what's the performance impact like?

[HybridDog]

Out of curiosity, what's the performance impact like?

I don't know. How can I measure it?

[Calinou]

@HybridDog Measure the FPS in a complex scene before and after enabling it 🙂

[paramat]

I am not convinced it is worth adding, seeing banding is apparently rare (i never have) and when you do it is probably very subtle and not a problem.
👎

[HybridDog]

Measure the FPS in a complex scene before and after enabling it slightly_smiling_face

I've tested it and didn't notice any difference. It was about 40 FPS with and without the dithering.

I am not convinced it is worth adding, seeing banding is apparently rare (i never have) and when you do it is probably very subtle and not a problem.

I often see subtle banding in minetest when I look closely. This is not a problem, but the simple debanding effect is optional and it slightly increases the visual quality without noticeable performance loss.

[paramat]

But it also adds to review, testing, bugfixing and maintenance workload, and to code complexity, for near-zero benefit. I think this is what sfan5 means by 'worth it'.

[HybridDog]

But it also adds to review, testing, bugfixing and maintenance workload, and to code complexity, for near-zero benefit.

The code for this is very simple, so I think there's not much to review and maintenance, and if there's a bug, you can simply disable the setting or remove the feature. Testing it also shouldn't be difficult.

[benrob0329]

My issue is that if it significantly increases screenshot size, then it probably also increases video file size. So I'll never use this, and more than likely neither will other content creators because recording MT already produces huge video files.

Then, if it's also disabled by default, and a large portion of our user-base either don't look at settings, or disable shaders anyways, why add it in the first place?

[HybridDog]

My issue is that if it significantly increases screenshot size, then it probably also increases video file size.

It should only affect lossless compression.

Then, if it's also disabled by default, and a large portion of our user-base either don't look at settings, or disable shaders anyways, why add it in the first place?

It is just a small feature, so there's not much to be added.
Since the shaders path can be configured, it is alternatively possible to add the dithering to a custom shader fragment code.

[Calinou]

If anyone is interested in reviving this PR or distributing a third-party shader to provide this feature, note that you can use a more effective algorithm which is still pretty cheap: godotengine/godot#42942

// From http://alex.vlachos.com/graphics/Alex_Vlachos_Advanced_VR_Rendering_GDC2015.pdf
// and https://www.shadertoy.com/view/MslGR8 (5th one starting from the bottom)
// NOTE: `frag_coord` is in pixels (i.e. not normalized UV).
vec3 screen_space_dither(vec2 frag_coord) {
	// Iestyn's RGB dither (7 asm instructions) from Portal 2 X360, slightly modified for VR.
	vec3 dither = vec3(dot(vec2(171.0, 231.0), frag_coord));
	dither.rgb = fract(dither.rgb / vec3(103.0, 71.0, 97.0));

	// Subtract 0.5 to avoid slightly brightening the whole viewport.
	return (dither.rgb - 0.5) / 255.0;
}

// ...

#ifdef USE_DEBANDING
	// For best results, debanding should be done before tonemapping.
	// Otherwise, we're adding noise to an already-quantized image.
	color += screen_space_dither(gl_FragCoord.xy);
#endif

[HybridDog]

I have rebased this and applied Calinou's suggestion, which works a lot better than a simple checkerboard pattern.

[Calinou]

Tested locally, it works as expected.

Cropped section of the image with Colors > Auto > Equalize in GIMP and 3× nearest-neighbor scaling:

It may be worth enabling this setting by default, as it'll help a lot once #13881 are implemented (you can notice banding on the screenshots I posted there).

Also, I suggest renaming the setting to debanding as dithering may be confused for a setting that intentionally makes the game look worse (e.g. palletization shaders that aim for a PS1-like look).

[HybridDog]

It may be worth enabling this setting by default, as it'll help a lot once #13881 are implemented (you can notice banding on the screenshots I posted there).

Done. I assume that on OLED screens, which have almost infinite contrast, banding may be very visible in Minetest when playing in a dark cave, but I haven't tested it.

Dithering may also reduce hypothetical subtle screen flickering caused by rounding and numerical precision limits, for example a background colour alternating between #B9EBE9 and #B9ECE9. A similar but, as far as I know, stronger flickering happened in the past (#8416).

Also, I suggest renaming the setting to debanding as dithering may be confused for a setting that intentionally makes the game look worse (e.g. palletization shaders that aim for a PS1-like look).

I've renamed it. I think debanding is a more generic term and it includes not only dithering but also, for example, algorithms which remove banding after the quantisation, such as AdaDeband.

[Calinou]

Done. I assume that on OLED screens, which have almost infinite contrast, banding may be very visible in Minetest when playing in a dark cave, but I haven't tested it.

I'm using a LG C2 42" which is an OLED display 🙂

The debanding shader looks great on it, but I can certainly notice banding when it's disabled.

[Desour]

Tested, works.
Left is without dithering, right is with:

Interestingly, this also in a way improves screenshots. This is how the screenshot looks like if I look at it with an image viewer that transforms the colors to my screen's color space (which is not srgb):

---

Considering how simple this change is, I support it.

Code looks fine.

@Calinou Is it actually fine to use the code from those slides, copyright-wise? (IANAL)

[Desour]

LGTM, and works.

[grorp]

Thank you for the explanation in #9014 (comment).

I don't usually notice banding while playing Minetest, but if I look for it, it is very obvious. This PR fixes the obvious cases of banding. In a direct before/after comparison, it also improves the image quality in scenes where I didn't notice any banding.

---

The debanding doesn't work on my Android phone ("ogles2" Irrlicht video driver). The reason seems to be a lack of precision: it works if I add precision highp float; at the beginning of the shader. For testing, I took two screenshots with 50x dithering applied:

Screenshot of broken 50x dithering (this PR)

Screenshot of working 50x dithering (this PR with precision highp float;)

I see two possible solutions:

1. Disable debanding by default on Android.

   This might also be a good idea because Godot had a problem with this debanding code on mobile, which apparently still hasn't been solved:

   Debanding breaks rendering on mobile (GLES3) godotengine/godot#49989
   "Use Debanding" option on iOS causes rendering issue godotengine/godot#56443
   Enabling debanding on mobile results in partially black screen (GLES3) godotengine/godot#45366

2. On OpenGL ES, use precision highp float; if available (#ifdef GL_FRAGMENT_PRECISION_HIGH). Disable debanding otherwise.

[Calinou]

This might also be a good idea because Godot had a problem with this debanding code on mobile, which apparently still hasn't been solved:

We could probably add highp where required to fix it. This means debanding will run slower, but it's better to have it run slower than to be broken. We can still choose debanding to be disabled by default on mobile for performance reasons.

I'm not aware of a high-quality mediump-friendly debanding shader.

[HybridDog]

Thanks for testing.
I have added the check for GL_FRAGMENT_PRECISION_HIGH and highp qualifiers but I don't know if it works.

I'm not aware of a high-quality mediump-friendly debanding shader.

On the lower left corner the dithering doesn't look broken (there are slight differences due to camera movement):

The reason is probably that gl_FragCoord is smaller there.
It may be possible to make the dithering work with low floating-point precision by adding modulo operations, e.g.

	frag_coord = vec2(mod(frag_coord.x, 33.0), mod(frag_coord.y, 33.0));

However, I don't know which effect this has on performance and quality.

[grorp]

Thanks for the changes. The debanding now works on my Android device (and it also still works on my desktop computer).

The reason is probably that gl_FragCoord is smaller there. It may be possible to make the dithering work with low floating-point precision by adding modulo operations, e.g.

	frag_coord = vec2(mod(frag_coord.x, 33.0), mod(frag_coord.y, 33.0));

However, I don't know which effect this has on performance and quality.

That doesn't seem to be worth it.

We can still choose debanding to be disabled by default on mobile for performance reasons.

I am in favor of that.

[HybridDog]

I have changed the setting now so that dithering can be enabled on OpenGL only (and not OpenGL ES).

[grorp]

I have changed the setting now so that dithering can be enabled on OpenGL only (and not OpenGL ES).

Why is the enum value called glsl_only? Shouldn't it be opengl_only?

Anyway, I'd prefer if the setting stayed a boolean and you just added settings->setDefault("debanding", "false"); to the "Altered settings for Android" section of defaultsettings.cpp (reasons: 1. simplicity, 2. consistency with other graphics settings).

[HybridDog]

Why is the enum value called glsl_only? Shouldn't it be opengl_only?

If I remember correctly, I mistakenly thought that OpenGL is a broad term which includes OpenGL ES, whereas GLSL is not a broad term and thus does not include the OpenGL ES Shading Language. opengl_only sounds better in my opinion.

Anyway, I'd prefer if the setting stayed a boolean and you just added settings->setDefault("debanding", "false"); to the "Altered settings for Android" section of defaultsettings.cpp (reasons: 1. simplicity, 2. consistency with other graphics settings).

I also prefer a simple bool setting but I think it's not possible to set a different default value in settingtypes.txt on Android, so if I understand it correctly, either the desktop or the Android settings menu would show the wrong default value.
I have changed it back to bool nonetheless and added the line to defaultsettings.cpp since other settings also only have the desktop default in settingtypes.txt.

[grorp]

so if I understand it correctly, either the desktop or the Android settings menu would show the wrong default value.

No, luckily the settings menu (implicitly) gets its default values from defaultsettings.cpp and only uses settingtypes.txt as a fallback. (This is because Settings:get also returns default values from defaultsettings.cpp.)

Ah, maybe you're referring to the default value in the tooltip of the reset button. In that case, I guess you're right.

[HybridDog]

No, I haven't looked at the settings code thoroughly and accidentally assumed that it would show the default value from settingtypes.txt.

[grorp]

Thanks for your incredible patience!