SUMMARY Peak HDR brightness is broken, it has been broken for a while, ever since HDR brightness began being tied to SDR brightness (or thereabouts) i only noticed recently however how broken it actually was by comparing it against Windows 11 and PS5, bright clear colors close to white, like a sun, looks completely washed out on MPV, it even affects contrast of other scenes. STEPS TO REPRODUCE MPV settings used mpv --vo=gpu-next --target-colorspace-hint --gpu-api=vulkan --gpu-context=waylandvk 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 OBSERVED RESULT 1. Contrast is broken on the elevator scene at 0:34 2. At 0:40 scene with Sun peeking over the top of the pantheon, peak brightness is muted, looks washed out and doesn't look too different in brightness and contrast from the rest of the scene, looks almost SDR like, beams of light look bloomy and present the same problem. EXPECTED RESULT Best way to compare is using Windows 11 with Chrome or Edge or a PS5, contrast is starker and looks appropriate. albeit panel quality dependent, the sun scene should look significantly brighter than the rest of the image. SOFTWARE/OS VERSIONS Windows: Windows 11 Linux/KDE Plasma: 6.4.2 KDE Plasma Version: 6.4.2 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 ADDITIONAL INFORMATION -Monitor used was a aw2725df, with it being oled when i said above that "beams of light look 'bloomy'" its because of the HDR presentation and nothing to do with dimming zones -Already tried all calibration configurations possible, with the first page being 1000 nits and the second page being whatever, from 0 to 100) -Also already tried setting color accuracy to prefer color accuracy, RGB range to Full or limited and limiting color resolution -Tried changing settings on MPV as well, like using target-peak=1000 or target-prim=bt.2020 and target-trc=pq
I cannot reproduce this, on KDE 6.4.3, using an Asus XG27UCS monitor. Though I experienced different bugs with HDR calibration settings which I will report in their own issue. With my HDR settings at the display's detected peak value of 486 and with the SDR brightness level manually set down to 203.
I'm experiencing an issue that fits this description with HDR games. Both with Gamescope and Proton-GE's Wayland option, I'm seeing Elden Ring Nightreign and Like a Dragon Gaiden have muted highlights on both my monitor (AOC Q27G40XMN) and TV (TCL QM851G). As Mini-LED displays, I wouldn't expect ABL to be a factor. Standalone Gamescope and Hyprland do not have this issue.
I stand corrected, I can reproduce this. When I was reporting before, I had a misconfigured SDR brightness. However, the brightness seems fine with tev (https://github.com/Tom94/tev) but not with mpv, or gamescope, or Proton EM or GE using HDR Wayland mode. Also seems fine with the Wayland color-management-v1 patch set applied to Chromium dev channel. Cannot reproduce the squashed peak on labwc with my patch sets applied. GNOME is broken in a different way, by the way. The Chromium HDR patch set seems to only achieve Display P3 color range, but the HDR images and videos on wide-gamut.com are squashed to P3, not display peak.
Ugh. This looks like it could be a culprit: ``` m_shader->setUniform(GLShader::FloatUniform::MaxDestinationLuminance, inputColor.transferFunction().maxLuminance); ``` maxLuminance of the input color? Also, while this will be 10,000 nits for PQ, this value will likely be 80 for both sRGB and for the locally generated transfer function returned by get_windows_scrgb.
In the meantime, `KWIN_DISABLE_TONEMAPPING=1` gets around the issue for me.
(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. If it's failing even when tonemapping to the absolute peak brightness of the display, something else is wrong with the whole tonemapping thing. :/
(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.
Okay, here's kscreen-doctor: > > kscreen-doctor -o > Output: 1 DP-1 d0a9f63f-3e58-4dca-b04d-58294a36774e > enabled > connected > priority 1 > DisplayPort > replication source:0 > Modes: 1:3840x2160@60! 2:3840x2160@160* 3:3840x2160@144 4:3840x2160@120 5:3840x2160@120 6:3840x2160@120 7:3840x2160@100 8:3840x2160@60 9:3840x2160@60 10:3840x2160@50 11:3840x2160@30 12:3840x2160@30 13:3840x2160@25 14:3840x2160@24 15:3840x2160@24 16:2560x1440@160 17:2560x1440@120 18:2560x1440@60 19:1920x1200@60 20:1920x1080@120 21:1920x1080@120 22:1920x1080@100 23:1920x1080@60 24:1920x1080@60 25:1920x1080@60 26:1920x1080@50 27:1920x1080@30 28:1920x1080@30 29:1920x1080@25 30:1920x1080@24 31:1920x1080@24 32:1600x1200@60 33:1680x1050@60 34:1280x1024@60 35:1440x900@60 36:1280x960@60 37:1280x800@60 38:1280x720@60 39:1280x720@60 40:1280x720@60 41:1280x720@50 42:1024x768@75 43:1024x768@60 44:800x600@75 45:800x600@60 46:720x576@50 47:720x576@50 48:720x480@60 49:720x480@60 50:720x480@60 51:720x480@60 52:640x480@75 53:640x480@60 54:640x480@60 55:640x480@60 56:1600x1200@160 57:1280x1024@160 58:1024x768@160 59:2560x1600@60 60:2560x1600@160 61:1920x1200@160 62:1280x800@160 63:3200x1800@60 64:3200x1800@160 65:2880x1620@60 66:2880x1620@160 67:1920x1080@160 68:1600x900@60 69:1600x900@160 70:1368x768@60 71:1368x768@160 72:1280x720@160 > Geometry: 0,0 2259x1271 > Scale: 1.7 > Rotation: 1 > Overscan: 0 > Vrr: Automatic > RgbRange: Automatic > HDR: enabled > SDR brightness: 203 nits > SDR gamut wideness: 0% > Peak brightness: 486 nits, overridden with: 486 nits > Max average brightness: 486 nits > Min brightness: 0.0969 nits > Wide Color Gamut: enabled > ICC profile: none > Color profile source: EDID > Color power preference: prefer efficiency and performance > Brightness control: supported, set to 100% and dimming to 100% > DDC/CI: allowed > Color resolution: automatic (10), range: [8; 16] bits per color > Allow EDR: unsupported > Output: 2 DP-2 edd03ce9-e04e-4b8a-b059-21bfc6db47aa > enabled > connected > priority 2 > DisplayPort > replication source:0 > Modes: 73:3840x2160@60*! 74:3840x2160@30 75:2560x1440@60 76:1920x1200@60 77:1920x1080@60 78:1920x1080@60 79:1920x1080@60 80:1600x1200@60 81:1680x1050@60 82:1600x900@60 83:1280x1024@60 84:1440x900@60 85:1280x800@60 86:1152x864@60 87:1280x720@60 88:1280x720@60 89:1280x720@60 90:1024x768@60 91:800x600@60 92:720x480@60 93:720x480@60 94:640x480@60 95:640x480@60 96:640x480@60 97:2560x1600@60 98:3200x1800@60 99:2880x1620@60 100:1368x768@60 > Geometry: 2259,0 1920x1080 > Scale: 2 > Rotation: 1 > Overscan: 0 > Vrr: Automatic > RgbRange: Automatic > HDR: incapable > Wide Color Gamut: incapable > ICC profile: /home/chris/.config/color/icc/devices/display/LGUltraHD.icc > Color profile source: ICC > Color power preference: prefer efficiency and performance > Brightness control: supported, set to 50% and dimming to 100% > DDC/CI: allowed > Color resolution: automatic (10), range: [8; 16] bits per color > Allow EDR: unsupported
I am using mpv, with: > hwdec=auto > vo=gpu-next > gpu-api=vulkan > gpu-context=waylandvk > profile=high-quality > target-colorspace-hint > ytdl-format=bestvideo[vcodec^=av01]+bestaudio/bestvideo[vcodec!^=av01]+bestaudio/best > ytdl-raw-options-append="cookies=<path to cookies file>" > cookies=yes > cookies-file=<path to cookies file> > slang=eng,en > screenshot-format=jxl And I am also testing Proton EM and GE using the combined Wayland and HDR options. Strangely enough, using tev to view images results in correct brightness mapping.
(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
I was comparing versus disabled tonemapping, and also versus labwc/wlroots, which also doesn't do tonemapping.
(In reply to Zamundaaa from comment #7) > Either way, please re-test with mpv's dmabuf-wayland backend, it seems to > behave much better. `dmabuf-wayland` resolves the flickering... but the screen also goes completely black on fullscreen for me when the OSD fades. Besides, gpu-next is the only way to access a bunch of different options, especially the more recent HDR stuff. KWin and / or AMD seem to be the culprit here.
And thus, I figured out why the tonemapping is sometimes "not" the problem: According to the tonemapping MR implementation, it is already bypassed by direct scanout. There are probably other things that can bypass it.
Here are a couple of gamma related bug reports related to AMD and Kwin that seem to only affect HDR: https://gitlab.freedesktop.org/drm/amd/-/issues/4444 https://invent.kde.org/plasma/kwin/-/commit/d2df32c9c664023bb6a1409dbaecbd3078dbaaec
(In reply to Christopher Snowhill from comment #13) > And thus, I figured out why the tonemapping is sometimes "not" the problem: > According to the tonemapping MR implementation, it is already bypassed by > direct scanout. There are probably other things that can bypass it. Direct scanout does not bypass tone mapping, that was just an issue while the MR was still WIP.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!