GIMP color-management spec and further discussion

Hi, all

I wrote up a quick spec for how GIMP should deal with color profiles
associated with files and images. The spec is attached, and is also
attached to bug 608961. If you have any general thoughts/comments, I
would love to hear them, but please note the scope of the document.

My main questions so far:
1) What should we do when exporting to formats that don't support color
profile tagging? One option is obviously to convert to sRGB. Are there
people who are familiar with formats like this? What is the standard
thing to do? What do people usually use these formats for?
2) What should we do when an opened image contains an invalid profile?

Obviously, options for both of these things are "prompt the user." It
seems like there should be better alternatives, but I'm not sure what
they might be. guiguru? others?

--xsdg

[1] https://bugzilla.gnome.org/show_bug.cgi?id=608961


Author: Omari Stephens <xsdg@xsdg.org>
Version: 1
Date: 3 February 2010

This spec is intended to define GIMP's color profile management behavior as pertains to the opening and exporting of image files. How this is achieved or implemented, and especially the UI and UX considerations involved, is not currently in the scope of this spec.

Further discussion will happen on the mailing list: gimp-developer@lists.xcf.berkeley.edu


1) When an image is opened with no associated color profile, we assume that it is encoded in sRGB space. In practice, I'll say that it has an implicit sRGB profile. The user will have the following options:
a) Assert (aka "apply") some explicit color profile
b) Leave the image without an explicit color profile
c) Convert the image from the implicit profile to some explicit profile (AdobeRGB, ProPhotoRGB, sRGB, etc.)

2) When an image is opened _with_ an associated color profile, the user will have the following options:
a) Leave the image with the explicit color profile
b) Convert the image to some other explicit profile

3) When a PNG is opened that is tagged with the sRGB chunk
a) This is as-yet undecided. See the later discussion about sRGB chunk vs. sRGB profile.

4) When an image with an explicit profile is exported
a) It will be tagged with that profile in whatever way is appropriate for the file format.
b) If this is an sRGB PNG, we need to decide between an sRGB chunk and sRGB profile. See later discussion.
c) If the file format has no way to embed color profile information, (FIXME!)

5) When an image with an implicit profile is exported
a) The image is saved with no color profile information. For PNG, this means no sRGB chunk and also no iCCP chunk.


PNG: sRGB chunk vs. sRGB profile
In theory, an untagged PNG and a PNG with the sRGB chunk should be treated identically. In practice, and particularly among web browsers, this is not the case. See [1]. Given this context, we face the question of what to do when we have the choice to use either an sRGB chunk or an sRGB profile in the iCCP chunk. In theory, these two choices should have the same outcome. However, it is not clear whether theory matches reality in this case either; I have very little data to judge either way.

[1] "Making the Color Spaces Match" section of http://hsivonen.iki.fi/png-gamma/

Hi all,

Omari Stephens wrote:
> Hi, all
>
> I wrote up a quick spec for how GIMP should deal with color profiles
> associated with files and images. The spec is attached, and is also
> attached to bug 608961. If you have any general thoughts/comments, I
> would love to hear them, but please note the scope of the document.

Please don't forget to incorporate EXIF data into the show:
https://bugzilla.gnome.org/show_bug.cgi?id=492048

For quite some time, users will have to deal with incompatible and
especially simply incomplete implementations of color management.
Possibly that pain [1] can be eased if users are supported to specify
workarounds, like: 'camera xy' + 'filename starts with _' => AdobeRGB.
Sort of heuristic device drivers.


regards,
yahvuu


PS: I think the scope of your questions is actually more of UX. As you said,
the pure technical solution is to popup when inference fails.


[1] an example of how it took 5 days to track down the
import problems for some Pentax cameras:
https://lists.xcf.berkeley.edu/lists/gimp-user/2010-January/016415.html

NOTE: if someone wants to think about the UI/UX involved in the color
management spec, I would really appreciate it. Right now, I have no
time for thinking outside the box — it's all I can do to find 30 minutes
here and there to do some GIMP hacking as it is. So if you don't want
to see more options at the bottom of the "Color Management"
configuration pane, your help would be appreciated.

(more comments inline)

On 02/07/2010 12:36 PM, yahvuu wrote:
> Hi all,
>
> Omari Stephens wrote:
>> Hi, all
>>
>> I wrote up a quick spec for how GIMP should deal with color profiles
>> associated with files and images. The spec is attached, and is also
>> attached to bug 608961. If you have any general thoughts/comments, I
>> would love to hear them, but please note the scope of the document.
>
> Please don't forget to incorporate EXIF data into the show:
> https://bugzilla.gnome.org/show_bug.cgi?id=492048
>
> For quite some time, users will have to deal with incompatible and
> especially simply incomplete implementations of color management.
> Possibly that pain [1] can be eased if users are supported to specify
> workarounds, like: 'camera xy' + 'filename starts with _' => AdobeRGB.
> Sort of heuristic device drivers.

I specifically chose to ignore that problem for now, as I think it's
more difficult to deal with than the generic "has embedded ICC profile
or not?" problem. I should probably have mentioned that in the spec
("what is out of the scope of this spec" or somesuch).

For one, as Sven pointed out, we can't ship the AdobeRGB color profile.
This means that even if we know it _should_ be AdobeRGB, the user will
need to take some action either to make that profile available or to tag
it manually.

Secondly, we currently use libexif for parsing EXIF in JPEG. We need to
switch to exiv2, but since the latter is C++, we'll need a C/C++
compatibility layer as well. A further problem is that we don't
currently support EXIF in PNG, which we should (and would be able to
with exiv2).

In short, I would consider "make EXIF work right" a mostly-orthogonal
problem to "make color management work right". They're both important,
but the color management problem is the one that I'm focusing on right now.

> PS: I think the scope of your questions is actually more of UX. As you said,
> the pure technical solution is to popup when inference fails.
True. Unfortunately, guiguru doesn't seem to have been around in any
real capacity of late, so I think I'm going to have to start off by
adding functionality in ways that work but are non-ideal, and then we
can refine it later on.

> [1] an example of how it took 5 days to track down the
> import problems for some Pentax cameras:
> https://lists.xcf.berkeley.edu/lists/gimp-user/2010-January/016415.html
Hmm. matching the filename against /_...[0-9]{4}\.jpg/i is one
potential heuristic to suggest (this image should be AdobeRGB), but I'm
not sure it would be worth the effort — if someone has a bunch of
untagged (as opposed to EXIF-tagged) AdobeRGB images, then they've got a
problem in their workflow.

--xsdg

Omari Stephens wrote:
> For one, as Sven pointed out, we can't ship the AdobeRGB color profile.
> This means that even if we know it _should_ be AdobeRGB, the user will
> need to take some action either to make that profile available or to tag
> it manually.

i think that is a special case of 'invalid profile detected', with some
extra help to show how to install the profile.


> Secondly, we currently use libexif for parsing EXIF in JPEG. We need to
> switch to exiv2, but since the latter is C++, we'll need a C/C++
> compatibility layer as well. A further problem is that we don't
> currently support EXIF in PNG, which we should (and would be able to
> with exiv2).

thank you, i see. The scope is the 2.8 release. Proper EXIF handling may even
be beyond 2.10 as bug #56443 suggests. (The introduction "probably i'm just
missing the point, but ..." was in my head but didn't make it into the posting)


regards,
yahvuu

Omari Stephens wrote:
> For one, as Sven pointed out, we can't ship the AdobeRGB color profile.
> This means that even if we know it _should_ be AdobeRGB, the user will
> need to take some action either to make that profile available or to tag
> it manually.

Why can't you apply a profile compatible with AdobeRGB ? I've
certainly made one available under the public domain ("ClayRGB1998.icm").

Graeme Gill.

On 02/08/2010 07:41 PM, Graeme Gill wrote:
>
> Omari Stephens wrote:
>> For one, as Sven pointed out, we can't ship the AdobeRGB color profile.
>> This means that even if we know it _should_ be AdobeRGB, the user will
>> need to take some action either to make that profile available or to tag
>> it manually.
>
> Why can't you apply a profile compatible with AdobeRGB ? I've
> certainly made one available under the public domain ("ClayRGB1998.icm").
What does "compatible with AdobeRGB" actually mean? How does
"compatible with AdobeRGB" differ from "AdobeRGB"? (Note: I assume that
you know what you're talking about here much more than I do.)

Beyond that, if someone has the "real" AdobeRGB profile, it would be
nice if they could swap it in somehow. Of course, the importance of
this depends on your answers to my questions above.

Either way, though, I think the EXIF problem is definitely important but
is also mostly decoupled from what I'm trying to fix right now.

--xsdg

Omari Stephens wrote:").
> What does "compatible with AdobeRGB" actually mean?

It means that it was written to conform to Adobe's published
specification of AdobeRGB.

> How does
> "compatible with AdobeRGB" differ from "AdobeRGB"? (Note: I assume that
> you know what you're talking about here much more than I do.)

It differs from the AdobeRGB profile in that it was created completely
independently from it, and was not authored by Adobe, does not
come from Adobe, nor is it endorsed or certified or approved
by Adobe.

> Beyond that, if someone has the "real" AdobeRGB profile, it would be
> nice if they could swap it in somehow. Of course, the importance of
> this depends on your answers to my questions above.

Any "real" or "actual" AdobeRGB profile is (of course) Copyright
by Adobe. How is that useful to you ?

(Why don't you simply look at them side by side first ?)

Graeme Gill.

Omari Stephens wrote:
> Obviously, options for both of these things are "prompt the user." It seems like there
> should be better alternatives, but I'm not sure what they might be. guiguru? others?

You're better having a set of defaults that the user can configure,
so they aren't constantly hassled by prompts. The configuration can
have options such as "prompt me" for certain combinations.

> Author: Omari Stephens <xsdg@xsdg.org> Version: 1 Date: 3 February 2010

> 1) When an image is opened with no associated color profile, we assume that it is
> encoded in sRGB space.

> c) Convert the image from
> the implicit profile to some explicit profile (AdobeRGB, ProPhotoRGB, sRGB, etc.)

Not a good idea. There are losses in every color conversion. Ideally you want to
keep an image in its original format, unless the user explicitly decides to
convert to another colorspace. Input is not the place to do this.

So the application (GIMP) should have a transformation step available to:

1) Convert from one colorspace to another. If an image has no tag,
then both profiles would need to be specified.

2) Assign a profile to the image. This would set or override a tag.

One idea to consider is the possibility of a "weak color tag". This
is for a image that is to be considered un-tagged, but has a profile
to specify the source colorspace for the purposes of display, and conversion.

There should be a "color tag" status somewhere for an image.

> 2) When an image is opened _with_ an associated color profile, the user will have the
> following options:

> b) Convert the image to some other explicit profile

Same comment as above.

> 4) When an image with an explicit profile is exported
> a) It will be tagged with that
> profile in whatever way is appropriate for the file format.
> b) If this is an sRGB PNG,
> we need to decide between an sRGB chunk and sRGB profile. See later discussion.
> c) If the file format has no way to embed color profile information, (FIXME!)

For c), have the option to covert to a particular colorspace (ie. sRGB).

d) Have an option to write the file without an embedded profile. This is an important
option in regard to dealing with other applications, for instance sending calibration
or profiling files to a particular device.

> 5) When an image with an implicit profile is exported a) The image is saved with no
> color profile information. For PNG, this means no sRGB chunk and also no iCCP chunk.

You could really have the same options as 4, although you might default them
differently.

There are many possible ways of dealing with this issue. The important things as
I see them are 1) Allow defaulting to logical and useful workflows 2) Allow
flexibility to accommodate particular needs.

Graeme Gill.

On 02/08/2010 01:39 AM, Graeme Gill wrote:
> Omari Stephens wrote:
>> Obviously, options for both of these things are "prompt the user." It seems like there
>> should be better alternatives, but I'm not sure what they might be. guiguru? others?
>
> You're better having a set of defaults that the user can configure,
> so they aren't constantly hassled by prompts. The configuration can
> have options such as "prompt me" for certain combinations.

Yes. By "prompt the user" I meant something similar to the current
behavior when an image is tagged with a color profile other than the
working space profile; the options are:
1) Do nothing
2) Convert to working space profile
3) Prompt the user

I was hoping someone would come up with a better convention, but since
that doesn't seem to be happening, I will rev the spec and mention this
UX paradigm explicitly, with the hope that it will be improved upon in a
later revision.

>> Author: Omari Stephens<xsdg@xsdg.org> Version: 1 Date: 3 February 2010
>
>> 1) When an image is opened with no associated color profile, we assume that it is
>> encoded in sRGB space.
>
>> c) Convert the image from
>> the implicit profile to some explicit profile (AdobeRGB, ProPhotoRGB, sRGB, etc.)
>
> Not a good idea. There are losses in every color conversion. Ideally you want to
> keep an image in its original format, unless the user explicitly decides to
> convert to another colorspace. Input is not the place to do this.
>
> So the application (GIMP) should have a transformation step available to:
>
> 1) Convert from one colorspace to another. If an image has no tag,
> then both profiles would need to be specified.
>
> 2) Assign a profile to the image. This would set or override a tag.
>
> One idea to consider is the possibility of a "weak color tag". This
> is for a image that is to be considered un-tagged, but has a profile
> to specify the source colorspace for the purposes of display, and conversion.

Your "weak color tag" is exactly what I meant by an "implicit sRGB
profile". My judgment was that it wouldn't be useful to have a "weak"
tag that wasn't sRGB — anything else should be explicit and embedded.

> There should be a "color tag" status somewhere for an image.
Because the only implicit color tag is sRGB, the absence of an
icc-profile parasite (or an empty one) can be considered equivalent to
the implicit sRGB tag.

>> 4) When an image with an explicit profile is exported
>> a) It will be tagged with that
>> profile in whatever way is appropriate for the file format.
>> b) If this is an sRGB PNG,
>> we need to decide between an sRGB chunk and sRGB profile. See later discussion.
>> c) If the file format has no way to embed color profile information, (FIXME!)
>
> For c), have the option to covert to a particular colorspace (ie. sRGB).
Cool. Any thoughts from other people?

> d) Have an option to write the file without an embedded profile. This is an important
> option in regard to dealing with other applications, for instance sending calibration
> or profiling files to a particular device.
I was thinking a tiny bit about this, but hadn't come up with anything
conclusive. I'll probably implement something trivial where you can
select a menu item to dump the icc-profile.

>> 5) When an image with an implicit profile is exported a) The image is saved with no
>> color profile information. For PNG, this means no sRGB chunk and also no iCCP chunk.
>
> You could really have the same options as 4, although you might default them
> differently.
Hmm; good point. Will think about that.

> There are many possible ways of dealing with this issue. The important things as
> I see them are 1) Allow defaulting to logical and useful workflows 2) Allow
> flexibility to accommodate particular needs.
Yup. Thanks for thinking about this.

--xsdg

On 02/07/2010 04:55 AM, Omari Stephens wrote:
> Hi, all
>
> I wrote up a quick spec for how GIMP should deal with color profiles
> associated with files and images. The spec is attached, and is also
> attached to bug 608961. If you have any general thoughts/comments, I
> would love to hear them, but please note the scope of the document.

Hi Omari,

Comments on the spec:

"1) When an image is opened with no associated color profile, we assume
that it is encoded in sRGB space."

I don't think we should assume that, do you have an example use case
where that is a good idea? Speaking of use cases, we should document
somewhere what uses cases the solution must support. If we don't
document this then there will be use case regressions when the system is
adjusted later.

I think we should rather assume the image is in the working space color
space. My thinking is that it is the same working space color profile
that is used for the GIMP color picker and also for images without a
color profile attached. So when you pick RGB 128,128,128 in the GIMP
color picker and open an image with no color profile, RGB 128, 128, 128
in the image will be displayed the same as RGB 128,128,128 in the GIMP
color picker.


"2) When an image is opened _with_ an associated color profile, the user
will have the following options:"

I don't think I follow completely, why would we ask the user what to do
here? If the image has a color profile attached, we should definitly use
it. If the user wants to convert to some other color space for some
reason, he can do that when he pleases


"3) When a PNG is opened that is tagged with the sRGB chunk
a) This is as-yet undecided. See the later discussion about sRGB
chunk vs. sRGB profile."

If the image is specified as in sRGB, why should we not treat it as such?


"4) When an image with an explicit profile is exported
c) If the file format has no way to embed color profile information,
(FIXME!)"

In terms of a problem, this is pretty similar to "when an image has
several layers and we export to an image format that does not support
layers, what do we do?". If the image doesn't support any kind of layer,
we simply merge or flatten the image, no questions asked. If the image
supports both layers and non-layers (such as animated GIF), we let the
user choose. I think we should do the same in this case: if the target
image format does not support color management whatsoever, we should
just write the RGB values verbatim, i.e. do the best of the situation
without becoming annoying and asking questions. If the written RGB
values are important than the user needs to do a color space conversion
before exporting into that format.

/ Martin

Martin Nordholts wrote:
> On 02/07/2010 04:55 AM, Omari Stephens wrote:
> "1) When an image is opened with no associated color profile, we assume
> that it is encoded in sRGB space."
>
> I don't think we should assume that, do you have an example use case
> where that is a good idea?

I think the best guess is sRGB, assuming a file that was produced by a legacy device.
Which were (back then) to be viewed on monitors with a profile similar to sRGB.

Another source for images of these kind are web developers who want to
achieve consistent colors cross a web page -- the rationale beeing:
if the browser has no color profile information, the colors may be wrong,
but at least consistent.

Among garden-variety photo labs, it's pretty much standard to discard any
color profile information and just assume sRGB.


> I think we should rather assume the image is in the working space color
> space.

The user's choice of a working space does not reveal any information about
an unknown image. I don't think the chosen working space should be
used as input for import heuristics.

> My thinking is that it is the same working space color profile
> that is used for the GIMP color picker and also for images without a
> color profile attached. So when you pick RGB 128,128,128 in the GIMP
> color picker and open an image with no color profile, RGB 128, 128, 128
> in the image will be displayed the same as RGB 128,128,128 in the GIMP
> color picker.

OK, the color picker's colors must match, of course. Probably that means
that the color picker can't show any numbers as long it's not yet clear
which color space it will be assigned to.
Or, perhaps better: the color picker gets disabled when no image is open.

But the same problem still occurs when switching between images with
different working color spaces. The very same color may have different
RGB values in different color spaces. Assuming a calibrated monitor,
the color picker displays absolute colors, so i think the RGB values
should change, not the colors.


regards,
yahvuu

I had composed a response, and then shortly before sending, WIFI on my
laptop conked out. I think yahvuu covered most of what I was going to
say, though. I'll send it anyway when I pull the laptop out again.

--xsdg

On 02/10/2010 07:09 PM, yahvuu wrote:
> Martin Nordholts wrote:
>> On 02/07/2010 04:55 AM, Omari Stephens wrote:
>> "1) When an image is opened with no associated color profile, we assume
>> that it is encoded in sRGB space."
>>
>> I don't think we should assume that, do you have an example use case
>> where that is a good idea?
>
> I think the best guess is sRGB, assuming a file that was produced by a legacy device.
> Which were (back then) to be viewed on monitors with a profile similar to sRGB.
>
> Another source for images of these kind are web developers who want to
> achieve consistent colors cross a web page -- the rationale beeing:
> if the browser has no color profile information, the colors may be wrong,
> but at least consistent.
>
> Among garden-variety photo labs, it's pretty much standard to discard any
> color profile information and just assume sRGB.
>
>
>> I think we should rather assume the image is in the working space color
>> space.
>
> The user's choice of a working space does not reveal any information about
> an unknown image. I don't think the chosen working space should be
> used as input for import heuristics.
>
>> My thinking is that it is the same working space color profile
>> that is used for the GIMP color picker and also for images without a
>> color profile attached. So when you pick RGB 128,128,128 in the GIMP
>> color picker and open an image with no color profile, RGB 128, 128, 128
>> in the image will be displayed the same as RGB 128,128,128 in the GIMP
>> color picker.
>
> OK, the color picker's colors must match, of course. Probably that means
> that the color picker can't show any numbers as long it's not yet clear
> which color space it will be assigned to.
> Or, perhaps better: the color picker gets disabled when no image is open.
>
> But the same problem still occurs when switching between images with
> different working color spaces. The very same color may have different
> RGB values in different color spaces. Assuming a calibrated monitor,
> the color picker displays absolute colors, so i think the RGB values
> should change, not the colors.
>
>
> regards,
> yahvuu
>
>

On 2/10/10, yahvuu wrote:

> Among garden-variety photo labs, it's pretty much standard to discard any
> color profile information and just assume sRGB.

It's pretty much standard where you live maybe, but not where *I* live :)

Alexandre

Martin Nordholts wrote:
> "4) When an image with an explicit profile is exported
> c) If the file format has no way to embed color profile information,
> (FIXME!)"
>
> In terms of a problem, this is pretty similar to "when an image has
> several layers and we export to an image format that does not support
> layers, what do we do?". If the image doesn't support any kind of layer,
> we simply merge or flatten the image, no questions asked. If the image
> supports both layers and non-layers (such as animated GIF), we let the
> user choose. I think we should do the same in this case: if the target
> image format does not support color management whatsoever, we should
> just write the RGB values verbatim, i.e. do the best of the situation
> without becoming annoying and asking questions. If the written RGB
> values are important than the user needs to do a color space conversion
> before exporting into that format.

While this is certainly a good point and in contrast to what i've proposed
elsewhere [1], i'm a lot less shure that this the best solution.
The counter-arguments are just too striking:

a) *Not* converting to sRGB by default fosters the accidental release of
unmanaged non-sRGB files, i.e. files, which cannot be interpreted correctly
without external information.

b) A cycle of export and re-import should preserve as much of the image data
as possible to comply with the principle of least surprise.
From assuming sRGB on import follows conversion to sRGB on export here.

c) The layers analogy applies, but can be used with a slight twist:
File formats that don't support profiles can be regarded as formats which don't
support other color spaces than sRGB. So export should silently auto-convert
by default.


regards,
yahvuu


[1] https://lists.xcf.berkeley.edu/lists/gimp-developer/2010-February/024222.html