"Alastair M. Robinson" <[EMAIL PROTECTED]> writes:
> 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"
> 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)
This is also what I originally proposed at GIMPCon. I have then been
told that this would be the wrong thing to do and that we should
convert the image on load. Now that you backed up my original proposal
I tend to agree with you that converting the image data is not
feasible as long as we work with 8bit per channel.
> 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.
Color-correcting the color-selectors is of course a must. We have put
the color display filter architecture into libgimpwidgets to be able
to implement this. It shouldn't be too hard and could be achieved for
Gimp-developer mailing list