On 01/23/2010 08:04 AM, Martin Nordholts wrote:

Hi

Right now we don't have a clearly defined color management strategy for GIMP.

I would like us to settle a minimal color management strategy for GIMP so that we can fix some inconsistencies in our color management, in particular for PNG [1], for 2.8. In short the problem with PNG is that the current code always writes an sRGB chunk to a PNG file if no color profile is attached to the image and no gamma is specified.

I suggest that we formally settle with this minimal color management strategy:

"""
An image either has or has not a color profile attached. A color profile is attached as a GimpParasite named "icc-profile".

For images that have a color profile attached, this color profile is used when displaying the image and is embedded when the image is saved or exported.

For images that does not have a color profile attached, the global color profile defined under Color Management in Preferences is used to display the image, but no profile is embedded into saved or exported files.
"""

So, does the above sound like a sound foundation for color management in GIMP? I don't expect us to have time to apply this strategy consistently all over GIMP for 2.8 but at least we have settled on something that we can put in devel-docs and continue to build on later, and it allows us to fix the PNG problem for 2.8.

Sounds eminently reasonable; I had run into this issue also.

I had naively signed up for the "work on color management" job. That said, do you happen to know where the sRGB thingie is added by default? (if not, I can probably find it, but if you know offhand, I'm not beyond laziness ;o)

I had also been taking a peek at [2] and [3], which also seem to fall under the umbrella of this desired behavior. Finally, [4] is something that bites me a lot, but needs some UI/UX work. guiguru?

[2] https://bugzilla.gnome.org/show_bug.cgi?id=556608 "Monitor color profile is not applied to filter preview" [3] https://bugzilla.gnome.org/show_bug.cgi?id=478528 "Layer previews are not color managed"
[4] https://bugzilla.gnome.org/show_bug.cgi?id=320447 "fast switching between 'color managed display' and 'softproof'"

--xsdg

On 01/24/2010 07:26 AM, Omari Stephens wrote:

On 01/23/2010 08:04 AM, Martin Nordholts wrote:

Hi

Right now we don't have a clearly defined color management strategy for GIMP.

I would like us to settle a minimal color management strategy for GIMP so that we can fix some inconsistencies in our color management, in particular for PNG [1], for 2.8. In short the problem with PNG is that the current code always writes an sRGB chunk to a PNG file if no color profile is attached to the image and no gamma is specified.

I suggest that we formally settle with this minimal color management strategy:

"""
An image either has or has not a color profile attached. A color profile is attached as a GimpParasite named "icc-profile".

For images that have a color profile attached, this color profile is used when displaying the image and is embedded when the image is saved or exported.

For images that does not have a color profile attached, the global color profile defined under Color Management in Preferences is used to display the image, but no profile is embedded into saved or exported files.
"""

So, does the above sound like a sound foundation for color management in GIMP? I don't expect us to have time to apply this strategy consistently all over GIMP for 2.8 but at least we have settled on something that we can put in devel-docs and continue to build on later, and it allows us to fix the PNG problem for 2.8.

Sounds eminently reasonable; I had run into this issue also.

FWIW, http://hsivonen.iki.fi/png-gamma/ seems like a pretty good article on this topic; curious folks should give it a read. It also suggests that the current GIMP behavior is Bad.

I had naively signed up for the "work on color management" job. That said, do you happen to know where the sRGB thingie is added by default? (if not, I can probably find it, but if you know offhand, I'm not beyond laziness ;o)

It was actually trivial to find. Right now, I'm just considering the consequences before I nuke that 4 lines of code.

I had also been taking a peek at [2] and [3], which also seem to fall under the umbrella of this desired behavior. Finally, [4] is something that bites me a lot, but needs some UI/UX work. guiguru?

These will probably be more than 4 lines of code ;o)

[2] https://bugzilla.gnome.org/show_bug.cgi?id=556608 "Monitor color profile is not applied to filter preview" [3] https://bugzilla.gnome.org/show_bug.cgi?id=478528 "Layer previews are not color managed"
[4] https://bugzilla.gnome.org/show_bug.cgi?id=320447 "fast switching between 'color managed display' and 'softproof'"

--xsdg

On 01/24/2010 08:31 AM, Martin Nordholts wrote:

Omari Stephens wrote:

I had naively signed up for the "work on color management" job. That said, do you happen to know where the sRGB thingie is added by default? (if not, I can probably find it, but if you know offhand, I'm not beyond laziness ;o)

It was actually trivial to find. Right now, I'm just considering the consequences before I nuke that 4 lines of code.

You are talking about
http://git.gnome.org/browse/gimp/tree/plug-ins/common/file-png.c#n1456 right?

Nuking those four lines is not enough, a way to embedd an sRGB profile must also be added. Unfortunately, assagning an sRGB profile to an image in current GIMP does not "stick" since sRGB is the default color space. We need to change this. Changing this is likely to cause problems in other parts of the color managed code which needs to be taken care of.

Any licensing folks about? Debian's "icc-profiles" package ships an sRGB profile that has license [1]. The ICC itself also provides sRGB v2 and v4 ICC profiles for use with licenses [2] and [3], respectively. Can we ship one of these with GIMP? At the very least, the PNG spec calls for IEC 61966-2-1, which is one of the sRGB v2 profiles, though both the BPC-enabled and BPC-disabled versions seem to count as 61966-2-1.

Also, from a practical standpoint, are there important situations where someone would want to tag a PNG as sRGB, but where simply applying the actual sRGB color profile wouldn't be a reasonable substitute to the sRGB PNG chunk?

The PNG standard has this to say (from http://www.w3.org/TR/PNG/#11sRGB ): """
It is recommended that a PNG encoder that writes the sRGB chunk also write a gAMA chunk (and optionally a cHRM chunk) for compatibility with decoders that do not use the sRGB chunk. Only the following values shall be used.
[…]
When the sRGB chunk is present, it is recommended that decoders that recognize it and are capable of colour management [ICC] ignore the gAMA and cHRM chunks and use the sRGB chunk instead. Decoders that recognize the sRGB chunk but are not capable of colour management [ICC] are recommended to ignore the gAMA and cHRM chunks, and use the values given above as if they had appeared in gAMA and cHRM chunks.

It is recommended that the sRGB and iCCP chunks do not both appear in a PNG datastream.
"""

Here are the licenses:
[1] HP sRGB license, from Debian's icc-profiles package: sRGB Profile Licensing Agreement:
To anyone who acknowledges that the file "sRGB Color Space Profile.icm" is provided "AS IS" WITH NO EXPRESS OR IMPLIED WARRANTY: permission to use, copy and distribute this file for any purpose is hereby granted without fee, provided that the file is not changed including the HP copyright notice tag, and that the name of Hewlett-Packard Company not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. Hewlett-Packard Company makes no representations about the suitability of this software for any purpose.

[2] ICC sRGBv2 license, from http://www.color.org/srgbprofiles.xalter To anyone who acknowledges that the files "sRGB_IEC61966-2-1_no_black_scaling.icc" and "sRGB_IEC61966-2-1_black scaled.icc" are provided "AS IS" WITH NO EXPRESS OR IMPLIED WARRANTY, permission to use, copy and distribute these file for any purpose is hereby granted without fee, provided that the files are not changed including the ICC copyright notice tag, and that the name of ICC shall not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. ICC makes no representations about the suitability of this software for any purpose.

[3] ICC sRGBv4 license, from http://www.color.org/srgbprofiles.xalter To anyone who acknowledges that the file "sRGB_v4_ICC_preference.icc" is provided "AS IS" WITH NO EXPRESS OR IMPLIED WARRANTY, permission to use, copy and distribute this file for any purpose is hereby granted without fee, provided that the file is not changed including the ICC copyright notice tag, and that the name of ICC shall not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. ICC makes no representations about the suitability of this software for any purpose.

--xsdg

On 01/24/2010 09:03 AM, Omari Stephens wrote:

On 01/24/2010 08:31 AM, Martin Nordholts wrote:

Omari Stephens wrote:

I had naively signed up for the "work on color management" job. That said, do you happen to know where the sRGB thingie is added by default? (if not, I can probably find it, but if you know offhand, I'm not beyond laziness ;o)

It was actually trivial to find. Right now, I'm just considering the consequences before I nuke that 4 lines of code.

You are talking about
http://git.gnome.org/browse/gimp/tree/plug-ins/common/file-png.c#n1456 right?

Nuking those four lines is not enough, a way to embedd an sRGB profile must also be added. Unfortunately, assagning an sRGB profile to an image in current GIMP does not "stick" since sRGB is the default color space. We need to change this. Changing this is likely to cause problems in other parts of the color managed code which needs to be taken care of.

Any licensing folks about? Debian's "icc-profiles" package ships an sRGB profile that has license [1]. The ICC itself also provides sRGB v2 and v4 ICC profiles for use with licenses [2] and [3], respectively. Can we ship one of these with GIMP? At the very least, the PNG spec calls for IEC 61966-2-1, which is one of the sRGB v2 profiles, though both the BPC-enabled and BPC-disabled versions seem to count as 61966-2-1.

Also, from a practical standpoint, are there important situations where someone would want to tag a PNG as sRGB, but where simply applying the actual sRGB color profile wouldn't be a reasonable substitute to the sRGB PNG chunk?

::snip? SNIP!::

After a bit more thinking, it occurs to me that it makes no sense for us to not have a a copy of the working-space color profile, if we want to consider the image tagged with that profile. Consider the following:

1) Suppose we consider the image not to be associated with _any_ profile. We use our default working-space profile because that's why it's there. When we export an image, it should not be tagged as associated with any color profile.

2) Suppose we consider the image to be associated with our working-space profile. When we export an image, it should be tagged with our working-space profile. If what we export is a JPG or a TIFF, they have no equivalent to PNG's "sRGB chunk" — we need to have a copy of the actual sRGB profile on hand so that we can apply it to the exported file.

For exporting to PNG here, if our working-space is sRGB v2, we have the option of applying the color profile or adding the PNG sRGB chunk. According to the standard, these should be equivalent. Whether this is the case in practice is something I'm unsure about.

3) If the user tags the image with some color profile from her filesystem, then we cache that profile in the icc-profile parasite. We use the parasite to tag the image when we export it.

4) If the user opens an image that is already tagged with some profile, the profile is already in the icc-profile parasite. We use the parasite to tag the image when we next export it.

--xsdg

On Sunday 24 January 2010 01:35:20 am Omari Stephens wrote:

On 01/24/2010 09:03 AM, Omari Stephens wrote:

On 01/24/2010 08:31 AM, Martin Nordholts wrote:

Omari Stephens wrote:

I had naively signed up for the "work on color management" job. That said, do you happen to know where the sRGB thingie is added by default? (if not, I can probably find it, but if you know offhand, I'm not beyond laziness ;o)

It was actually trivial to find. Right now, I'm just considering the consequences before I nuke that 4 lines of code.

You are talking about
http://git.gnome.org/browse/gimp/tree/plug-ins/common/file-png.c#n1456 right?

Nuking those four lines is not enough, a way to embedd an sRGB profile must also be added. Unfortunately, assagning an sRGB profile to an image in current GIMP does not "stick" since sRGB is the default color space. We need to change this. Changing this is likely to cause problems in other parts of the color managed code which needs to be taken care of.

Any licensing folks about? Debian's "icc-profiles" package ships an sRGB profile that has license [1]. The ICC itself also provides sRGB v2 and v4 ICC profiles for use with licenses [2] and [3], respectively. Can we ship one of these with GIMP? At the very least, the PNG spec calls for IEC 61966-2-1, which is one of the sRGB v2 profiles, though both the BPC-enabled and BPC-disabled versions seem to count as 61966-2-1.

Also, from a practical standpoint, are there important situations where someone would want to tag a PNG as sRGB, but where simply applying the actual sRGB color profile wouldn't be a reasonable substitute to the sRGB PNG chunk?

::snip? SNIP!::

After a bit more thinking, it occurs to me that it makes no sense for us to not have a a copy of the working-space color profile, if we want to consider the image tagged with that profile. Consider the following:

1) Suppose we consider the image not to be associated with _any_ profile. We use our default working-space profile because that's why it's there. When we export an image, it should not be tagged as associated with any color profile.

This does not seem correct to me. How do you know that the working space profile is correct for this image? If you are assuming that all users will have sRGB as their working space this assumption will fail for at least some subset of users. For example it is common for photographers to use wider gamut color spaces such as ProPhotoRGB or BetaRGB as their working color space. Using one of these color spaces for viewing untagged images is definitely not correct.

The general guidance from CM experts is that if you are going to make assumptions about what color space should be used with an untagged RGB image then it should be sRGB. But for the general case you should also allow the user to specify how they want this to be handled. Most users will just let you do the default handling of untagged images (IE. use sRGB) but other users may want to be asked what should be done for each image or to setup some other default behavior like always using some other (IE. not sRGB) profile.

2) Suppose we consider the image to be associated with our working-space profile. When we export an image, it should be tagged with our working-space profile. If what we export is a JPG or a TIFF, they have no equivalent to PNG's "sRGB chunk" — we need to have a copy of the actual sRGB profile on hand so that we can apply it to the exported file.

Again it appears that you are assuming that sRGB will always be the users working space profile. This is not a valid assumption.

For exporting to PNG here, if our working-space is sRGB v2, we have the option of applying the color profile or adding the PNG sRGB chunk. According to the standard, these should be equivalent. Whether this is the case in practice is something I'm unsure about.

PNG appears to be a special case where the specification states that any untagged image is sRGB by default. So it appears the PNG needs to be handled in a different way than JPG, TIF .. files. Since the specification is clear about this there is not need to assume how this should be handled. If the PNG image is not tagged it is sRGB.

3) If the user tags the image with some color profile from her filesystem, then we cache that profile in the icc-profile parasite. We use the parasite to tag the image when we export it.

4) If the user opens an image that is already tagged with some profile, the profile is already in the icc-profile parasite. We use the parasite to tag the image when we next export it.

--xsdg

On 01/24/2010 08:29 PM, Hal V. Engel wrote:

On Sunday 24 January 2010 01:35:20 am Omari Stephens wrote:

::snip? SNIP!::

After a bit more thinking, it occurs to me that it makes no sense for us to not have a a copy of the working-space color profile, if we want to consider the image tagged with that profile. Consider the following:

1) Suppose we consider the image not to be associated with _any_ profile. We use our default working-space profile because that's why it's there. When we export an image, it should not be tagged as associated with any color profile.

This does not seem correct to me. How do you know that the working space profile is correct for this image? If you are assuming that all users will have sRGB as their working space this assumption will fail for at least some subset of users. For example it is common for photographers to use wider gamut color spaces such as ProPhotoRGB or BetaRGB as their working color space. Using one of these color spaces for viewing untagged images is definitely not correct.

The general guidance from CM experts is that if you are going to make assumptions about what color space should be used with an untagged RGB image then it should be sRGB. But for the general case you should also allow the user to specify how they want this to be handled. Most users will just let you do the default handling of untagged images (IE. use sRGB) but other users may want to be asked what should be done for each image or to setup some other default behavior like always using some other (IE. not sRGB) profile.

Good catch. Your suggestion is indeed what I had intended. It means that every image is tagged with a profile. It seems the easy way to implement this would be to just assume that "empty icc-profile parasite" == "image implicitly tagged with sRGB".

An image with only an implicit sRGB tag is exported without any color profile or tag attached. If it's PNG, it is exported with neither an sRGB chunk nor an iCCP chunk.

As always, the user may assert (aka "apply") some color profile for the image, or may convert the image to some color profile, in which case the starting profile will be whatever lives in icc-profile, be it the implicit sRGB profile or some explicit thing.

Furthermore, the user may chose to have GIMP prompt them as to what to do, with options being (1) assert some color profile (2) leave untagged, in which case we implicitly use sRGB, (3) convert from an implicit sRGB to some explicit profile, like AdobeRGB or ProPhotoRGB.

2) Suppose we consider the image to be associated with our working-space profile. When we export an image, it should be tagged with our working-space profile. If what we export is a JPG or a TIFF, they have no equivalent to PNG's "sRGB chunk" — we need to have a copy of the actual sRGB profile on hand so that we can apply it to the exported file.

Again it appears that you are assuming that sRGB will always be the users working space profile. This is not a valid assumption.

This was more an argument for "we need to have sRGB profiles on-hand" than anything. If our working space is anything other than sRGB v2, we're guaranteed to have a file somewhere. We've only been lazy with sRGB v2 because lcms has the profile built in somewhere.

For exporting to PNG here, if our working-space is sRGB v2, we have the option of applying the color profile or adding the PNG sRGB chunk. According to the standard, these should be equivalent. Whether this is the case in practice is something I'm unsure about.

PNG appears to be a special case where the specification states that any untagged image is sRGB by default. So it appears the PNG needs to be handled in a different way than JPG, TIF .. files. Since the specification is clear about this there is not need to assume how this should be handled. If the PNG image is not tagged it is sRGB.

From the reading I've done, there is a practical difference between PNG-with-sRGB-chunk and untagged-PNG: """
According to the CSS2 specification, the CSS color values refer to the sRGB color space. In practice, however, all browsers except Mac IE 5 with ColorSync enabled (disabled by default) seem to just treat the CSS color values as values in whatever color space the system color space happens to be. Still, it would be reasonable to expect the colors of an sRGB-labeled PNG image to be treated consistently with CSS colors. """ (from http://hsivonen.iki.fi/png-gamma/)

We need to enable the practical use of GIMP, and as such, we need to differentiate between untagged and tagged-with-sRGB-chunk. This is why GIMP's current behavior of always-tagging, while correct in theory, is incorrect in practice.

My question was essentially whether we _also_ need to differentiate between PNG-tagged-with-sRGB-chunk and PNG-with-sRGBv2-color-profile. In theory, the two options are equivalent. In practice, though, this may not actually be the case.

--xsdg