GNOME Bugzilla – Bug 555562
GIMP should ask before applying working space profile
Last modified: 2015-12-29 02:00:40 UTC
Pictures made with Canon Poweshot A10 or Lumix Fx 35 have an embedded sRGB IEC61966-2.1 ICC profile. These profiles are well recognized by other picture viewers but not by Gimp. Gimp transforms this embedded profile and applies the RVB profile defined in Preferences (Adobe RG(1998)) without proposing me "What to do". This option to propose a choice is also defined in preferences.
Hi and thanks for the bug report! Could you attach a (small) file that can be used to reproduce the problem please?
The assumption is that no profile means sRGB. And the embedded sRGB profile is equivalent to sRGB, So this behavior is intentional.
If I understand the bug reporter correctly, the bug is that even though the 'File Open behaviour' is 'Ask me what to do' in the Color Management Preferences, GIMP converts the image from sRGB to Adobe RGB(1998). This is a lossy operation and we definitely should ask the user if this is what the user wants here. Could you give us a sample file to play with Alain?
"If I understand the bug reporter correctly, the bug is that even though the 'File Open behaviour' is 'Ask me what to do' in the Color Management Preferences, GIMP converts the image from sRGB to Adobe RGB(1998). This is a lossy operation and we definitely should ask the user if this is what the user wants here." It is exactly my problem, but only with images coming from my cameras. If an image is modified by a program, without changing embedded profile, Gimp recognizes the embedded one and Color Management Preferences is correctly applied (it asks me what to do'). I joint two images. The first image comes directly from my canon Powershot A10. The second, is the same image rewrited in Photoshop without changing embedded profile.
Created attachment 120264 [details] Original image
Created attachment 120265 [details] Rewrited without modifications
When looking at the Original image in an hex editor I don't see a trace of an ICC profile. I can see several occurances of 'photoshop' in the file though, so I suspect that the file uses some Photoshop specific way of specifying that the image should be associated with an sRGB color profile. Closing as INVALID since the Original image doesn't appear to contain an ICC color profile. Feel free to reopen if you can prove me wrong.
Yes, you are true. Effectively, my original image hasn't ICC profile embedded. I have been misleaded by Photoshop diagnostic and by viewing exif datas of the image. In fact, after having searched informations on the web about this problem, I understood that numeric cameras images have no embedded ICC profil but have a specific codification permitting to certain color managed softwares to determine the space color sRGB of these images. (Only expensive pro cameras permit to set embedded profiles). If it's true, perhaps Gimp could work like these softwares instead of applying the profile defined in color management preferences, making important colors changes. Or at least, Gimp could alert the user of missing profile as he does it when embedded profile is different from the one defined in color management preferences, when opening image. This feature would permit to user to apply the desired profile in all cases, but I think this solution would be fastidius when working on a great number of numeric cameras pictures. If you are interested, here is a good link about this subject : http://regex.info/blog/photo-tech/color-spaces-page3/
Setting a working space profile other than sRGB is basically unsupported in GIMP and it hasn't seen much testing. The bug reporter has a point here. Images without a profile are assumed to be sRGB. So, if a working space profile other than sRGB is specified, such images should be converted and the user should be asked before this conversion is applied. At least if that is specified as the "File Open behavior" in the color management preferences.
No unconfirmed bugs with milestones, please.
2.6 -> 2.8
I posted a proposed fix to this at Bug 492048. Many modern cameras (Fuji, among others) do not embed ICC profiles. (Since EXIF 2.2.1 this is no longer a requirement). If the Interoperability Index is correctly set, the profile may be defaulted.
The "configurable working space profile" is IMO a completely broken idea alltogether. It's confusing in both the code and the GUI, does unexpected things, and is inconsistently implemented. We should get rid of it: 1. a NULL profile on an image means built-in sRGB or linear RGB 2. deal with profile assignment/conversion as pixels are imported into GIMP via file-import or copy and paste 3. turn the GimpColorConfig "rgb-profile" property into a "preferred RGB profile", and call it "Preferred" in the GUI 4. always present this preferred profile next to the built-in one, before the separator, whenever the user has to chose a profile to assign or convert to 5. don't use it anywhere else, it's the user's responsibility to select it when pixels enter GIMP 6. don't treat this profile differently from an arbitrary one after it has been chosen for an image 7. change the "Apply Color Profile" so it can be used for both imported files and pasted buffers, and enhance it to offer a profile conversion to any profile using the usual combo, but default to the built-in RGB ones This way, users can have a preferred RGB working space, but it is assigned to the image normally and things don't behave differently than with any random other profile.
Bye bye configurable RGB working space: commit 77dac3ea60c4d645303fdbc1eb57700a5a296883 Author: Michael Natterer <mitch@gimp.org> Date: Thu Aug 20 16:02:22 2015 +0200 Bug 555562 - GIMP should ask before applying working space profile Get rid of the "configurable RGB working space profile". Instead, turn GimpColorConfig's "rgb-profile" property into a "Preferred RGB profile" thing that is only a hint and never used without explicit user interaction. Present it next to the built-in profile in the profile combo boxes and call it "Preferred" in the prefs dialog and its tooltip. Most importantly, don't use it as the image's profile when the image is not tagged with a profile. Untagged images are now always in the sRGB or linear RGB built-in color spaces. This commit reduces the "Apply color profile" dialog on file import to a simple "Convert to built-in RGB", but that dialog is about to be moved to the core and improved anyway. app/core/gimpimage.c | 16 ++------------ app/dialogs/color-profile-dialog.c | 64 ++++++++++++++++++++++--------------------------------- app/dialogs/preferences-dialog.c | 2 +- libgimpconfig/gimpcolorconfig.c | 38 ++++++++++++++++++++++----------- plug-ins/common/lcms.c | 8 ------- 5 files changed, 55 insertions(+), 73 deletions(-)
This doesn't change anything by itself, but makes the code easily changeable to whatever we want it to do: commit b51ee77ec01ec141d12586d9375d970123ecc772 Author: Michael Natterer <mitch@gimp.org> Date: Sun Aug 23 10:51:31 2015 +0200 app: implement the "Convert to RGB Working Space" import dialog in the core Add gimp_image_import_color_profile(), a GUI vtable entry query_profile_policy() and a new dialog which returns the profile policy and the profile to convert to. Get rid of the wrapper that calls the lcms plug-in for that dialog, the plug-in is now completely unused. This commit doesn't add any new features, it's just the former lcms plug-in dialog implemented in app/ (except the little fix that it is now aware of linear vs. gamma images). app/core/gimp-gui.c | 20 ++++ app/core/gimp-gui.h | 20 +++- app/core/gimpimage-color-profile.c | 78 ++++++++++++++++ app/core/gimpimage-color-profile.h | 5 + app/dialogs/Makefile.am | 2 + app/dialogs/color-profile-import-dialog.c | 151 +++++++++++++++++++++++++++++++ app/dialogs/color-profile-import-dialog.h | 33 +++++++ app/file/file-open.c | 85 +---------------- app/gui/gui-vtable.c | 24 ++++- app/plug-in/Makefile.am | 5 +- app/plug-in/plug-in-icc-profile.c | 138 ---------------------------- app/plug-in/plug-in-icc-profile.h | 32 ------- app/widgets/gimphelp-ids.h | 1 + po/POTFILES.in | 2 +- 14 files changed, 336 insertions(+), 260 deletions(-)
This will not be fixed in 2.8.
The functional part of Bug 555562 - detecting DCF interoperability index information and assigning an appropriate built-in GIMP sRGB or AdobeRGB1998-compatible profile, but only if there isn't already an embedded ICC profile - was taken care of in Bug 492048. The remaining issues are UI issues. There seem to be two separate UI issues: 1. Notifying the user that an ICC profile was assigned because the image didn't have an embedded ICC profile and did have camera DCF information (specifically the interoperability index, which is a required DCF tag that defaults to R98 for the sRGB color space, but can also be R03 for the AdobeRGB1998 color space). This notification would be part of the popup that the user sees unless the user has specified a default action in "Preferences/Color Management". I would urge notifying the user about assigning an ICC profile on the basis of DCF information even for sRGB DCF information, because sometimes the damage done by assigning the wrong profile isn't immediately obvious just by looking at the image. 2. A way in "Preferences/Color Management" for users to preselect which on-disk ICC profiles should be used for camera-saved jpegs/etc, that do have DCF information and don't have embedded ICC profiles. This benefits users who don't want to assign GIMP's built-in sRGB and/or AdobeRGB1998-compatible profiles, but rather prefer to assign other ICC profiles (perhaps the proprietary AdobeRGB1998 profile from the Adobe website, or the sRGB/AdobeRGB1998 profiles that were bundled with the proprietary software that's delivered with most digital cameras). Otherwise these users are faced with assigning "the right" profile every time they open a camera-saved jpeg. Martin Ramshaw provided a patch for dealing with DCF information (https://bug492048.bugzilla-attachments.gnome.org/attachment.cgi?id=267695), which includes proposed modifications to the GIMP color management UI to allow the user to specify "use these profiles as appropriate, if the image doesn't have an embedded ICC profile". The relevant code in the patch might provide a nice starting point for code that allows users to set their own preferences for assigning an AdobeRGB1998(-compatible) or sRGB from disk, instead of using the GIMP built-in profiles. This screenshot shows the proposed UI modifications: https://bug492048.bugzilla-attachments.gnome.org/attachment.cgi?id=267694 Looking at the screenshot, it might be better to replace the words "fallback profiles" with something like "Use these on-disk profiles for DCF files", and for the checkbox, replace "Use fallback RGB profiles" with something like "For DCF files use these on-disk profiles instead of the GIMP built-in sRGB and AdobeRGB1998-compatible profiles". And maybe make the DCF preferences dialog collapsible, with a more or less informative label (maybe "Profiles for camera-saved jpegs and other DCF images"). Various considerations on UI information regarding assigning a profile on the basis of the DCF interoperability index can be found in the comments above and in Bug 492048.
There is just too much in this bug apart from the actual issue that is now fixed (silently applying some configured color profile on loading). Can we close this and have bugs for smaller issues? One bug at a time? :)
I think the only remaining issues are UI issues: (1) some way to allow the user to choose their own "on disk" sRGB and AdobeRGB profiles for DCF camera-saved jpegs, plus (2) some way to notify the user that a profile was assigned on the basis of DCF information. Would these be better as one bug report or two?
Actually, I don't know. Why do we need (1) at all? We automatically pick profiles that are definitely now wrong, and the user can always assign another profile later. The fraction of users that would do that is probably close to zero, there is IMO no need to bother all users with such a choice where lots of things can go wrong. (2) would be nice to have, and is probably an enhancement request too, we currently have no way of communicating this in the profile import dialog.
How about closing this bug report and not worrying about (1) unless/until a user indicates that the current behavior is causing issues? Would you like me to file an enhancement request for (2)?
Yes please :) Closing this bug as FIXED.
Bug 759942 is an enhancement request to let users know when an ICC profile was assigned based on camera DCF information.