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 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/

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

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 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/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

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