https://bugs.kde.org/show_bug.cgi?id=506645
Zamundaaa <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Status|REPORTED |NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #7 from Zamundaaa <[email protected]> --- (In reply to Christopher Snowhill from comment #4) > Ugh. This looks like it could be a culprit: > > ``` > m_shader->setUniform(GLShader::FloatUniform::MaxDestinationLuminance, > inputColor.transferFunction().maxLuminance); > ``` That's from the ICC shader, where input and output max luminance must be the same. (In reply to Christopher Snowhill from comment #6) > (In reply to Dominick DiMaggio from comment #5) > > In the meantime, `KWIN_DISABLE_TONEMAPPING=1` gets around the issue for me. > > So I was correct that it was the tonemapping filter. But I think the real > culprit, if tonemapping is to be used at all, is that it's tonemapping to > the SDR brightness range, when it should be tonemapping to the configured > peak brightness level, which is the first setting in the HDR tuner. This > setting is supposed to be autodetected from the display, but can be > overridden. It's not mapping to the SDR range, unless you configured your display to be equivalent to an SDR one (reference = max luminance). What kind of settings are you using? Please attach the output of kscreen-doctor -o, and be specific about which software/media you're using. The combination of display capabilities + configuration + content HDR metadata define how colors are mapped to the display, without knowing all the details, it's hard to figure out what's happening. (In reply to bio3c from comment #0) > Best video to reproduce this issue is this one: > https://www.youtube.com/watch?v=72_rYwzLhjk or search for "LG Oled 2021 4K > HDR PEAK Brightness Test | Chasing The Light Via Samsung TV" on youtube > -Already tried all calibration configurations possible, with the first page > being 1000 nits and the second page being whatever, from 0 to 100) That video has max. mastering display luminance of 1000 nits, so with max sdr brightness of <= 100 nits, there should definitely not be any KWin-side tone mapping, only a multiplier for the brightness. Note that comparisons with Windows are not particularly useful, it does HDR quite badly (which is to say, usually too bright, but sometimes too dark) unless your brightness settings happen to perfectly match the room the HDR video was created for. Maybe try configuring your phone to have the same brightness as the screen (comparing the white background on some website, not the HDR video), and then watch the same video side by side. I also tested > MPV settings used mpv --vo=gpu-next --target-colorspace-hint --gpu-api=vulkan > --gpu-context=waylandvk side by side with > mpv --vo=dmabuf-wayland --hwdec=auto-safe and gpu-next looks noticeably darker. The HDR metadata that KWin gets is the same in both cases, so maybe gpu-next is doing tone mapping, doesn't adjust the HDR metadata though, and then gets tone-mapped again by KWin? Though it shouldn't matter in your case, where the display luminance range is much greater than the video... Either way, please re-test with mpv's dmabuf-wayland backend, it seems to behave much better. -- You are receiving this mail because: You are watching all bug changes.
