Hi all,

this is probably a bit more of outside-the-box thinking than was originally asked for. However, i believe the described user interface enables fairly smooth workflows, so please give it a shot.

The approach taken is notably different from the way established applications deal with color spaces, so some reasoning is provided. Without a chance to compensate for the length, a short summary is preprended. At the bottom, a direct reply to the spec [1] is given.

regards, yahvuu

--------------------
In short:
--------------------

- Every GIMP composition (aka XCF) has a color profile, the working color space. - The working color space is an image mode, in addition to RGB/grey/indexed.

Import: - Open non-XCF: working space = file's color profile if exists; else sRGB. - Open as layers: convert new layer to working space

The user can override these default choices immediately after import: http://yahvuu.files.wordpress.com/2009/08/implicit-confirm.png

The secondary workflow (non-XCF to non-XCF) supports working with non-managed images. GIMP remembers wether the imported image had a profile attached and adjusts export defaults accordingly.

Export: A drop-down selector offers options ranging from "embed full profile" to "don't write a profile".

-------------------- Full version:
--------------------

** Working Color Space

Every GIMP composition has an associated color profile, the working space. The working space is considered an image mode. It can be read off and modified via the Image->Mode menu. Along the lines of:

---------------- Color profile (sRGB IEC61966-2.1) Info... Assign Color profile...
Convert to Color profile...

The new menu entry displays the "Color Profile" tab of the "Image Properties" dialog. For new images, the working space can be set in the "new image" dialog or by choosing a suitable template.

Other image editors use a preference option to enforce a globally pre-determined working space. Such a policy is very questionable, as 8-bit processing demands the working space to be chosen carefully, dependent on both the image and the task at hand.

** Import

It is not possible to do the Right Thing automatically when a bitmap gets imported. Ultimatively, color space handling is an artistical choice.

A seemingly pretty well-determined scenario shows why: Say, the current composition is a collage of 20 photos, in sRGB mode. Now via File->"Open as Layers" an AdobeRGB bitmap gets inserted. It seems obvious that the new bitmap should be converted to sRGB. However, if the user plans to desaturate the new layer, assigning sRGB instead of converting would probably be a better choice. And even if a conversion were the right choice, GIMP wouldn't know the desired rendering intent (a very good guess is possible, though).

Additionally, in quite some cases the profile detection will fail due to missing EXIF support / proprietary profile tagging schemes (bug #492048).

There are two basic scenarios for import: - Open : start a new composition - Open as Layers: insert a new bitmap into an existing composition.

In the first case, any desired color space adjustment can be carried out using the Image->Mode commands. In the second case, however, all pre-existing layers would be affected as well by these commands. So there must be a way to manipulate the new layer without deteriorating the rest of the composition.

The notorious pop-up solution would be a big kill-joy: http://yahvuu.files.wordpress.com/2009/08/conversion-popup.png in ASCII:
"GIMP can't know what to do with the new bitmap": [ ] assign profile XY
[ ] convert to profile XY
[x] do nothing

The problem with that approach is that the user has to confirm even if the default choice is perfectly fine.

The solution is to allow the user to adjust afterwards. That could look like following: http://yahvuu.files.wordpress.com/2009/08/implicit-confirm.png The idea is to make the commit implicit: if the user moves on and continues working on the composition (e.g. painting), this means that the choice of color space treatment is accepted.

The color space setting can be adjusted interactively, which is an additional bonus. For notifying of invalid profiles or other problems, a warning/info button can be displayed:
http://yahvuu.files.wordpress.com/2009/08/conversion-delayed-confirm-warning.png

[I hope that something along these lines is feasible.]

Note the similarity of this approach with the way a newly pasted layer gets positioned: as GIMP cannot know the desired position, a reasonable default is offered and the user can adjust later on. (Imagine every layer pasting action would result in a pop-up dialog: "GIMP doesn't know where to position the layer:" [x] center
[ ] top left
[ ] bottom right)

The difference is that the layer position can be edited in a fully non-destructive manner, whereas the desired color space adjustment becomes permanent once the user continues working on the composition.

(FIXME: how to deal with multiple imported layers? Without multi-selection, a notify bar at the top of the viewport seems attractive. But compare [2])

** Export

It is fully valid to export a photo both as a managed JPEG for the photo lab and as an unmanaged JPEG for web. So export must provide both choices.

A drop-down selector fits this purpose well. Which options are available, depends on the file format. For example, JPEG could have - "Embed Profile"
- "sRGB EXIF hint" (in case the composition is in sRGB) - "No Profile"

Which option is default, depends on how the composition was created -- see next section.

** Unmanaged Data

The primary workflow (work is saved in XCF, gets exported on delivery) is supposed to be fully color managed. Every XCF file is color managed. By default, imported data is assumed to be sRGB.

However, the secondary workflow (non-XCF to non-XCF) supports unmanaged data. While a working space is mandatory for editing, any composition may be exported without attaching a color profile. In detail:

- GIMP remembers wether a newly imported image (Open non-XCF) is lacking a color profile. This amounts to a flag: "export without profile by default".

- Open as Layers, or pasting/droping a layer does not change the flag, since a working profile has already been determined in this scenario.

- 'Quick' Export aka "Overwrite file" acts according to that flag.

- 'Normal' Export: if the flag is set, "write unmanaged file" becomes the default option. Otherwise "attach profile".

- Manipulating the working space (Image->Mode Assert/Convert) resets the flag.

- Saving (XCF) and Re-opening also resets the flag -- XCF is always color managed.

** Preferences

The color management preferences can be reduced to #1 Monitor profile(s):
Items as before (color profile, [] use system monitor, rendering intent).

The default color profile is "Generic sRGB Monitor". This amounts to an unmanaged display path if the working space is sRGB. For other working spaces, the display data gets transformed to sRGB in order to give the best possible approximation, even if the monitor is not profiled/calibrated.

Unprofiled AdobeRGB monitors are probably not very common, but could be supported by a "Generic ClayRGB Monitor" profile.

In case out of _display_ gamut colors should get marked, the corresponding checkbox belongs to the View menu.

#2 Softproofing Devices List An entry consists of:
- device profile
- rendering intent
- black point compensation - out of gamut color [wether of not to mark out-of-gamut colors should reside in the View menu]

As softproofing will reside under View->Filters, the devices list should be editable there, too.

Obliterated Items: - Mode of operation:
Every GIMP composition has a color profile. Working with unmanaged files is supported for the secondary workflow. Via the "Generic sRGB Monitor" an unmanaged display path is available. This is nearly identical to color management turned off. There is no need for a static, global switch.

- RGB profile: A global workspace policy is overkill for 8-bit processing. The working space is a property of the current composition. While there would be reason to have an item "New image's working profile", a lot of confusion can be avoided by moving this functionality to the "New image" dialog and the templates selection, respectively.

- CMYK profile: There is no CMYK mode in GIMP, and the only place where this setting got used is the CMYK color selector. This selector effectively specifies an RGB value, so the CMYK color therein should be relative to the current RGB working space. (Even in future: outside the upcoming prepress projection, all colors are RGB colors).

- File Open behaviour: What to do on import, depends on the file and the task at hand. Any static choice gets in the way of a smooth workflow.

-------------------- Reply to specs
--------------------

Omari Stephens wrote [1]:

I wrote up a quick spec for how GIMP should deal with color profiles associated with files and images.

For ease of reading, i'll comply with the terms 'implicit' and 'explicit' (profile). At the UI surface, however, every composition has a profile and only 'normal' profiles exist. A flag named "export of unmanaged files preferred" probably better incorporates the semantics (this is not meant to anticipate implementation decisions).

The only situation where an implicit profile makes a difference is on export. Changing the working profile makes any implicit profile an explicit one. In consequence, on export, a user-chosen profile gets embedded by default. Saving (XCF) and re-opening the composition makes the profile explicit, too.

The basic image import scheme is: - Open:
A new composition gets created. The working color space gets adopted from the foreign file if possible.

- Open as Layers or paste/drop a new layer onto an existing composition: The new layer(s) get converted to the working color space by default.

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.

agreed. Attached to the new layer, an "Adjust" button is displayed [3]. (The button is not strictly necessary in this case, as all required actions are available from the menus as well. The idea is to match the "open as layers" import case on the UI.)

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

a) Is available via Image->Mode->"Assign Color Profile" and additionally, via the "Adjust" button b) Not applicable. Every GIMP composition has a color profile. c) Available via Image->Mode->"Convert Color Profile" and additionally, via the "Adjust" button

Net result: no need to prompt the user.

1x) Open as Layers; imported image has no associated color profile

Analogous; the only difference here is that the "Adjust" button is now the only way to fix a color space mismatch. (Convert/Assign from the Image->Mode menu would affect _all_ layers).

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

Option a) is a good default: set the composition's working color space from the imported image. Any desired conversions can be achieved later on via Image->Mode->"Convert Color Profile"

2x) Open as Layers; imported image is color managed

Analogous, the new layer gets converted to working space. The user can fine-tune or rechoice afterwards: attached to the new layer an "Adjust" button gets displayed [3].

FIXME: how to deal with multiple imported layers?

3) When a PNG is opened that is tagged with the sRGB chunk

PNG special case saved for later.

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

d) don't write any profile (Graeme)

The export dialog gets a drop-down selector to specify profile embedding: - "Embed profile", as in a) : default - ... : other options, if available (EXIF hint?!?) - "No profile", as in d) : last option

b) PNG case t.b.d. c) drop-down box disabled, write plain RGB without conversion. (Martin)

5) When an image with an implicit profile is exported a) The image is saved with no color profile information.

There are two cases:
- File->"Overwrite XXX.YY": no profile gets written - File->"Export...": drop-down selector as in 4), but the last option "No profile" is default

PNG t.b.d.

My main questions so far:
1) What should we do when exporting to formats that don't support color profile tagging?

simply write RGB values without conversion. Without 'pull-over projections' as designed for the CMYK solutions model, we can't sensibly offer auto-conversion. Better be predictable than über-clever.

2) What should we do when an opened image contains an invalid profile?

This case can be treated similarily to an image without a profile, cases 1) resp. 1x): assume sRGB for the new layer, and display 'Info' Button, which on demand informs about the corrupt profile. [4]

-------------------- References
--------------------

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

[2] http://people.mozilla.com/~faaborg/files/20090821-notification/newNotification-i1.png

[3] http://yahvuu.files.wordpress.com/2009/08/implicit-confirm.png

[4] http://yahvuu.files.wordpress.com/2009/08/conversion-delayed-confirm-warning.png

Hi -- and apologies i'm quite late,

Martin Nordholts wrote:

I would like to add that with GEGL, desaturation will always be performed in linear light 32-bit RGBA (maybe even LAB), so the color space of source bitmap won't matter for the quality of the conversion.

Additionally, with floating point processing i'd like to see the user working with just 'colors' -- and be relieved from having to choose a working space.

I wonder what the problems of ultra-wide gamut color space are (due to virtual colors etc.). I'd be grateful for any pointers.

The subject of the mail suggests this is for 2.8, but it should work pretty good on any GIMP version because of it's generic nature. I am afraid this will be necessary unless we postpone or reschedule the GIMP 2.8 release.

.. i'll hope for some magic that someone chimes in to make it happen ;)

However, there are several options to lessen the required coding effort for import handling *). The most radical of which is to use the classic pop-up dialog, together with a corresponding prefs item: "Ask on bitmap import: always/never/if in doubt". The other sections of the proposal can stay pretty much the same.

If this variant sounds reasonably close to a minimal strategy, i can work out the details, just let me know if that makes sense ;)

In comparison with the current behaviour, this solution gives better defaults to support both a color-managed primary workflow and the secondary workflow, which moreover may be unmanaged -- without one having to dive into the preferences.

regards, yahvuu

*) There are two more variants which should require less coding than the on-canvas approach and still offer smooth workflows:

Adjusting the color space conversion boils down to two steps: 1) undo the last import and 2) re-do with the new parameters, so my uneducated guess is that the bitmap to be imported could be pushed on the undo stack...

Variant 1: buttons in the viewport corner instead of an attachment to the new layer(s): http://yahvuu.files.wordpress.com/2009/08/var1-viewport.png

Variant 2: GtkInfoBar: http://yahvuu.files.wordpress.com/2009/08/var2-gtkinfobar.png