Closed agyild closed 3 years ago
FWIW, I wouldn't qualify that monitor as a real HDR monitor (I should know, I have one). 4 or 6 backlight zones do not an HDR display make ;).
So, yeah, while it technically will support 10-bit output (with a not-that-great colorspace coverage), I'd basically avoid HDR at all costs on it.
FWIW, I wouldn't qualify that monitor as a real HDR monitor (I should know, I have one). 4 or 6 six backlight zones do not an HDR display make ;).
So, yeah, while it technically will support 10-bit output (with a not-that-great colorspace coverage), I'd basically avoid HDR at all costs on it.
I know it's not a top tier HDR monitor. But I am okay with getting closest results to HDR, it's still slightly better than SDR.
My honest opinion would be that, if you don't know what you're doing, not to play with any of those options. I don't think there's a "one size fits all" solution here because every monitor and every environment is different and it sort of comes down to what you actually want to accomplish, which requires having at least a basic understanding of what's possible.
Such a guide would probably help, but it'd have to be very much broken down by different types of platforms and use cases and I don't know enough about e.g. Windows to write a guide that would even be applicable to you. Maybe I'll give it a shot some day. For now, all I can recommend with a straight face is to just pretend HDR doesn't exist, it's mostly a pointless marketing gimmick anyways.
Your actual peak is probably considerably lower. The peak of my display is supposedly close to 2000nits. In reality, it's coming out at around 1000nits. You can't just crank the brightness, it doesn't quite work like that. There are a lot of variables. Display calibration is very specific.
What I want to do is taking a for instance a HDR1000 content and adapting it to my display's characteristics as much as possible. I am fine with default hable tonemapping. From trial and error I can see that if I don't set target-peak
to a closer value to 600, some of the white content seems to blow and details disappear although everything seems to be brighter. So modifying target-peak
seems the right thing to do. The only problem I have while Windows HDR mode is active overlay elements (OSD & subtitles) in mpv that is normally supposed to be in white, display in gray instead. Also SDR content seems dull while played in HDR (i.e. not equivalent to a YouTube SDR movie playback while HDR mode enabled). If I only could solve those, I could live with how things are by scripting SDR/HDR behavior.
Here is my baseline HDR setup:
So I am wondering how I should move on from here. I have some idea about color calibration, gamuts etc. So I would appreciate it if you could point me in the right direction. I just want a Netflix-app equivalent HDR experience in mpv, that's it.
In SDR, I am just using icc-profile-auto
. Leaving it enabled in HDR causes brightness and colors to blow, so I disable it in HDR.
If you've calibrated it with display Cal to 120nits, did you apply it to Windows as the default? And from my own experience with that exact same setup, you need to apply the adjustment for the i1 and leave everything on auto so it measures everything. It's a colorimeter not a spectrometer.
If you've calibrated it with display Cal to 120nits, did you apply it to Windows as the default? And from my own experience with that exact same setup, you need to apply the adjustment for the i1 and leave everything on auto so it measures everything. It's a colorimeter not a spectrometer.
Yes, it is applied as the default and DisplayCAL manages the profile. I just modified White level to Custom and set 120 nits as the target. And also modified other settings that only affect the profile and calibration quality. Everything else is set to their default or auto values (D6500, 2.2 Gamma etc).
The other thing is, if you're using Windows 10, you don't need an icc. Just let the d3d swapchain do it's work.
I've been having a "dim" everything (interface, video, subtitles, etc) on MPV and don't know if it's related to this issue so I thought I'd post here before making a separate one. The issue is very much like this: https://github.com/microsoft/vscode/issues/68069#issuecomment-461383197
Where it's not a color profile or video playback issue, but just the application overall is dim with an HDR screen. The solution that works there is to add --force-color-profile srgb, but that option doesn't exist here.
Sorry if this isn't the issue everyone is talking aobut here.
I've been having a "dim" everything (interface, video, subtitles, etc) on MPV and don't know if it's related to this issue so I thought I'd post here before making a separate one. The issue is very much like this: microsoft/vscode#68069 (comment)
Where it's not a color profile or video playback issue, but just the application overall is dim with an HDR screen. The solution that works there is to add --force-color-profile srgb, but that option doesn't exist here.
Sorry if this isn't the issue everyone is talking aobut here.
Yep. I am also having the same issue with mpv. Normally white GUI content appears dimmed out while HDR is active.
What GPUs do you guys, have? And how are they configured?
What GPUs do you guys, have? And how are they configured?
Don't think it's relevant since it's probably something in the API level. But still, I use a NVIDIA GeForce GTX 1080.
Well, I have a 2060, Windows 10, HDR enabled, 4:2:2 12bit, no config for HDR stuff and I get a perfect output.
I have recently re-tested the current Windows D3D11 HDR support in general, and by default with PQ you get a target-peak
of 10k, which should (more or less) pass all content through. So in that sense it actually by default works better than expected (I was expecting target-peak
being at 100 nits by default for some reason). So yes, "just make sure your screen is getting detected as the one where the swap chain would get created" and it should auto-work on the most basic level.
If for some reason the HDR mode of your monitor is not getting auto-detected, --d3d11-output-csp=pq
(possibly paired with --d3d11-output-format=rgb10_a2
) is what you'd generally otherwise get with a 10bit+ connected screen with BT.2020+PQ configured,
Some current planned improvements would be:
target-peak
value (but not by default).
target-peak
value (expected max brightness) to the D3D11 swap chain, which should at the end of it go all the way through the wire to help the screen figure out how much it would have to do by itself.Some things that can be useful to people for tweaking their experience from some of my testing sessions:
P cycle tone-mapping
L cycle-values target-peak 100 250 400 800 1000 1500 2500
k add target-peak 50
j add target-peak -50
l show-text ${target-peak}
As for the dim overlay (OSD) components (which includes the OSC, subtitles etc) the general effect can be seen by adjusting target-peak
higher, for example. With HDR output this is generally due to a mess that is "Your white is no longer white in HDR", which is also discussed in ITU-T report BT.2408-3.
In this document, if you look at table 1 - "Nominal levels for PQ and HLG production", it gets explained that the "HDR Reference White" (aka "Graphics White") is now at 203 nits. Thus a standard 100 nit SDR graphics signal (which is what the on-screen overlays such as subtitles or controls would be) would have to be boosted towards the graphics white brightness.
That said, whether this is actually needed or not will heavily depend on various parameters. I seem to have previously been able to replicate grey overlays by just enabling HDR output, but when I just tried to re-test a brightness-boosting PR (#7490) it all seems white enough. Seems to depend on the position of the moon, among other things...
In any case, it'd be nice if someone with the "grey on-screen overlays" issue active could check out that proof-of-concept code and say if the whites at the very least are now properly white (while blacks have of course become dark grey since it just dumbly boosts brightness).
As for the dim overlay (OSD) components (which includes the OSC, subtitles etc) the general effect can be seen by adjusting target-peak higher, for example. With HDR output this is generally due to a mess that is "Your white is no longer white in HDR", which is also discussed in ITU-T report BT.2408-3.
In this document, if you look at table 1 - "Nominal levels for PQ and HLG production", it gets explained that the "HDR Reference White" (aka "Graphics White") is now at 203 nits. Thus a standard 100 nit SDR graphics signal (which is what the on-screen overlays such as subtitles or controls would be) would have to be boosted towards the graphics white brightness.
That said, whether this is actually needed or not will heavily depend on various parameters. I seem to have previously been able to replicate grey overlays by just enabling HDR output, but when I just tried to re-test a brightness-boosting PR (#7490) it all seems white enough. Seems to depend on the position of the moon, among other things...
In any case, it'd be nice if someone with the "grey on-screen overlays" issue active could check out that proof-of-concept code and say if the whites at the very least are now properly white (while blacks have of course become dark grey since it just dumbly boosts brightness).
Instead of boosting can't we have something simple and stupid like sub-color
? Where 1.0
gets mapped to maximum approximate white point. I don't know the current behavior but it should be simple to implement. Just get the maximum white point value at startup and multiply it with subtitle and overlay color multipliers and finally send the signal.
Yea, I've had discussions on this, and I think the next attempt will not attempt to boost, but rather just adjust the adjustment back from linear space to PQ/HLG/whatever.
Also add the control for reference SDR white point. We've discussed it in #4248 - with name sdr-target-peak. But you raise a good point, that the reference defaults are different.
since this question was already discussed and some action were taken, i will close this. if there is still an issue not addressed here please open a new issue.
So I have a Samsung LC27HG70 monitor that apparently supports up to 600 cd/m2. In Windows I want to be able to watch HDR content at optimized settings. I have searched with "mpv + hdr", multiple results including github issues came up from few years back. And the more I read the more I got confused. I tried applying each different setting, they were all okay in a different fashion so I was not sure if I was doing it right. I have noticed if I enable Windows HDR mode and maximize my monitor's brightness and finally set
target-peak
to600
, HDR seems to be okay. But then everything on video overlay gets grayed out. So it obviously seems like a hack instead of a proper fix. I have a .icc profile that was generated in SDR mode and some people suggest enabling it in mpv config, some people suggest playing with hdr-peak and target-x options etc. It's just confusing. And manual only lists each option as a reference, it doesn't tell you what to do. Can you write what one needs to do watch HDR content from scratch with step-by-step instructions along with assumptions (e.g. Your monitor's brightness must be set at 100%, mpv should be fullscreen, Windows HDR should be enabled and calibrated to this etc.) you make for those instructions? How you do it and test it out in your environment?