GNOME Bugzilla – Bug 575744
exif tags and embedded color space profile not synchronized
Last modified: 2018-05-24 12:32:51 UTC
Please describe the problem: 1. opening a jpg image including exif tags that specify a color space (e.g. AdobeRGB) 2. converting the image to another colorspace (e.g. sRGB) 3. saving the converted image Bug: the newly saved image contains the new color space profile, but at the same time the new image still contains the old exif tags, referring to the original color space. As a result exif tag information and embedded color profile are not synch'ed. This causes other software to mis-interpret the image color space. Steps to reproduce: 1. Open jpg image which includes: EXIF color space tag to "Uncalibrated" and the InteropIndex EXIF field to "R03", which, together, means Adobe RGB 2. Convert image to sRGB, using Image -> mode -> Change color profile... [ I am not sure about the exact menue names, since I do ot use an English GIMP] 3. Save converted image as jpg Actual results: The saved jpg image contains an sRGB color profile, but still holds: EXIF color space tag to "Uncalibrated" and the InteropIndex EXIF field to "R03", which, together, means Adobe RGB Expected results: After conversion to sRGB the EXIF color space tag should be set to 1 (sRGB) and the InteropIndex tag should be removed. Alternatively, the color space tag could be left to Uncalibrated but the InteropIndex then has to be set to "R98", which also means sRGB. One way or another GIMP should update the medatada to tell what was done, this is clearly a bug, the file should not be written with an sRGB profile and metadata saying otherwise. Does this happen every time? Yes Other information:
The proper way to fix this is to add EXIF support to the lcms plug-in. It can then take care of updating the EXIF tags when doing the color space conversion. We would appreciate a patch that does this.
*** Bug 689042 has been marked as a duplicate of this bug. ***
Note that the Exif 2.2 specification specifies only two values for its ColorSpace tag: sRGB and Uncalibrated. However, many programs extend it with some heuristics for recognizing the AdobeRGB color space using other Exif tags. See also the DCF specification (JEITA CP-3461) for the Exif extensions. The lcms plug-in should be updated so that: - If the image contains an Exif block and the color profile attached to the image looks like sRGB, then set the Exif ColorSpace tag to sRGB. - If the image contains an Exif block and the color profile attached to the image looks like anything else than sRGB, then set the Exif ColorSpace tag to Uncalibrated *and* delete the InteroperabilityIndex. - If the image does not contain an Exif block, do nothing special. That would be the minimum to support Exif correctly. Optionally, the lcms plug-in could also be updated to support such as AdobeRGB according to DCF and other Exif extensions. Volunteers for updating the plug-in are welcome...
Another possibility; many cameras do not embed ICC profiles. I have attached a patch to Bug 492048 that enables the correct profile to be attached (at user discretion) for the two usual options: sRGB and AdobeRGB.
This all seems pretty much as described, neither a Mode -> Convert or an ICC profile conversion on Open affect image metadata. As a first step I will look into updating the ICC profile parasite.
Now that bug 492048 is almost fixed, this one becomes more relevant again.
This adds API to set the metadata colorspace, still unused. commit 15b7b17b12ab73b0d90a26c822da3cb20bdeb917 Author: Michael Natterer <mitch@gimp.org> Date: Wed Sep 30 20:47:52 2015 +0200 Bug 492048 - Detect color space in Exif 2.21/DCF 2.0 option files Some refactoring: add gimp_metadata_get,set_colorspace() and a new enum GimpMetadataColorspace which so far can be one of { UNSPECIFIED, UNCALIBRATED, SRGB, ADOBERGB }. The setter is untested and I don't know if it's doing the right thing, please review. Use the getter in gimp_image_metadata_load_finish(), so complex metadata logic and profile creation/setting are separated. libgimp/gimpimagemetadata.c | 79 +++----------------- libgimpbase/gimpbase.def | 2 + libgimpbase/gimpmetadata.c | 172 +++++++++++++++++++++++++++++++++++++++++++- libgimpbase/gimpmetadata.h | 87 ++++++++++++---------- 4 files changed, 233 insertions(+), 107 deletions(-)
There now is an elaborate discussion in bug 492048 about whether or not we should synchronize the metadata tags at all.
(In reply to kuhnruediger from comment #0) > Please describe the problem: > 1. opening a jpg image including exif tags that specify a color space (e.g. > AdobeRGB) > 2. converting the image to another colorspace (e.g. sRGB) > 3. saving the converted image > > Bug: the newly saved image contains the new color space profile, but at the > same time the new image still contains the old exif tags, referring to the > original color space. GIMP does NOT embed the built-in sRGB profile, so the statement that "the newly saved image contains the new color space profile" is incorrect. But the statement that "the new image still contains the old exif tags, referring to the original color space" is true. > As a result exif tag information and embedded color profile are not > synch'ed. This causes other software to mis-interpret the image color space. What causes other software to misinterpret the image color space is GIMP's failure to embed the built-in sRGB profile. If GIMP had all along been embedding the built-in sRGB profile, this bug report never would have been filed. > Steps to reproduce: > 1. Open jpg image which includes: > EXIF color space tag to "Uncalibrated" and the InteropIndex EXIF field to > "R03", which, together, means Adobe RGB > 2. Convert image to sRGB, using Image -> mode -> Change color profile... > [ I am not sure about the exact menue names, since I do ot use an English > GIMP] > 3. Save converted image as jpg > > > Actual results: > The saved jpg image contains an sRGB color profile, but still holds: No, the saved jpg image doesn't contain an sRGB color profile. There is no embedded ICC profile at all, because GIMP currently doesn't embed the built-in sRGB profile. > One way or another GIMP should update the medatada to tell what was done, > this is clearly a bug, the file should not be written with an sRGB profile > and metadata saying otherwise. The real bug is that GIMP doesn't embed the built-in sRGB profile in exported images, about which several bug reports have been filed: Bug 512485 - It's not possible to assign the builtin sRGB color profile to an image. Bug 627594 - colour management - unable to save images with sRGB profile Bug 689042 - Unable to Assign and Embed Color Profile I don't know of any other ICC profile color-managed image editing software that doesn't embed the assigned ICC profile upon exporting the image. If there is such software, users of such software should be filing bug reports. I've looked, and I can't find any other ICC profile color-managed software that modifies the original camera-saved DCF/exif/maker-note color space information, except apparently darktable changes one tag, which imho is the wrong thing to do, for reasons explained in bug 492048.
(In reply to Elle Stone from comment #9) > I don't know of any other ICC profile color-managed image editing software > that doesn't embed the assigned ICC profile upon exporting the image. If > there is such software, users of such software should be filing bug reports. The exception, of course, is software that provides an "export for the web" option that explicitly does not embed an ICC profile. In this particular case, the image should already be in the sRGB color space, and the original dcf/exif/maker-note color space tags (if any) should NOT be embedded in the image. The usual "use case" for not embedding the sRGB profile in images is dealing with web design, where improper browser color management (a serious issue) renders images with embedded sRGB profiles differently from css elements and images without embedded ICC profiles. The other "use case" is people following advice (extremely bad advice, given browser mishandling of images without embedded ICC profiles) to never embed ICC profiles, to save space in photographic images uploaded to the web. In which case the user ought to be embedding as little metadata at all, and so of course the dcf/exif/maker-note color space tags shouldn't be embedded in the image. GIMP currently covers the web-design and space-saving use cases by not embedding the built-in sRGB profile in any exported image, as per bug 646511. Given the new capability that GIMP has to embed metadata, combined with default "save all the metadata" export settings hidden behind the advanced "drop down" export menus, anyone exporting design elements for use on a website might be inadvertently exporting a whole lot of embedded metadata, depending on the source image for the exported design element. GIMP needs an "export for the web" option to cover use cases where the user doesn't want to embed the built-in sRGB profile. In these use cases, dcf/exif/maker-notes color space metadata should be removed. The default action, the action that should be taken unless the user chooses to "export for the web" should be to automatically embed the GIMP built-in sRGB profile, assuming that's the profile that's assigned to the XCF file from which the image was exported.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/301.