As part of putting together an overview of how Gimp color management works (and doesn't work) from a user's perspective, I did some bugzilla searching to locate the open bug reports that deal with Gimp color management.

Of the 22 open bug reports that I found, possibly 5 or so bugs could be closed for one reason or another, 4 "extend color management" bugs could be consolidated under one tracking bug, 4 CMYK-related bugs could be moved to the existing CMYK tracking bug, and 4 DCF-related bugs could be consolidated under one tracking bug.

General color management bugs

1. Bug 397359 - Can not access to Colormanagement parameters

   This bug involves the display filters. It's odd behavior. But if you disable color management for a given image through the "color management " display filter, there's no way to re-enable it for that particular image short of closing the image and reopening it. Is there any reason to keep "color management" as a display filter? Is there any reason to have the option to disable color management for a given image but not for other images?

2. Bug 320447 - fast switching between "color managed display" and "softproof" (perhaps at some point discuss specifics on the mailing list)

   I would love to see better soft proofing in Gimp. It would be nice to get input from the user and developer mailing lists as to how good soft proofing should function. The Luminous Landscape has an excellent (albeit Photoshop-centric) tutorial on soft proofing. And I've done a comparison of the Gimp, Cinepaint, Krita, and digiKam soft proofing interfaces (the comparison doesn't include using Gimp third-party plug-ins). It seems to me that Cinepaint has the perfect interface but lacks in the ability to actually make appropriate edits to the image while soft proofing. Whereas Gimp allows all the changes one would like to make, but as this bug report notes there isn't any easy way to judge the effects of making edits to the image while soft proofing.

3. Bug 344525 - Improve ICC color profile selection (perhaps close as theoretically a nice idea, cumbersome in actual practice)

   Wouldn't it be better for the Colour Management settings to read the list of profiles from /usr/share/color/icc and ~/.color/icc, then present the appropriate profiles by their descriptor tags in a listbox (ala Scribus)? This would be a lot less annoying than the current file selector method.

   Although presenting the user with a list sounds nice in theory, in practice it can create serious useability problems:

   1. At this point in time there are several "default" locations for icc profiles in the user's home folder, not just "~/.color/icc", and sometimes the profiles in the home folders are duplicates of the profiles in /usr/share/color/icc.
   2. A list takes away the user freedom to put profiles wherever the user wants to put them. This is a serious problem for people who make and use custom profiles for cameras, monitors, scanners, printers, etc. Some people make a custom camera profile for every shooting session. People who make their own prints will have not just one but a whole series of custom printer-paper profiles. People who make their own custom monitor profile might well have several different monitor profiles created for different purposes. And so forth.
   3. If a user installs all the possible profile packs provided by their Linux distribution, that's a lot of profiles to have to wade through when looking at a precompiled list. As a test, I installed all the profile packs provided by openSUSE 12.2: the result was 70 or so profiles in /usr/share/color/icc and ten subfolders of /usr/share/color/icc. The various image editing programs install additional profiles beyond these 70 profiles. For people who use profiling software to create custom camera, monitor, scanner, and printer profiles, the number of profiles to wade through on a precompiled list gets even longer. For someone who also downloads various profiles from various sources on the internet, the list gets much longer, much faster.
   4. Speaking as someone who has a lot of ICC profiles on my computer, I find wading through and trying to decipher the "description only" lists that digiKam 2.9 and Krita 2.5 provide to be very, very difficult. My solution when dealing with digiKam and Krita is to "locate and destroy" all profiles I'm not actually using, to get them off "the list". This gets cumbersome and time-consuming as different applications put their profiles in different places, and the process has to be repeated every time I update or reinstall image-editing software or profile packs. I also sometimes resort to using iccToXml to modify the profile descriptions so I can tell "which profile on the list is which", which is something most users wouldn't want to do, even if they knew it was possible.
   5. Plus there is always the problem of getting "my" profiles into a predetermined folder. I solve the problem by "sudo chown -R elle /usr/share/color", then moving all the profiles I'm not currently using out of /usr/share/color/icc and moving all the profiles I am using into /usr/share/color/icc, after doing a "search and destroy" to remove profiles from other predetermined folders. This is not a particular nice solution, but when using digiKam or Krita, it's the only way I can get easy access to all and only the ICC profiles I actually intend to use.
   6. If the ICC profile the user really wants to use hasn't been transferred to one of the folders that are used to compile the list of available profiles, the user is forced to copy the profile to another folder, and the usual "list" folders are all either hidden or belong to root. Depending on the code that creates the list, the user may or may not need to restart the image editor to gain access to the new profile. This is a major inconvenience.
   7. Does the proposed list show just the profile description? Or also the profile filename and path? Either way, some profiles have enormously long descriptions that are difficult to show in a small drop-down box. And if you only show the description, how will the user know, for example, "which is which" of the 19 or more sRGB profile variants that might be on their computer? Many profiles have less-than-helpful descriptions, and in actual practice I find the profile description to be a singularly useless way to locate a specific ICC profile.

   To summarize, if a user only has a few ICC profiles on their system, and those profiles have well-written descriptions, and the user never has any reason to add a new profile, a list is a convenience. Otherwise, it's a huge hindrance. If someone wants to undertake all the extra coding it would take to provide an ICC profile list, at the very least make it an option controllable through "Preferences/Color Management".

   The current Gimp behavior is the nicest, most convenient behavior possible for anyone who makes and uses custom ICC profiles and/or has more than just a handful of ICC profiles on their computer. The only changes I'd personally like to see are first, that Gimp automatically open the last folder that was used to choose an ICC profile; and second, that the profile path and name always be provided. Currently in some places (such as the list of recently used profiles), Gimp only gives the (usually less than helpful) profile description.

4. Bug 608961 - Make GIMP color management behavior reasonable (perhaps close as probably not legally possible and not a good idea in general to be distributing ICC profiles with Gimp)

   The only concrete topic discussed in this bug report is whether to add the color.org V2 sRGB variants to the Gimp distribution. Three questions:

   One, is it even possible given the color.org copyright constraints? I'm not a lawyer, but I don't think the color.org licence is compatible with open source in general or with the requirements of specific Linux distributions (some of which take a harder line than others). There is not only the actual profile licence, but also the "shrink-wrap" notice you have to agree with before you can even access the profiles (http://color.org/resourcemain2.xalter).

   Two, do Gimp users need the color.org sRGB V2 profile variants? I think the answer is no:

   1. You can download the lcms V2 sRGB profile (which has a compatible open source licence) from the lcms website profile pack, or you can get it from various profile packs available through your Linux distribution.
   2. You can download the original sRGB V2 profile (with a public domain copyright) from the Argyllcms website, and it also comes with the argyllcms package.
   3. The color.org V2 profiles are a bit strange. One has a non-zero black point and a modified sRGB TRC, and it's intended for use as a MONITOR profile, not a working space profile. The other has a stated non-zero black point that conflicts with the profile TRC. In other words, it is a faulty profile. See here for further discussion: http://www.freelists.org/post/argyllcms/Shadow-detail-problem,23.

   Three, should Gimp take on the task of distributing ICC profiles? There are existing open source profile packs that already provide a pretty good selection of ICC profiles. If there is a need for an additional profile, it seems to me that it would make sense to ask one of the profile pack maintainers to add that profile to a profiles pack. If Gimp starts distributing ICC profiles, Gimp will just be adding to the proliferation of open source profile variants (last I counted there were 27 sRGB variants on my openSUSE 12.2 box, all installed directly from the openSUSE repositories).

   It seems to me that this bug should be marked as closed.

5. Extend color management beyond the image itself (perhaps consolidate all four bugs under one tracking bug)

   These bugs all want the same thing: extend color management beyond the actual image itself. I suspect Pippin's plans for Gimp might make these bugs obsolete. In any event, they could all be gathered together into one tracking bug called "Extend color management beyond the image itself". I probably missed a few other bug reports that fall into this category.

   1. Bug 467930 - color selectors are not color managed
   2. Bug 478528 - Layer previews are not color managed
   3. Bug 499794 - decompose plug-in does not take ICC profile of image into account
   4. Bug 556608 - Monitor color profile is not applied to filter preview

CMYK bug reports

It seems to me that that two of these bug reports can be closed as "not a bug" and the remaining bug reports perhaps could be brought under the CMYK "tracking bug", "Bug 123598 - CMYK support". That way, whoever undertakes to code up better CMYK support can just look at one bug instead of lots of bugs:

1. Bug 123598 - CMYK support

   Quoting from the bug, "The report is a big vague but we could leave it open as a tracking bug for adding CMYK support." A number of bugs have already been brought under this tracking bug.

2. Bug 586521 - CMYK Color Selector / CMYK Color Mistake (perhaps close as invalid)

   This bug report looks like a simple misunderstanding of how Gimp is currently designed to deal with opening a CMYK image. The person who submitted the bug also seems to have concluded that the problem wasn't a bug but a misunderstanding of how Gimp works. The last comment also says the bug is invalid. So it looks like the bug can be closed.

3. Bug 72344 - Support PSD files with Duotone data.

   This bug report got turned into a request for Duotone support. I think it also can be made part of Bug 123598 - CMYK support.

4. Bug 640613 - support for exporting CMYK TIFF format

   This bug report also could be moved to Bug 123598 - CMYK support and then marked closed.

5. Bug 647957 - The discrepancy between the values ​​CMYK in the "Information about the cursor" and the choice of color dropper tool

   This bug report shows the eye-dropper tool showing CMYK colors, so it looks like the reporter is using a third party plug-in. So this seems to be a request that Gimp add CMYK support and perhaps should be moved to Bug 123598 - CMYK support.

   Otherwise this bug is a request that the eye-dropper show the same color as the image, even when the image is not in the sRGB color space, which would be a duplicate of Bug 467930 - color selectors are not color managed (listed below under Extend color management beyond the image itself)

   So it looks to me like this bug can be split up and closed: the CMYK part moved to Bug 123598 - CMYK support, and the color selector part marked as a duplicate of Bug 467930.

6. Other bug reports that mention CMYK

   Searching open bug reports for reports that mention CMYK turns up several other bugs, but these bugs aren't specifically CMYK-related:

   1. Bug 154715 - Photoshop PSD Import Failure & TIFF Import Failure
   2. Bug 165063 - Can't import SVG paths from Illustrator (replace XML parser)
   3. Bug 323789 - Low Res and High Res simultaneous jobs
   4. Bug 382688 - Export as a PDF file
   5. Bug 425258 - Shortcut for Channel selection in Curves dialog etc.
   6. Bug 638940 - Support importing CMYK .PSD files

When the image has the wrong color model ICC profile embedded

There's only one example, an RGB image with an embedded CMYK ICC profile, but I suspect the same problem would occur if an RGB image had a LAB or GRAY color model ICC profile embedded.

exiftool 1x1.jpg
File Name                       : 1x1.jpg
Color Space Data                : CMYK
Profile Connection Space        : Lab
Profile Description             : U.S. Web Coated (SWOP) v2

When the image doesn't have an embedded ICC profile

The present behavior is that if the image doesn't have an embedded ICC profile, and the user has not chosen an RGB profile in the Color Management Settings, then the image is assumed to be "sRGB built-in". If the user has chosen an RGB profile in the Color Management Settings, then all images without embedded ICC profiles are assumed to be in the chosen RGB profile. In either event, the user has the option of then going to "Image/Mode/Assign color profile" to assign a different ICC profile.

Exporting images with and without an embedded profile

Regarding all of these bug reports, if the user understands how Gimp is intended to work, then the user can control whether or not the sRGB color space profile is embedded in an exported image. It seems to me that ideally exporting an image with or without an embedded profile should be a user-chosen option at the time of export, even when the assigned ICC profile is "sRGB built-in". Untagged images might be OK for the web (as long as the image really is an sRGB image), but everywhere else the image is simply "mystery meat".

• Bug 646511 - Having the possibility to remove ICC profiles (for web designs)

  The bug report says:

  While under Photoshop, it's possible to remove these color profile info while saving for Web, we don't have any feature that does the same thing under GIMP. . . . We can only remove gamma and that's all, no ICC profile removal option. . . . If you can't see why I talk about violet color, check the screenshot I attached to this report, it shows very well the huge difference I have when I view a pic having ICC profiles under Firefox and Chromium. The banner is OK under Chromium, but it appears violet under FF . . . This banner is actually a JPEG, but the issue is exactly the same with PNGs . . .

  This bug could be closed as a misunderstanding of how Gimp is intended to work. At present, Gimp is coded such that if the image has been assigned or is otherwise assumed to have the "sRGB built-in" profile, then upon export no ICC profile is embedded in the image. For all other assigned, assumed, and/or converted to ICC profiles, the profile is embedded in the image file upon being exported. Certainly at the present time pngs and jpegs alike are exported without embedded ICC profiles if "sRGB built-in" is the image color space assigned/assumed/converted to by Gimp.

• Bug 689042 - Unable to Assign and Embed Color Profile

  This bug report is the opposite of the previous bug report. The person wants the option of saving the image with an embedded sRGB profile. Again, Gimp operates as intended. If the person wants an embedded sRGB profile, the only option is to assign an sRGB profile from disk.

  The following two closed bug reports are about the same issue as the previous bug, but both of these bugs were resolved as "not a bug".

  1. 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

  This issue comes up often enough that perhaps this bug report could be kept open as a feature request.