Hi List,

If I'm reading correctly, Gimp currently only uses D-Bus for instance management. The web-site hints at the possibility of doing more (http://developer.gimp.org/standards.html). Has anyone written any code or documentation related to this?

To me the most obvious use for a D-Bus api would be communication between the Gimp and a photo manager. For example, the photo manager could request the Gimp open an image file for editing, bring the Gimp UI to the top of the window stack and let the user edit the image. When the user saves or closes the image, Gimp would send a D-bus notification to the photo manager allowing the photo manager to update information about that image (e.g. if the user uses "save as" the photo manager could mark the new image as "related" to the original). As it stands, photo managers have a hard time keeping in sync with externally edited images.

Any reactions? I'd be tempted to scratch around a little in the code and, depending on how daunting the task, hack together a simple prototype interface if there is any interest.

cheers, dm

On Thu, Feb 18, 2010 at 3:00 PM, wrote:

Send Gimp-developer mailing list submissions to        gimp-developer@lists.XCF.Berkeley.EDU

To subscribe or unsubscribe via the World Wide Web, visit        https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to        gimp-developer-request@lists.XCF.Berkeley.EDU

You can reach the person managing the list at        gimp-developer-owner@lists.XCF.Berkeley.EDU

When replying, please edit your Subject line so it is more specific than "Re: Contents of Gimp-developer digest..."

Today's Topics:

  1. UI Proposal for GIMP 2.8 color management (yahvuu)   2. Re: moving windows in the git version (Martin Nordholts)

----------------------------------------------------------------------

Message: 1 Date: Wed, 17 Feb 2010 21:58:42 +0100 From: yahvuu
Subject: [Gimp-developer] UI Proposal for GIMP 2.8 color management To: gimp-devel List
Message-ID:
Content-Type: text/plain; charset=ISO-8859-1

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

------------------------------

Message: 2 Date: Thu, 18 Feb 2010 07:30:55 +0100 From: Martin Nordholts
Subject: Re: [Gimp-developer] moving windows in the git version To: gimp-developer@lists.XCF.Berkeley.EDU Message-ID:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 02/17/2010 08:37 AM, Olivier wrote:

For several weeks now (I compile the git version every Monday), the windows in normal mode (i.e. multi-window mode) behave in a weird way: I place them where I want them on one virtual screen, and then I move to another one virtual screen. When I come back, the windows have moved to a different place, always the same.

Sorry about that, hopefully fixed forever with this commit and a regression test I added:

commit 45efd8407938e1f7487b9b372c195aab32a4f90a Author: Martin Nordholts
Date:   Thu Feb 18 07:21:20 2010 +0100

    Bug 608834 - Toolbox and docks move on desktop change

    Make sure that after we have set GTK_WIN_POS_MOUSE on a     dialog created with the dialog factory, it is eventually     reset. Also remove the only occurance of the     DEBUG_FACTORY define.

 / Martin

--

My GIMP Blog: http://www.chromecode.com/
"Multi-column dock windows and 2.8 schedule"

------------------------------

When the user saves or closes the image, Gimp would send a D-bus notification to the photo manager allowing the photo manager to update information about that image (e.g. if the user uses "save as" the photo manager could mark the new image as "related" to the original).

That is not trivial. For the work-flow you describe, it could probably be done. But not every image opened ends up being related to the image that is saved later.

Agree this will never be perfect. It will be up to the client app (and user) to figure out if the image is really related or not. It's still a lot better than forcing the user of the photo manager to manually find the file and create the link.

Probably the most interesting part for using D-Bus in GIMP would be to export the full PDB as a D-Bus interface.

I guess, but does that allow hooking into gimp events? (my experience with scripting gimp is limited to very straightforward stuff) For my purposes, I'd really like to see client notifications.

PS: Pretty please, next time you write to this list, do not quote the full mailing-list digest. We kindly ask everyone here to only quote relevant material.

Sorry, I forgot to delete it. :(