Hi,
(Second try, this time sent to the list at large. Brains where art thou!)
Sven Neumann wrote:
Well, we have only one internal color space. We just need to agree on what we want to call it...
My two-penneth (as author of the separate plugin, and a day-to-day user of the GIMP in a pre-press environment):
There are as I understand it, two possible ways of dealing with colour profiles.
In the first method, is what I believe is what PhotoShop uses (and what I think Sven proposed): When an image is loaded, scanned or whatever, it is converted from its source colour space into a "working" colour space (sRGB, AdobeRGB, etc.). Of course, the source colour-space and working colour-space can be the same. The advantage of this method is that the working data is always "normalised", so plugins and the like have perceptually identical results, whatever the image's "native" colour space.
The workflow for an sRGB Image might be:
Image (AdobeRGB) -> Working data (convert to sRGB) -> Editing -> Save (convert back to AdobeRGB)
Personally, I don't think this method is appropriate for the GIMP until such time as we have support for 16-bit or float pixels, because if we convert from the source space to a working space with only 8 bits per sample we're going to lose some information through quantization errors.
The second method, which I think we should use for the time being, is just to keep track of the "source" profile for each image (and have a user-selectable default profile - sRGB, AdobeRGB or whatever). This source profile should be user-changable (so the user can tag a scanned image with the scanner's profile, for example), and just needs to be accessible to the proof and image-saving code.
The equivalent workflow would be: Image (tagged with AdobeRGB) -> Working data (8-bit RGB, unmodified) -> Editing -> Save (AdobeRGB)
The advantage is that the image data doesn't have to be transformed between profiles (so we need the facility to do this manually, should the user need it), but there are some disadvantages:
The effects of some plugins will look different depending on the image's colour space. (GFlare's flares, for example, will look slightly different applied to an sRGB image compared with an AdobeRGB image...).
Colour-choosing is less-predictable (though no less than at present), since the RGB values selected are in a variable colour space. Since we're unlikely to get a PanTone colour-selector any time soon, this shouldn't be an issue. The ultimate solution here is to have a colour-profile attached to the colour-selector, and simply transform the selected colour to the current image's profile. The colour-selector's profile is probably as close as we need to get at the moment to a "working" profile.
You would have to convert between colour spaces when copying and pasting between images with different profiles. (Ideally a warning with yes/no buttons. I personally wouldn't want this done silently, because again it would introduce quantization errors with 8-bit data).
In short, though, if we use this method, we don't need to agree on what to call our working space, because it will simply be whatever is appropriate for the image being edited!
Hope this little essay is some help!
All the best, -- Alastair M. Robinson
