Created attachment 161450 [details] Quick example of the bug SUMMARY In multi monitor setup with different color profiles, opening a file with various methods will result in a color inconsistency. Eg: drag dropping from a windows explorer or right click -> Open with -> Krita will result in a wrong display profile being applied. While directly opening from Krita in Recent Images will result in a correct display profile being applied. (See attached video for details) Reproducible in 5.2.0 beta and current git master e1a13f9ad45f072df4fe6fef5a9eba851bd47216 STEPS TO REPRODUCE 1. In multi monitor setup, use different profiles for each screen 2. Put Krita in one of the screen 2. Open image from windows explorer using either drag and drop or right click -> Open with -> Krita 3. Open the same image directly from krita using File -> Open or Recent Images OBSERVED RESULT The image will rendered differently as if the display profiles are incorrectly assigned EXPECTED RESULT The image is rendered consistently across different method of opening files SOFTWARE/OS VERSIONS Windows: 10 22H2 Qt Version: 5.15.7
Hi, Kampidh! Could you please check if this bug is somehow related with Krita window moving from one display to another? I can reproduce the issue when dragging Krita window from one display to another. When screen scale factors are different, Krita window make become temporarily covering both displays, which seems to break the update of the output profile.
(In reply to Dmitry Kazakov from comment #1) > Hi, Kampidh! > > Could you please check if this bug is somehow related with Krita window > moving from one display to another? I can reproduce the issue when dragging > Krita window from one display to another. When screen scale factors are > different, Krita window make become temporarily covering both displays, > which seems to break the update of the output profile. Hi, Dmitry! It looks like so, I can confirm too that juggling the Krita window from one screen to another can trigger this behavior. For additional details that might be helpful: my screens are 1440p and 1080p. Although they have the same scaling in windows settings (100%).
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1934
Git commit f33b17a26aaed37a075f64a536126afca5ebf957 by Dmitry Kazakov. Committed on 12/09/2023 at 16:00. Pushed by dkazakov into branch 'master'. Fix profile change when Krita is moved between screens We cannot use QApplication::desktop()->screenNumber(mainWindow) in the handler of the screenChanged() signal, because this information is not yet ready when the signal is delivered. M +0 -14 libs/ui/KisMainWindow.cpp M +0 -5 libs/ui/KisMainWindow.h M +16 -2 libs/ui/KisView.cpp M +2 -1 libs/ui/KisView.h M +19 -4 libs/ui/canvas/kis_canvas2.cpp M +2 -0 libs/ui/canvas/kis_canvas2.h M +1 -0 libs/ui/kis_config.cc M +1 -0 libs/widgetutils/CMakeLists.txt A +39 -0 libs/widgetutils/KisScreenMigrationTracker.cpp [License: GPL(v2.0+)] A +37 -0 libs/widgetutils/KisScreenMigrationTracker.h [License: GPL(v2.0+)] https://invent.kde.org/graphics/krita/-/commit/f33b17a26aaed37a075f64a536126afca5ebf957
Git commit c8dbc495d8ad7b1d77f78c0b0a06805aba43839e by Dmitry Kazakov. Committed on 12/09/2023 at 16:00. Pushed by dkazakov into branch 'master'. Fix detection of screen profile after closing Preferences dialog QApplication::activeWindow() is null for a small timeframe after closing the preferences dialog, so the profile was set to the default value (that, is "screen #0"). M +4 -3 libs/ui/canvas/kis_canvas2.cpp https://invent.kde.org/graphics/krita/-/commit/c8dbc495d8ad7b1d77f78c0b0a06805aba43839e
Git commit 1e2c4fad70259fc2f6e0e43765de1ef9b09b909f by Dmitry Kazakov. Committed on 12/09/2023 at 16:01. Pushed by dkazakov into branch 'krita/5.2'. Fix detection of screen profile after closing Preferences dialog QApplication::activeWindow() is null for a small timeframe after closing the preferences dialog, so the profile was set to the default value (that, is "screen #0"). M +4 -3 libs/ui/canvas/kis_canvas2.cpp https://invent.kde.org/graphics/krita/-/commit/1e2c4fad70259fc2f6e0e43765de1ef9b09b909f
Git commit 4472e32175656ab1b28a42aba6943ce6a3fba54b by Dmitry Kazakov. Committed on 12/09/2023 at 16:01. Pushed by dkazakov into branch 'krita/5.2'. Fix profile change when Krita is moved between screens We cannot use QApplication::desktop()->screenNumber(mainWindow) in the handler of the screenChanged() signal, because this information is not yet ready when the signal is delivered. M +0 -14 libs/ui/KisMainWindow.cpp M +0 -5 libs/ui/KisMainWindow.h M +16 -2 libs/ui/KisView.cpp M +2 -1 libs/ui/KisView.h M +19 -4 libs/ui/canvas/kis_canvas2.cpp M +2 -0 libs/ui/canvas/kis_canvas2.h M +1 -0 libs/ui/kis_config.cc M +1 -0 libs/widgetutils/CMakeLists.txt A +39 -0 libs/widgetutils/KisScreenMigrationTracker.cpp [License: GPL(v2.0+)] A +37 -0 libs/widgetutils/KisScreenMigrationTracker.h [License: GPL(v2.0+)] https://invent.kde.org/graphics/krita/-/commit/4472e32175656ab1b28a42aba6943ce6a3fba54b
Reopened because even though the moving the display already fixed, the file opening still a bit unreliable: - From explorer, right click -> Open With -> Krita still gives a wrong profile - From explorer, drag drop to Krita to open is a mixed bag, sometimes it's correct, and sometimes not. I still can't perfectly pinpoint what the trigger is, but sometimes if there's a image currently opened in Krita, the opened file from drag and drop often times to be in a correct profile. - Internally, using File -> Open or Recent Files is always having the correct profile. However, if the profile is incorrect in one of the opened files, juggling the Krita window across the screens and returning it back fixes the profile now (it wasn't before, IIRC). Another additional finding is that it looks like only affects my second screen (drawing tablet), while placing the Krita on primary screen didn't seem to have this mismatched profile while opening a file from explorer. (I'm a bit suspecting that it has to do with the last cursor position while opening the image from explorer, but trying to move the explorer to same screen as Krita still gives the bug...)
Git commit a81b66f75ca8103bead983d82e90033f4ce76f51 by Dmitry Kazakov. Committed on 13/09/2023 at 17:54. Pushed by dkazakov into branch 'master'. Fix canvas display profile when file is D&D'ed into Krita We shouldn't rely on the "current active window" of Krita in such questions, because Krita's window may be merely inactive, e.g. when we D&D a file to it from a Windows explorer (or when opened via "Open With..." action). M +5 -0 libs/ui/KisView.cpp M +5 -0 libs/ui/KisView.h M +9 -1 libs/ui/canvas/kis_canvas2.cpp https://invent.kde.org/graphics/krita/-/commit/a81b66f75ca8103bead983d82e90033f4ce76f51
Git commit 910b1b0caf2fa5cb260cfddfd4ee827d43f94736 by Dmitry Kazakov. Committed on 13/09/2023 at 17:55. Pushed by dkazakov into branch 'krita/5.2'. Fix canvas display profile when file is D&D'ed into Krita We shouldn't rely on the "current active window" of Krita in such questions, because Krita's window may be merely inactive, e.g. when we D&D a file to it from a Windows explorer (or when opened via "Open With..." action). M +5 -0 libs/ui/KisView.cpp M +5 -0 libs/ui/KisView.h M +9 -1 libs/ui/canvas/kis_canvas2.cpp https://invent.kde.org/graphics/krita/-/commit/910b1b0caf2fa5cb260cfddfd4ee827d43f94736