Hi,

We posted a detailed summary of what was going on with the development of GIMP in 2013:

https://mail.gnome.org/archives/gimp-us ... 00225.html

In short, most of the time was spent on improving the GEGL-based version of GIMP (to be released as v2.10) and porting GIMP plugins to GEGL, so that you could benefit from 32bit float precision per color channel as much as possible.

We also successfully participated in Google Summer of Code 2013 and merged more code from GSoC2012 into the main development branch, namely Seamless Clone and Warp Transform tools.

It's still too early to say when GIMP 2.10 could be released. We need more people to move various bits of GIMP to GEGL (the base work is done, though) and speedup GEGL itself.

Spectacular news! Thanks.

Is the new Matting tool going to be introduced in GIMP-2.10?

Thanks for the update!

It took a while to get from V2.6.x to V2.8.x but for me, the wait was well worth it. I'm very pleased how GIMP 2.8.x turned out and I hope that V2.10.x is another step in the right direction.

Thank You very much for your comprehensive information.
However, I have not found information about solving the problem loading script-fu (too long - without visualization of progress).
Merry Christmas !

Very good Alexandre, thank you for the summary link.

Appreciate the update Prokoudine. Very happy with 2.8's development progression. Very cool that 64-bit native works flawlessly with this version of GIMP. Can't wait for higher bit depth edit capability so I can finally tell the GIMP bashers at other forums that I frequet to take a hike (I would use more colorful language, but Tux or Molly won't let me; lol).

It is impressive to see how many new features and enhancements are contemplated for the next releases of GIMP thanks to the important work of so many keen people throughout the past year, proving that the GIMP community is more alive than ever.

Thanks for the overview.

is this new?
I thought the Name is program: "GNU Image Manipulation Program"

Yes, most likely. It's by no means complete:we still need to improve the user interaction aspect at the very least. But it's unlikely that we will roll back changes there.


The way Script-Fu is executed makes it difficult to add preview. We'd like to improve that, of course, we just don't have any particular plans at the moment. Kevin Cozens would explain that better, but I'm not sure if he's on this forum.


Yes, a typo. And yes, we'd like to have a complete OpenEXR plugin. It was among Google Summer of Code project ideas this year. So it's on radar, but needs a developer.


With OpenCL you get handy things like multithreading etc. See http://www.slideshare.net/lgworld/imple ... l-and-gimp.


Before we can work on advanced CMYK support, the foundation (GEGL port) should be done. That automatically means v3.2 at the very least (v3.0 is reserved for GTK+3 port that should restore Wacom support for Windows users). But then you need to consider a few things:

1) We aim to provide tools to different kinds of users. E.g. both photographers, graphic designers, 3D artists, scientists, and desktop publishing professionals need non-destructive editing, but it's mostly the latter who need advanced CMYK (and spot colors) support. So between a) giving much required tools to everyone, then taking care of industry-specific things one by one, and b) giving industry-specific tools to a much smaller group of users while making everybody else wait, our choice is a).

There are other similar considerations like fixing the abomination which is the floating selection , or the auto-expansion of images (try rotating a layer that's the size of an image -- currently, GIMP permanently clips the content that goes out of bound).

2) None of us are currently awesome at desktop publishing. It's a very specific expertise, and the feature needs a very careful treatment.

Together, that makes advanced CMYK support a low priority. I hope the explanation was clear enough

It's is absolutely possible to make those priorities shift though. For instance, we weren't planning the Unified Transform tool to be as early as part of v2.10, but then we got a dedicated developer who was really committed to making that happen (Mikael did a lot of preliminary work before he chose it as his GSoC2012 project).

So advanced CMYK support in e.g. v3.2 is a possibility in case, similarly, a committed developer stops by to work on that (another prerequisite is that Peter Sikking's usability team has the time/funds for the work with that developer).



I don't think we ever discussed that feature long enough. Actually, GEGL already reads various RAW files via libopenraw. So it's kind of done already (it's just several lines of code to add direct RAW files opening via GEGL to GIMP), and in a future non-destructive workflow the kind of interaction that is between Photoshop and ACR, that is, using RAW files as smart objects, would just work in GIMP.

However, again, there are a few considerations here as well:

1) Hubert is currently on his tod with libopenraw, unlike e.g. Rawspeed library that is taken care of by two teams -- Rawstudio and darktable. I can't say how complete it is at this point.

2) Just opening RAW files wouldn't do. You'd also need all sorts of processing features such as hot pixel suppression. Currently we have noone to work on that. One of the ideas was to somehow join forces with the darktable team, but no plans were ever made.


Not entirely true If you have a closer look at the changes in UFRaw here, you'll see some progress towards making UFraw compatibe with GIMP 2.9-2.10 already. So UFRaw is at least maintained even if not actively developed. Can't speak for separate+ though; indeed, it's been a while since I last heard from Yoshinori-san.


Any specifics?


Er, patience is a virtue, perhaps?

Is it possible to add something like a tabbed interface or multi columns for script-fu dialogs? This could definitely help with too long of dialogs that have many value input areas. For instance Fenceposts excellent "Animated Fire" script.
Currently it is so long on low res monitors that it's hard to enter values for each field. He did somewhat shorten the dialog by combining some procedures but it would really be nice if i wanted to write a script with many procedures that could be tabbed or have user input areas in separate columns to shorten the dialogs interface.
Tux and Saulgoode mention two different possibilities.
An NEW SF-PAGE script-fu-register procedure for tabbed interface dialogs, and Scrolling in script-fu dialogs.
viewtopic.php?f=9&t=9363

Two photography related Gimp books I recommend,
GIMP 2.8 for Photographers by Klaus Goelker
The Artist's Guide to GIMP, 2nd Edition by Michael J. Hammel

Any photographer that uses Gimp should read, GIMP 2.8 for Photographers and Michael J. Hammel, the author of The Artist's Guide to GIMP is very thorough, an awesome teacher.

prokoudine, I would like to make a suggestion. I liked the visual presentation mode "alpha channel lock" in GIMP 2.6. The visualisation was sharper. Now, in version 2.8 I am always in doubt if the channel is locked or not. The same can be said of "reverse gradient." It would be possible to return to the old way?

I noticiced that too Carlos. I have to double check all the time to see if it is on or off. It also depends on the theme you are using to whether you can see it more clearly or not.

So we ask everyone to have the same opinion to demonstrate here. So, maybe we can get the modification.

may be, if it makes you happy ... but that did'nt change anything.
RAW-processors are photo-editing-tools.

Thank you Alexandre, and thanks to all the other GIMP contributors and developers