Sven Neumann writes:
> When an image file we open has an embedded color profile we should ask > the user if the image should be converted to linear sRGB (which is > what GIMP assumes internally).

Er, what's "linear" about sRGB? It's gamma encoded (and that's a good thing). Doesn't the term "linear" in the context of colour spaces mean one with components that are linear in intensity, i.e. a linear transformation of the CIEXYZ colour space, which sRGB isn't. Or am I confused?

I don't know, maybe we should also allow other (more wider gamut) internal working colour spaces than sRGB? A lot of the proprietary software users seem to use the "Adobe RGB" colour space. I don't know if they are just kidding themselves or whether it actually is noticeably better to use a wider gamut when working on photographic images. (If one uses a colour space with a much wider gamut than the monitor, or different primaries, (most monitors are "close" to sRGB), one definitely has to use a display profile.)

BTW, a good site with colour management info is www.brucelindbloom.com

--tml

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

Hi Alastair,

I'm no colourspace expert (far from it), but there were a couple of things which I spotted in this which prompted questions.

Quoting "Alastair M. Robinson" :

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)

Yes, this is what was discussed at the conference, with one important difference. We don't convert back to AdobeRGB or whatever at save time, we simply save the working image data, with the sRGB color profile.

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.

I see your point. Perhaps there could be some kind of pre-loading where we apply the color profile in floating-point, and quantise afterwards? Just thinking out loud, this may be completely unfeasible.

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).

The equivalent workflow would be: Image (tagged with AdobeRGB) -> Working data (8-bit RGB, unmodified) -> Editing -> Save (AdobeRGB)

How does this fit in with display calibration? If we work on the unmodified image data as we read it in, then on what data should the monitor's calibration profile work during projection? Should it work on the raw RGB data, or should we apply the input profile at projection time? Would a color profile be a per-layer thing?

I think these are the kinds of issues that Sven thought about before, and they make adding color management considerably more complicated. I think that the simplicity of applying a color profile on imput and not having to worry about it in the rendering code outweighs the down side of any quantisation that occurs.

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!

I think this is probably a very bad idea.

Cheers, Dave.

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 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?)

On Thu, Jul 08, 2004 at 05:47:56PM +0300, Steve Stavropoulos wrote:

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)

But one could want to make operations using specific profiles. I mean, addition is clearly not the same in CMYK or in sRGB, and marginally different in other color spaces. I do not develop for the Gimp, I am even partially color blind (which is why I read stuff about color spaces), but I think operations should be done in the image color space. Which means we have to keep track of an "image color space".

Alastair M. Robinson wrote:

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!

Dave Neary wrote:

I think this is probably a very bad idea.

I agree with Dave on this one. Here is just one example of the sort of nasty thing that can happen if different images use different color spaces, with corresponding display filters: You could have two two-layer images, A and B, such that:

(1) Layer A1 is visually identical to layer B1. (2) Layer A2 is visually identical to layer B2. (3) When layers 1 and 2 are composited in "Add" mode, the two images look different.

This can happen because of the nonlinearity in color profiles.

It would be a real can of worms not to use the same color space internally for all images -- losses in conversion are not an important enough factor to overcome this. (But there is a reasonably strong case for allowing choice as to which color space is used internally.)

Best, -- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

On Thu, 8 Jul 2004, Jean-Christophe Dubacq wrote:

But one could want to make operations using specific profiles. I mean, addition is clearly not the same in CMYK or in sRGB, and marginally different in other color spaces.

Gimp uses only one internal colorspace, 8bit RGB and I don't see that changing any time soon. So, you will never make operations in CMYK. The whole point with colorspaces is to have acurate colors. If you work in a colorspace with a wide enough gamut you are ok. That's why photoshop uses internally Adobe RGB 1998 independently of the images original color space.

Hi Dave,

Dave Neary wrote:

Yes, this is what was discussed at the conference, with one important difference. We don't convert back to AdobeRGB or whatever at save time, we simply save the working image data, with the sRGB color profile.

OK - I agree that converting back to the original space is in most situations unneccessary.

I see your point. Perhaps there could be some kind of pre-loading where we apply the color profile in floating-point, and quantise afterwards? Just thinking out loud, this may be completely unfeasible.

Assuming we're using lcms, the internal conversion will be applied in full precision - the problem is that the destination data, by necessity of the GIMP's current limitations, must be 8-bit RGB. Converting 8-bit RGB data from one profile to another will not be a 1:1 mapping, so some colour information will be lost - I haven't yet conducted empirical tests for the severity of this effect, but I suspect that the 8-bit source data will be downgraded to something like 7 - 7.25 bit. For me, seeing as 8-bit RGB is already inadequate for smooth subtle gradients (cf. my gradient dither patch of a few months back) this is unacceptable. I concede, however, that not everybody will see it this way!

How does this fit in with display calibration? If we work on the unmodified image data as we read it in, then on what data should the monitor's calibration profile work during projection? Should it work on the raw RGB data, or should we apply the input profile at projection time? Would a color profile be a per-layer thing?

First of all, a profile on its own is worthless for rendering accurate colour - they must be used in pairs, source and destination, to create a colour "transform". Thus, if the GIMP is using sRGB internally, then at projection time you feed the RGB image data through an sRGB->Monitor Profile transformation. If instead you're using the unmodified RGB data from the original file, you just use an Image Profile -> Monitor Profile transform instead. (If the source image has no profile of it's own, then you can just tag it with a default profile.)

In short, projection your way looks like this:

Image (Source Profile) -> Internal data (sRGB) -> Screen (Monitor Profile) Two transformations, first from Source Profile to sRGB, secondly from sRGB to the Monitor's profile. This would work very nicely if the internal data could be stored in 16-bit or float precision. Because it can't we lose precision.

My way looks like this:

Image (Source Profile) -> Internal data (Source Profile) -> Screen (Monitor Profile)
Just one transformation directly from the source profle to the screen profile, and more importantly, no destructive change to the raw image data.

I don't think it would be feasible to make the profile a per-layer thing. I personally consider per-image to be the best solution, as long as there's some way of warning the user if they're copying and pasting between images with mismatched profiles.

I think these are the kinds of issues that Sven thought about before, and they make adding color management considerably more complicated. I think that the simplicity of applying a color profile on imput and not having to worry about it in the rendering code outweighs the down side of any quantisation that occurs.

I'll conduct some tests some time and try and figure out just how bad these quantisation errors could be. I can certainly see the appeal of a simplistic approach, but if a little extra effort can prevent unnecessary destructive changes to the image data, I think it's worth exploring.

I think this is probably a very bad idea.

Could you expand on why you think this? Confusion? Difficulty of implementation? Something else?

All the best, --
Alastair M. Robinson

Hi Sven,

Sven Neumann wrote:

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.

Is there a transcript of these discussion available anywhere?

I'd certainly be interested to hear all the counter-arguments :)

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.

The colour selectors are perhaps one of the trickier aspects of my proposal; for their RGB values to be meaningful, the transform applied to the colour selector would need to change to reflect the current image's profile.

All the best, --
Alastair M. Robinson

Hi William,

William Skaggs wrote:

(1) Layer A1 is visually identical to layer B1. (2) Layer A2 is visually identical to layer B2. (3) When layers 1 and 2 are composited in "Add" mode, the two images look different.

This can happen because of the nonlinearity in color profiles.

I can see that this would happen; I don't, however, consider that to be a major problem, because you'd be able to see with more accuracy than at present what the result would be!

It would be a real can of worms not to use the same color space internally for all images -- losses in conversion are not an important enough factor to overcome this. (But there is a reasonably strong case for allowing choice as to which color space is used internally.)

I beg to differ!

A silently applied destructive change to the image data is in my opinion a very important factor!

All the best, --
Alastair M. Roobinson

Hi Steve,

Steve Stavropoulos wrote:

Whatever you do, you will have to make a compromise. The question is,

There we are in full agreement :)

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

I'm not worried about the conversion so much as the fact that the limited precision of the destination data (8-bit RGB) will cause us to lose colour information. A conversion of 8-bit data between two RGB profiles will not be a 1:1 mapping, so the converted data will not use the full dynamic range that 8-bit RGB can provide. Since the dynamic range of 8-bit RGB is already severly limited, I consider impairing it further to be unacceptable.

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
http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html when comparing color spaces.

If the GIMP is going to hand off the colour-matching work to littlecms, then using a different profile is as trivial as providing the filename of AdobeRGB instead of sRGB!

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.

Absolutely - though under my proposal, if an sRGB image is loaded, then for that image sRGB *is* the working space.

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.

Agreed. Subconsciously, I suppose I'd considered it "good manners" to save a modified image in the same colour space it started in, but you're right, this is not necessary.

All the best --
Alastair M. Robinson

Alastair M. Robinson writes:

I beg to differ!

A silently applied destructive change to the image data is in my opinion a very important factor!

It should definitely not be silently applied. When you open an image that uses a different colorspace from the standard one, you should get a dialog that asks whether you want to (1) convert to Gimp's working space, or (2) use the RGB values without conversion. If you convert, then you should be asked to choose a conversion intent. Nothing should happen without the user's knowledge.

For users who don't want to deal with these things, it may be useful to have a preference which, if enabled, turns off colorspace conversions and all queries related to them.

Best, -- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

Hi Alastair,

Alastair M. Robinson wrote:

Dave Neary wrote:
Assuming we're using lcms, the internal conversion will be applied in full precision - the problem is that the destination data, by necessity of the GIMP's current limitations, must be 8-bit RGB. Converting 8-bit RGB data from one profile to another will not be a 1:1 mapping, so some colour information will be lost - I haven't yet conducted empirical tests for the severity of this effect, but I suspect that the 8-bit source data will be downgraded to something like 7 - 7.25 bit.

I may be misunderstanding things, but if the conversion from the source colourspace to sRGB is done in lcms losslessly, then all we're losing is the out-of-gamut colours from the colourspace conversion. And, of course, the cost of discarding precision in the data we get after the application of the profile. But I think we still get the full 8 bits of data (they may not have the exact colours in the source file, though).

First of all, a profile on its own is worthless for rendering accurate colour - they must be used in pairs, source and destination, to create a colour "transform". Thus, if the GIMP is using sRGB internally, then at projection time you feed the RGB image data through an sRGB->Monitor Profile transformation.

Yes, but since this profile is applied once, on the projection drawable, as the final step, its application doesn't present any problems. But I see what you mean - we can go from the source colourspace directly to the monitor's with one transformation. This, however, poses problems for say the checkerboard pattern (which will be transformed differently with different source profiles), and for any occasion where different profiles get mixed (cut & paste operations, for example).

I would have thought you would still have to have the 2 profiles applied though... I'm sure I just don't know how lcms works.

I'll conduct some tests some time and try and figure out just how bad these quantisation errors could be.

Great - quantitative data will really help.

I can certainly see the appeal of a simplistic approach, but if a little extra effort can prevent unnecessary destructive changes to the image data, I think it's worth exploring.

Sure.

I think this is probably a very bad idea.

Could you expand on why you think this? Confusion? Difficulty of implementation? Something else?

The "this" was referring to a passage that you cut - I think it is probably a bad idea to have lots of image data in different colorspaces. I can't put my finger on why, but I just have this feeling that we will end up with a certain amount of confusion when it comes to colour stuff (as you pointed out, the colour picker is a good example, so is cut & paste).

I'm more than willing to defer to the many experts we have, though. I wish I knew enough about the subject to consider myself one.

Cheers,
Dave.

Hi,

David Neary wrote:

I may be misunderstanding things, but if the conversion from the source colourspace to sRGB is done in lcms losslessly, then all we're losing is the out-of-gamut colours from the colourspace conversion. And, of course, the cost of discarding precision in the data we get after the application of the profile. But I think we still get the full 8 bits of data (they may not have the exact colours in the source file, though).

As a (somewhat extreme) analogy, imagine applying a lightening gamma curve to an 8-bit data set (0,1,2,3,4.....253,254,255) you'd end up with not all codes being used at the dark end and codes being used multiple times at the light end - something like (0,2,4,6,7 .... 254,254,255,255). I.e. there are missing codes at the dark end, and reused codes at the light end, due to the limited dynamic range of the destination space. The problem I'm talking about will be something vaguely similar; there will likely be missing and reused codes in the working space.

Yes, but since this profile is applied once, on the projection drawable, as the final step, its application doesn't present any problems. But I see what you mean - we can go from the source

I wasn't suggesting this was a problem, merely trying to explain that profiles are only meaningful when used in pairs. People talk about applying a profile to an image; usually what they mean is applying a transformation between profiles to an image. It's an important distinction.

colourspace directly to the monitor's with one transformation. This, however, poses problems for say the checkerboard pattern (which will be transformed differently with different source profiles), and for any occasion where different profiles get mixed (cut & paste operations, for example).

It will indeed - I had already mentioned the cut-and-paste case as a possible pitfall. I hadn't considered the checkerboard pattern, but I'm not totally convinced that this is a critical problem!

I would have thought you would still have to have the 2 profiles applied though... I'm sure I just don't know how lcms works.

Yes, you need 2 profiles - the key is that you don't use profiles directly, you use transformations built from a pair of profiles.

The proposed method of using a standard working space involves three profiles (and hence two transformations linking them) - the image's own profile, the internal working space profile and the monitor profile.

The "this" was referring to a passage that you cut - I think it is probably a bad idea to have lots of image data in different colorspaces. I can't put my finger on why, but I just have this feeling that we will end up with a certain amount of confusion when it comes to colour stuff (as you pointed out, the colour picker is a good example, so is cut & paste).

I can certainly understand your gut feeling, and agree to a certain extent. The thought of destructive modification to the source data in just loading it makes me marginally queasier though!

I agree that copy-and-paste is a major potential pitfall, and will require at least a warning on mismatched profiles, and at best an option to convert as part of the paste operation.

I'm more than willing to defer to the many experts we have, though. I wish I knew enough about the subject to consider myself one.

I'm no expert either (expert: n. from "X", meaning unknown, and "Spurt", meaning a drip under pressure!), but I have used colour profiles outside of the usual PhotoShop setting, and am just anxious that any colour management abilities the GIMP should sprout will be usuable for pre-press work in my job!

All the best, --
Alastair M. Robinson

On Thu, 8 Jul 2004, Alastair M. Robinson wrote:

I'm not worried about the conversion so much as the fact that the limited precision of the destination data (8-bit RGB) will cause us to lose colour information. A conversion of 8-bit data between two RGB profiles will not be a 1:1 mapping, so the converted data will not use the full dynamic range that 8-bit RGB can provide.

That's exactly why we need the internal 8bit RGB colorspace used by gimp to be the widest possible. If the internal colorspace is wide enough then you won't notice any lost colors during the conversion. I don't know how much or how little these looses are, but photoshop works internally with adobe rgb 98 and no one complains about that. It seems that for practical use even the conversions to and from CMYK will be ok. The specifications of color spaces and the gamut projections on http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html I think will be of great help.

Since the dynamic
range of 8-bit RGB is already severly limited, I consider impairing it further to be unacceptable.

I don't think that we will have much lost gamut if we work in a wide-gamut internal color space. But again, I'm not an expert...

Hi Steve,

Steve Stavropoulos wrote:

That's exactly why we need the internal 8bit RGB colorspace used by gimp to be the widest possible. If the internal colorspace is wide enough then you won't notice any lost colors during the conversion. I don't know how

I'm not actually talking about gamut clipping, I'm talking about an effective loss of colour depth through quantization errors. I'm about to run some experiments, so I can hopefully provide some concrete illustrations, or eat humble pie, as may be appropriate!

much or how little these looses are, but photoshop works internally with adobe rgb 98 and no one complains about that. It seems that for practical use even the conversions to and from CMYK will be ok.

Photoshop can get avoid this issue by using 16-bit / float values to hold internal data. We can't (yet).

The specifications of color spaces and the gamut projections on http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html I think will be of great help.

Yes indeed, I'll digest that information in due course...

All the best, --
Alastair M. Robinson

> I am afraid that this is not possible simply because the color > selector is not associated with an image. All we can do is to correct > the color selector using the monitor profile.

You mean that the colour selector would implicitly always be sRGB? I'm afraid that's not a good idea.

Assume GIMP uses Sven's original idea (i.e. Alastair's preferred method) where images keep their original colour space. Say a user is working on an image in some colour space with a much larger gamut than sRGB. If the colour selector allows only sRGB colours to be selected, the "most blue" colours he can select have the B value 255. When converted to the image's wide-gamut colour space, the colour will have significantly less B value. There won't be any way to select the colours that are out of the colour selector's sRGB gamut.

I don't know what the solution is. Maybe some way to (temporarily) associate an invokation of the colour selector with a specific image? An entry in the menu "Select colour in image's colour space"? What does Potatoshop do?

--tml

Hi,

Quoting Sven Neumann :

All we are discussing here is
whether it makes sense to use display filters to color-correct the image display (and optionally color selector displays).

I don't think there is any argument about that. It does make sense to apply the monitor's profile as the last step in the projection.

The other
point that we are discussing is how file plug-ins should handle embedded color profiles, i.e. whether to attach the profile to the image or not.

I may be listening to a different conversation. The other point was whether embedded profiles should be applied at load time or be factored into the projection. In this scheme, the core would have to be at least aware of color profiles attached to images. It's not simply a question of attach or apply, since one has implications for the core, and the other doesn't. So this isn't just about the file plug-ins.

Cheers, Dave.

Hi Sven,

Sven Neumann wrote:

Well, it got to be doable in the file plug-ins since we don't want to have the core depend on lcms. Applying the embedded profile at load time could very well happen in the file plug-ins though. If the core needs to perform colorspace transformations then we should postpone this whole thing and do it properly with GEGL.

Given the limitations we're trying to work within, I think the best compromise is likely to be something like this:

- GIMP uses a user-selectable working profile. - If a user loads an image tagged with a different profile, she is presented with the following options: - Convert from the image's profile to the working profile, and accept the degredation that will result.
- Change the GIMP's working profile to match this image. This will leave the image data untouched. (This should disable the display filter for existing images, since they are presumably using a different profile.) - Load the image without colour management, disabling the display filter for this image.
- If a use loads an image with no profile, the display filter should be disabled.

- A simple plugin should be available to fill in the gaps, i.e. tagging an image with a specific profile (for images with no profile), or converting an image to the current working space if it has changed.

For the majority of users, this should suffice; I suspect compositing images with different profiles won't be a particularly common occurrence - the user just needs to be made aware that colour-space transformations are a destructive change, and have an opportunity to avoid them.

All the best, --
Alastair M. Robinson

Hi David,

David Neary wrote:

I'll conduct some tests some time and try and figure out just how bad these quantisation errors could be.

Great - quantitative data will really help.

I've done some testing - I wrote a little program that puts every possible 8-bit RGB colour through an lcms transform. A frequency table is kept of every colour that comes out the other side, which gives us some idea of how many codes are "lost" - how badly the dynamic range is reduced.

First, as a control subject, I analyzed the gamma function at 1.1 and 0.6. The results are as follows:

Gamma 1.1 Code use tally:
00: 1707993
01: 13481272
02: 1529388
03: 0
04: 57834
05: 0
06: 0
07: 0
08: 729
09: 0

In other words, 13,481,272 colours are mapped with a 1:1 ratio, so can be transformed back again without loss. 1,707,993 colours are missing from the destination set, and just under 1,600,000 colours are arrived at from multiple source colours.

Gamma 0.6 Code use tally:
00: 7647887
01: 4251528
02: 3700404
03: 0
04: 1073574
05: 0
06: 0
07: 0
08: 103823
09: 0

Gamma 0.6 is considerably more destructive, only 1/4 of the codes maintain a 1:1 mapping.

Now for AdobeRGB sRGB:

sRGB -> AdobeRGB1988 Code use tally:
00: 8102616
01: 4172676
02: 3175714
03: 438068
04: 538838
05: 66267
06: 124002
07: 23117
08: 48831
09: 87087

AdobeRGB1988 -> sRGB Code use tally:
00: 8012181
01: 8325155
02: 156167
03: 54498
04: 10468
05: 58725
06: 15054
07: 2108
08: 2129
09: 140731

This isn't as bad as I'd feared, but still considerably worse than either of the gamma tests.

In both cases nearly half the codes in 8-bit RGB space are lost!

This in effect reduced 24-bit RGB to 23-bit RGB. As I said, this isn't as bad as I'd feared - I was expecting to see a loss of nearly 1-bit per channel; in fact we lose only approximately 1-bit over the whole image.

If anyone's curious enough to want the source of my test program, just ask :)

All the best,
--
Alastair M. Robinson

Hi Alastair,

Alastair M. Robinson wrote:

Given the limitations we're trying to work within, I think the best compromise is likely to be something like this:

- Change the GIMP's working profile to match this image. This will leave the image data untouched. (This should disable the display filter for existing images, since they are presumably using a different profile.)

So say I open an image with a color profile, and then load a second image with a different profile. If I now decide to do the above, what do we do to the first image?

1) We stop using the profile for the first image (and if the image window is open, this will obviously change the visual representation of the image), but keep it attached to the image so that we can re-save it with the image at save time

2) We stop using the profile and propose the dialog with the 4 options the next time the image is activated (basically allowing us to change the working colorspace on demand, but this could get annoying, I guess)

3) Something else I hadn't thought of?

- the user just needs to be made aware that colour-space transformations are a destructive change, and have an opportunity to avoid them.

That sounds sane. I'm not quite sure how it would be implemented, but it probably involves having a color profile parasite attached to an image, with some kind of configuration parameter for the working colorspace and the monitor profile.

Cheers, Dave.

Hi,

Sven Neumann wrote:

David Neary writes:

1) We stop using the profile for the first image (and if the image window is open, this will obviously change the visual representation of the image), but keep it attached to the image so that we can re-save it with the image at save time

That doesn't sound feasible to implement. How would the other image get notified about this change? There isn't any notification about parasite changes.

Yeah - fair point. The changing colorspace has to get taken into account next time we activate the image, then - and we're back to option 2.

Cheers,
Dave.

Hi Dave,

David Neary wrote:

So say I open an image with a color profile, and then load a second image with a different profile. If I now decide to do the above, what do we do to the first image?

1) We stop using the profile for the first image (and if the image window is open, this will obviously change the visual representation of the image), but keep it attached to the image so that we can re-save it with the image at save time

I think this is the best bet - disable the colour-management filter for any images that don't use the current working profile.

2) We stop using the profile and propose the dialog with the 4 options the next time the image is activated (basically allowing us to change the working colorspace on demand, but this could get annoying, I guess)

The easiest option is to provide a simple plugin that adds a couple of menu entries - for example:
Image -> Colour Management -> Convert to working profile and
Image -> Colour Management -> Use as working profile

That sounds sane. I'm not quite sure how it would be implemented, but it probably involves having a color profile parasite attached to an image, with some kind of configuration parameter for the working colorspace and the monitor profile.

I'm not 100% sure, but I think the TIFF plugin already attaches embedded profiles as a parasite, so they're preserved when the image is saved again. If so, we have a lead to follow!

All the best, --
Alastair M. Robinson

It really isn't all that complicated. Here is all you need to do (this is basically what Sven outlined with a couple of extra details.)

1) Gimp uses the same color space internally for all images. This could be either sRGB or a user-selected one (in which case it is specified by a preference).

2) Gimp permits the use of a monitor profile to color-correct the display. A conversion is done between the working colorspace and the monitor colorspace -- the user is asked to choose the intent of the conversion as a preference (the normal choice would be "perceptual", but people setting things up for printing would sometimes make other choices).

3) When you open an image, if it does not have any color profile info, it is assumed to be in Gimp's working colorspace. If it does, then you are asked to choose between two options:

a) convert it to Gimp's working colorspace. If you choose this, then you are asked to choose the conversion intent.

b) use the RGB values from the image, without any correction.

Whatever is done, a parasite is attached to the image describing it.

4) When you save an image, you have the option of converting it to a different colorspace and/or attaching a color profile if the file format supports it.

It is a bad idea to change the working colorspace based on the image. Users need to be able to form an understanding of the relationship between what they see on the screen and the pixel values in the image. It will drive people nuts if 255,255,255 looks gray at one time and white at another. That's what will happen if the working colorspace is flopping around all the time.

Best, -- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

I haven't read the whole thread, but the last mail in the thread by William Skaggs seems very similar to the ideas discussed at gimpcon, what follows is my own understanding of what we discussed there:

assuming working space of gimp == sRGB

new image parasite_set ("export_profile", "sRGB")

loading of file profile==sRGB best scenario, just load the file
parasite_set ("export_profile","sRGB")

loading of file !profile "no color profile associated with image" "convert from [sRGB (dropdown)]"
"save as [sRGB (dropdown)]"
parasite_set ("export_profile", users_choice)

loading of file profile!=sRGB "image has a color profile attached" "convert from [YUV (dropdown)]"
"save as [sRGB (dropdown)]"
parasite_set ("export_profile", users_choice)

displaying the image while working on it this is actually the hardest thing to get right,. since it requires user interaction
and cooperation,. even with a correct icc profile for the display the user can introduce errors to the display by fiddling with the brightness/contrast knobs.

saving when export_profile == sRGB attach profile if possible

saving when export_profile != sRGB this is of course dependent upon the file supporting the intended format, if it does
pixel data should be converted upon saving, and the correct profile attached.

/pippin

On 12 Jul 2004 21:47:21 +0200, Sven Neumann wrote:

loading of file !profile
"no color profile associated with image" "convert from [sRGB (dropdown)]"
"save as [sRGB (dropdown)]"
parasite_set ("export_profile", users_choice)

This means that we would need to open a dialog for almost every image file the user opens. Is that a good idea? Shouldn't we just assume sRGB in that case?

We should provide a checkbox in the dialog, asking that the dialog newer be shown again, (it whould hide that part of the dialog, and a preference would be used to toggle it back on).

/pippin

David,

So say I open an image with a color profile, and then load a second image with a different profile. If I now decide to do the above, what do we do to the first image?

how about attaching a profile to each image? Correction is then done using the individual image's profile and the application-wide monitor profile. This gives you a lot of flexibility in the use of different profiles and saves you from having to switch the workspace profile back and forth.

From my own research on the matter, the way it is done in most apps and

CMS workflows seems to use three profile settings: 1. a monitor profile
2. a default image profile
3. a working space profile

The meaning of the monitor profile is obvious. The default image profile is assigned to images that don't have an embedded profile. The working space profile is a kind of preferred colour space, such as the in-house space of a studio.

The workflow is then as follows: When an image is opened, it is assigned its embedded profile, or, if there is none, the default image profile. The assigned profile is then compared to the workspace profile. If they are identical, nothing happens, since the image already is in the user's working space. Otherwise, the user is notified of the fact that the image profile differs from the working space profile and is asked whether she would like to convert the image to the working space or to maintain its original profile. For ease of use there should be a preference setting that defines a default for this dialog and allows it not to be displayed (e.g. "always convert images to working space").

Display correction is then done based on the profile that was assigned to the image (which could be the embedded profile, the default image profile, or, if the image was converted, the workspace profile).

Here the working space is more of a preference setting, a colourspace that the user prefers to work in. It is not necessarily used in the display correction (only if it is made the image's profile).

In addition there are usually functions to assign a different profile to an image (only changes the attached profile, but doesn't manipulate the image data) or to convert an image to a different profile (changes the profile and the image data).

Hope this is of any use Stef

an

Hello.

Several mails in this thread says that the images will be converted between colorspaces, such as monitor colorspace.

Does GIMP keep two versions of the same image: one for image processing and saving, and one for displaying?

I remember how XV converted images to fit better to the display. If one had 8-bit display (and most had), the image was quantized to 8-bit. Then when the image was enhanged and saved as jpeg, one could see that the jpeg image contained the quantized and dithered 8-bit image! People lost their 24-bit images because they used XV to trim and flip the images!!

Please don't make the same mistage with the colorspace issue. Worse is if you force people to convert images in lossy way as you have planned.

Juhana
--
http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software

On Fri, 16 Jul 2004 16:40:23 +0300, Juhana Sadeharju wrote:

Hello.

Several mails in this thread says that the images will be converted between colorspaces, such as monitor colorspace.

Does GIMP keep two versions of the same image: one for image processing and saving, and one for displaying?

The monitor colorspace would never be an intermediate colorspace, just the final transformation the final composite would go through, the final composite (consisting of the "merge visible layers" is just an intermediate representation seperate from the actual data in the layers)

Please don't make the same mistage with the colorspace issue. Worse is if you force people to convert images in lossy way as you have planned.

The user would be in full control of what conversions happens, and could choose not to apply a transform, for most unspecified rgb data, sRGB would probably be a safe assumption, and thus would be no problem in actual use, the added benefit would be that the images would be "blessed" with correct information, when users have a monitor profile as well, they can be assured that the reproduction of the images is correct across other color managed programs and devices.

/pippin