Created attachment 186086 [details] Night Light at 1900K - picking red color SUMMARY Color picker returns different/wrong colors when night light is enabled and/or ICC profiles are used. STEPS TO REPRODUCE 1. Turn on night light and/or use ICC profile 2. Use color picker OBSERVED RESULT Picked color is different than in application EXPECTED RESULT 3. Picked color is the same as in application (as without night light and ICC profile) SOFTWARE/OS VERSIONS KDE Plasma Version: 6.5.0 KDE Frameworks Version: 6.19.0 Qt Version: 6.10.0 ADDITIONAL INFORMATION Similar issue to https://bugs.kde.org/show_bug.cgi?id=498881 , but for color picker.
Changing this is technically possible, but I'm not entirely sure it should be done. In its current state, the color picker picks colors from the screen, matching what you actually see, not what the application technically provided.
Let me explain. Use cases: User turns on night light (because it's night or just prefers warm colors most of the time) and picks a color from the application (user doesn't see the color correctly at the moment, user but trusts the application that it picks it correctly): - user wants to put picked color in another application as it's color (user doesn't have to see it correctly at this moment, it just trusts the picker is doing the job correctly); when user turns off the night light, user will notice that color differs between source and target (wrong!) - user wants to send picked color to somebody and user trusts the picker is picking the correct color, user doesn't know that they send different color (wrong!) - user wants to "google" about picked color and read description about the color, so the color must be the real color as in source application Similar for ICC profiles: When user calibrates monitor and use ICC profile to see colors correctly, the picked color should not be changed by applying the ICC profile there. User will pick different color from the same application depends which monitor is connected? I think it's errornous. For example: I like color of the background in this application, it's e.g. #123456 (but it'll be different). Another user will measure color in the same application and it will also be different. In this case you can't know the exact color of the application or pixel value in photo (you have to use photo editor for this instead of simple color picker + user doesn't know that picker picks different color). Picked color from kwin's color picker will differ than using built-in color picker e.g. in Krita, this will also be confusing. > matching what you actually see Looks like picked color is not what I actually see, because it doesn't pick color with all graphics operations applied (I guess it doesn't respect gamma), so picked color is incorrect. If the picked color would be correct (with all graphics operations), then the option somewhere in settings to select the behavior maybe will be nice-to-have. Also screenshots and screencasts are fixed, so it's too much inconsistent. --- Additonal info: Color blindness options are also affected (including screenshots and screencasts even in 6.5.0).
If it is used to check how kwin applies colors (by developers, testers), the current behavior could be disabled by default and make it accessible by dbus or env var (just like "show compositing" is now hidden).
I have working patch based on screenshot code, I could create and MR and let's discuss it there - do it?
> > matching what you actually see > > Looks like picked color is not what I actually see, because it doesn't pick > color with all graphics operations applied (I guess it doesn't respect > gamma), so picked color is incorrect. > > If the picked color would be correct (with all graphics operations), then > the option somewhere in settings to select the behavior maybe will be > nice-to-have. It is correct - with low color temperatures and some ICC profiles, the conversion to the output colorspace is lossy, because the framebuffer is fixed point and just clips away negative color values, so sRGB->output->sRGB is just not an identity transform. Along with throwing away the effect night light and ICC profiles have on the color, re-rendering in sRGB also changes the colors of blur and all translucent surfaces. As we did indeed make the same tradeoff for screencasts and screenshots, maybe doing the same for the color picker is the last bad option too. Do make that MR, I'll ping some people on it that might have insight on what artists will want out of this. > Additonal info: Color blindness options are also affected (including > screenshots and screencasts even in 6.5.0). Yes, they're per-window effects atm. That's something I hope to address sooner than later (making it a fullscreen post-processing effect), but it requires completing https://invent.kde.org/plasma/kwin/-/merge_requests/6743 first.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8316
Git commit 134b8e48f11a4eef2264cec72729d9e7438f0c04 by Xaver Hugl, on behalf of Błażej Szczygieł. Committed on 05/11/2025 at 12:58. Pushed by zamundaaa into branch 'master'. plugins/colorpicker: Don't apply color profile for picked color We'll read pixel value the same as in application. This fixes wrong color when using Night Light or ICC profile. Use the same logic as screenshot and screencast. M +1 -0 src/plugins/colorpicker/CMakeLists.txt M +69 -25 src/plugins/colorpicker/colorpicker.cpp M +0 -2 src/plugins/colorpicker/colorpicker.h A +43 -0 src/plugins/colorpicker/colorpickerlayer.cpp [License: GPL(v2.0+)] A +30 -0 src/plugins/colorpicker/colorpickerlayer.h [License: GPL(v2.0+)] https://invent.kde.org/plasma/kwin/-/commit/134b8e48f11a4eef2264cec72729d9e7438f0c04