Hi,

David Neary writes:

The two propositions are (or seem to be):

1) Apply embedded profiles (after prompting the user whether they would like to do that) at load time, or attach the profile to the image at load time and use the raw image data, assuming that sRGB (or some other colourspace) is the internal colourspace all the time.

2) Allow the user to set the internal colourspace, and warn when an attached colourspace does not match the current internal one, allowing the user to either apply the profile to convert to the current colourspace, set the internal colourspace to the new one, or not use the colour profile for the image.

I don't see how (2) could work without adding color management throughout the application and most plug-ins. This is certainly a goal for the time with GEGL but nothing that we should target for 2.2.

It seems to me that (1) is the best solution for now. I propose however that we keep most of this functionality in a color-management plug-in. Such a plug-in would offer to apply color profiles and to change the color profile attached to an image. Combined with a color display filter to handle the monitor profile this would keep the lcms dependency to a few defined places and would still allow us to add some basic color management. This should allow us to collect some experiences in this new area. Experience that should help us to get color management right in GEGL.

I was talking to Sven on IRC, and he seemed to believe that neither of these would be done for 2.2, and that only the infrastructure which would allow these to be done easily post-2.2 (when we hope to have higher bitdepths internally for image data). At least, that's what I think he said, but I didn't really follow.

I think that we should focus on adding the API that is needed to implement some basic but useful color management in plug-ins and modules. Whether this means that 2.2 will include these plug-ins and modules or if they will be developed separately (and perhaps even after 2.2 is released) remains to be seen.

Sven

So at the most concrete possible level, here is a suggestion on how to start:

Step 1: Add a "Color Management" page to the Preferences.

Step 2: Add "enable/disable color management" and "working colorspace" options to the page. To start with, sRGB will be the only option for the latter, but the infrastructure should not build in any assumption that this will always be true.

Step 3: In the file-loading code, after an image has been loaded, check for the presence of parasites called either "icc-profile" or "colorspace". If one of these is found, execute the color management plug-in.

Step 4: Write a color management plug-in.

Best, -- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

Hi,

"William Skaggs" writes:

So at the most concrete possible level, here is a suggestion on how to start:

Step 1: Add a "Color Management" page to the Preferences.

Step 2: Add "enable/disable color management" and "working colorspace" options to the page. To start with, sRGB will be the only option for the latter, but the infrastructure should not build in any assumption that this will always be true.

Step 3: In the file-loading code, after an image has been loaded, check for the presence of parasites called either "icc-profile" or "colorspace". If one of these is found, execute the color management plug-in.

Step 4: Write a color management plug-in.

Sounds good except that Step 4 should be first.

Sven

Hi Sven,

Sven Neumann wrote:

"William Skaggs" writes:

So at the most concrete possible level, here is a suggestion on how to start:

Step 1: Add a "Color Management" page to the Preferences.

Step 2: Add "enable/disable color management" and "working colorspace" options to the page. To start with, sRGB will be the only option for the latter, but the infrastructure should not build in any assumption that this will always be true.

GIMP really won't care what this working space is; as far as the core is concerned it's just a filename, so why limit it to sRGB even temporarily?

Step 3: In the file-loading code, after an image has been loaded, check for the presence of parasites called either "icc-profile" or "colorspace". If one of these is found, execute the color management plug-in.

Step 4: Write a color management plug-in.

Sounds good except that Step 4 should be first.

Sure, but the plugin will depend on the implementation of the other stages. The guts of the plugin, thanks to lcms, will be pretty trivial - far simpler than the separate plugin; the most important factor will be the design of its user interface, and supporting factors, e.g. do we support tagging images both with an actual profile, or with the filename of a profile, and such like.

There are a couple of other issues that might warrant discussion with the developers of lcms; how to go about comparing profiles for equality for instance (we want to be able to avoid converting between an embedded profile and the working space if they are in fact the same profile!)

All the best, --
Alastair M. Robinson

Hi,

"Alastair M. Robinson" writes:

Sure, but the plugin will depend on the implementation of the other stages. The guts of the plugin, thanks to lcms, will be pretty trivial - far simpler than the separate plugin; the most important factor will be the design of its user interface, and supporting factors, e.g. do we support tagging images both with an actual profile, or with the filename of a profile, and such like.

Well, adding a few gimprc options takes a couple of minutes only and that should be all that is needed for now.

We already support tagging images with a profile. the suggested parasite name for this is currently "icc-profile" and we should try to keep this for backward compatibility. Of course we will need to define some more parasites. Perhaps someone could sit down and propose the parasites we will need for color management.

There are a couple of other issues that might warrant discussion with the developers of lcms; how to go about comparing profiles for equality for instance (we want to be able to avoid converting between an embedded profile and the working space if they are in fact the same profile!)

Does lcms provide an API for this?

Sven

PS: I wonder if we should add the separate plug-in to the GIMP tarball for GIMP 2.2. Would you like to see that happening?

Hi,

I wrote this in an earlier mail already but perhaps you didn't notice, so here's my question again:

I wonder if we should add the separate plug-in to the GIMP tarball for GIMP 2.2. Would you like to see that happening?

Sven

Hi,

David Neary writes:

I wrote this in an earlier mail already but perhaps you didn't notice, so here's my question again:

I wonder if we should add the separate plug-in to the GIMP tarball for GIMP 2.2. Would you like to see that happening?

I would. I assumed you were asking Alastair, though.

I do, that's why I sent my mail To: "Alastair M. Robinson".

Sven

Hi Sven,

Sven Neumann wrote:

I wrote this in an earlier mail already but perhaps you didn't notice, so here's my question again:

Sorry, yes I did miss that...

I wonder if we should add the separate plug-in to the GIMP tarball for GIMP 2.2. Would you like to see that happening?

I'd be delighted - though there are a few bugs I'd like to fix first!

If it's going to become semi-official, though, I guess some discussion is needed about various points:

1. Where in the menus it should live. Currently, my functions are in Image->Separate. The separation is, however, performed on the current layer, not the whole image. The separation functions themselves are really not much more than a colour-profile-aware version of the compose/decompose code that's there already, so maybe alongside those would be the best place. Alternatively, depending on how far we get with colour-management in general, a new top-level Colour Management menu might be a better option?

2. Should the saving function be left with the separation functions, or be moved into the TIFF plugin.

3. How about adding support to the TIFF plugin for loading CMYK images into individual greyscale layers, thus solving the biggest limitation that the separate plugin currently has, i.e. not being able to load its own images back in. (This would have to be an alternative option to converting the CMYK data to RGB using lcms, if we implement that, or using libtiff's own Everything->RGBA converter.)

Does anyone else want to bring up any further points?

Finally, a question: How is a plugin supposed to go about storing persistent data between sessions (i.e. in my case, the filenames of the profiles last used)?

All the best, --
Alastair M. Robinson

Hi,

"Alastair M. Robinson" writes:

Finally, a question: How is a plugin supposed to go about storing persistent data between sessions (i.e. in my case, the filenames of the profiles last used)?

The plug-in can attach a persistent parasite to gimp.

Sven

Hi,

David Neary writes:

Finally, a question: How is a plugin supposed to go about storing persistent data between sessions (i.e. in my case, the filenames of the profiles last used)?

The plug-in can attach a persistent parasite to gimp.

Are parasites ever saved across sessions? I didn't think they were.

Persistent parasites are saved of course. Otherwise they wouldn't be persistent.

This also implies that the plug-in authors should be careful with persistent parasites. They would better be able to parse any parasite they set in an earlier version (or at least detect that the format changed and gracefully ignore it).

Sven