vo_gpu_next: add --target-contrast-hdr option by Headcrabed · Pull Request #18073 · mpv-player/mpv

Headcrabed · 2026-06-03T19:33:48Z

Should be helpful for Windows ACM/macOS cases, which assuming 1000:1 contrast might result in washed out colors.

Wayland shouldn't need this since we have #17345

kasper93 · 2026-06-03T19:46:29Z

Why not do it with autoprofile?

Headcrabed · 2026-06-03T19:50:15Z

Why not do it with autoprofile?

Doing such seems more clean, and quite a lot of use cases need it.

github-actions · 2026-06-03T20:20:42Z

Download the artifacts for this pull request:

Windows

macOS

kasper93 · 2026-06-03T20:23:44Z

Why not do it with autoprofile?

Doing such seems more clean, and quite a lot of use cases need it.

I don't know, it hardcodes some dubious logic into the C code, when this can be fully achieved with user config if user needs something like that.

Headcrabed · 2026-06-04T07:27:22Z

Why not do it with autoprofile?

Doing such seems more clean, and quite a lot of use cases need it.

I don't know, it hardcodes some dubious logic into the C code, when this can be fully achieved with user config if user needs something like that.

While autoconfig could do this, the users need such config are increasing since windows would enable ACM by default on new version+wide-gamut display. I think teaching every user to manually write a config for this is quite unrealistic....

kasper93 · 2026-06-04T11:03:30Z

Why not do it with autoprofile?

Doing such seems more clean, and quite a lot of use cases need it.

I don't know, it hardcodes some dubious logic into the C code, when this can be fully achieved with user config if user needs something like that.

While autoconfig could do this, the users need such config are increasing since windows would enable ACM by default on new version+wide-gamut display. I think teaching every user to manually write a config for this is quite unrealistic....

I don't think using inf contrast is required for acm. Could you describe your issue, there is likely misunderstanding here.

Headcrabed · 2026-06-04T11:51:20Z

I don't think using inf contrast is required for acm. Could you describe your issue, there is likely misunderstanding here.

Since ACM is only available to wide-gamut monitor, the contrast of the monitor is highly possible to be higher than 1000:1, even after clamping by color space conversion. And in such case the actual contrast range is not possible for mpv to get in SDR, still assuming 1000:1 would result in washed out color, and inf would solve this issue.

kasper93 · 2026-06-04T11:56:07Z

I don't think using inf contrast is required for acm. Could you describe your issue, there is likely misunderstanding here.

Since ACM is only available to wide-gamut monitor, the contrast of the monitor is highly possible to be higher than 1000:1, even after clamping by color space conversion. And in such case the actual contrast range is not possible for mpv to get in SDR, still assuming 1000:1 would result in washed out color, and inf would solve this issue.

Then, it's on user to set. "ACM" meaning > 1000:1 contrast is far fetched and I would even say it's wrong. Wide gamut displays like IPS exist for decades and realistically > 1000:1 is OLED of VA only.

Headcrabed · 2026-06-04T12:14:15Z

Then, it's on user to set. "ACM" meaning > 1000:1 contrast is far fetched and I would even say it's wrong. Wide gamut displays like IPS exist for decades and realistically > 1000:1 is OLED of VA only.

Modern IPS displays(even without local dimming) could also easily reach >1000:1. And old wide-gamut monitors basically have broken edid so ACM couldn't be enabled at all.

Headcrabed · 2026-06-04T12:15:19Z

And this option is not enabled by default, so existing users won't run into problems either.

Jules-A · 2026-06-04T16:20:54Z

I feel like this is a terrible way to go about it. I currently use a different contrast for SDR (9999999), in reality there's probably not much difference between it and inf but using inf feels wrong. This new option wouldn't even help me.
Wouldn't it be better to just have a separate setting for HDR contrast that overwrites target-contrast in HDR?

I feel like that would help a tonne more people, like those who need to set it to more reasonable values like 1500 for IPS or 3000 for VA ect. while also making it MUCH easier to understand for the same people you were trying to make this for (new users who don't understand auto-profiles).

Headcrabed · 2026-06-04T16:29:08Z

I feel like this is a terrible way to go about it. I currently use a different contrast for SDR (9999999), in reality there's probably not much difference between it and inf but using inf feels wrong. This new option wouldn't even help me. Wouldn't it be better to just have a separate setting for HDR contrast that overwrites target-contrast in HDR?

I feel like that would help a tonne more people, like those who need to set it to more reasonable values like 1500 for IPS or 3000 for VA ect. while also making it MUCH easier for the same people you were trying to make this for (new users who don't understand auto-profiles).

That's also a good idea. @kasper93 what's your opinion on this?

Headcrabed · 2026-06-04T16:32:56Z

I feel like this is a terrible way to go about it. I currently use a different contrast for SDR (9999999), in reality there's probably not much difference between it and inf but using inf feels wrong. This new option wouldn't even help me. Wouldn't it be better to just have a separate setting for HDR contrast that overwrites target-contrast in HDR?

Also I wonder how to achieve this, modify current target-contrast to only SDR and add a new target-contrast-hdr for HDR? Or add two options, target-contrast-hdr and target-contrast-sdr to override target-contrast value?

Jules-A · 2026-06-04T16:55:05Z

Also I wonder how to achieve this, modify current target-contrast to only SDR and add a new target-contrast-hdr for HDR? Or add two options, target-contrast-hdr and target-contrast-sdr to override target-contrast value?

I don't get what's so hard to understand, it would basically just be an override only for HDR. If user doesn't specify anything then don't do anything (defaults to target-contrast), otherwise if it's set and the output is HDR then use the value from target-contrast-hdr (or whatever name) instead.

Headcrabed · 2026-06-04T19:28:11Z

Done. I've switched to use @Jules-A 's idea.

Jules-A · 2026-06-04T20:47:55Z

Well if you were going by my idea, you are still overthinking it, I was just suggesting an override, so there should just be <auto|10-1000000|inf> (is documentation wrong? I can set 9999999). It shouldn't change current behavior by setting it.
Documentation for each setting is a bit unnecessary as you've already mentioned it's the same as target-contrast, so you just need to report the difference.

Documentation is confusing, if your goal is for making it easier for people without technical knowledge can't you just simplify it to something like:

--target-contrast-hdr=<auto|10-1000000|inf>
Same as --target-contrast, but is used to override the --target-contrast
setting when --target-trc is set to a HDR transfer function.
This is useful when the correct contrast ratio can not be automatically
detected due to issues with monitor reported values, color management
implementations or simply wanting a separate value for HDR.
auto is the default and will try to use the detected the value from the
display but will fallback to infinite contrast when using a HDR --target-trc.
(Only for --vo=gpu-next)

Also, assuming you do follow that, couldn't you just do something like this (haven't tested it:

Headcrabed · 2026-06-05T07:46:13Z

Well if you were going by my idea, you are still overthinking it, I was just suggesting an override, so there should just be <auto|10-1000000|inf> (is documentation wrong? I can set 9999999). It shouldn't change current behavior by setting it. Documentation for each setting is a bit unnecessary as you've already mentioned it's the same as target-contrast, so you just need to report the difference.

I don't the value can be not set by default. The struct gl_video_opts is zero initialized so it is always set, so I use no as default value to represent not overriding.

10-1000000 seems to be wrong. 10 / PL_COLOR_HDR_BLACK means 1e7f(10/1e-6f) so it should be 10-10000000. I'll fix that.

Documentation is confusing, if your goal is for making it easier for people without technical knowledge can't you just simplify it to something like:

--target-contrast-hdr=<auto|10-1000000|inf>
Same as --target-contrast, but is used to override the --target-contrast
setting when --target-trc is set to a HDR transfer function.
This is useful when the correct contrast ratio can not be automatically
detected due to issues with monitor reported values, color management
implementations or simply wanting a separate value for HDR.
auto is the default and will try to use the detected the value from the
display but will fallback to infinite contrast when using a HDR --target-trc.
(Only for --vo=gpu-next)

Also, assuming you do follow that, couldn't you just do something like this (haven't tested it:

seems better, thanks.

Jules-A · 2026-06-05T07:55:20Z

I don't the value can be not set by default. The struct gl_video_opts is zero initialized so it is always set, so I use no as default value to represent not overriding.

I mean... it shouldn't override if you do if

if (opts->target_contrast_hdr && pl_color_space_is_hdr(color))
        contrast = opts->target_contrast_hdr;

since if it's 0 it won't override.

Headcrabed · 2026-06-05T07:57:57Z

I don't the value can be not set by default. The struct gl_video_opts is zero initialized so it is always set, so I use no as default value to represent not overriding.

I mean... it shouldn't override if you do if
if (opts->target_contrast_hdr && pl_color_space_is_hdr(color))
        contrast = opts->target_contrast_hdr;
since if it's 0 it won't override.

In this case, if user set target-contrast for SDR, the HDR value would also get changed. We still need a value to let HDR use OS-reported value and still use user-defined value for SDR.

Jules-A · 2026-06-05T08:01:57Z

In this case, if user set target-contrast for SDR, the HDR value would also get changed. We still need a value to let HDR use OS-reported value and still use user-defined value for SDR.

But it's only going to do if using a HDR colorspace (pl_color_space_is_hdr(color))? Or am I mistaken that apply contrast gets changed on colorspace change but instead just gets set once?

Headcrabed · 2026-06-05T08:07:54Z

In this case, if user set target-contrast for SDR, the HDR value would also get changed. We still need a value to let HDR use OS-reported value and still use user-defined value for SDR.

But it's only going to do if using a HDR colorspace (pl_color_space_is_hdr(color))? Or am I mistaken that apply contrast gets changed on colorspace change but instead just gets set once?

It seems applied per-frame, so colorspace change should affect this.

In the code, the max contrast value is defined as 10/PL_COLOR_HDR_BLACK, which actually means 1e7f than 1e6f. So fix the value in documentation. Signed-off-by: Shengyu Qu <wiagn@4d2.org>

Should be helpful for Windows ACM/macOS cases, which only use target-contrast=auto might cause washed out colors. Wayland shouldn't need this since we have mpv-player#17345 Signed-off-by: Shengyu Qu <wiagn@4d2.org>

Headcrabed force-pushed the sdr_inf branch 2 times, most recently from ecc57b5 to 4fde03b Compare June 3, 2026 19:56

Headcrabed force-pushed the sdr_inf branch from 4fde03b to 1542b0c Compare June 4, 2026 11:53

Headcrabed force-pushed the sdr_inf branch from 1542b0c to 24b73cb Compare June 4, 2026 19:26

Headcrabed changed the title ~~vo_gpu_next: Add sdr-inf mode for --target-contrast option~~ vo_gpu_next: add --target-contrast-hdr option Jun 4, 2026

Headcrabed force-pushed the sdr_inf branch from 24b73cb to c69c903 Compare June 4, 2026 19:29

Headcrabed force-pushed the sdr_inf branch 2 times, most recently from c7085ff to 4f73b6a Compare June 5, 2026 08:24

options: fix contrast range for --target-contrast

c9ae860

In the code, the max contrast value is defined as 10/PL_COLOR_HDR_BLACK, which actually means 1e7f than 1e6f. So fix the value in documentation. Signed-off-by: Shengyu Qu <wiagn@4d2.org>

vo_gpu_next: add --target-contrast-hdr option

8b33a40

Should be helpful for Windows ACM/macOS cases, which only use target-contrast=auto might cause washed out colors. Wayland shouldn't need this since we have mpv-player#17345 Signed-off-by: Shengyu Qu <wiagn@4d2.org>

Headcrabed force-pushed the sdr_inf branch from 4f73b6a to 8b33a40 Compare June 9, 2026 18:33

Conversation

Headcrabed commented Jun 3, 2026

Uh oh!

kasper93 commented Jun 3, 2026

Uh oh!

Headcrabed commented Jun 3, 2026

Uh oh!

github-actions Bot commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kasper93 commented Jun 3, 2026

Uh oh!

Headcrabed commented Jun 4, 2026

Uh oh!

kasper93 commented Jun 4, 2026

Uh oh!

Headcrabed commented Jun 4, 2026

Uh oh!

kasper93 commented Jun 4, 2026

Uh oh!

Headcrabed commented Jun 4, 2026

Uh oh!

Headcrabed commented Jun 4, 2026

Uh oh!

Jules-A commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Headcrabed commented Jun 4, 2026

Uh oh!

Headcrabed commented Jun 4, 2026

Uh oh!

Jules-A commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Headcrabed commented Jun 4, 2026

Uh oh!

Jules-A commented Jun 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Headcrabed commented Jun 5, 2026

Uh oh!

Jules-A commented Jun 5, 2026

Uh oh!

Headcrabed commented Jun 5, 2026

Uh oh!

Jules-A commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Headcrabed commented Jun 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

github-actions Bot commented Jun 3, 2026 •

edited

Loading

Jules-A commented Jun 4, 2026 •

edited

Loading

Jules-A commented Jun 4, 2026 •

edited

Loading

Jules-A commented Jun 4, 2026 •

edited

Loading

Jules-A commented Jun 5, 2026 •

edited

Loading