The current state is just a quick preliminary implementation. It is far from being finished.

Let's put this on the milestone for 2.6.

Would be nice to have and seems pretty straightforward to implement. Let's aim for 2.8 here.

The current design is a compromise due to the fact that the GIMP core doesn't know anything about color profiles and doesn't link lcms directly. The idea was to allow color management to be implemented in platform-specific modules and plug-ins. The lcms implementation is just one possible way of doing it. But there doesn't seem to be much interest and so far our experience with lcms has been good. So perhaps we could drop this and actually link libgimpcolor and libgimpwidgets against lcms. But this needs to be discussed on the mailing-list.

Although presenting the user with an automatically generated drop-down list of ICC profiles sounds nice in theory, in practice it creates serious useability problems:

1. The proposed list of ICC profiles would need to hit all the "default" locations. 

* 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. These locations vary for Windows, Linux, and no doubt BSD and Mac.

* Some applications, including argyllcms, put ICC profiles in completely nonstandard, software-specific folders. I can give you a long list of other programs that put ICC profiles in odd places. 

* Maintaining a list of "all the places" would be an on-going battle.


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 working spaces, cameras, monitors, scanners, printers, etc, including people who:

*make a custom camera profile for every shooting session. 
*make their own prints and have not just one but a whole series of custom printer-paper profiles. 
*make their own custom monitor profiles and have several different monitor profiles created for different purposes.
*make their own working space profiles because the standard profile packs aren't suitable for one reason or another.
*download profiles from the internet
*install software not through the usual repositories, but perhaps through wine or locally


3. Precompiled lists can be very, very long. 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 lcms to generate their own working space profiles or 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.

* 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 essentially impossible. My solution is to "locate and move" all profiles I'm not actually using, to get them out of all the "default" locations and hence 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. Most users won't want to mess with chowning root folders, and in a multi-user setting, this wouldn't even be an option.


4. Plus there is the on-going problem of getting new profiles into or out of "default" folders:

* 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. For example, Krita and digiKam require a restart. It's a ***major*** user inconvenience to have to exit an imaging program just to add a new profile to some predetermined location.

*If the ICC profile the user really wants to use hasn't already 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. 


5. In practice the profile descriptions are not nearly as helpful as one might hope:

*A description doesn't really tell you ***which*** sRGB or ***which*** ProPhoto or ***which*** AdobeRGB profile you are about to select, unless you already know what the description for each profile variant. 

*It's highly unlikely in practice that anyone really knows which description goes with which profile. I sometimes resort to using iccToXml to modify the profile descriptions to make them more specific (ie add which software distributed it, where it's located, its file name, etc) so I can tell which profile is which on the digikam and krita drop-down lists. Most people won't be able to do this, so they'll be stuck just guessing which is which. 

*It ***does*** matter which sRGB (or AdobeRGB or ProPhotoRGB, etc) profile a person chooses. There are still faulty sRGB and AdobeRGB profiles floating around open source software. And there are slight differences between various nominally the same profiles, even when the profile isn't completely faulty to begin with.


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

* 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 ***please, please, please*** make it an option controllable through "Preferences/Color Management". 


7. The only changes I'd personally like to see in how Gimp handles accessing ICC profiles are:

*That Gimp automatically open the last folder that was used to choose an ICC profile

*That the profile path and name ***always*** be provided, in addition to the description. Currently in some places (such as the list of recently used profiles), Gimp only gives the (almost always less than helpful) profile description. But there is no guarantee that a description is even unique! which means carefully rechoosing a profile from disk instead of selecting it from the list of recently used profiles. 

So please, please, please, no drop-downs with descriptions as the only way to choose an ICC profile! Let the user put her profiles anywhere she wants! And let those profiles be chosen by path and file name, not just by description.

So it could probably be useful if GIMP handles ICC profiles like other resources, e.g. patterns, and includes tagging, searching, configurable folders, and have them displayed in a dockable dialog?

Oh hell no, better have a list of directories, a different one on each
platform, monitor them for changes, and update our list of profiles
accordingly.

If you go the route of making a list of all possible directories in which one might find ICC profiles, monitoring for changes, updating list accordingly, etc, would you please also offer the option of letting the user set **just one** user-specified directory instead of **all** the directories? And make sure the path and file name are given as well as the description?

Once I did an experiment to see how many ICC profiles could be installed just using the OpenSuse repositories. The grand total was 117 profiles, including 27 different sRGB profile variants and nine different AdobeRGB profiles. 

Fortunately only about 9 of the sRGB profiles were in /usr/share/color/icc and subfolders. Unfortunately my preferred sRGB profile, from Argyllcms, is in a non-standard location. See this article for details: http://ninedegreesbelow.com/photography/linux-icc-profiles.html

I have been having a long email exchange with Elle about CM and colour profiles.

Unfortunately even the average user soon has far too many seemingly identical profiles.

The current GIMP profile selection remembers them all but due to the way they are tagged, it is far too easy to select the wrong one.

For this reason, I think it is time - as Elle suggests in Bug 608961 - that GIMP distribute its own colour profiles.

The main advantage as I see it, is that there would then be only one single directory with only five profiles!

Want to enable another profile in GIMP? Copy it to this directory (possibly /usr/share/color/icc/gimp or something like)

[For the problematic AdobeRGB1998 profile, this will be needed. Or else use the provided ClayRGB1998 profile!]

Personally I have a whole lot more than five ICC profiles on my computer and I would greatly resent having to put a copy of all those profiles into one folder just so Gimp could find them. At the present time Gimp allows the user to look in any folder the user chooses. I hope this remains the case.

While it's true that I provided sample code in https://bugzilla.gnome.org/show_bug.cgi?id=608961 that makes five ICC profiles, I didn't mean to imply that anyone should only have access to just those five ICC profiles. If Gimp were to provide ICC profiles it would be nice to ask Gimp users which profiles they actually like to use.

One major point of my comment on https://bugzilla.gnome.org/show_bug.cgi?id=608961 was that as Gimp moves to linear gamma image editing, and as darktable already allows the exporting of linear gamma openexr images, it would be nice if users had access to linear gamma versions of the ICC profiles that they want to use. So assuming Gimp users did want these five profiles, that would be ten profiles already, two versions of each profile.

A good naming scheme, with the name of the profile repeated in the description, would solve the problem of "which profile is which".

As far as the AdobeRGB1998 profile from Adobe goes, that is not a floss profile and if a user wants to use that exact profile, they can get it from Adobe.

Well, for various reasons, I am generally drowning in profiles.

So I was responding to:

    "would you please also offer the option of letting the user set **just
     one** user-specified directory instead of **all** the directories?"

I have no objection to other ideas, but this seemed to be the simplest.

The point about Linear profiles is well taken, Blender switched around 2.5:

    http://wiki.blender.org/index.php/Dev:2.5/Source/Imaging/Colour_Management

It was quite disruptive to me personally - but I got over it quickly.

The real problem with profiles is that they are very rarely tagged in any useful way. The ideal would be self-documenting tags that both describe the profile itself as well as possible end uses.

Hmm, you are right. I did say that. I'm drowning in profiles, too. That's what I like about being able to navigate to the desired folder, which is how Gimp works at present. By comparison, picking a profile with Krita's or digiKam's or Cinepaint's dropdown menu is much, much, much more difficult.

If there were a drop-down menu, in theory, one folder would seem to make things easier. In practice, that's how darktable works and I find I don't like it at all. Yes, the list of profiles is limited to the profiles in the folder. But adding a new profile means closing darktable, adding the profile to the folder, and reopening darktable. Even if closing and reopening darktable weren't necessary, stopping to add a profile to a folder is an unwanted break in the workflow. Being able to navigate to the folder like Gimp allows at present is much easier.

If someone does add a dropdown menu to Gimp, how to make it work best would require a lot of thought. It might make life easier for people who only have a few profiles all in one folder and/or its subfolders, but I doubt it would make life easier for people drowning in profiles.

You are right to say the real problem is profiles aren't tagged in any useful way. Better profile file names and descriptions would help users a whole lot, whether or not drop-down menus were being used.

Is there any outcome here? I'm tempted to conclude that our current combo
box of files is not that bad :) and we can safely close this bug because
having a general "Improve feature foo" is not overly useful.

(In reply to Michael Natterer from comment #13)
> Is there any outcome here? I'm tempted to conclude that our current combo
> box of files is not that bad :) and we can safely close this bug because
> having a general "Improve feature foo" is not overly useful.

The way GIMP currently is set up to allow users to choose ICC profiles that have been put wherever is convenient for the user, is exactly perfect. The new information displayed for ICC profiles is really nice!

Please don't change a thing! Closing the bug seems to me to be an excellent idea.

Thanks, so be it :)