When the checkbox: Configure Krita -> Color Management -> [ ] Use system monitor profile is checked... Krita is expected to automatically attribute color profiles set in the OS's Color Management panel to each screen accordingly. However, in multi-screen scenarios, it sometimes attributes profiles to the wrong displays. ######### The problem appears to be: The screen list underneath the checkbox: Screen 1: Screen 2: ... Krita gets this list from the system's Display settings panel. For KDE Plasma, Screen 1 is the "Primary" screen set in Plasma's Display settings. For Windows and Gnome, Screen 1 is the display plugged into the connector with highest priority. But when it comes to actually applying the profiles, the top-left screen is always #1. This often cause profiles to be attributed to the wrong displays, breaking color accuracy in a color managed workflow. ######### Workaround: A) For dual screen, manually adding 2 profiles using the "Folder" icon below, assign them in reversed order to what the "Use system monitor profile" checkbox's automatically does. B) KDE Plasma only: Make the top-left display "Primary". I have no idea how we deal with this issue if we had more than 2 displays. :P ######### Notes: I think this is the exact bug that plagued me all these years, causing my color management effort to fail since my first day as a Krita user -- I always use 2 monitors, and the lower one is always set to "Primary" or #1 in the system's Display settings. I was perplexed by things like the dark areas being too black, but since 2 monitors were both sRGB, and they had outstanding color accuracy, I never had any clue. Recently I replaced all my old displays. My top display is still sRGB, but the lower one is now AdobeRGB. After calibration and profiling, the sheer amount of over-saturation on the lower screen and the de-saturation on the top screen naturally led me to the assumption that the sRGB display's profile was applied to the AdobeRGB display, and vise versa. I was right, and I tested my theory on KDE Plasma, Gnome, Windows 10. It happened everywhere. I think this issue should be consider critical -- it breaks color accuracy in a properly configured color managed workflow. Thanks to this bug, many of my previous pictures are irreversibly affected in a bad way. Thank god I'm mostly a hobbyist XD. I suggest if we can't fix the bug soon, we at least remove that checkbox and add a warning below the screen list. ######### Possibly related: https://bugs.kde.org/show_bug.cgi?id=412393 https://bugs.kde.org/show_bug.cgi?id=407498 https://bugs.kde.org/show_bug.cgi?id=412608
Hey Tyson, can you give your operating system information? It's rather vital here as everything behaves differently in each operating system :)
(In reply to wolthera from comment #1) > Hey Tyson, can you give your operating system information? It's rather vital > here as everything behaves differently in each operating system :) Hi Wolthera, I think this is not OS specific, but I tested them on the following: Manjaro KDE 18.1.0 Manjaro Gnome 18.1.0 Fedora Gnome 31 beta Windwos 10 1903 2 different machines in 2 locations
I did some further test today, and found that on one machine no matter how I arrange the multi-displays, Krita will always attribute wrong profiles to each monitor. Manually setting the profile does not work (at first) on Display #1 but works on Display #2. Check/Unchecking the Use system monitor profile checkbox will make the manually assigned profile work for Display #1 as well, and it will remain working on restart.
(In reply to Tyson Tan from comment #3) > I did some further test today, and found that on one machine no matter how I > arrange the multi-displays, Krita will always attribute wrong profiles to > each monitor. Manually setting the profile does not work (at first) on > Display #1 but works on Display #2. Check/Unchecking the Use system monitor > profile checkbox will make the manually assigned profile work for Display #1 > as well, and it will remain working on restart. So on this particular machine (it has KDE Plasma), I had to set the lower monitor as "Primary" for Krita to auto-configure the profiles properly. I also noticed that unless I configure it like that, every other graphics apps (gwenview, Firefox) would also color manage incorrectly the same way as Krita did. I'm so confused right now...
Could it just be a bug in colord? That's where we get the information from.
(In reply to Boudewijn Rempt from comment #5) > Could it just be a bug in colord? That's where we get the information from. Yes, the more I test, the more it seems to be a problem on the system's side: 1) Whenever Krita got it wrong, other applications would go wrong as well; 2) Now more careful tests revealed that each machine behaves differently. But that particular behavior remains the same across different OSes -- KDE, Gnome, Manjaro, Fedora, LiveUSB, Windows 10...all fails the same way, all fixed with the same workaround. It seemed to ignore which connectors I used and the order of of them, not even how the displays are arranged in the system. My initial conclusion was completely invalid. 3) Things in common: AMD GPU, Cintiq Pro, DisplayPort. Later I will do a test on my Laptop with Intel GPU, a Type-C cable to a normal display. All said, if we can get Displays' EDID from the OSes, list them in Krita's Color Management settings with their names visible, people can easily assign profile manually.
We cannot get that in a cross-platform way. There is some code that could theoretically interface with the system's color management system, but so far, I only implemented that for Linux, and only if the desktop runs colord.
(In reply to Boudewijn Rempt from comment #7) > We cannot get that in a cross-platform way. There is some code that could > theoretically interface with the system's color management system, but so > far, I only implemented that for Linux, and only if the desktop runs colord. My bad, it doesn't have this option under Windows 10. Maybe I went insane since I haven't been sleeping well lately...But yes, it behaves like that under KDE/Gnome. I also tried to test this with Laptop-Intel Graphics-Type-C(detected as DP)-Cintiq Pro 13, but it ran into the infamous Intel Color Range Bug: https://wiki.archlinux.org/index.php/Intel_graphics#Weathered_colors_(color_range_problems) This is another Linux death trap for color management, but somehow the workaround didn't work now so I gave up the test. I do notice that in colord, Wacom devices have "Unknown" before their model name. I wonder if it is related?
@Tyson Tan - will this MR fix the issue? https://invent.kde.org/graphics/krita/-/merge_requests/457 - I believe it will at least improve the situation, but do I understand correctly that it will fix everything that Krita has to fix? (Since you already established it's not Krita's fault that the color management is broken).
Git commit 77f6562d503686816cb728122dfdaa1bb0168aff by Agata Cacko. Committed on 06/08/2020 at 14:06. Pushed by tymond into branch 'master'. Show display names in Color Management -> Display Before this commit, user would have to figure out on their own which display is which. Because of a bug in the system assigning color profiles to displays, the automatic way doesn't always work so the user needs to assign color profiles on their own. Before this commit the dialog only showed "Screen 1, Screen 2". This commit adds following information: - name - if model is not null, add model; if it is null, add manufacturer info - resolution It is also shortened so the maximum length is 25 characters. M +40 -3 libs/ui/dialogs/kis_dlg_preferences.cc https://invent.kde.org/graphics/krita/commit/77f6562d503686816cb728122dfdaa1bb0168aff
Git commit f9553ab19e8120d9e157dbfa07db601631226e67 by Agata Cacko. Committed on 16/10/2020 at 19:25. Pushed by tymond into branch 'krita/4.3'. Show display names in Color Management -> Display Before this commit, user would have to figure out on their own which display is which. Because of a bug in the system assigning color profiles to displays, the automatic way doesn't always work so the user needs to assign color profiles on their own. Before this commit the dialog only showed "Screen 1, Screen 2". This commit adds following information: - name - if model is not null, add model; if it is null, add manufacturer info - resolution It is also shortened so the maximum length is 25 characters. M +41 -3 libs/ui/dialogs/kis_dlg_preferences.cc https://invent.kde.org/graphics/krita/commit/f9553ab19e8120d9e157dbfa07db601631226e67
I believe I did everything we can do in Krita to solve this issue (automatic color management is broken, so one needs to do manual; for manual, there is a user-friendly text now that in most cases should allow setting the color profiles correctly). @Tyson Tan can you please confirm?
Hi Tiar, My apologies, I have given up using multi-monitor altogether because of this bug. Now I use a single Cintiq on each working location, so unfortunately I cannot test or confirm about the situation.
If there is one thing I can comment, I think Krita's current Color Management Display identification text is still inadequate. It only shows something like "DisplayPort-3 C 3840x2160". If I had two 4K display both connected to displayports, there is no way I can tell them apart. To help users assign ICC profiles accurately, I recommend you show users the Display's Vendor and Model on that page.
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
Someone needs to adjust the text to give better feedback about the monitors.
Unfortunately, I looked at tiar's code, and it already adds all the information we can retrieve. The main problem is that Qt doesn't get to know what kind of Monitor you have (this is also visible if you look at the System Info for bug reports under help), so we can't show more information. :/
OK, thanks for the info! :)
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1768
Git commit 054517cd8f42e0f4215f7eae2628428bc23b3370 by Agata Cacko. Committed on 15/05/2023 at 14:09. Pushed by tymond into branch 'master'. Fix color profiles being assigned to screens by indexes Before this commit, Krita assigned color profiles to screens based on screen indexes, which apparently can change (see the bug report). This commit introduces "screen string identifier" which is a concatenation of multiple screen properties like manufacturer, serial number, resolution etc. (Note that especially on Windows, any of those properties might be empty strings). Related: bug 407498, bug 412608 M +36 -1 libs/ui/kis_config.cc M +2 -0 libs/ui/kis_config.h https://invent.kde.org/graphics/krita/commit/054517cd8f42e0f4215f7eae2628428bc23b3370