Re: [Gimp-developer] GIMP 2.9 XCF files and digiKam, gnome file browsers, etc

Does anyone know of *any* image viewer that can display a thumbnail for GIMP 2.9 XCF files? Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership:

Re: [Gimp-developer] GIMP 2.9 XCF files and digiKam, gnome file browsers, etc

On 01/03/2016 03:04 AM, Boudewijn Rempt wrote: On Sat, 2 Jan 2016, Elle Stone wrote: I'd like to ask the digiKam devs to provide support for showing a thumbnail for GIMP 2.9 XCF files. But if the XCF files are likely to change substantially before 2.10 is released, maybe now is not a good

[Gimp-developer] GIMP 2.9 XCF files and digiKam, gnome file browsers, etc

Is the GIMP 2.9 XCF file format? API? (not sure what the right phrase is) stable enough that it makes sense to hope that other applications like digiKam and various other file browsers and image viewers could start showing thumbnails? For example, digiKam can create thumbnails for 2.8 XCF

Re: [Gimp-developer] Image viewer for openexr and floating point tiff file formats, and maybe even XCF?

On 12/31/2015 09:55 AM, Alexandre Prokoudine wrote: Doesn't media-gfx in Gentoo have a djv port? There is an overlay, but nothing in portage itself. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership:

Re: [Gimp-developer] Image viewer for openexr and floating point tiff file formats, and maybe even XCF?

On 12/31/2015 09:20 AM, scl wrote: DJV indeed opens FP-TIFF and OpenEXR, but no 2.9 XCF (I guess no other program than GIMP 2.9 will be able to open the latter). How did you manage to install and run djv? I haven't managed to compile the code from git

[Gimp-developer] Image viewer for openexr and floating point tiff file formats, and maybe even XCF?

Are there any image viewers for Linux that can display openexr and floating point tiffs? What about GIMP 2.9 XCF files? I've always used geeqie as a fast and lightweight image viewer. But geeqie can't read the 32-bit floating point files produced by editing software such as high bit depth

Re: [Gimp-developer] Image viewer for openexr and floating point tiff file formats, and maybe even XCF?

On 12/31/2015 06:11 PM, Liam R. E. Quin wrote: On Thu, 2015-12-31 at 11:37 -0500, Elle Stone wrote: 1. Open a folder with an image viewer, so that all the image files in the folder (well, at least floating point and integer tiffs, openexr files, pngs, and jpegs; also raw files would be nice

[Gimp-developer] GIMP can't find libmypaint-gegl

I updated and tried to rebuild GIMP from git, with the following error: checking for LIBMYPAINTGEGL... no configure: error: Package requirements (libmypaint-gegl >= 1.1) were not met: No package 'libmypaint-gegl' found There isn't any libmypaint or libmypaint-gegl in Gentoo portage, and

Re: [Gimp-developer] GIMP can't find libmypaint-gegl

On 12/22/2015 08:41 PM, Owen Cook wrote: On 12/22/2015 08:19 PM, Owen Cook wrote: After you built Mypaint, you should have had a libmypaint-gegl.pc which needs to be included in your PKG_CONFIG path but here is the pc file which I think explains what is going on. As you can see, I built

Re: [Gimp-developer] GIMP can't find libmypaint-gegl

On 12/22/2015 08:19 PM, Owen Cook wrote: After you built Mypaint, you should have had a libmypaint-gegl.pc which needs to be included in your PKG_CONFIG path Does this mean I need to install Mypaint in the prefix along with babl/GEGL/libmypaint/GIMP? I cloned Mypaint from git, but there

Re: [Gimp-developer] GIMP can't find libmypaint-gegl

On 12/22/2015 06:46 PM, Eneko Castresana wrote: Sorry, I meant to say "in case you didn't install to the standard directories"; that needs to be done so that the shared libraries can be found in non-standard dirs. Cheers, Eneko 2015-12-23 0:38 GMT+01:00 Eneko Castresana:

Re: [Gimp-developer] HSL Color Picker

On 12/13/2015 03:19 AM, Michael Horvath wrote: On 12/12/2015 1:43 PM, Alexandre Prokoudine wrote: And there is at least one 3rd party color selector for the CIE LCH colorspace: http://registry.gimp.org/node/16814 So anyone with programming skills can contribute an HSL color selector (I'd

Re: [Gimp-developer] Bug found: Unified transform and perspective tool fail silently when layer is hidden.

On 12/09/2015 01:05 AM, Gez wrote: I raised this subject in the UI mailing list a few days ago. In my opinion, A should be the solution. We need to discuss the usefulness of having the original layer during transforms. In my experience, most of the times it's a hurdle, blocking the context for

Re: [Gimp-developer] Bug found: Unified transform and perspective tool fail silently when layer is hidden.

On 12/09/2015 12:33 PM, C R wrote: Is this what you mean by "original layer"? If a layer stack has two layers, A and B, with B as the upper layer, and if a transform/rotate/etc tool is used on B, the "original layer" is layer B *before* the tranform, and the transformed layer is

[Gimp-developer] Automating a series of editing steps using high bit depth GIMP

Following up on https://mail.gnome.org/archives/gimp-user-list/2015-December/msg00055.html: Is there a recommended guide to/procedure for the various programmatic solutions to automating a series of editing steps when using GIMP 2.9? Will the resulting images be high bit depth images or only

Re: [Gimp-developer] ANNOUNCE: GIMP 2.9.2 released

On 11/29/2015 12:41 PM, C R wrote: I could not successfully get gegl to build from source. My apologies for not responding sooner. It sounds like you might have had an issue with establishing the prefix, either during installation or possibly when starting/running GIMP. If you decide to

[Gimp-developer] git version numbering

According to the "About" box, GIMP from git master is now on version 2.9.3. Is the 2.9.2 release code exactly the same as the last git master 2.9.1 code? Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List

Re: [Gimp-developer] git version numbering

On 11/27/2015 07:16 AM, Alexandre Prokoudine wrote: Git master is one commit newer than 2.9.2. Thanks! ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership:

Re: [Gimp-developer] SGO to WGO Transition

Sorry, this was a double post, didn't realize I'd already sent the other post on the same topic. On 11/23/2015 02:13 PM, Elle Stone wrote: On 11/23/2015 11:06 AM, Pat David wrote: I have scripting turned off and the top navigation header renders just fine. So I cannot replicate this. Could

Re: [Gimp-developer] SGO to WGO Transition

On 11/23/2015 11:06 AM, Pat David wrote: On Sat, Nov 21, 2015 at 7:01 AM Elle Stone <ellest...@ninedegreesbelow.com <mailto:ellest...@ninedegreesbelow.com>> wrote: I stand corrected. There is a header at the top of each page, with Wilber in the header. But the user must en

Re: [Gimp-developer] SGO to WGO Transition

On 11/23/2015 02:28 PM, Pat David wrote: If someone is going to purposefully block content (whatever the reason), then they should expect things to not look as designed (but should still be functional). I think we're covering that. Nice fonts are nice to see. But downloading fonts and

Re: [Gimp-developer] SGO to WGO Transition

On 11/23/2015 04:50 PM, Pat David wrote: Hi! On Mon, Nov 23, 2015 at 2:23 PM Elle Stone <ellest...@ninedegreesbelow.com <mailto:ellest...@ninedegreesbelow.com>> wrote: Well, now I feel silly - other than Wilbur and the download icon, I didn't realize that the items besi

Re: [Gimp-developer] SGO to WGO Transition

On 11/23/2015 12:06 PM, Pat David wrote: On Fri, Nov 20, 2015 at 3:18 PM Elle Stone All pages: The site requires javascript enabled to display the icons at the bottom of the page. Otherwise, except for the GIMP icon, the icons are just place-holders. Some people

Re: [Gimp-developer] SGO to WGO Transition

On 11/23/2015 12:06 PM, Pat David wrote: We could, but this does rely on CSS animations, which I can't assume everyone has available (IE8-9 don't for instance). I can look into possibly showing something like that, but for now I'm going to keep the attributions plainly visible for the authors.

Re: [Gimp-developer] SGO to WGO Transition

On 11/21/2015 07:44 AM, Elle Stone wrote: * Wilber is on the new home page, but he's sort of lost against the background image at the top, and he's missing from the other pages. It would help with branding if Wilber were prominently visible at the top of every page. * There's

Re: [Gimp-developer] SGO to WGO Transition

Page loading speed: Starting from an empty cache, http://static.gimp.org/ takes a slow count of four to six seconds before the above-the-fold content finishes loading. The picture at the top is the last item to load. I have a relatively slow internet connection (cable, but not "high speed

Re: [Gimp-developer] SGO to WGO Transition

Branding: The new website has a lot going for it. The font is larger and easier to read. The website layout seems more spacious. It looks more "modern", if that makes sense. I suspect it will be easier to maintain. But something about the new website has seemed odd to me from the beginning.

Re: [Gimp-developer] xdg-app; was: WGO Transition Meeting

On 11/18/2015 09:59 AM, Jernej Simončič wrote: On Wednesday, November 18, 2015, 15:09:56, Elle Stone wrote: I run IceWM instead of a full desktop, so there are only two gnome dependencies. IceWM still works for you? I used it in a VNC session on my server, but replaced it with LXDE because

Re: [Gimp-developer] xdg-app; was: WGO Transition Meeting

On 11/18/2015 06:22 AM, Jon Nordby wrote: We do this in imgflo, which is based on GEGL. There is no GTK+ though, and would need to build more dependencies to be fully distro-independent*. Gentoo allows to run a command ("emerge -epv gimp") that shows *all* the dependencies for a package as

Re: [Gimp-developer] xdg-app; was: WGO Transition Meeting

On 11/17/2015 08:44 AM, Elle Stone wrote: Do any of the developers and packages on this list developers and packagers, people who package GIMP, sorry for the typo! ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org

Re: [Gimp-developer] xdg-app; was: WGO Transition Meeting

On 11/17/2015 06:33 AM, Alexandre Prokoudine wrote: On Tue, Nov 17, 2015 at 2:31 PM, Elle Stone wrote: On 11/17/2015 03:17 AM, Alexandre Prokoudine wrote: It doesn't have to be RPM, and it doesn't have to be DEB. It doesn't even have to be installable. A simple static build inside a tarball

Re: [Gimp-developer] xdg-app; was: WGO Transition Meeting

On 11/17/2015 08:10 AM, Alexandre Prokoudine wrote: On Tue, Nov 17, 2015 at 2:44 PM, Elle Stone wrote: How do you make a static build? The ./configure --help does mention static something or other, but I've never tried to make a static build. Neither have I :) Does this really make

Re: [Gimp-developer] High bit depth GIMP is excellent, awesome, amazing, if it's patched . . .

On 11/09/2015 09:46 AM, Elle Stone wrote: High bit depth GIMP is an amazingly excellent and awesome image editor. I posted a tutorial on how to use some of the incredibly useful new features that will be unfamiliar to people using other image editors: Autumn colors: An Introduction to High Bit

Re: [Gimp-developer] High bit depth GIMP is excellent, awesome, amazing, if it's patched . . .

On 11/11/2015 10:24 AM, Alexandre Prokoudine wrote: 11 нояб. 2015 г. 17:36 пользователь "Elle Stone" написал: Has anyone had a chance to try my patched version of GIMP or read the tutorial on using high bit depth GIMP? Questions and feedback regarding either or both would be very we

[Gimp-developer] High bit depth GIMP is excellent, awesome, amazing, if it's patched . . .

High bit depth GIMP is an amazingly excellent and awesome image editor. I posted a tutorial on how to use some of the incredibly useful new features that will be unfamiliar to people using other image editors: Autumn colors: An Introduction to High Bit Depth GIMP's New Editing Capabilities

[Gimp-developer] Interoperability problems between GIMP and other high bit depth image editors

There are interoperability problems between high bit depth GIMP and other high bit depth image editors. Much of what follows relates to bug 751553, "Linear precision doesn't display the image correctly" (https://bugzilla.gnome.org/show_bug.cgi?id=751553), which is a first step in fixing the

Re: [Gimp-developer] bad displaying of an image

On 10/17/2015 08:20 AM, Øyvind Kolås wrote: On Sat, Oct 17, 2015 at 12:05 PM, Alexander Rabtchevich wrote: Latest 2.9 builds introduced a bag - an image is displayed with equidistant horizontal lines. The lines are only previewed, the image itself does not have

Re: [Gimp-developer] building GIMP from git

On 10/07/2015 12:54 PM, Olivier wrote: ​Finally I succedded in installing ​GIMP, by fetching gegl, babl, gdk-pixbuf, and gimp itself from git, and configuring and installing them all under the same prefix. Under Ubuntu 15.04, the GIO extra modules are located in

Re: [Gimp-developer] building GIMP from git

On 10/07/2015 10:10 AM, Olivier wrote: Hello all. I'm trying to build GIMP-2.9 as explained on http://www.gimp.org/source/howtos/gimp-git-build.html. I'm using Ubuntu 15.04. Everything seems to work smootly, but when I try using gimp-2.9 I get the error message: GEGL operation missing! GIMP

Re: [Gimp-developer] building GIMP from git

On 10/07/2015 11:38 AM, Elle Stone wrote: On 10/07/2015 10:10 AM, Olivier wrote: Hello all. I'm trying to build GIMP-2.9 as explained on http://www.gimp.org/source/howtos/gimp-git-build.html. I'm using Ubuntu 15.04. Everything seems to work smootly, but when I try using gimp-2.9 I get

Re: [Gimp-developer] WGO Update Status

On 10/05/2015 09:37 PM, Jehan Pagès wrote: Hi, 1/ Is it possible to force the download page at least to be https? There are some companies which provides free certificates with root CA in all mainstream browsers. This would be a prerequisite to pretend to provide safe download. For instance I

Re: [Gimp-developer] Portable development environment for GIMP

On 10/02/2015 09:24 PM, Christopher Curtis wrote: I've never used it but wouldn't Gentoo be ideal for this? A source-based distribution that compiles and installs the latest dependencies? Gentoo usually is compiled optimized for the specific hardware that it's run on. I'm assuming this

Re: [Gimp-developer] gimp.org tutorials

On 09/25/2015 11:26 AM, Pat David wrote: On Fri, Sep 25, 2015 at 8:47 AM Elle Stone <ellest...@ninedegreesbelow.com <mailto:ellest...@ninedegreesbelow.com>> wrote: It would be nice if officially hosted GIMP tutorials could be modified to include notes about "techni

Re: [Gimp-developer] gimp.org tutorials

On 09/24/2015 03:42 PM, Pat David wrote: All, I am still trudging through the list of tutorials from the old site and (slowly) migrating them one at a time to the new infrastructure. That's a hugely impressive amount of hard work you've been doing. I've noticed a couple of things, though.

Re: [Gimp-developer] Crash with Print simulation

On 09/18/2015 01:59 PM, Gez wrote: El vie, 18-09-2015 a las 13:56 -0400, Elle Stone escribió: Hmm, hopefully it was implied by the post topic, but in "Edit/Preferences/Color Management" pick "Print simulation" as the "Mode of operation". Yes, it was clear. But

Re: [Gimp-developer] Crash with Print simulation

On 09/18/2015 12:01 PM, Elle Stone wrote: The Color Management Preferences combination that sometimes causes a crash seems to be: 1. Open or make a floating point sRGB image with out of gamut RGB values. As an aside, out of gamut RGB values generate screenfuls of terminal messages like

Re: [Gimp-developer] Crash with Print simulation

The crash with Print simulation might be related to LCMS 2.8 from git. I can trigger a crash with LCMS 2.8 from git installed, and so far haven't managed to trigger a crash with LCMS 2.7 or 2.6 installed. The slowness is another issue, but that also is triggered somewhat sporadically.

[Gimp-developer] Crash with Print simulation

With current GIMP from git (last updated yesterday), "Preferences/Color Management/Print simulation" is sometimes very slow to refresh the screen, even with small (900x600px) images, and will sometimes crash GIMP. The last time I used GIMP 2.9's Print simulation was in April 2015, using LCMS

Re: [Gimp-developer] Different results between RGB to Grayscale conversion and Desaturate (luminosity) filter

On Mon, Jun 15, 2015 at 2:29 PM, thomas manni free fr wrote: in master branch, using Colors Desaturate (luminosity) and Image Mode Grayscale on a RGB image (whatever the image precision) gives different results. This does not appear in branch gimp-2-8, since the 2 actions are computed the

[Gimp-developer] sRGB was second worst performer against spectral reference

context are self explanatory. The study suggests that sRGB is just about the worst possible color space you could use for image editing. Best regards, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ gimp

Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

On 05/01/2015 07:03 PM, Gez wrote: You chose one of the few cases where both linear and perceptually uniform could be valid options and none of them are right or wrong. Of course I'm not against allowing two valid instances of the same thing, like in this case. I've already given other

Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

On 04/30/2015 05:43 PM, Michael Schumacher wrote: On 04/30/2015 11:40 PM, Elle Stone wrote: What are specifications? Something that describes how features are supposed to work when they are implemented. For examples have a look at the Save Export and Single Window Mode specifications

Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

On 05/02/2015 10:21 AM, Gez wrote: El sáb, 02-05-2015 a las 06:09 -0400, Elle Stone escribió: But you're not proposing to add a toggle to gradients alone, you're proposing to put them*everywhere*. Yes. And your reason is that users have to decide how operations are performed, no matter

Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

On 05/02/2015 02:44 PM, Øyvind Kolås wrote: On Sat, May 2, 2015 at 9:45 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: To be more blunt, the babl flips are Pippin's brain-child. If Pippin says no user choice, is there any real benefit to anyone if I write up a spec? Wouldn't it just

[Gimp-developer] GIMP needs a new color management person, take 2

the list). And if anyone wants to fork GIMP, send me an email because I might want to lend a hand. Best, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography -- http://ninedegreesbelow.com Color management and free/libre photography

Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

On 05/02/2015 03:39 PM, Øyvind Kolås wrote: I'm not entirely sure what you are proposing or how it could be implemented in the UI. Is this what you mean? 1. Make a list of all RGB editing operations that are provided by GIMP. 2. Decide for each operation whether it should be done using linear

Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

On 05/01/2015 09:25 AM, Ofnuts wrote: It depends a bit what the workflow is. If users need to switch all tools at random between linear and perceptual, this will be complicated. Complicated or not, it really is needed. But if you can categorize workflows into those that are always

Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

On 05/01/2015 08:46 AM, Douglas Ray wrote: On 1/05/15 12:00 PM, Gez wrote: El jue, 30-04-2015 a las 17:40 -0400, Elle Stone escribió: http://ninedegreesbelow.com/bug-reports/gimp-linear-perceptual-rgb.html Is what's shown in the screenshots feasible in terms of linking the operations

Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

On 04/30/2015 10:00 PM, Gez wrote: I think that allowing that would complicate the UI and the the tools themselves, as all of them should have both paths available. All the tools need to provide the user with the ability to choose linear or perceptual RGB at will, at the user's discretion.

Re: [Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

On 04/29/2015 03:57 PM, Joao S. O. Bueno wrote: Now help us think on the next steps. For example get that e-mail worked into a feasible specification: If you can, refine it, then maybe try to get someone with UI expertise that could fine tune that your suggestions into specifications that could

Re: [Gimp-developer] Gimp in private schools and educational institutions

On 04/29/2015 02:47 PM, Nathan Summers wrote: We do not make GIMP to compete against Photoshop. GIMP_is_ used at schools. Also, USA is not the only country in the world. Not even the largest one out there. So our target audience is non-English speaking photographic professionals that don't

Re: [Gimp-developer] Gimp in private schools and educational institutions

On 04/18/2015 11:55 PM, Liam R. E. Quin wrote: On Wed, 2015-04-08 at 12:58 -0500, Sam Bagot wrote: A product called Gimp can't be used [in schools] Although GIMP can be used in at least some schools, I agree with your premise. These conversations always seem to run the same course: A:

[Gimp-developer] GIMP useability - choosing linear vs perceptually uniform RGB

The single biggest useability issue with GIMP 2.9 is the mechanism for allowing the user to switch between linear and perceptually uniform RGB. In the current UI, the user has no way to know whether any given editing operation is performed on linear or perceptually uniform RGB. For most

Re: [Gimp-developer] GIMP 2.9 useability - out of gamut and HDR channel values

On 04/19/2015 03:40 PM, Liam R. E. Quin wrote: On Sun, 2015-04-19 at 09:56 -0400, Elle Stone wrote: An issue that will arise for everyone who uses GIMP 2.9 is how to deal with HDR and out of gamut colors. Can't say it has arisen for me yet Maybe you only edit sRGB images and you haven't

[Gimp-developer] GIMP 2.9 useability - out of gamut and HDR channel values

An issue that will arise for everyone who uses GIMP 2.9 is how to deal with HDR and out of gamut colors. An HDR color is any floating point color with at least one RGB channel value that is greater than 1.0. An out of gamut (OOG) color is any color with at least one RGB channel value that

Re: [Gimp-developer] Gimp in private schools and educational institutions

On 04/15/2015 08:19 AM, Joao S. O. Bueno wrote: On 15 April 2015 at 05:40, Simon Budig si...@budig.de wrote: No. It would only play into the hands we already have with fake packagers who sell Gimp without mentioning the Gimp brand name and without mentioning that Gimp is available for free as

Re: [Gimp-developer] Gimp in private schools and educational institutions

On 04/11/2015 06:54 AM, Simon Budig wrote: Hi Sam. Sam Bagot (dsm...@gmail.com) wrote: Is there any thought on salvaging the marketing effort and renaming this product so that it can be taken seriously by people and institutions? Also, a big barrier to entry adopting Linux for people is a

Re: [Gimp-developer] Create New Layer Button

. On Fri, Apr 3, 2015 at 5:47 PM, Elle Stone ellest...@ninedegreesbelow.com mailto:ellest...@ninedegreesbelow.com wrote: As long as shift-click and dragging a color to the new layer keeps on working, changing the new layer dialog doesn't present any problem that I can see. In case

Re: [Gimp-developer] Create New Layer Button

On 04/03/2015 07:44 AM, Gez wrote: El dom, 29-03-2015 a las 11:53 -0400, Elle Stone escribió: What you just described - shift-click the new layer button plus dragging the foreground/background color - works perfectly, MUCH better than using the new layer dialog. Thanks! Many thanks

Re: [Gimp-developer] Create New Layer Button

On 03/30/2015 05:57 AM, Joseph Bupe wrote: On 29 March 2015 at 23:32, Elle Stone ellest...@ninedegreesbelow.com mailto:ellest...@ninedegreesbelow.com wrote: , would any of the GIMP developers be in a position to make use of the collected information? BIG question ! But I like the idea

Re: [Gimp-developer] Create New Layer Button

On 03/30/2015 08:08 AM, Joseph Bupe wrote: When you say the opinion poll reflects the point of view of the person who writes it, does that mean the outcome is already decided in advance regardless of what the respondents will say? Of course not. But the people responding to the poll can't make

Re: [Gimp-developer] Create New Layer Button

On 03/30/2015 12:14 PM, C R wrote: Elle, to answer your question, I'm a graphic designer mainly, but I use photography as a graphic design tool. I would consider myself a decent photographer, but I'm much better at photo-editing than I am at photography, to be perfectly honest. :) From me, you

Re: [Gimp-developer] Create New Layer Button

On 03/29/2015 02:32 PM, Kevin Payne wrote: Date: Sun, 29 Mar 2015 19:57:38 +0200 From: ofn...@gmx.com How hard would it be to add meaningful usage statistics in Gimp? It was done some years ago. The GIMP wikipedia page reports it was created by the University of Warterloo and called ingimp

Re: [Gimp-developer] Create New Layer Button

On 03/28/2015 02:54 PM, Gez wrote: But again, since not everyone uses GIMP the same way, it is impossible to come up with something that makes everyone happy. That's when a good interface designer should design the best possible solution which of course won't make everyone happy but maybe will

Re: [Gimp-developer] Create New Layer Button

On 03/28/2015 02:54 PM, Gez wrote: El sáb, 28-03-2015 a las 05:28 -0400, Elle Stone escribió: On 03/27/2015 10:45 PM, Gez wrote: It seems reasonable to require an extra click for committing extra options and having the most commonly used option accessed quickly, without interruptions

Re: [Gimp-developer] Create New Layer Button

On 03/28/2015 07:00 AM, Ofnuts wrote: These contextual menus are a mixed blessing. Of course they make things simple, but it can be somewhat too simple. How will new users discover options or functionalities that are new to them(*)? The people who really benefit from this are the advanced users

Re: [Gimp-developer] Create New Layer Button

On 03/27/2015 09:59 AM, Joseph Bupe wrote: It would be better to have short-cut menu that corresponds to the layer content. That way issues like this one wouldn't arise. For instance, if I have a selection with matching ants, the menu would have options like: - fill selection with fg colour -

Re: [Gimp-developer] Create New Layer Button

On 03/26/2015 08:16 PM, Ofnuts wrote: It was also not so obvious to some more advanced users :) let's face it, in a software with the breadth of Gimp, everyone is going to overlook some feature. +1. For example, I looked for a long time for a way to save a selection as a channel - it's right

Re: [Gimp-developer] Cage Transform Tool's transformations

On 03/17/2015 02:51 PM, Joseph Bupe wrote: Ok Alex, the progress bar in the link below is what I am referring to. It appears between every tweak on the Cage transform tool. Link: http://s4.postimg.org/qqlkwjx4t/snapshort.png I just feel it's too disruptive because I have to halt and wait for

Re: [Gimp-developer] Useability enhancement request: unified/expanded file export dialog

On 03/14/2015 02:34 PM, yahvuu wrote: You might consider a freely editable operations chain for each file to be exported. The exports then can be considered twigs of the GEGL tree*). When different exports of the same composition are supported, the dialog could look like in the following

Re: [Gimp-developer] Useability enhancement request: unified/expanded file export dialog

On 03/11/2015 05:05 PM, Ofnuts wrote: For current Gimp there is the Save for Web plug-in that lets you crop/scale the image. However it's not uncommon to do a little bit of sharpening after a downscale, or maybe add some watermark... Better take the habit to use ImageDuplicate. This creates an

Re: [Gimp-developer] Useability enhancement request: unified/expanded file export dialog

On 03/11/2015 05:29 PM, Joao S. O. Bueno wrote: Thinking on an UI for this now is up to us - so, why not bring the idea to the list? This list? or the GIMP users list? Currently, actually most export plug-ins do perform a image-duplicate, image-flatten (or merge visible layers) and save

[Gimp-developer] Useability enhancement request: unified/expanded file export dialog

The GIMP bug report guidelines say to ask on the mailing list before filing enhancement request bug reports. When editing images using GIMP 2.9, one useability issue kept cropping up over and over again, and that's exporting images to disk. Here are some proposed enhancement requests for

Re: [Gimp-developer] handle transform tool

On 03/10/2015 01:46 AM, Mikael Magnusson wrote: If the code executed faster, it seems like it would be extremely useful for things like controlled modification of facial features and for smoothly blending together portions of several frames of the same subject, when the frames don't match up

[Gimp-developer] One person's perspective on GIMP 2.9 useability

I sat down recently and spent a marathon session editing a whole bunch of images using GIMP 2.9 to see where the bottlenecks and useability problems might be. Although I do edit in other RGB working spaces, for this particular editing session all the images were in-camera-saved sRGB jpegs.

Re: [Gimp-developer] handle transform tool

On 03/08/2015 06:53 PM, Michael Natterer wrote: They are not in the menu because it requires quite some hacking to make menu entries configurable like that (significant amounts of weird code, not worth the effort for experiments). Playground tools are only available from the toolbox. Mitch,

Re: [Gimp-developer] handle transform tool

On 03/08/2015 11:34 AM, Michael Natterer wrote: So now we have some new code, in the playground, so that it will be off by default in a stable release. A somewhat off-topic question: I have the n-point deformation and handle transform checked in the playground and I restarted GIMP. But I

Re: [Gimp-developer] Maintaining buffers in a custom format in GIMP for EXR support

On 02/26/2015 04:55 AM, Mukund Sivaraman wrote: Because babl has no support for chromaticities, GIMP would need to provide extension code to babl, that can convert these custom formats to a working space by maintaining a map from the format's name to a struct chromaticities and registering

Re: [Gimp-developer] GIMP looking for babl and GEGL outside the prefix

On 02/23/2015 07:11 AM, Michael Natterer wrote: A more-or-less complete development prefix environment looks like this (working example from my disk, with all the same packages in prefix also installed by the OS in /usr): PREFIX=/home/elle/code/gimpdefault/run export PATH=$PREFIX/bin:$PATH

Re: [Gimp-developer] GIMP looking for babl and GEGL outside the prefix

On 02/22/2015 11:27 AM, Partha Bagchi wrote: Welcome back. :) Thanks! Can you not simply pass the LIB statement to configure/autogen or adjust PKG_CONFIG_PATH? I use these commands to set up the prefix before installing and updating babl/GEGL/GIMP: prefix=/home/elle/code/gimpdefault/run

[Gimp-developer] GIMP looking for babl and GEGL outside the prefix

I installed babl/GEGL/GIMP from git in a prefix. Then I installed babl/GEGL/GIMP-2.8 from Gentoo portage. When I tried to update GIMP from git in the prefix, I got the following terminal output core/libappcore.a(gimphistogram.o): In function `gimp_histogram_calculate':

[Gimp-developer] N-Point deformation tool

http://www.gimp.org/, GOOGLE SUMMER OF CODE 2013 RESULTS, mentions Marek Dvorožňák's N-Point deformation tool that makes it possible to deform objects while preserve shapes consistency. I watched the video and would love to use that tool. Is the N-Point deformation tool already part of the

Re: [Gimp-developer] GIMP looking for babl and GEGL outside the prefix

Hi Partha, Chris, and Mukund, and thanks! for trying to help sort this out. I've rebuilt babl/GEGL/GIMP in a prefix many times without any problems. The problem started when I installed babl/GEGL/GIMP-2.8 from Gentoo portage. For some reason GIMP from git is looking for babl in /usr before

Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

On 11/20/2014 06:53 AM, Elle Stone wrote: On 11/20/2014 04:34 AM, Elle Stone wrote: Unbounded sRGB is NOT HDR scene-referred. If you guys would actually do a little reading and try to understand what you are talking about, this whole conversation could have been over a long time ago

Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

On 11/21/2014 09:43 AM, Øyvind Kolås wrote: On Fri, Nov 21, 2014 at 2:05 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Again, my apologies for being snippy. Hopefully I haven't bored you all to tears trying to explain problems with editing in the unbounded sRGB color space. For personal

Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

On 11/19/2014 06:13 PM, Simon Budig wrote: Hi Elle. Elle Stone (ellest...@ninedegreesbelow.com) wrote: In case you don't understand this, HDR sRGB data is still *bounded* by the sRGB xy chromaticities. It's only unbounded along the Y axis. There are NO negative channel values in HDR sRGB

Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

On 11/19/2014 06:20 PM, Jon Nordby wrote: On 19 November 2014 23:57, Elle Stone ellest...@ninedegreesbelow.com mailto:ellest...@ninedegreesbelow.com wrote: In case you don't understand this, HDR sRGB data is still *bounded* by the sRGB xy chromaticities. It's only unbounded along

Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

On 11/19/2014 10:47 PM, Simon Budig wrote: Since a few questions have popped up on IRC and it really is a weird concept to grasp I thought I'd expand a bit on the color math that is being discussed here. Sorry it is so long, I hope it is somewhat entertaining though :) Most of what you said

Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

On 11/20/2014 05:13 AM, Mikael Magnusson wrote: On Thu, Nov 20, 2014 at 10:42 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 11/19/2014 10:47 PM, Simon Budig wrote: Since a few questions have popped up on IRC and it really is a weird concept to grasp I thought I'd expand a bit

Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

On 11/20/2014 05:17 AM, Øyvind Kolås wrote: On Thu, Nov 20, 2014 at 9:42 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: Using unbounded sRGB as a universal color space for image editing is a really bad idea There has been no plan for using unbounded sRGB as a universal color space

<    1   2   3   4   5   6   >