| Summary: | Using ENABLE_HDR_WSI=1 with HDR mode disabled results in blacks being slightly luminated with mpv | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | FK <fk-kde-bugs> |
| Component: | colour-management | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | nate, syboxez, xaver.hugl |
| Priority: | NOR | ||
| Version First Reported In: | 6.2.1 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/f702ad9c4cee58e8e438e3d22ff202a80ac8b3ff | Version Fixed/Implemented In: | 6.2.3 |
| Sentry Crash Report: | |||
|
Description
FK
2024-10-16 09:56:17 UTC
Could you attach the command line output when you run mpv? It should print some HDR metada, which KWin may be using to do black point compensation (wrong) (In reply to Zamundaaa from comment #1) > Could you attach the command line output when you run mpv? It should print > some HDR metada, which KWin may be using to do black point compensation > (wrong) [HDR Layer] Created HDR surface [HDR Layer] Enabling format: 64 colorspace: 1000104008 [HDR Layer] Enabling format: 58 colorspace: 1000104008 [HDR Layer] Enabling format: 97 colorspace: 1000104002 [HDR Layer] Enabling format: 97 colorspace: 1000104005 [HDR Layer] Enabling format: 64 colorspace: 1000104008 [HDR Layer] Enabling format: 58 colorspace: 1000104008 [HDR Layer] Enabling format: 97 colorspace: 1000104002 [HDR Layer] Enabling format: 97 colorspace: 1000104005 btw. with HDR display mode enabled, it looks OK. hmm, I wasn't able to reproduce this; on my external monitor, the default black bars in mpv turn off the local dimming (which I force-enabled in SDR mode), and I don't see a difference vs. SDR application's black levels. Are you using an ICC profile? (In reply to Zamundaaa from comment #3) > hmm, I wasn't able to reproduce this; on my external monitor, the default > black bars in mpv turn off the local dimming (which I force-enabled in SDR > mode), and I don't see a difference vs. SDR application's black levels. > > Are you using an ICC profile? No, ICC profile is "None". I left these lines out: HDR Layer] Creating swapchain for id: 5 - format: VK_FORMAT_R16G16B16A16_UNORM - colorspace: VK_COLOR_SPACE_SRGB_NONLINEAR_KHR [HDR Layer] Creating swapchain for id: 5 - format: VK_FORMAT_R16G16B16A16_UNORM - colorspace: VK_COLOR_SPACE_SRGB_NONLINEAR_KHR My command looks like this: ENABLE_HDR_WSI=1 mpv <file> --no-config --background-color='#00000000' --target-colorspace-hint=yes --vo=gpu-next --gpu-context=waylandvk with display HDR enabled it looks fine, without it, the black bars are blacker than the content (due to alpha values being set to 00. Without background-color they'd be slightly gray as well). As a workaround for now I just set gpu-context=wayland instead of waylandvk for SDR content - this way the vk layer isn't used and SDR looks alright again.
With profile-cond=get("video-params/sig-peak", 0) > 1 waylandvk is set and HDR gets enabled through a lua script and kscreen-doctor.
Btw. I have had the issue of enabling HDR sometimes not properly triggering the display since the inception of HDR in kwin. This happens when I turn it off and on again, it appears it's not sending the proper mode to the display. The HDR logo doesn't show and colors are washed out.
I think I see how this could happen; if the min. luminance HDR metadata is zero, but the transfer function's minimum is not completely zero, then that minimum would be mapped to a value >0 by black point compensation. (In reply to FK from comment #5) > Btw. I have had the issue of enabling HDR sometimes not properly triggering > the display since the inception of HDR in kwin. This happens when I turn it > off and on again, it appears it's not sending the proper mode to the > display. The HDR logo doesn't show and colors are washed out. That's a GPU driver bug, which you can report at https://gitlab.freedesktop.org/drm/amd/-/issues A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6656 Please test that MR, to see if it actually helps This seems to fix it for me. Thanks! *** Bug 494907 has been marked as a duplicate of this bug. *** Git commit cef6656ff57e19e7eb551f81ee5b03028a7f38a9 by Xaver Hugl. Committed on 24/10/2024 at 14:10. Pushed by zamundaaa into branch 'master'. core/colorspace: ensure that we don't create elevated blacks with black point compensation There are cases where the minimum luminance can be lower than the transfer function's minimum; in those cases, the transfer function's minimum would get mapped to a value greater than black in the target transfer function. To avoid that, this just takes the max. of the metadata and transfer function minimum M +1 -1 autotests/test_colorspaces.cpp M +5 -2 src/core/colorspace.cpp https://invent.kde.org/plasma/kwin/-/commit/cef6656ff57e19e7eb551f81ee5b03028a7f38a9 Git commit f702ad9c4cee58e8e438e3d22ff202a80ac8b3ff by Xaver Hugl. Committed on 24/10/2024 at 14:27. Pushed by zamundaaa into branch 'Plasma/6.2'. core/colorspace: ensure that we don't create elevated blacks with black point compensation There are cases where the minimum luminance can be lower than the transfer function's minimum; in those cases, the transfer function's minimum would get mapped to a value greater than black in the target transfer function. To avoid that, this just takes the max. of the metadata and transfer function minimum (cherry picked from commit cef6656ff57e19e7eb551f81ee5b03028a7f38a9) M +1 -1 autotests/test_colorspaces.cpp M +5 -2 src/core/colorspace.cpp https://invent.kde.org/plasma/kwin/-/commit/f702ad9c4cee58e8e438e3d22ff202a80ac8b3ff |