Hi, "Alastair M. Robinson" <blackfive@xxxxxxxxxxxxxxxxx> writes: > 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) 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 2.2. Sven
