Enabling debanding adds banding instead of removing

[wiwaz]

Important Information

• mpv version: v0.37.0-230-gd90a5ff1
• Platform and Version: Windows 11 23H2
• Source of the mpv binary: zhongfly
• Which version of mpv introduced the problem: Has been an issue since deband was implemented.
• GPU model, driver and version: GTX 1080Ti, Driver 546.33
• Possible screenshot or video of visual glitches: https://slow.pics/c/MsIxgcoT

Reproduction steps

Open a video file and toggle debanding on. Sample attached has noticeable banding when debanding is enabled, bottom left/right of the image especially.

Expected behavior

Debanding removes banding.

Actual behavior

Debanding adds banding.

Log file

output.txt

Sample files

https://github.com/mpv-player/mpv/assets/105133551/0393f209-4f78-49b2-a109-a622937e9a68

[NSQY]

Using the archives from shinchiro I managed to track down the issue to 0.34. It would appear that the change vo_gpu: lower default deband threshold to preserve more detail exposes this bug. Raising --deband-threshold back to 64 on 0.34 hides this problem.

Of course, enabling deband should not introduce banding in the first place.

Here is an (imo) more obvious example: https://slow.pics/c/34CfFa5M

[ghost]

Worth noting that this issue is not apparent with f3kdb (which I'm told is what libplacebo's deband is based upon) and that specific content types are more prone to this issue occuring (specifically, gradients with only very fine dithering present).

Unfortunately the entirety of Crunchyroll's catalog falls under this nature of source as they use very fine ordered dithering, meaning enabling deband will always add banding with these streams, defeating a very common use-case of the filter.

[Jules-A]

What the hell? I can't really spot the banding in the original source but with banding you need a threshold of ~46 + ugly grain or 50 without grain to not have added banding artifacts... Do you have a source that has actual banding for testing?

EDIT: Just realised the default threshhold is 48 now. Does having that much grain really help with debanding vs increasing the threshhold?

[LightArrowsEXE]

@Jules-A NSQY posted a sample.

Also whether the source image used has banding or not is irrelevant to the point being made; enabling debanding can introduce banding on sources that had little-to-no banding before, and introduce new banding on sources that are banded. Your comment adds nothing to this conversation.

[LightArrowsEXE]

Please read the issue title as well as the actual issue itself. None of your comments have been relevant to the issue at hand, so please stop posting. Thank you.

[Jules-A]

Please read the issue title.

That was not a sample of source banding, if you read the OP and NSQY's message properly. Unless you mean using the banded image as a sample to try and deband lol... I was asking for a video sample as I'm not sure testing just a single image is a good judge to check if it's enough. There's also the fact that it already has grain applied, afaik, debanding already grained sources isn't very effective? The main reason I wanted a source with banding was to help find new values for debanding that doesn't just fix this issue but is effecting for actually debanding without damaging the image too much. I assume this issue will likely be fixed by simply raising the threshhold but if it reverts back to the previous 64 without finding a more optimal value it would be pretty wasteful.

None of your comments have been relevant to the issue at hand

Seriously??? I confirmed the issue and shared the threshhold of where the issue starts to become unnoticeable but that was just testing with OPs sample which is why I was asking for sample with source banding to try and determine the best way to overcome the issue.

Even if it isn't going to fix the actual issue, maybe people want to find a solution themselves until it is fixed? Yet all you are doing is spamming "it's irrelevant" without adding anything to the conversation.

[LightArrowsEXE]

I assume this issue will likely be fixed by simply raising the threshhold

This does not address the actual issue at hand. It still introduces banding at lower thresholds when it should not.

The main reason I wanted a source with banding was to help find new values for debanding that doesn't just fix this issue but is effecting for actually debanding without damaging the image too much.

Once more, this is irrelevant to this issue. If you want to propose new default values, discuss it in a relevant issue. This is not the place for that, as this is a more fundamental issue with the debander itself.

[mightyhuhn]

that's how a deband filter works it has a treshhold so it differences between a band and something that is a detail.

if you now have 8 band and the debander only catches 4 of them it will look like 4 bigger bands it's just how it is.

so what else except the treshhold or a different debander is there to talk about?

[ghost]

so what else except the treshhold or a different debander is there to talk about?

Read the issue name? Don't derail this issue.

[mightyhuhn]

i did and i say it again.

this is excepted behaviour from debanding filters. yes they can add banding as shown if i didn't make that very clear already. it removes banding and creates more in the process.

or to say it in another way it removes banding in this case the human eye doesn't see as much and creates bands that the human eye can see.

[kunkanader]

4chan is laughing at you

[mightyhuhn]

glad to be of service.

[arch1t3cht]

To get this discussion back on track:

I looked into this and the one big difference I found between ordinary f3kdb and mpv/libplacebo's shaders is that f3kdb looks up four pixels in the source image, while the shaders sample four points in the texture at potentially non-integer coordinates. I can imagine (it's fairly hard to do actual quantitative evaluations here, maybe someone else has more insights) that this can make a big difference in material with strong dithering like NSQY's sample, where sampling at non-integer coordinates smooths out the dithering much more.

Rounding the offsets before the lookup, e.g. simply with

-         GLSLH(vec2 o = dist * vec2(cos(dir), sin(dir));)
+         GLSLH(vec2 o = round(dist * vec2(cos(dir), sin(dir)));)

gets rid of most of the introduced banding in NSQY's sample. Some banding is still left, but then again ordinary (neo)f3kdb via VapourSynth also adds a bit of banding to this sample (but less than mpv currently does), so it's likely that this change will make mpv/libplacebo match ordinary f3kdb much closer.

[haasn]

I can't say I notice the banding in the OP sample, so can you check if this MR improves things?

https://code.videolan.org/videolan/libplacebo/-/merge_requests/639

[arch1t3cht]

Here are some comparisons: (Using my sample (posted by NSQY) since the banding is much clearer there, note though that this seems to be a fairly special sample (possibly due to the kind of dithering it uses); it's rare that the added banding is that bad)

F3kdb vs current libplacebo: https://slow.pics/c/BsvcqU6Q F3kdb vs deband_nearest: https://slow.pics/c/VxEtrmo2

One can see that even here a small amount of banding is added, but it's nowhere near as bad as before and it seems to match f3kdb's output.

It should be noted, though, that this strongly depends on the debanding parameters: This is the same comparison with thresh=64 (as opposed to 48):

F3kdb vs current libplacebo: https://slow.pics/c/Nyp5wZqy F3kdb vs deband_nearest: https://slow.pics/c/jtjV7pRt

Here, current libplacebo adds less banding (almost none) with thresh=64 than with thresh=48 and the MR makes it add slightly more again (but, again, this matches f3kdb).

My conclusion: There doesn't seem to be a perfect solution here. Some of the problems involved might just be a systematic problem with the method used by f3kdb (and thus by mpv/libplacebo). (Also, this test was just on one sample. It's also possible for these changes to also affect how well banding is removed on "normal" material. That's hard to say without more tests.) Still, this MR does seem to bring libplacebo's behavior in line with f3kdb's. That's why I'd say that it's a good idea to merge this, since it'll make libplacebo's debanding behavior more predictable and will prevent any issues of the form "Libplacebo adds banding on this sample but f3kdb doesn't" (which this issue started out as).

The comparisons were generated with VapourSynth via the vs-placebo plugin:

import vapoursynth as vs
from vstools import set_output

clip = vs.core.lsmas.LWLibavSource("../../koumei.mkv").resize.Bicubic(format=vs.YUV420P16)

clip = clip.resize.Bicubic(range=1)     # resampling to full range is necessary to make f3kdb's param scaling match mpv's
set_output(clip, "Source")

thresh = 48

set_output(clip.f3kdb.Deband(range=16, y=thresh, cb=thresh, cr=thresh), "f3kdb")
set_output(clip.placebo.Deband(radius=16, threshold=thresh / 16.384, grain=64 / 8.192), "placebo")

[haasn]

What about a sample with actual banding, does the deband_nearest branch reduce the ability of this filter to remove banding?

[ghost]

While deband_nearest does put things in line with f3kdb, it's clear there is a deeper issue at play since the core problem is still present, just to a far lesser degree. My initial issue was just "Placebo seems to perform worse than f3kdb" so perhaps its out of scope for this but looking into smoothing methods that preserve gradients better may be a good idea.

[mightyhuhn]

here are the two mpdn deband algorithm https://slow.pics/c/uysvgzks

i can not really test this program i need to change system setting to even open it and it doesnt have a screenshot function. but the filter is open source.

so if more screenshot are wanted from it please collect a couple first i dont even have a correct keyboardlayout at the moment...

[arch1t3cht]

What about a sample with actual banding, does the deband_nearest branch reduce the ability of this filter to remove banding?

I grabbed the most recent episode (out of all shows) that was uploaded to Crunchyroll and made the same comparisons with that (the links contain comparisons for multiple frames) Libplacebo master: https://slow.pics/c/uzMSjQ1e Libplacebo deband_nearest: https://slow.pics/c/9nJKnWyo

In these frames I cannot really see a difference between master and deband_nearest, even in frames 4 and 5 where there is still some banding left after debanding.

[arch1t3cht]

Thanks!