Created attachment 188982 [details] glitch I use a dual screen setup where each monitors uses an ICC profile which after applied makes the color tone colder than the uncalibrated stock. When such profile is used the color uncorrected image pops in under some specific (albeit not 100% identified) conditions. One example is included from the attached file, it is simple-scan scanner application, where you can see that while the dropdown menu is showing it appears as yellowish, which is the color it would have witouth any ICC profile applied. STEPS TO REPRODUCE 1. apply an ICC profile to the screen un der Wayland 2. set color precision to high 3. open simple scan and in its preferences pull down the menu as showin in the attachment. OBSERVED RESULT The fade in effect appears as the color profile is not applied to it. EXPECTED RESULT Smooth , the color correction should be applied everytime SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.5.5 KDE Frameworks Version: 6.22.0 Qt Version: 6.10.1 Kernel Version: 6.18.6-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 32 × Intel® Core™ i9-14900K Memory: 64 GiB of RAM (62.5 GiB usable) Graphics Processor: NVIDIA GeForce RTX 4060 ADDITIONAL INFORMATION As a workaround, enabling the "night light" function even a bit (6400k) makes thing look right.
(In reply to Antonio Orefice from comment #0) > 2. set color precision to high Does that mean with "prefer efficiency" this doesn't happen?
Hard to say, I've to set high color precision, because otherwise the color correction is totally broken. Plaease, see new attachments made with standard precision.
Created attachment 189656 [details] Color precision not High, night mode set to off.
Created attachment 189657 [details] wrong shadow and colors Both image with color precision set to efficient, up with nightmode off, down with night mode set to minimum after zero. Notice broken shadows and wrong color in the second image.
Created attachment 189658 [details] my color profile for testing Adding my color profile for testing
Hmm, that profile is definitely pretty weird. Setting that profile on my laptop turns all gray-ish tones very blue. And yeah, I see the issue with the shadows as well, though in my case only with "prefer accuracy". With "prefer efficiency" it seems fine. Weirder still, zooming in with "prefer accuracy" turns white surfaces also into a blue-ish tone, but with "prefer efficiency" it doesn't. Even weirder than that, there is no BToA tag, so the two code paths should end up doing the exact same... The profile also has some "AR0T", "AR70", "AR71" and "AR72" tags in it, which seem to be non-standard (and undocumented) tags, but I'm not sure if they're relevant for us.
Blue tone is expected, since my display is very very warm without it. It may be unnoticed, so I'll write it again: " ADDITIONAL INFORMATION As a workaround, enabling the "night light" function even a bit (6400k) makes thing look right. "
> Blue tone is expected, since my display is very very warm without it. Yes, but also no. There's no VCGT in that profile, so it's not actually supposed to do any adjustments to the image, it should only describe the display as it is. And that also seems to be the cause of the problem. Looking at the TRCs, all the channels end before 100%. Most likely, lcms inverting those curves will result in white getting mapped to the native display white instead of the adjusted one. That also explains why night light "fixes" it, because 100% white doesn't happen anymore once it's enabled. So, arguably the profile is broken. Maybe we can work around it though.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8840
Git commit 20cccbc193049acef036b98a60afb8ca06cc7f22 by Xaver Hugl. Committed on 19/02/2026 at 15:16. Pushed by zamundaaa into branch 'master'. core/iccprofile: calculate inverse TRC ourselves Some (incredibly) broken profiles have the TRC and VCGT merged. The "TRC" tags of such profiles can have curves where a 100% input value does not map to 100% of the output value. Inverting such curves with LCMS doesn't yield the desired result, as it maps 100% input to 100% output. This commit fixes that by just inverting the TRC in a new function, which also checks for the maximum output value and ignores all values above it. M +67 -4 src/core/iccprofile.cpp https://invent.kde.org/plasma/kwin/-/commit/20cccbc193049acef036b98a60afb8ca06cc7f22
Thanks!
Git commit 8db6fed650d7c6016914ce8e8ba50faa6887f488 by Xaver Hugl. Committed on 20/02/2026 at 00:47. Pushed by zamundaaa into branch 'Plasma/6.6'. core/iccprofile: calculate inverse TRC ourselves Some (incredibly) broken profiles have the TRC and VCGT merged. The "TRC" tags of such profiles can have curves where a 100% input value does not map to 100% of the output value. Inverting such curves with LCMS doesn't yield the desired result, as it maps 100% input to 100% output. This commit fixes that by just inverting the TRC in a new function, which also checks for the maximum output value and ignores all values above it. (cherry picked from commit 20cccbc193049acef036b98a60afb8ca06cc7f22) Co-authored-by: Xaver Hugl <xaver.hugl@kde.org> M +67 -4 src/core/iccprofile.cpp https://invent.kde.org/plasma/kwin/-/commit/8db6fed650d7c6016914ce8e8ba50faa6887f488