https://bugs.kde.org/show_bug.cgi?id=506645
--- Comment #10 from [email protected] --- (In reply to Zamundaaa from comment #7) > (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. thx, does look better, also using KWIN_DISABLE_TONEMAPPING=1 still need to test without it, using 250 nits on the second calibration screen, i will keep comparing vs my PS5 then because it does seem to have the "best" presentation, may take a few days -- You are receiving this mail because: You are watching all bug changes.
