506212 2025-06-26 12:50:19 +0000 Night Color causes green tint in HDR highlights on Wayland 2025-11-07 23:08:46 +0000 1 1 4 Plasma kwin colour-management 6.4.1 Arch Linux Linux RESOLVED FIXED NOR normal --- 1 wszqkzqk kwin-bugs-null nate xaver.hugl https://invent.kde.org/plasma/kwin/-/commit/6acc3934dccf5b4d2618ab04cca064b3d67bd1c2 6.5.3 0 oldest_to_newest 2436566 0 wszqkzqk 2025-06-26 12:50:19 +0000 SUMMARY Night Color causes green tint in HDR highlights on Wayland when enabled STEPS TO REPRODUCE 1. Activate Night Color 2. Display HDR content (such as an unresponsive window) OBSERVED RESULT Bright HDR regions (specular highlights, skies) display with unnatural greenish tint Issue disappears immediately when Night Color is disabled EXPECTED RESULT Night Color temperature adjustment should not affect HDR color accuracy HDR highlights should maintain correct color balance regardless of Night Color state SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 6.4.1 KDE Frameworks Version: 6.15.0 Qt Version: 6.9.1 ADDITIONAL INFORMATION Reproducible: Always GPU: AMD Radeon Vega Mobile Series [Integrated] of Ryzen R7 5800H Display: CSO1602 2436678 1 xaver.hugl 2025-06-26 17:12:39 +0000 Can confirm. I haven't been able to narrow down where exactly that would happen, but afaict at some point in the pipeline we must be clipping to rgb of the actual display capabilities, instead of rgb with the white point for night light. The result is normal white, which in comparison to the rest of the display looks very green. 2467621 2 bug-janitor 2025-11-03 15:27:16 +0000 A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8353 2468139 3 xaver.hugl 2025-11-05 15:39:11 +0000 Git commit d70ee5efc9d6b856a067ed284896481cd59a91ac by Xaver Hugl. Committed on 05/11/2025 at 14:01. Pushed by zamundaaa into branch 'master'. opengl/colormanagement: also clip after tonemapping With night light, the maximum luminance that can be represented in the buffer without color shifts is lower than the value represented by 1.0. When writing into the buffer, OpenGL implicitly clips for us to 1.0, so we end up with an out of bounds value, which ends up causing color shifts when the result is converted to a different white point. To avoid that, explicitly clip to the maximum luminance after tonemapping. M +1 -0 src/core/colorpipeline.cpp M +5 -3 src/opengl/colormanagement.glsl https://invent.kde.org/plasma/kwin/-/commit/d70ee5efc9d6b856a067ed284896481cd59a91ac 2468185 4 xaver.hugl 2025-11-05 18:22:26 +0000 Git commit 6acc3934dccf5b4d2618ab04cca064b3d67bd1c2 by Xaver Hugl. Committed on 05/11/2025 at 17:43. Pushed by zamundaaa into branch 'Plasma/6.5'. opengl/colormanagement: also clip after tonemapping With night light, the maximum luminance that can be represented in the buffer without color shifts is lower than the value represented by 1.0. When writing into the buffer, OpenGL implicitly clips for us to 1.0, so we end up with an out of bounds value, which ends up causing color shifts when the result is converted to a different white point. To avoid that, explicitly clip to the maximum luminance after tonemapping. (cherry picked from commit d70ee5efc9d6b856a067ed284896481cd59a91ac) Co-authored-by: Xaver Hugl <xaver.hugl@kde.org> M +1 -0 src/core/colorpipeline.cpp M +5 -3 src/opengl/colormanagement.glsl https://invent.kde.org/plasma/kwin/-/commit/6acc3934dccf5b4d2618ab04cca064b3d67bd1c2