Shouldn't MPV linearize "BT.1886" using BT.2035 parameters?

[goeiecool9999]

When viewing SDR "BT. 1886"[1] content MPV treats the content as if their black level is 0.203 nits and white level is 203 nits[2]. I can see that the 203 nits figure is derived from section 5.1.1 in BT.2408 describing how to incorporate SDR content into HDR content. However BT.2408 also says to assume perfect blacks and just use pure gamma 2.4, so using a 1000:1 contrast ratio BT.1886 curve with a peak of 203 nits does not follow the report practices exactly. Regardless I think that neither a pure 2.4 gamma nor a 1000:1 contrast ratio BT. 1886 curve is optimal for linearizing "BT.1886". Ideally MPV would linearize BT.1886 using a 10.000:1 contrast ratio, as described in BT.2035. The way MPV is currently there seems to be no way to get it to do this. I tried setting vf to format=min-luma=0.01:max-luma=100 but that didn't seem to affect the output at all. It didn't even dim the content. I could only get the output to change when max-luma went over 203 and I have no idea if min-luma ever did anything.

To further illustrate my point I have plotted the different display curves on a logarithmic scale. I cut it off at x = 1/255 so you can get an idea for the max error at the lowest 8-bit color value for the pure gamma curve
red = BT.1886 1000:1
green = BT.1886 10.000:1 (BT.2035)
blue = gamma 2.4 with perfect blacks.
Black = 1000:1 Gamma 2.2

Without the option to change the assumed contrast ratio and peak of SDR content it is impossible to get MPV to tone map the green curve onto the black curve, which would be ideal for a gamma 2.2 computer monitor trying to view content mastered for BT. 2035.

Am I onto something here? I welcome your input.

[1] in scare quotes because BT. 1886 doesn't define the EOTF's parameters
[2] I found this out with watchpoints in GDB because I find libplacebo hard to comprehend because I'm not used to reading C source code. I may be wrong about this.

[kasper93]

Yes, there is room for improvement here. Using gamma2.4 is not really feasible for most of viewing environments. However currently we should be getting rough estimate of contrast from the display, at least for HDR output, where this matters.

I tried setting vf to format=min-luma=0.01:max-luma=100

This should work, what is your output? If it's not PQ transfer, those parameters may have little impact as it would mostly round trip back on output.

[goeiecool9999]

I don't own any display that supports PQ or wide gamut. My output is an SDR TN LCD PC monitor so likely 1000:1 gamma 2.2. In the mean time I have set my target-trc to BT.1886 for SDR content so MPV doesn't touch the gamma.
Side note: The MPV man pages say that if target-trc is set to auto it will automatically tone map HDR to gamma 2.2, but that doesn't seem to be the case (anymore?). When I open an HDR file with the default settings and look at the information overlay it says the display uses bt.1886, and when I change target-trc to gamma2.2 the output changes.

[kasper93]

It probably pretty old and outdated wording. But in fact the current mpv/libplacebo version defaults to sRGB, but with treat-srgb-as-power22 it will be gamma2.2.

As for bt.1886 parametrization, this works

--no-config --sdr-adjust-gamma --target-peak=203 --target-contrast=1000 --vf=format=min-luma=0.01:max-luma=100

But the different won't be huge, as the black level offset is negated by target contrast. But you can play with this.

[goeiecool9999]

Current as in latest commit or current as in latest release? I'm on v0.41.0 and also on Linux. Maybe I'm missing something? when I open an SDR file with --no-config the overlay shows that display transfer is bt.1886.

Shouldn't setting the max-luma to 100 and the target peak to 203 result in a noticeable halving of the brightness? When I toggle the filter on and off nothing appears to change.