Bug 412943 - Use System Monitor Profile checkbox attributes wrong profile to screens, breaking color management
Summary: Use System Monitor Profile checkbox attributes wrong profile to screens, brea...
Status: RESOLVED UPSTREAM
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: unspecified
Platform: Other All
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2019-10-14 17:17 UTC by Tyson Tan
Modified: 2023-05-15 14:10 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tyson Tan 2019-10-14 17:17:55 UTC
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
Comment 1 wolthera 2019-10-14 17:19:22 UTC
Hey Tyson, can you give your operating system information? It's rather vital here as everything behaves differently in each operating system :)
Comment 2 Tyson Tan 2019-10-14 17:26:32 UTC
(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
Comment 3 Tyson Tan 2019-10-15 00:46:58 UTC
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.
Comment 4 Tyson Tan 2019-10-15 01:22:06 UTC
(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...
Comment 5 Halla Rempt 2019-10-16 12:05:53 UTC
Could it just be a bug in colord? That's where we get the information from.
Comment 6 Tyson Tan 2019-10-16 13:50:24 UTC
(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.
Comment 7 Halla Rempt 2019-10-16 13:59:28 UTC
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.
Comment 8 Tyson Tan 2019-10-17 02:33:48 UTC
(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?
Comment 9 Tiar 2020-08-03 14:34:35 UTC
@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).
Comment 10 Tiar 2020-08-06 14:07:08 UTC
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
Comment 11 Tiar 2020-10-16 19:26:59 UTC
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
Comment 12 Tiar 2021-03-30 13:06:46 UTC
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?
Comment 13 Tyson Tan 2021-04-01 08:49:38 UTC
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.
Comment 14 Tyson Tan 2021-04-01 08:56:10 UTC
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.
Comment 15 Bug Janitor Service 2021-04-02 04:33:47 UTC
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.
Comment 16 wolthera 2021-09-09 12:45:26 UTC
Someone needs to adjust the text to give better feedback about the monitors.
Comment 17 wolthera 2021-09-21 14:49:45 UTC
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. :/
Comment 18 Tyson Tan 2021-09-21 15:18:59 UTC
OK, thanks for the info! :)
Comment 19 Bug Janitor Service 2023-03-02 19:04:43 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1768
Comment 20 Tiar 2023-05-15 14:10:46 UTC
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