GNOME Bugzilla – Bug 751030
Add the ability to embed the GIMP built-in sRGB profile upon exporting an image
Last modified: 2018-05-24 15:22:34 UTC
Many GIMP users choose to edit using the GIMP built-in sRGB profile(s, now there's a linear version). If these users want to export a final image to disk with an actual ICC profile embedded in the exported image, so far their only option has been to find and download an equivalent profile on disk and then assign the equivalent profile to the image before exporting it, or else use command line tools or another image editor to assign the equivalent profile on disk. Many times the exported image really does need an embedded ICC profile, even if the image is an sRGB image: * Some print shops want an actual embedded ICC profile, to avoid having to guess what the color space really is. * Photographers who upload images to the web often want to embed an sRGB profile in the image, to accomodate issues with today's not-very-well-color-managed browsers. * When opening the exported and profileless image with another image editor, the user has to tell the other image editor what the correct profile is, which again means they need to find the equivalent profile on disk. It would be very helpful if the user could request that the correct GIMP built-in sRGB profile be embedded in the image upon export.
Actually an image without a profile is meaningless. Color values are just numbers until they are given a definition through profile. Of course, this works OK since most (all?) programs will just consider a profile-less image as sRGB, but maybe GIMP — as an advanced image editing program — should know better and do the right thing, which is: always embed a profile (even if just the default sRGB)? At least this way, we make 100% sure that the image would show up the same everywhere. Because theoretically, you could have your image assigned a different profile somewhere else. That's just an idea. Maybe that's a bad one, I don't know.
That would at least never be broken because the data *is* sRGB, and better than another export option.
Personally I try to never export an image to disk without an embedded ICC profile. But web designers will have conniption fits if they can't easily export sRGB images without embedded ICC profiles. This is because of the totally and diversely broken ways the various browsers and OS's handle color management. Of course web designers always have the option to use a script to remove embedded profiles. And of course photographers, artists, etc have the option to use a script to embed a profile in the profileless sRGB images currently exported from GIMP (which is what I do, or else I assign the equivalent profile from disk before exporting the image). But there probably isn't any way to keep both groups happy without offering both groups an easier option than using a script or an extra "assign profile" step. One possibility would be to embed the built-in sRGB profile by default, and add an "export for the web" dialog that could have various options including the option to embed or not not embed the sRGB profile. Another possibility would be to put a checkbox in Preferences that allows the user to specify whether or not to embed the built-in sRGB profile upon exporting sRGB images.
Yes, that's why I was wondering if this could be a bad idea: are they cases where people really don't want an embedded ICC. Though… > This is because of the totally and diversely broken ways the various browsers and OS's handle color management. What's the worst broken behavior a browser (or other software) can have towards color management? Well if they don't take it into account (= always consider sRGB), whether you embed the ICC or not is the same. But are you saying there are cases where they would display the image wrongly *because* you have a sRGB embedded profile? > add an "export for the web" dialog that could have various options including the option to embed or not not embed the sRGB profile. > […] > Another possibility would be to put a checkbox in Preferences If we have to give the choice, I would be in favor of both a preferences in color management for choosing the default behavior + a checkbox in export dialog to override this behavior. Because it's boring to always change the options (hence you want a preferred defaults), yet I don't want to go in preferences each time I have a different export need.
See https://bugzilla.gnome.org/show_bug.cgi?id=646511 for why sometimes web developers want to remove embedded ICC profiles. I forgot that we already have the option to remove an already embedded profile - "Image/Color Management/Discard Color Profile" from the above bug report. Ideally all elements (images and css) that don't have embedded ICC profiles should be treated by browsers as sRGB images and then converted from sRGB to the monitor profile for display in the browser. This is not what most browsers actually do. Most browsers do most things related to color management wrong. And one wrong thing some browsers do is treate images with embedded ICC profiles differently than css elements and images without embedded ICC profiles. Firefox with its default CM settings does exactly that: treats images with embedded ICC profiles differently than css elements and images without embedded profiles: https://bugzilla.mozilla.org/show_bug.cgi?id=621474 This jpeg shows the correct settings for full and proper FF CM (but I expect most users never change the default FF settings): http://ninedegreesbelow.com/galleries/viewing-photographs-on-the-web/firefox-31-color-management-preferences.jpg From a web graphics design point of view it's more important that the css colors match the graphic design element colors than it is for the graphic design colors to be properly displayed (for example displaying a logo with surrounding css-generated colors that need to match the logo colors). For displaying photographs or artwork, even sRGB images need embedded ICC profiles. Of course many browsers still don't support V4 profiles. But that would be a separate bug report.
-- 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/701.