On Wed, 7 Jul 2004, Alastair M. Robinson wrote: > Sven Neumann wrote: > > > Well, we have only one internal color space. We just need to agree on > > what we want to call it... > > 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. > Whatever you do, you will have to make a compromise. The question is, what is the best compromise. I'm very far from being an expert in this area, but I'll try to put in some thoughts. You are worried about quantization errors during the conversion, but if you do the conversion in 16 bit or more I think you will not have much problems. In the littlecms site I found a command line program that does the colorspace conversion with very high accuracy. Check http://www.littlecms.com/newutils.htm#icctrans (This command line program does compute colorspace conversion based on icc profiles. Additionally, it can show XYZ and Lab values of PCS, and up to 16 bits of precision (48, 64 bits per pixel)). So, we even have example code ready for the conversion. The bigger problem we will have when converting colorspaces, is the limited gamut of sRGB in comparison with the source colorspace. For example, if we convert from CMYK to sRGB, then almost any color with CMYK values in the range C>90, M<10, Y<10, will have no sRGB counterpart. Would it be feasible to switch from sRGB to something better? Maybe AdobeRGB? I found usefull the http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html when comparing color spaces. Keep in mind though, that if we change the internal color space from sRGB to something else there must be an option for the user to save his image in sRGB (and maybe that should be the default on many cases). sRGB is the best option when someone tries to view an image in a computer monitor with no color profiling. As for the proposed conversion on save to the starting colorspace, I completely dissagree. I don't see any reason to introduce more errors coming from a less than optimal conversion. What I think best is: Image (Any space) -> Working data in Internal gimp colorspace (sRGB or better something else) -> Editing -> Save (user selectable space; defaulting, at least for the xcf format, to the internal gimp colorspace) The question is: Are all these feasible for the 2.2 release? (which can be trivially converted to: Is there anyone willing to work on that?)
