gpu-next: --cscale-antiring is broken, --scale-antiring affects chroma

[Artoriuz]

Important Information

• mpv version: [git-ab30028
• Platform and Version: Windows 11 22621.1848
• Source of the mpv binary: Shinchiro

Reproduction steps

Run anything with mpv --no-config --vo=gpu-next --profile=gpu-hq --screenshot-format=png --no-hidpi-window-scale --cscale-antiring=1

Expected behavior

--cscale-antiring=1 should affect the chroma scaling step.

Actual behavior

--cscale-antiring=1 doesn't do anything, but --scale-antiring=1 affects both chroma scaling and RGB scaling.

Log file

log.txt

Sample files

--cscale-antiring=0:

--cscale-antiring=1:

[haasn]

Q: Is there even any value in cscale-antiring and scale-antiring being separate options?

Exposing both as separate controls in libplacebo would require an unfortunate API modification, which I was rather keen on avoiding because I think these scaler options are bloat anyway and there's little reason to use a different upscaler for luma than for chroma..

[Artoriuz]

Libplacebo is your project and you should feel free to do whatever you want with it, I'm just reporting this as a bug because the behaviour differs between gpu and gpu-next.

In my opinion having scale-antiring affect both scale and cscale just isn't very intuitive, and it breaks the pattern seen in many other settings (scale-radius, scale-window, scale-param, scale-blur, etc...).

If I'm not mistaken, at the beginning libplacebo didn't even distinguish between scale and cscale, so it was perfectly valid for the scale-whatever settings to affect both of them. This isn't the case anymore though, and being able to set cscale but not cscale-antiring feels very inconsistent.

I agree with you that these settings are mostly unnecessary bloat, but using a cheaper filter for chroma is a relatively valid use-case for people running mpv on toasters or even just on laptops running on battery. Bilateral filters are also a thing, so I wouldn't call the ability to pick a different filter for chroma completely worthless.

In any case, I'm just reporting that these settings are currently kinda weird.

[Artoriuz]

I just wanted to say that the recent change that enabled polar antiring for downscaling has the same behaviour. Setting --scale-antiring affects downscaling as well and --dscale-antiring is broken.

I'm positive you probably already knew that, but I'll just leave a comment here just in case.

[CrHasher]

I just wanted to say that the recent change that enabled polar antiring for downscaling has the same behaviour. Setting --scale-antiring affects downscaling as well and --dscale-antiring is broken.

I'm positive you probably already knew that, but I'll just leave a comment here just in case.

I can confirm this on gpu-next as soon as you switch on scale-antiring=x.x AR is applied even on downscale even if dscale-antiring=0.0:

Only scale-antiring=x.x active: No antiring at all: This is a 4k video downscaled with a polar scaler I don't need AR in this case but mpv with gpu-next ignores my dscale-antiring=0.0:

Forgive my Barbieism its first 4k trailer I could find :D

[CrHasher]

And the documentation still says this:

--scale-antiring=, --cscale-antiring=, --dscale-antiring=, --tscale-antiring= Set the antiringing strength. This tries to eliminate ringing, but can introduce other artifacts in the process. Must be a float number between 0.0 and 1.0. The default value of 0.0 disables antiringing entirely.

Note that this doesn't affect the special filters bilinear and bicubic_fast, nor does it affect any polar (EWA) scalers.

[dyphire]

Q: Is there even any value in cscale-antiring and scale-antiring being separate options?

They should work separately like other scale and cscale options, including dscale-antiring. The current behavior is confusing and inconvenient.

Exposing both as separate controls in libplacebo would require an unfortunate API modification, which I was rather keen on avoiding because I think these scaler options are bloat anyway and there's little reason to use a different upscaler for luma than for chroma..

This statement is not accurate, the human eye is not as sensitive to chroma information as it is to luminance information. In fact, there are a lot of people who don't use advanced upscaler for chroma upscaling in practice, it's not even about performance, it's just not necessary. In addition to mpv, video renderers like madvr and mpcvr offer separate scale, dscale, and cscale options as well, which speaks volumes about the necessity of them as standalone options.

[yeezylife]

dscale=spline36
dscale-antiring=0.8
scale-antiring=0.8

And dscale-antiring for orthogonal scaler doesn't seems to work no matter how I set it.

[norinoriko]

Downscaling AR has been disabled for more than a year now https://github.com/mpv-player/mpv/issues/11905.

[dyphire]

dscale=spline36
dscale-antiring=0.8
scale-antiring=0.8

And dscale-antiring for orthogonal scaler doesn't seems to work no matter how I set it.

You should open a new issue for this, dscale-antiring needs to work as expected.

[llyyr]

You should open a new issue for this, dscale-antiring needs to work as expected.

This ticket is sufficient to track this. scale-antiring applies to both scale and cscale, and used to also apply to dscale until it was explicitly disabled in https://github.com/haasn/libplacebo/commit/9855b663f1da050c36dd2278ceb372044c44fc73. I don't think there's much value in antiring while downscaling

The solution is to allow setting different AR values depending on the pass in libplacebo, but I don't think anyone cares enough to work on this

[dyphire]

You should open a new issue for this, dscale-antiring needs to work as expected.

This ticket is sufficient to track this. scale-antiring applies to both scale and cscale, and used to also apply to dscale until it was explicitly disabled in haasn/libplacebo@9855b66. I don't think there's much value in antiring while downscaling

Discussing the role of anti-ringing when downscaling can be argumentative, and I don't intend it to be. I just wanted to point out that *scale-antiring should work as described in the manual for the option, and if not then the description should be updated to point out that it doesn't work on --vo=gpu-next. This was ignored after https://github.com/haasn/libplacebo/commit/9855b663f1da050c36dd2278ceb372044c44fc73 a year ago.

[norinoriko]

I think the order of the events are being mixed up here. --dscale-antiring produces aliasing on both vo_gpu and vo_gpu_next. Ortho downscaling AR was disabled on vo_gpu_next because of the issue described in this ticket, where users would set --scale-antiring and unexpectedly get aliasing artifacts while downscaling.

I just wanted to point out that *scale-antiring should work as described in the manual for the option, and if not then the description should be updated to point out that it doesn't work on --vo=gpu-next.

The manual isn't really the correct place to document this IMO, so I've added it to "Known Issues" in https://github.com/mpv-player/mpv/wiki/GPU-Next-vs-GPU

This is off-tangent but simply re-enabling ortho dscale AR wouldn't really solve the core of the problem. The ortho AR filter would need to be tweaked or refactored to avoid such quality issues in the first place. If I remember correctly, the suggestion of making ortho AR less aggressive was floated in the past, but no one has really done any extensive tests to justify refactoring ortho AR.

[Artoriuz]

dscale=spline36
dscale-antiring=0.8
scale-antiring=0.8

And dscale-antiring for orthogonal scaler doesn't seems to work no matter how I set it.

As mentioned above dscale-antiring was disable a while ago for quality reasons. If you really want to use AR while downscaling right now, you can use this user shader.

It isn't a solution to the problem, and the shader isn't perfect by any means, but since its logic is slightly different it doesn't seem to suffer from the same aliasing problems.