--target-trc=srgb behaviour mismatch between vo=gpu and vo=gpu-next

[Artoriuz]

Important Information

Provide following Information:

• mpv version: mpv-x86_64-20220313-git-7ac4b7d (shinchiro)
• Windows Version: Windows 11 Pro 21H2 22000.556
• Source of the mpv binary: shinchiro git
• If known which version of mpv introduced the problem:
• Possible screenshot or video of visual glitches: mpv --no-config --vo=gpu --hidpi-window-scale=no --screenshot-format=png:

mpv --no-config --vo=gpu --hidpi-window-scale=no --screenshot-format=png --target-trc=srgb:

mpv --no-config --vo=gpu-next --hidpi-window-scale=no --screenshot-format=png:

mpv --no-config --vo=gpu-next --hidpi-window-scale=no --screenshot-format=png --target-trc=srgb:

mpv --no-config --vo=gpu-next --hidpi-window-scale=no --screenshot-format=png --icc-profile='.\sRGB2014.icc:

mpv --no-config --vo=gpu-next --hidpi-window-scale=no --screenshot-format=png --icc-profile='.\sRGB_v4_ICC_preference.icc':

Reproduction steps

Opening the same Rec.709 bt.1886 yuv420 SDR video file with mpv --no-config --vo=gpu --target-trc=srgb and mpv --no-config --vo=gpu-next --target-trc=srgb.

Expected behavior

I suppose the outputs should be somewhat consistent regardless of the choice of vo.

Actual behavior

As we can see in the screenshots above, black point seems wildly different between gpu and gpu-next with --target-trc=srgb. Using the sRGB profiles provided by color.org didn't exactly provide any guidance either, as the v2 and v4 profiles give wildly different results as well.

I don't really know which output is supposed to be correct here, but I just wanted to report it anyway.

Log file

gpulog.txt gpunextlog.txt

[Artoriuz]

Just to add, using the v2 sRGB ICC profile from color.org with --vo=gpu-next and --icc-intent=0 (perceptual) does match the output of --target-trc=srgb with --vo=gpu.

[LaserEyess]

https://github.com/mpv-player/mpv/wiki/GPU-Next-vs-GPU#general-differences

• gpu-next, unlike gpu, performs black point compensation during color management, leading to subtly different results for many of the tone mapping-related options
• gpu-next generally defaults to bt.1886 instead of gamma2.2 for the display output, due to the better/different black point handling

[dyphire]

Try use --target-trc=gamma2.2 on --vo=gpu-next and test.

[haasn]

I haven't yet had time to fully digest your issue report but the quick comment I will give now in case it helps understand is that, as @LaserEyess noted, gpu-next performs black point compensation.

This means that, if everything is working correctly, I would expect --vo=gpu-next --target-trc=srgb to behave similar to --icc-profile=sRGB.icc --icc-force-contrast=1000 (on either VO). --vo=gpu --target-trc=srgb on the other hand behaves more like --icc-profile=sRGB.icc --icc-force-contrast=inf (on either VO).

Maybe that helps you figure out what's going on. In any case, I don't plan on looking at this issue until my (overdue) rewrite of the ICC profile handling code in libplacebo.

[Artoriuz]

@dyphire The behaviour is the same with --target-trc=gamma2.2, gpu-next produces brighter results than gpu: gpu: gpu-next:

@haasn Thanks for the explanation, I've just tested the scenarios you mentioned and as you said, --vo=gpu-next --target-trc=srgb behaves the same as --vo=gpu --icc-profile=sRGB2014.icc --icc-force-contrast=1000. However, the --icc-force-contrast flag doesn't seem to be working on gpu-next.

mpv --no-config --vo=gpu-next --screenshot-format=png --hidpi-window-scale=no --target-trc=srgb:

mpv --no-config --vo=gpu --screenshot-format=png --hidpi-window-scale=no --icc-profile='.\sRGB2014.icc' --icc-force-contrast=1000:

mpv --no-config --vo=gpu-next --screenshot-format=png --hidpi-window-scale=no --icc-profile='.\sRGB2014.icc' --icc-force-contrast=1000:

In any case that's fair, thanks.

[haasn]

However, the --icc-force-contrast flag doesn't seem to be working on gpu-next.

Oh, right. I forgot about that.

[Artoriuz]

--gamma-factor doesn't seem to be working either. It's probably a good idea to keep track of which flags are unimplemented/deprecated in gpu-next.