Bug 407498 - Color profiles should take into account monitor model and serial number
Summary: Color profiles should take into account monitor model and serial number
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Microsoft Windows Microsoft Windows
: NOR wishlist
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
: 412608 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-05-13 14:57 UTC by Neviril
Modified: 2023-05-18 09:42 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Neviril 2019-05-13 14:57:44 UTC
SUMMARY
A discussion on #Krita on IRC relatively to a bug in the color profile->display association revealed a larger background problem of associating a color profile to a "screen number".

Screen numbers are not fixed: they can change depending on which is the primary display, number of displays connected and what display outputs are enabled on the graphics card at any given time. On the other hand, monitor model and serial number are fixed.

It's important to take into account some sort of unique identifier, as the calibration (and associated color profile) of two or more physically identical displays will likely not be identical, as personal experience also revealed after coming across identical displays with noticeably different factory colors even with the same display settings from the OSD.

The Krita developer involved in the discussion pointed out that there doesn't seem to be a way of getting the screenNumber of a QScreen, that QDesktopWidget is also pretty much obsolete and doesn't really work well under high dpi, and that some broken displays might not not have the proper serial number in their EDID info.


SOFTWARE/OS VERSIONS
Windows: Windows 10 64-bit 1809


ADDITIONAL INFORMATION
Information valid as of the latest nightly build from Jenkins at the time of writing (git 1f648b3).
Comment 1 Alvin Wong 2019-05-13 17:17:56 UTC
By the way, I just ran `qtdiag` on Windows and it gives an empty string for manufacturer/model/serial number. Turns out they aren't implemented for Windows (and also macOS it seems)... should I say I'm not surprised.

They can still be implemented, but at the end there needs to be a fallback in case those strings are really not available.

So what we probably need are:

1. A way to generate an unique key for a monitor (probably by manufacturer/model/serial no.).
2. Somehow a fallback mapping to be used when the unique key doesn't work? Or would it be better to have Krita just ask the user to confirm the display profile mapping on startup and whenever the connected screens are changed (but only if the user have set a custom profile)?
Comment 2 wolthera 2019-10-09 14:12:58 UTC
*** Bug 412608 has been marked as a duplicate of this bug. ***
Comment 3 Tiar 2020-04-07 18:30:46 UTC
In the duplicate bug report there is a suggestion to use the size of the display in pixels 

> Getting an extra hint under "Screen" to identify the monitors on this interface. (eg. can be the geometry@position: eg. 1920x1080@0,0 and 1440x900@1920,0, or device name)

as a hint when assigning profiles. It will be extra useful if:
- the qtdiag returns empty string, so the display model etc. is not known,
- the user has several displays of the same manufacturer and model name (probably bought in bunk, often seen in companies).
Comment 4 Tiar 2021-08-09 19:42:49 UTC
This commit has been made in response to bug :
https://invent.kde.org/graphics/krita/-/commit/77f6562d503686816cb728122dfdaa1bb0168aff

It changes the "Screen X" text to something that should include resolution and either model or manufacturer (manufacturer, if the model is empty). The information provided is kind of very varied depending on the display and manufacturer so it's difficult to judge which part of the information is the most useful, and I tried to make it short. I guess it could still be improved by ensuring all of the information Krita has access to is displayed, but - maybe it's already helpful?
Comment 5 Bug Janitor Service 2021-08-24 04:36:39 UTC Comment hidden (obsolete)
Comment 6 Alvin Wong 2021-08-24 07:38:21 UTC
The colour profile setting is still based on the index of the screen as in `QApplication::screens()`. Say you close the lid of your laptop and switch to an external monitor, the colour profile for the wrong monitor will be used.
Comment 7 Tiar 2021-08-30 20:05:50 UTC
Do you think we could assume that displays with the exact same strings for [all information we could get from Qt screen] are the same and can use the same color profile? I could make it use all the model information etc. as a key in configuration, but that information is so random that I'm a bit scared to use it. Though, it looks like using the index is not much better either. So I guess the model (+all others) string would be better.

Is that what you had in mind? It seems to make sense for me.
Comment 8 Alvin Wong 2021-08-31 08:03:43 UTC
I think Qt still haven't implemented the code to retrieve the display model/serial number for Windows (don't know about macOS). The only available information on Windows - the name - is in the form of `\\.\DISPLAY1` which I am unable to find documentation on whether it is assigned in a deterministic way... but at least it shouldn't change from just closing the laptop lid, unlike the list index which definitely changes.
Comment 9 amyspark 2023-02-23 21:56:00 UTC
*** Bug 466068 has been marked as a duplicate of this bug. ***
Comment 10 Bug Janitor Service 2023-03-02 19:04:40 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1768
Comment 11 grum999 2023-05-13 09:35:50 UTC
Hi 

Wanted to test last Krita Next and Plus on windows.

krita-5.1.5 (e0453bf87f)
krita-5.2.0 (6128ba9453)

Krita process start in an endless loop
Running krita.com from cmd.exe, I get this message printed in a loop:
> calculateMonitorNameToInfo: cannot join monitor name and display info via display id: name: \\.\DISPLAY1 -> id: \\?\DISPLAY#DEFAULT_MONITOR#4&8B487E3&0&UID0#{E6F07B5F-EE97-4A90-B076-33F57BF4EAA7}

Could it be related to this bug? and MR 1768?

Note: my windows 10 runs in a virtual machine (I use it just to execute krita to test if my plugins are working on windows...)


Grum999
Comment 12 Tiar 2023-05-15 14:10:30 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 412608, bug 412943

M  +36   -1    libs/ui/kis_config.cc
M  +2    -0    libs/ui/kis_config.h

https://invent.kde.org/graphics/krita/commit/054517cd8f42e0f4215f7eae2628428bc23b3370
Comment 13 Dmitry Kazakov 2023-05-16 10:40:51 UTC
Hi, grum999!

This patch should fix the issue:
https://invent.kde.org/szaman/qtbase/commit/1300d28165436c389aa4820d3a24d8a4510566e1

If everything goes well, the problem should go with the next nightly builds
Comment 14 grum999 2023-05-18 09:13:28 UTC
Hi Dmitry

Tested krita-nightly-x64-5.2.0-prealpha-b91d20e6a6 (build #2099, 2023-05-18@10.18am) on my Windows VM
Problem is still here: krita stay stucked in a loop to display "...cannot join monitor name..." message
:-( 


Grum999