PSA: d3d11 targets srgb gamma

[atrxia1]

As of haasn/libplacebo@e572f60, mpv will now adapt SDR content to srgb gamma if you are using the d3d11 rendering API, even with Windows ACM disabled. This might be a breaking change if you do not have a color-managed device, as mpv would previously leave SDR content untouched.

If you have an SDR display and would like to restore mpv's previous behavior, add this to your config:

target-colorspace-hint=no
target-trc=bt.1886

Edit: Changed title and description to better reflect the underlying change in behavior.

[Raza-0007]

Thank you for pointing this out.

Just wanted to add that the conversion from BT.1886 to srgb happens even with gpu-api=vulkan

I don't know whether this change is good or bad, as my knowledge in this area is limited. But I have read that srgb is best for photos and still graphics, while BT.1886 is best for videos. Since mpv is primarily a video player, BT.1886 would have been a better choice. But I will defer to the decision of the developers who no doubt have in-depth knowledge in this area.

[atrxia1]

mpv can't query if ACM is enabled or disabled. You likely have a different color-management setting enabled on your device that causes mpv to target srgb gamma.

[Raza-0007]

Then most probably it is the setting inside Nvidia control panel "Use Nvidia color settings" that I have toggled that is causing this. It is not on by default.

Here are some strange results from my testing. Both my displays, internal and external, are SDR only. External display has a mode called "HDR effect" but it is disabled. HDR mode is off in Windows 11, Windows ACM is disabled and colors are managed by Nvidia globally. Same video is being played on both displays.

External display:

gpu-api=d3d11 mpv transfers from Bt.1886 to srgb
gpu-api=vulkan mpv transfers from Bt.1886 to srgb

Internal display:

gpu-api=d3d11 mpv transfers from Bt.1886 to srgb
gpu-api=vulkan mpv does not transfer from Bt.1886

Both non-transferred Bt.1886 and transferred to srgb video looks good. The srgb is a shade darker than Bt.1886, but color balance looks good.

I don't know what to make of this but since everything looks good, I am just going to leave it as is.

[Headcrabed]

Personally, I advice to enable windows ACM, and use gpu-api=vulkan with target-colorspace-mode=auto+target-colorspace-hint-mode=target. This would get you the best color management experience.

[Headcrabed]

mpv can't query if ACM is enabled or disabled. You likely have a different color-management setting enabled on your device that causes mpv to target srgb gamma.

There is some method try to check ACM enablement status when using vulkan, but not that reliable: https://code.videolan.org/videolan/libplacebo/-/commit/51c7d2c1942d988be6f155dc0b57770550c8ff48

[atrxia1]

Personally, I advice to enable windows ACM

Some form of color management is good on a wide-gamut display, but if you're still using a standard gamut display, this advice doesn't work wholesale. Whether or not you get a good experience with ACM is on a per-application basis. For example, Windows ACM breaks rendering certain website elements on Firefox.

[kasper93]

Even without ACM, srgb output is better in PC environment. bt.1886 is just raising blacks to make it "better" in not light controlled environment, but unless you really need this, you better of by outputting srgb or pure 2.2 gamma.

If you know what you need, you can control output with the options.

[atrxia1]

I agree that adapting gamma to an uncontroversial srgb target is better than leaving the source untouched (vo=gpu-next already adapts source gamut to target using gamut mapping unlike vo=gpu). But this is undeniably a noticeable change since it will darken the picture for those that are used to mpv looking a certain way, so I don't see any issue with bringing it up.

[Jules-A]

Well this is frustrating... srgb definitively looks wrong on my VA monitor (on Win10 so no ACM). That said, your suggested change doesn't look right either, is it even exactly how bt.1886 was before without target-colorspace-hint? (also why won't it switch to bt.1886 without that?). I've only tried DX11 so far.

srgb made things too dark and bt.1886 is making everything too bright :/

EDIT: my attempts to find a middle point have been bad, if anyone has any better suggestions that'd be much appreciated.

[Jules-A]

Unless you're explicitly disabling it and assuming infinite contrast, target-contrast should be set to whatever your display's real contrast ratio is. It's not really a setting meant for playing around with.

That's a bit conflicting considering my monitor is rated for 4000:1 but MPV is defaulting to 1000 with srgb and setting it higher just increases my problem with the darker areas, actually as far as I can setting it to 950 is making it look slightly better :/

[lextra2]

@Jules-A
If you care so much about color accuracy you should purchase a colorimeter or a display with known good sRGB pre-calibration profiles - or TV
Or just stick to MPV v40

Oh and target-contrast=inf should never be used, at least not on SDR. I crushes low light details, even on a calibrated OLED.

[atrxia1]

Oh and target-contrast=inf should never be used

Using --target-contrast in combination with --gamma-factor doesn't really make much sense. In fact, --target-contrast was originally designed to deprecate the old --gamma-factor method of correcting the excessive darkening from --target-trc=srgb when viewing BT.709 content. Even though both options aren't orthogonal, it probably makes more sense to pick one or the other.

[Jules-A]

@Jules-A If you care so much about color accuracy you should purchase a colorimeter or a display with [known good sRGB pre-calibration profiles

I've been considering an OLED monitor for over a year now but I want to avoid one with too much VRR flickering and the only ones that aren't so bad in that area are far more expensive. It would be nice to have everything work out of the box but I always end up calibrating myself anyway. It actually took me a whole 3 days to calibrate my current display...

Using --target-contrast in combination with --gamma-factor doesn't really make much sense. In fact, --target-contrast was originally designed to deprecate the old --gamma-factor method of correcting the excessive darkening

I kind of feel like they are doing completely different things, gamma is affecting the whole image and doesn't solve the issue for me, while changing the contrast only seems to affect the image greatly when there's an actual contrast.

[Headcrabed]

To calibrate monitor, don't use colorimeter, since if the colorimeter software don't have correct spectrum data, the calibration result would even worse than factory default... Use spectrometer instead. I advice to use Colorchecker Studio. (Also you can try to rent one instead of buy one)

Also use CIE 2015 as calibrate observer, don't use CIE 1931, that's not suitable for modern monitors, especially for OLED.