(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
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"
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
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
Gimp-developer mailing list