wayland_common: for HDR output always prefer PQ transfer

[kasper93]

Fixes: #16972

[Headcrabed]

Hmmm do we still prefer PQ transfer even when video itself is SDR?

[kasper93]

Hmmm do we still prefer PQ transfer even when video itself is SDR?

Yes, see --target-colorspace-hint-mode

[mahkoh]

The values from the luminance event are not indicative of "HDR". They only tell you how things should be encoded, not the permitted/useful range of the values. For that you should probably check if the max target luminance is higher than the reference luminance.

[kasper93]

Do you mean wl->preferred_csp.hdr.max_luma > wd->ref_luma?

[mahkoh]

IIRC yes.

[mahkoh]

That being said, there is no actual way to detect "HDR" in the wayland protocol. This is only a heuristic that is likely going to work.

[kasper93]

That being said, there is no actual way to detect "HDR" in the wayland protocol. This is only a heuristic that is likely going to work.

Well, @Zamundaaa says, this is the way.

[Zamundaaa]

Just so we are on the same page. By "adjusting brightness" I change the backlight strength on my laptop screen.

Yes, ish. You adjust a config value in KWin that gets used as the base value for the backlight. When content with max luminance > reference is shown, we increase the backlight beyond that, to be able to show the requested luminance, while the color management pipeline keeps the reference luminance at roughly the same luminance. I wrote a blog post about this before, maybe that helps.

Making it produce physically less light output, so I'm confused why Wayland reports higher luminance values for this case (bigger hdr headroom). I don't know how KWin handles that, maybe there is some compensation math, but from mpv point of view it's not compatible with what we do.

Like I said, KWin atm just assumes reference == 200 on SDR displays, so in order to tell apps that there is HDR headroom, it has to increase the reported max luminance.

Keep in mind that none of these values have all that much physical meaning. Just like sRGB isn't actually presented at 80cd/m² in the majority of cases, the image description from the compositor basically describes a video standard that the app should target, and how that's mapped to the screen is up to the compositor.

I want to make it closer to what SDR displays really do, but the current release of KWin just doesn't do that.

I mean sure we can tell mpv to tone map to 600 nits, but I don't see those highlights or anything popping out. Everything is brighter and look better when tonemapping to 200 nits and using full brightness of screen.

There's two possibilities for how that could happen:

• the manufacturer of your laptop tried to be "helpful" and made the backlight curve very non-linear, in which case the EDR feature won't work too well
• mpv reports HDR metadata that doesn't match the preferred image description, so KWin applies tonemapping on top and dims the highlights

I tested with mpv --vo=gpu-next --target-colorspace-hint=yes --hwdec=auto-safe /path/to/video and it works fine here. Wayland debug output shows that mpv is doing everything correctly.

You can check with cat /sys/class/drm/card1-eDP-1/amdgpu_bl1/brightness (Intel will have something similar) whether or not the backlight actually gets changed. If it doesn't get adjusted, maybe something else is broken.

[kasper93]

Yes, ish. You adjust a config value in KWin that gets used as the base value for the backlight. When content with max luminance > reference is shown, we increase the backlight beyond that, to be able to show the requested luminance, while the color management pipeline keeps the reference luminance at roughly the same luminance. I wrote a blog post about this before, maybe that helps.

Yes, I see. I kinda expected something like this.

Keep in mind that none of these values have all that much physical meaning. Just like sRGB isn't actually presented at 80cd/m² in the majority of cases, the image description from the compositor basically describes a video standard that the app should target, and how that's mapped to the screen is up to the compositor.

Fair. It actually does work as expected. I guess if I dim screen too much it does make it look "worse". You need to find the sweet spot where max highlight produces max brightness of the screen, to fully utilize the backlight. It's about 35% looking at it. It doesn't look of course too good, it's still a SDR screen, and quite old at that.

You can check with cat /sys/class/drm/card1-eDP-1/amdgpu_bl1/brightness (Intel will have something similar) whether or not the backlight actually gets changed. If it doesn't get adjusted, maybe something else is broken.

Yes, I did now and it does what advertised. One thing you can do with mpv is set --target-colorspace-hint-mode=source-dynamic to send per-scene metadata to compositor. It creates local dimming (with 1 zone) :) In default config =target we send constant tone-mapped luminance as reported by preferred desc. For this to fully drive the backlight it would need to report actual lumiance when < max_lum, but at the same time tonemap when > max_lum. This would need another mode in mpv, if we want to tone-map internally.

[Zamundaaa]

One thing you can do with mpv is set --target-colorspace-hint-mode=source-dynamic to send per-scene metadata to compositor. It creates local dimming (with 1 zone) :)

Oh, that's really cool.

[kkanungo17]

@kasper93 Would you recommend source-dynamic over target for best utilization of the backlight for now? Or have it still at target with target-peak set to max brightness?

[kasper93]

source-dynamic depends on a lot of factors, how fast your screen can adapt to new metadata or in case of KWin how fast compositor can react. It may produce classic dimming fluctuations. Especially on screens where backlight strength is visible well in black level.

I prefer target for consistent light output and mpv tonemapping.

I might add target-dynamic, but all the dynamic modes are kinda experimental.

target-peak set to max brightness?

You need to test, it's probably better to use reported value by compositor instead of manually setting it. Now we have it on all platforms, except macOS.

[K1aymore]

This also seems to switch to PQ when on an SDR display and the brightness in Plasma is less than 100%, since the reported max luminance increases and becomes higher than the reference luminance. On SDR displays it looks the same as gamma2.2, while on my HDR display PQ looks different depending on --tone-mapping (mobius matches gamma2.2). I'm not sure if #17070 intends to optimize for SDR displays and avoid extra conversions, or if it's possible to detect that anyway.

[kasper93]

This also seems to switch to PQ when on an SDR display and the brightness in Plasma is less than 100%, since the reported max luminance increases and becomes higher than the reference luminance. On SDR displays it looks the same as gamma2.2, while on my HDR display PQ looks different depending on --tone-mapping (mobius matches gamma2.2). I'm not sure if #17070 intends to optimize for SDR displays and avoid extra conversions, or if it's possible to detect that anyway.

This is as expected. When you lower display brightness, KDE will act as if this display is HDR (EDR in fact) and use the headroom for HDR highlights. You can disable EDR in display settings.

Of course they don't know the display parameters, nor they know how much headroom you can produce by reducing brightness. So the result will heavily depend on your display.

From your description, everything works as expected, if you see an issue please report full issue with specific scenario that should work differently.