0.41:gpu-next/vulkan reports unusually high contrast for SDR content/display

[Lompik]

mpv Information

mpv v0.41.0 Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Dec 22 2025 14:58:51
libplacebo version: v7.351.0
FFmpeg version: n8.0.1
FFmpeg library versions:
   libavcodec      62.11.100
   libavdevice     62.1.100
   libavfilter     11.4.100
   libavformat     62.3.100
   libavutil       60.8.100
   libswresample   6.1.100
   libswscale      9.1.100

Other Information

also on git master+placebo master

Reproduction Steps

on 0.41:
mpv --no-config --gpu-api=vulkan => video-target-params.min_luma = 1e-6
mpv --no-config --gpu-api=opengl => video-target-params.min_luma = 0.203

on 0.40, they are both 0.203.

bisected to ae211f7

Expected Behavior

auto is the default and assumes 1000:1 contrast as a typical SDR display

Actual Behavior

na

Log File

log.txt

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[kasper93]

/cc @mahkoh

When luminances and target luminances are the same it will scale min_luma to 0, as I understand this is what Wayland expect. Those values are not absolute display parameters like on Windows, instead they are in respect to reference luminances. As explained in the commit already.

Don't focus on numbers, but if you can validate that image is displayed correctly this will be enough.

[Lompik]

this is what Wayland expect

does wayland expect different things depending on opengl or vulkan?

but if you can validate that image is displayed

In my case comparing, --no-config --gpu-api=vulkan and --no-config --gpu-api=opengl is tricky because mesa sets wp_image_description_creator_params_v1#72.set_tf_named(SRGB) for vulkan. Any tips?

[kasper93]

does wayland expect different things depending on opengl or vulkan?

In opengl we output sRGB always. Vulkan tries to match preferred colorspace.

[Lompik]

Regardless of the values, for SDR display, does it make sense to have different value for opengl / vulkan? The way I understand it for gpu-next (may be wrong): min_luma is used the same way in opengl and vulkan. mpv does not send min_luma via wayland protocols with either vulkan or opengl. It is used in the bt.1886 handling in fragment shader.
The bisected commit exposes the fact that min_luma is not treated the same opengl / vulkan. I just fail to see why for SDR display. In fact, wd->csp.hdr.min_luma=0.000001 in info_done for both opengl / vulkan.

[kasper93]

That's valid observation. We don't support color management on OpenGL, so we also ignore preferred color space from compositor, but I guess, when it matches the (implicit) transfer we could try to use it, #17326, I will wait for mahkoh to say why its bad though :)

[mahkoh]

/cc @mahkoh

We had a bit of a discussion in #17149 (comment) about what the minimum luminance of libplacebo is. In my last comment I suggested a different approach that would have resulted in a minimum luminance of 0.203 for SDR transfer functions, I think.

But ultimately I thought that it shouldn't make a big difference, at least as far as wayland is concerned. I don't really understand what the issue here is. Is the image displayed incorrectly?

[kasper93]

We had a bit of a discussion in #17149 (comment) about what the minimum luminance of libplacebo is. In my last comment I suggested a different approach that would have resulted in a minimum luminance of 0.203 for SDR transfer functions, I think.

Ah, yes, I remember. I liked the proposed change, but sfan5 merged the PR in the current state at here we are now.

Frankly for SDR->SDR the min_luma doesn't matter, except for bt.1886, but it's not that significant.

Where it matters is when SDR->HDR, in which case it's already correct.

Frankly, I would rather change it on need basis, when something is clipped or lifted, is this the case?

[mahkoh]

I liked the proposed change

I remember that I still had a different concern with the proposed change. Something else that might have had to be changed slightly to make this correct. But I no longer remember what that was.

Frankly, I would rather change it on need basis, when something is clipped or lifted, is this the case?

I'm not sure. There is actually quite a big difference in the output. I've compared the test pattern with hdr.min_luma hard-coded two different values:

PL_COLOR_SDR_WHITE / PL_COLOR_SDR_CONTRAST:

PL_COLOR_HDR_BLACK

I don't know which one is more correct.

[mahkoh]

The transfer used here is bt.1886 so maybe this is the difference you mentioned in the PR and other transfer functions are not affected.

[Lompik]

isn't 0, 203 min/max luma is equivalent to --target-contrast=inf?

Weirdly, changing target-contrast with the default trc bt.1886 has no effect at all. But worth other trc (target-trc=gamm2.2) it absolutely has. I don't quite understand.

[mahkoh]

min=0 is the same as min=0.203. PL_COLOR_HDR_BLACK is 10^-6 or something like that.

[kasper93]

The transfer used here is bt.1886 so maybe this is the difference you mentioned in the PR and other transfer functions are not affected.

What happens is, that tonemapping will put black at min_luma value (in absolute linear space). After that apply bt.1886. Which basically cancels out the black lift. BUT the bt.1886 have also the other component, the "contrast" one which will be baked based on min/max levels.

Well basically we have to use the same Lw/Lb values as the compositor will use to linearized bt.1886, to inverse this transfer correctly.