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, <gimp-developer-request@xxxxxxxxxxxxxxxxxxxxxx> wrote: > Send Gimp-developer mailing list submissions to > gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxxx > > You can reach the person managing the list at > gimp-developer-owner@xxxxxxxxxxxxxxxxxxxxxx > > 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 <yahvuu@xxxxxxxxx> > Subject: UI Proposal for GIMP 2.8 color management > To: gimp-devel List <gimp-developer@xxxxxxxxxxxxxxxxxxxxxx> > Message-ID: <4B7C5882.8090001@xxxxxxxxx> > 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 <enselic@xxxxxxxxx> > Subject: Re: moving windows in the git version > To: gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > Message-ID: <4B7CDE9F.7080104@xxxxxxxxx> > 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 <martinn@xxxxxxxxxxxxx> > 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" > > > ------------------------------ > > _______________________________________________ > Gimp-developer mailing list > Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > > > End of Gimp-developer Digest, Vol 89, Issue 24 > ********************************************** > _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
