Created attachment 177523 [details] screenshot with night light on SUMMARY Night Light makes colors less vibrant on screenshots and recordings. I don't remember whether this used to be the case on 6.2, but I'd been using pre-6.3 Plasma for a very long time, testing all sorts of things, and do not remember noticing anything off there. However, I've noticed this while testing a video game's performance (my friend noticed the weird colors on my screenshots). STEPS TO REPRODUCE 1. Enable Night Light 2. Take a screenshot or record a video 3. Disable Night Light 4. Take a screenshot or record a video OBSERVED RESULT Captures from steps 2. and 4. look different; 4. looks okay, while 2. is washed out I'll attach two screenshots for easy comparison. One thing to note is that with night light on, when viewing the two screenshots, they don't look too different. The difference is only visible with night light off. EXPECTED RESULT Captures from steps 2. and 4. shouldn't look too different, or should ideally be the same SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.2.90 KDE Frameworks Version: 6.10.0 Qt Version: 6.9.0 Kernel Version: 6.12.10-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT
Created attachment 177524 [details] screenshot with night light off
Created attachment 177525 [details] the exact color I chose for testing
I wrote a small test to check this out without screenshotting, and it shows that green and blue are very slightly negative when converting to the night light adjusted colorspace at like 5000K, and become *very* negative at very low color temperatures. With an sRGB display it starts to be relevant at roughly 2500K, and at 1500K the color you used for testing ends up as -6'000'000. Using floating point numbers for the calculations back and forth, the transformations even out, but in compositing, colors are normally clamped to [0, 1], so the transformation back to the sRGB whitepoint makes the color more blue than it was before. Below 2000K, things are expected to be bad, as it's just plain impossible for an sRGB display to show that white point. 2000K and 2500K are still inside the gamut, but they're quite close to the edges and I'm afraid that making things weird might be inherent to how colors work. The only proper fix for this bug would be to just prevent the whitepoint from getting that extreme. I'll have to look if there's a feasible non-proper fix that keeps color temperature values that low working.
*** Bug 503824 has been marked as a duplicate of this bug. ***
> The only proper fix for this bug would be to just prevent the whitepoint from getting that extreme. I'll have to look if there's a feasible non-proper fix that keeps color temperature values that low working. To revise that, we could also re-render the scene for screenshots and screencasts directly in the target color space. That's a somewhat large project and would reduce screencast performance to some degree, but it which would avoid such errors at least on applications that don't do color management themselves.
Git commit f9d854bc629e3f682d848f7d15cd362436bb2e6b by Xaver Hugl. Committed on 30/07/2025 at 12:59. Pushed by zamundaaa into branch 'master'. plugins/screencast: also re-render the scene for region screencasts M +50 -118 src/plugins/screencast/regionscreencastsource.cpp M +8 -18 src/plugins/screencast/regionscreencastsource.h M +2 -2 src/scene/workspacescene.cpp https://invent.kde.org/plasma/kwin/-/commit/f9d854bc629e3f682d848f7d15cd362436bb2e6b
Git commit 68c41eed7df7d13e3e7881e807680683c6c40456 by Xaver Hugl. Committed on 30/07/2025 at 12:59. Pushed by zamundaaa into branch 'master'. plugins/screencast: re-render the scene for output screencasts This removes the requirement for the output to provide a single buffer for its contents, allows for color management operations to directly target the stream, and opens up the possibility of hiding items from the scene in the future. M +12 -2 src/core/outputlayer.cpp M +3 -0 src/core/outputlayer.h M +1 -0 src/plugins/screencast/CMakeLists.txt M +51 -41 src/plugins/screencast/outputscreencastsource.cpp M +12 -3 src/plugins/screencast/outputscreencastsource.h M +4 -2 src/plugins/screencast/regionscreencastsource.cpp M +2 -2 src/plugins/screencast/regionscreencastsource.h A +47 -0 src/plugins/screencast/screencastlayer.cpp [License: GPL(v2.0+)] A +30 -0 src/plugins/screencast/screencastlayer.h [License: GPL(v2.0+)] M +2 -2 src/plugins/screencast/screencastsource.h M +3 -3 src/plugins/screencast/screencaststream.cpp M +5 -3 src/plugins/screencast/windowscreencastsource.cpp M +2 -2 src/plugins/screencast/windowscreencastsource.h https://invent.kde.org/plasma/kwin/-/commit/68c41eed7df7d13e3e7881e807680683c6c40456
*** Bug 508138 has been marked as a duplicate of this bug. ***
Git commit 7f1ac1136e72b1b404235477dc20014ef3bd522f by Xaver Hugl. Committed on 03/09/2025 at 12:05. Pushed by zamundaaa into branch 'master'. plugins/screenshot: render the scene from scratch, instead of blitting This allows us to skip intermediary colorspace transformations, which avoids information loss with night light, and allows for tone mapping of HDR content to be applied for each window as needed. M +1 -0 src/plugins/screenshot/CMakeLists.txt M +138 -314 src/plugins/screenshot/screenshot.cpp M +4 -43 src/plugins/screenshot/screenshot.h M +22 -135 src/plugins/screenshot/screenshotdbusinterface2.cpp M +0 -2 src/plugins/screenshot/screenshotdbusinterface2.h A +43 -0 src/plugins/screenshot/screenshotlayer.cpp [License: GPL(v2.0+)] A +30 -0 src/plugins/screenshot/screenshotlayer.h [License: GPL(v2.0+)] https://invent.kde.org/plasma/kwin/-/commit/7f1ac1136e72b1b404235477dc20014ef3bd522f
*** Bug 511134 has been marked as a duplicate of this bug. ***