Separate --target-peak-sdr for SDR content

[unic0rn]

As it is, --target-peak works well with tone mapping and also makes it possible to treat the display as a "HDR in disguise".

But here's the thing. Every half-decent display is a "HDR in disguise" (or rather "half-HDR" - not as bright, not as precise, but not 100nits either). The whole idea of mastering SDR content for 100nits peak is a disaster, people are watching SDR content on their SDR displays with brightness set to the max all the time - what 100nits peak displays are on sale these days? The average for inexpensive monitors is around 250-300.

Some people have much brighter screens though, so --target-peak should work as it does. What I propose is --target-peak-sdr, being "maximum signal level for SDR content only". It may default to 100 for backward compatibility, and should work together with --target-peak, for example if someone has a 800 peak HDR screen, --target-peak=800 --target-peak-sdr=300 should display SDR content at 300 nits max, while tone mapping HDR content to full 800 nits range.

At this point I can't throw target-peak into the config to use different HDR tone mapping settings, because it'll mess with SDR playback. 100nits peak for SDR may be fine for calibration purposes, but it is not for actual video playback.

And a sidenote, --target-peak-sdr should also set the peak brightness for subtitles/OSD. As it is, those are displayed at 100 nits with --target-peak=250 on my SDR screen, which makes little sense - can't imagine that being enough on HDR screens either.

EDIT: just noticed that SDR default has changed from 100 to 203 in master. Makes sense, but that's just an arbitrary default - better than the old one, but considering the amount of different displays people have, my proposal stands.

[lextra2]

If sdr should get its own "target-peak-sdr" setting, I suggest to rename "target-peak" to "target-peak-hdr" for consistency sake.

[unic0rn]

If sdr should get its own "target-peak-sdr" setting, I suggest to rename "target-peak" to "target-peak-hdr" for consistency sake.

Well, not really. In the situation I've described, --target-peak still serves a purpose for SDR content playback, just as it does now - it defines screen's peak brightness, which may be different than the brightness you want to display your SDR content at (--target-peak-sdr), and can be set regardless if it's a SDR or HDR screen. It just so happens that it's also used for HDR content tone mapping, but HDR content doesn't need another setting because it defines full dynamic range so screen's peak brightness is all that's needed. For SDR content you need both screen's peak brightness (--target-peak) and the peak you want your SDR content to be mapped to, which is currently hardcoded at 100 nits (203 nits in master), and which --target-peak-sdr should take care of.

[lextra2]

For SDR content you need both screen's peak brightness (--target-peak) and the peak you want your SDR content to be mapped to, which is currently hardcoded at 100 nits (203 nits in master), and which --target-peak-sdr should take care of.

Ah. Makes sense.

[v-fox]

While it's a good idea to get rid of arbitrary hardcodings I vehemently disagree with statement that "mastering SDR content for 100nits peak is a disaster, people are watching SDR content on their SDR displays with brightness set to the max all the time". None of people I know do that and I target something in range of 80-120. I still need my eyes, thank you very much. Maxing out brightness with displays of 1000:1 contrast, which is all TN & IPS SDR displays, is just silly. Some people would do so, though. Or one can tempt luck with 3000:1 VA SDR displays where 200-300 might make some sense. Many TVs are like that nowadays, I think.

Anyway, good proposal.

[Doofussy2]

I think it would be a good option to have. It would be useful in my case as I run my display in HDR at all times. The new default of 203 is better, but my display is calibrated at around 300nits when playing SDR content. So being able to set that peak would be helpful.

[unic0rn]

While it's a good idea to get rid of arbitrary hardcodings I vehemently disagree with statement that "mastering SDR content for 100nits peak is a disaster, people are watching SDR content on their SDR displays with brightness set to the max all the time". None of people I know do that and I target something in range of 80-120.

You're the minority. There's a reason many people (in general, not mpv users) complain that HDR looks dark to them - but more about that below. Also, 200-300 nits in a dimly lit room is fine - it is bright, correct, but it isn't exactly too bright. And 200-300 nits range was the assumed average. I don't think every 500 nits SDR display owner watches SDR content with the brightness maxed out, but there certainly are people like that as well, I've encountered some. It's obviously too much, but unless you're watching in a completely dark room, black point isn't everything.

And obviously, this whole thing is much more useful for HDR display owners, since unless you have 10bit color precision, you're throwing away details by mapping SDR content to lower peak brightness than the one your display is operating at. Of course HDR to SDR loses details as well, but at least full RGB range gets used. For SDR on SDR, the best way would be to change monitor's settings - not ideal, but technically correct. But then, mpv forces such mapping anyway as soon as --target-peak differs from the hardcoded target for SDR, and the fact that value is hardcoded is actually half of the problem - such mapping is simply suboptimal. Noone wants to blind their users, so such default is safe, but yeah, it definitely should be configurable.

With that out of the way, consider what "mastering SDR content for 100 nits peak is a disaster" means. While I do think that SDR at 100 nits is kinda dim, that's not the whole story. A lot of HDR content, like The Witcher series for example, targets similar average brightness levels to SDR content running at 100 nits peak - there are brighter scenes, there are highlights, but the average brightness is pretty low (because HDR needs plenty of headroom for highlights, and not all HDR displays are 1000+ nits). Yet, even at such low average brightness, that HDR content can look way better than SDR.

Disclaimer for all tonemapped shots forward: --target-peak=250 --tone-mapping=mobius --hdr-compute-peak=no. Obviously, ideal viewing conditions would involve screen calibrated for 250 nits - can't help with that. It's more about differences though.

SDR:

SDR mapped to 100 nits at 250 nits peak display:

HDR mapped to 250 nits peak display:

So yeah, SDR screens have plenty of contrast - contrast that gets wasted. You don't need the whole picture to be overly bright to make it look good, but with 100 nits peak as "the standard" the end result is simply dull.

Overall, I want content to look like this:

Star Trek Picard, HDR mapped to 250 nits peak display. For me, it hits the sweet spot - it isn't too bright, it isn't as dim as The Witcher is in many places, and it's definitely not dull. As far as HDR content goes, it seems to be a rarity though. The Witcher for example - many scenes look great, despite lower average brightness, but many look almost like SDR - they lack that bit of range to maintain proper contrast. Star Trek Picard is different, there every scene looks perfect.

And in case of SDR at 100 nits peak, every scene looks equally dull. So while I prefer a bit dim HDR content over SDR blown out to 200-250 nits (as long as it is proper HDR, not a fake like The Mandalorian for example), I do prefer that blown out SDR to standard 100 nits SDR. SDR just lacks, well, dynamic range, and while blowing it up only masks the problem, as can be seen in The Witcher screenshots, while having negative effect on other things (color accuracy, film grain), it's a compromise.

[v-fox]

You're the minority. There's a reason many people (in general, not mpv users) complain that HDR looks dark to them - but more about that below.

No, I'm not. HDR displays users are minority so far and will be for a while. 200-300 is ridiculously bright for displays with such low contrast, it hurts eyes and looks washed out. And how much of those complains about "HDR displays" them maxing out with 400-500 nits and using some kind of "dynamic contrast" nonsense ?

With that out of the way, consider what "mastering SDR content for 100 nits peak is a disaster" means. While I do think that SDR at 100 nits is kinda dim, that's not the whole story.

Well, 80-120 nits is what sRGB/BT.709/SDR were targetting, apparently because HDR was not a thing then. It's what SDR displays are supposed to have by default which is why it's what SDR should be mastered for.
And then LCD makers decided to boost brightness to fake perception of detail in display shops due to being unable to boost contrast and gamut. Which is how we got default 200-300 nits SDR displays.

Also, I have a bone to pick with modern video mastering. Gamma and brightness looks all out of whack on newer recordings, especially on my simple VA display. Seems not to be a problem on most older content. Not sure if its a problem of sources or mpv's interpretation with default settings but I bet on mostly the former.

I have colour management enabled in Firefox (as much as it allows) and EDID-based colour profiles generated by DisplayCAL (before it was removed from distros due to being python2-only). In your Witcher screenshots, first one looks like having most brightness and contrast, very crisp (but some pink petals seem to clip to white), while third is dimmer (but no clipping) and second is dim (maybe even more so than 3rd) and clipped (which it has no good reason to be). Picard looks dull but not obviously washed-out, not sure if it's player's interpretation's fault or just Holywood's ugly brownish filter's.

But your use-case being the opposite of mine is exact reason why this should be configurable.
This seems to have been already discussed and proposed: #4248 (comment) which led to that commit but no SDR configuration.

[unic0rn]

HDR displays users are minority so far and will be for a while. 200-300 is ridiculously bright for displays with such low contrast, it hurts eyes and looks washed out. And how much of those complains about "HDR displays" them maxing out with 400-500 nits and using some kind of "dynamic contrast" nonsense ?

I was talking about SDR display users. Just earlier this week I had a conversation on reddit with one SDR display user arguing that SDR content looks fine on his 500 nits iMac with brightness maxed out. Insanity, I know. But that's the way it is. And average video content consumer has basically no knowledge about video content mastering nor about how it's supposed to look like.

And granted, by blowing up SDR to 200+ nits I'm not giving a damn about the original intent, but I'm trying to stay within reason, with properly calibrated gamma curve and so on. I just don't consider 100 nits to be enough as far as dynamic range goes, not in this day and age.

In regard to contrast, I respectfully disagree. As I've said, it's not all about black point. Viewing conditions matter, and the further those are from complete darkness, the more it makes sense to boost the brightness, regardless if it's OLED or TN. One could even argue that dynamic range influences image perception way more than pure contrast. Try telling an average person that the same display calibrated towards 100 and 300 nits has almost identical contrast in both cases and they won't believe you. Numbers aren't everything. My 250 nits SDR TN screen definitely doesn't look washed out, and I saw some 600 nits OLEDs and 1000 nits QLEDs, so I know that there are stupidly better displays around. If you're used to staring at 100 nits display for hours, your perception may be different. I've got IPS display in my smartphone set to 1/3 brightness, because at 1/2 it's brighter than my monitor, and at max it's a damn flashlight, so it's not like I'm trying to stare into a photon engine here.

Well, 80-120 nits is what sRGB/BT.709/SDR were targetting, apparently because HDR was not a thing then. It's what SDR displays are supposed to have by default which is why it's what SDR should be mastered for.

And it's why that standard should be long dead already. Current "SDR" displays are more like half-HDR, as far as dynamic range goes. Properly mastered HDR content looks on them much worse than on actual HDR display, but at the same time it's light years ahead of SDR @ 100 nits.

And then LCD makers decided to boost brightness to fake perception of detail in display shops due to being unable to boost contrast and gamut. Which is how we got default 200-300 nits SDR displays.

Which is better than 100 nits max. One can always lower the brightness and have his 100 nits. Most people won't. First comment you've linked mentions 120-160 nits, but that's perhaps for average office user. Second comment suggests 120-160 nits as SDR target, calling 100 nits "rather dark". And what's the current hardcoded target in master? 203 nits. As much as I respect people willing to set it to 100 nits, there are many for whom 203 nits will not be enough. I'm half time programmer, half time gamer/media consumer. For coding, I've got low contrast theme. For everything else, going below 250 nits is just a waste of display capabilities.

So yeah, this can't be hardcoded.

Also, I have a bone to pick with modern video mastering. Gamma and brightness looks all out of whack on newer recordings, especially on my simple VA display. Seems not to be a problem on most older content. Not sure if its a problem of sources or mpv's interpretation with default settings but I bet on mostly the former.

I very much doubt "mpv's interpretation" problem. Silly question, what's your display gamma, 2.2? Because as long as files are properly tagged, mpv shouldn't have a problem. Got Ctrl+r vf toggle format:colorlevels=full in input.conf for those that are not.

I have colour management enabled in Firefox (as much as it allows) and EDID-based colour profiles generated by DisplayCAL (before it was removed from distros due to being python2-only). In your Witcher screenshots, first one looks like having most brightness and contrast, very crisp (but some pink petals seem to clip to white), while third is dimmer (but no clipping) and second is dim (maybe even more so than 3rd) and clipped (which it has no good reason to be). Picard looks dull but not obviously washed-out, not sure if it's player's interpretation's fault or just Holywood's ugly brownish filter's.

Those are mpv screenshots, should be standard sRGB. As mentioned earlier, they're calibrated towards 250 nits peak brightness, so your display should be at least that bright to watch them properly. I can make another ones, calibrated towards different peak, but since most are tonemapped HDR, 100 nits peak is simply not enough.

The "very crisp" first screenshot from The Witcher is standard SDR, as is.
The second one is exactly the same one as first, except mapped to 100 nits on 250 nits display. It's basically the same SDR scene with --target-peak=250 (on mpv with SDR peak hardcoded to 100 nits). No more clipping than in the first screenshot.
Third one is HDR version of that scene, tonemapped for 250 nits peak display.

Point being, when you'll compare first and second screenshot, you'll notice that brightness is the only difference and when watching both at 250 nits screen, first one looks like blown out version of the second one - which it is, only processing went the other way around when creating those screenshots.
When you'll compare second and third though, you'll notice that while the average brightness is almost the same, third one has much higher local contrast between different parts of the scene. That's simply because it's HDR, and despite the fact it's not going anywhere near some insane brightness levels, it can - so it's not trying to squeeze everything into limited dynamic range, flattening it in the process, like the SDR version does.

As for Picard, it's all HDR, so it really has to be seen at 250 nits minimum - below that it's guaranteed to look dull. And yeah, one shot is overselling the "sunny vineyard" feel a bit, but overall I consider the colors there to be very good, accurately presenting lighting in different environments.

It's all about that 100 nits range being pure insanity on current SDR displays. When the content targets 200-250 nits (like those HDR scenes with tone mapping), it suddenly gets a lot more breathing room. It doesn't have to get much brighter on average to look much better, because every minor highlight here and there increases the overall dynamic range. SDR flattens everything into oblivion, which is why it gets that much brighter when blown out to 200+ nits - because relative brightness of some scene elements is different than in HDR, with darker elements being brighter than they should be. It shouldn't be the case (it suggests their tonemapping is worse than what mpv can do), but that's how it is often mastered. If SDR content would be mastered properly towards 200-300 nits, it would look much better by default. As it is, it's artificially limited to 100 nits and suffers.

It may be the reason why some new content looks worse in SDR than it used to - they're mostly filming in HDR now, tonemapping afterwards.

But your use-case being the opposite of mine is exact reason why this should be configurable.

Agreed.

[lextra2]

Also, I have a bone to pick with modern video mastering. Gamma and brightness looks all out of whack on newer recordings, especially on my simple VA display. Seems not to be a problem on most older content. Not sure if its a problem of sources or mpv's interpretation with default settings but I bet on mostly the former.

@v-fox
Reminds me of video games suddenly all using the cancer that is chromatic aberration around the year 2015. The cause is, of course, a new generation of game devs / "colorists" who ain't got much clue what they are doing and just try to leave their stain on the world. Another example would be ui designers who come and go and want to add their "flavor" to a website.

[v-fox]

In regard to contrast, I respectfully disagree. As I've said, it's not all about black point. Viewing conditions matter, and the further those are from complete darkness, the more it makes sense to boost the brightness, regardless if it's OLED or TN. One could even argue that dynamic range influences image perception way more than pure contrast. Try telling an average person that the same display calibrated towards 100 and 300 nits has almost identical contrast in both cases and they won't believe you. Numbers aren't everything.

For me, black point is crucial and I prefer watching something in darker environment. But, yeah, that's how we got SDR with blown up brightness and I hate that trend. If it had contrast capability to match to actually achieve that dynamic range then it would be fine. But even supposedly "HDR" displays are stuck with giant backlight zones and 8-bit encoding (how much of those "10-bit" displays are 8+FRC like TN with its 6+FRC with hardwired whatever dithering ?).

Which is better than 100 nits max. One can always lower the brightness and have his 100 nits. Most people won't. First comment you've linked mentions 120-160 nits, but that's perhaps for average office user. Second comment suggests 120-160 nits as SDR target, calling 100 nits "rather dark". And what's the current hardcoded target in master? 203 nits. As much as I respect people willing to set it to 100 nits, there are many for whom 203 nits will not be enough. I'm half time programmer, half time gamer/media consumer. For coding, I've got low contrast theme. For everything else, going below 250 nits is just a waste of display capabilities.

And @haasn, who made that commit, uses 90 nits :] Ironically, SDR displays that have default brightness blown-out also may have lowered default contrast which decreases dynamic range further. And with random controls it's newer clear where panel's native settings end and distortion due to signal meddling of control board begins.

I very much doubt "mpv's interpretation" problem. Silly question, what's your display gamma, 2.2? Because as long as files are properly tagged, mpv shouldn't have a problem. Got Ctrl+r vf toggle format:colorlevels=full in input.conf for those that are not.

It should be sRGB-compliant on display, in driver and in mpv. And video-output-levels=full should be mpv's default.

Point being, when you'll compare first and second screenshot, you'll notice that brightness is the only difference and when watching both at 250 nits screen, first one looks like blown out version of the second one - which it is, only processing went the other way around when creating those screenshots.
When you'll compare second and third though, you'll notice that while the average brightness is almost the same, third one has much higher local contrast between different parts of the scene. That's simply because it's HDR, and despite the fact it's not going anywhere near some insane brightness levels, it can - so it's not trying to squeeze everything into limited dynamic range, flattening it in the process, like the SDR version does.

Ironically, first one looks just fine to me, clipping notwithstanding. But second looks the worst because, unlike the first where brightness is gradually and naturally distributed, it gets clipped while being dull, it's not even actual white but grey. Third has colour gradation preserved while being dull.

If I would max-out brightness on the display itself, maybe third one would look better but github's background would burn my eyes, it's already not good. Guess, we need that stuff for the compositor too, maybe after Wayland will get itself together and KDE & Gnome devs actually implement that.

As for Picard, it's all HDR, so it really has to be seen at 250 nits minimum - below that it's guaranteed to look dull. And yeah, one shot is overselling the "sunny vineyard" feel a bit, but overall I consider the colors there to be very good, accurately presenting lighting in different environments.

Yeah, alright colours but it's a gloomy day on that vineyard :]

It may be the reason why some new content looks worse in SDR than it used to - they're mostly filming in HDR now, tonemapping afterwards.

Maybe. It almost always looks dull yet overblown and low-contrast to me, I have to decrease brightness and increase gamma in mpv. But I'm not ready for 200-300 nits of white blasting at me.

@lextra2
While I generally agree, I don't get all the hate for chromatic aberration. Of all the cheap visual fads, such as DoF, over-bloom, static full-screen motion-blur, film-grain, ridiculously low LoD & FoV, that one looks just fine to me. What I more concerned about is:

• Abandonment of "dynamic HDR" that predated "HDR" displays and tonemapped scenes to simulate behaviour of eyes and cameras which managed to properly use limited dynamic range SDR LCD displays have (see old HL2 HDR demo). I guess that --hdr-compute-peak does something similar.
• Lack of dithering & debanding when rendering at 16-32 bits and throwing it out on 8-bit screens which is especially bad on grey gradients. And coupled with VA's slow-response artifacts…

[unic0rn]

@v-fox throw those screenshots at fullscreen, then rise brightness to ~250 nits. they're 1080p for a reason (originally jpeg though, but it's not a disaster and shows what needs to be shown).

[v-fox]

throw those screenshots at fullscreen, then rise brightness to ~250 nits. they're 1080p for a reason (originally jpeg though, but it's not a disaster and shows what needs to be shown).

Yeah but that wouldn't make such settings any less impractical. I can't change physical brightness every time I run a player.

[unic0rn]

watching them in a window, with reduced peak brightness, when they're mostly tonemapped HDR shots, makes limited sense as well.

sidenote regarding games, the biggest HDR-related abomination these days are games tonemapping to... you've guessed it, 100 nits SDR. not all, but at least some. like they couldn't implement damn peak slider for SDR like they do for HDR. difference between SDR straight out of, for example, Gears 5, compared to properly tonemapped HDR output from that game, is simply insane.

[v-fox]

watching them in a window, with reduced peak brightness, when they're mostly tonemapped HDR shots, makes limited sense as well.

That's the thing though: on SDR display it's not reduced.

sidenote regarding games, the biggest HDR-related abomination these days are games tonemapping to... you've guessed it, 100 nits SDR. not all, but at least some. like they couldn't implement damn peak slider for SDR like they do for HDR. difference between SDR straight out of, for example, Gears 5, compared to properly tonemapped HDR output from that game, is simply insane.

Well, that's the consequence of hardcoding for 1000:1 TN & IPS LCD 96dpi (say hello to miniscule non-scaled text) displays and just removing any adaptation code. I'm baffled by what comes into their heads since year 2010 and how good ideas leave never to be back again.

It would be better if games, players and all GUI apps just rendered in some absolute colour space (RGB 16f/32f for full visible spectrum + "translucency & self-luminance" for everyone !) and let compositor down-sample and correct stuff for output devices. But that would require Wayland-like spec for Windows & Linux & MacOS with already implemented colour-correction protocol.