Bug 434618 - color space not found
Summary: color space not found
Status: CONFIRMED
Alias: None
Product: krita
Classification: Applications
Component: Color models (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: macOS (DMG) macOS
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2021-03-19 11:34 UTC by Manga Tengu
Modified: 2024-09-02 15:16 UTC (History)
2 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 Manga Tengu 2021-03-19 11:34:57 UTC
SUMMARY
When importing a jpg file from the web in krita, The image will be showed grayer than on the other applications. This is because the image is loaded with the wrong color model whatever the color model options, sRGB will be chosen because the monitor's profile is not found.
The workaround is to save the resulting image without incorporating the icc.
I have attached a screenshot to the issue.

STEPS TO REPRODUCE
1. import a jpg in krita
2. open the jpg in the system's viewer


OBSERVED RESULT
The image becomes grayer

EXPECTED RESULT
the image to look the same as everywhere in the OS

macOS: 11.2.3 (20D91)
15" 2018 MacBook pro
Comment 1 wolthera 2021-03-19 11:46:50 UTC
So, that's not exactly what's happening.

What is happening is that unassigned images that come in via copy-paste ask whether to use the monitor profile or sRGB, while images coming in via open file (like drag-and-drop), don't ask for monitor profile or srgb.

Futhermore, the monitor profile is not accesible from the assign color-profile functions, for some reason.

Anyway, I think unassigned images should always follow the copy-paste buffer behaviour.
Comment 2 Manga Tengu 2021-03-19 12:06:35 UTC
thanks for enlightning this report :light
Comment 3 wolthera 2021-09-09 12:36:27 UTC
Yeah, what this needs is better import behaviour.
Comment 4 Dmitry Kazakov 2024-08-22 16:39:01 UTC
Remove triaged keyword from CONFIRMED bugs
Comment 5 Robert Moerland 2024-09-01 09:41:18 UTC
I think I can reproduce the behavior, but I'm not a 100% sure given that "jpg file from the web" allows for some freedom. 

I'm testing with Krita 5.3.0-prealpha-703c3eae on Windows 10 and a Dell U2713H (wide gamut) monitor.

Steps that *did not* reproduce the issue:
- Import / drag and drop tagged sRGB image into Krita. Colors are the same as (color managed) photo viewer and PS CS 6
- Import / drag and drop tagged AdobeRGB image into Krita. Colors are the same as (color managed) photo viewer and PS CS 6
- Import / drag and drop untagged sRGB image into Krita. Colors are the same as (color managed) photo viewer and PS CS 6

Step that *did* (?) reproduce the issue:
- Import / drag and drop untagged AdobeRGB image into Krita. Colors are duller than the properly-tagged version. Rendering in other software depends on implementation (assume sRGB profile or assume monitor profile). 

My hesitation to fully confirm that I reproduced the bug stems from the fact that the proposed workaround ("save the resulting image without incorporating the icc") seems to actually trigger this behavior, if I understand the workaround well.
Comment 6 wolthera 2024-09-02 15:02:31 UTC
Yeah, the main problem is what to do with untagged images.

Thing is, for some reason Apple decided MacOS should show untagged images in their new DCI P3 color space in all their viewers.

However, Krita, being color managed, loads these as sRGB (as that's what is currently understood as the 'default' computer colorspace, if there's none known). This confused manga tengu, as that meant all their images looked way less colourful in Krita. So for them, using the copy-paste dialog to switch the image to DCI P3 by default is more helpful. (And then they need to be exported untagged, to make sure the image viewer and the like will show the same as in Krita)

On windows with an untagged Adobe RGB image, you have a similar problem: Untagged images are loaded with sRGB profile, which means that Adobe RGB images, being larger than sRGB like DCI P3 is, will look less colourful. Generally, what this needs is a unified way to handle untagged images, and a unified way to guide artists to export tagged/untagged...

I'm shifting this back to macOS, because while it *is* cross-platform as an issue, macOS' DCI P3 choices make it more obvious on that platform.
Comment 7 Robert Moerland 2024-09-02 15:16:28 UTC
Sure, and thanks for the additional info. I should have mentioned this in my original statement, but I used this bug to test drive the instructions for the upcoming bug hunt: https://krita-artists.org/t/need-two-volunteers-for-beta-testing-instructions-for-the-upcoming-krita-bughunting-event/100552

Apologies if the confirmation felt superfluous!