GNOME Bugzilla – Bug 500292
interpret Exif ColorSpace information
Last modified: 2016-04-17 16:08:17 UTC
I have a patch that changes the JPEG plug-in to interpret Exif ColorSpace information by using lcms to create a color profile from the whitepoint and primary chromaticities. It then attaches this profile to the image. There are some caveats here, so I am not committing this yet. First of all, I have not a single example image so I can't test this code. Secondly, it seems wrong to keep this information in the Exif data and to attach it as a profile. Perhaps we need an extra parasite for this?
Created attachment 99801 [details] [review] patch to interpret ColorSpace information
Btw, similar tags are defined for PNG files and should be treated similarly. libpng provides the function png_get_cHRM() to retrieve this information. But we should first define how to best treat them. One option would be to add an extra parasite for this information and to do the conversion to an ICC profile in the lcms plug-in.
I tend to agree that it feels weird to attach a color profile when the EXIF data already contains the necessary information for a color profile. Wouldn't the most natural be to not attach any new parasite at all and instead treat the EXIF parasite as the color profile parasite?
The lcms plug-in should not have to deal with EXIF data or details of the PNG file format.
Does this get any easier with the recent metadata changes?
DCF information isn't just a jpeg problem. It crops up in all file types in which the relevant metadata can be embedded (jpegs, pngs, tiffs, other?): *Most cameras only save in-camera-generated jpegs and perhaps raw files. But some cameras also save in-camera-generated tiffs. *Upon opening a camera-generated jpeg, some people immediately convert the image to a lossless format and carry all the original metadata along to the new file format. *Raw files also carry DCF information. After embedding an ICC profile in the interpolated image, 3 of the 4 open source raw processors that I checked did *not* remove the DCF-related metadata tags, thus leaving potentially contradictory color space information in the image file. Some possible approaches: *Pay attention to Exif/DCF/XMP color space information tags, but always ignore proprietary camera MakerNotes. *Upon opening any image, give precedence to an embedded ICC profile, and also check for, list, and offer to remove embedded DCF information. Don't bother updating it (given the number of "DCF-stupid" imaging programs, it's not very useful information). Just remove it or leave it as is, depending on the user's preference. *Perhaps include a Color Management Settings dialog to pre-select how to deal with embedded DCF information, perhaps: "always ask"; "always remove and embed a real profile"; "warn but don't remove"; "ignore". *One option is to start bundling sRGB and AdobeRGB profiles with Gimp (I suggest the public domain Argyllcms profiles) and then ask if the user wants to assign and embed the appropriate profile, and at the same time offer to remove all the DCF-related information. *If the DCF-related metadata indicates AdobeRGB, there might also be gamma, white point, and chromaticity tags, from which lcms can create an on-the-fly profile. But lcms can't do this automatically. Lcms doesn't read Exif/DCF tags. Lcms only reads and and only writes actual embedded ICC profiles. So code would need to be written to read the gamma, white point, and chromaticity tags and then that information would need to be fed to lcms. As an aside, EXR files also carry white point and chromaticity tags instead of actual ICC profiles (the gamma is assumed linear for EXR files). So the code to create an on-the-fly Adobe-compatible profile will also be useful for color-managing EXR files. This page shows what the various embeddable color space information tags look like: http://ninedegreesbelow.com/photography/embedded-color-space-information.html This page gives some Gimp-specific examples, a list of Gimp DCF bugs, and links to DCF and Exif standards: http://ninedegreesbelow.com/gimpgit/gimp-camera-dcf.html
Looks like this is now implemented, and we have separate bugs for the missing bits (such as letting the user know that we created a profile based on DCF information). Can we close this bug? Elle?
(In reply to Michael Natterer from comment #7) > Looks like this is now implemented, and we have separate bugs for > the missing bits (such as letting the user know that we created a profile > based on DCF information). Can we close this bug? Elle? I would say yes, this bug can be closed as https://bugzilla.gnome.org/show_bug.cgi?id=555562 and https://bugzilla.gnome.org/show_bug.cgi?id=759942 seem to cover all the issues raised in this bug report.
Thanks, closing :)