GIMP 2.9.4 and our vision for GIMP future

So you may have heard the news: we recently released a new development version of GIMP, version 2.9.4 (as well as a bugfix release 2.8.18, but this is not as awesome).

Small edit: I realized that my blog post has been linked on many major news website. I didn’t expect this! Therefore I just want to make clear that whatever I wrote below is my view of GIMP future. It may not be shared by other developers who have their own priorities and this post has not be written with the other devs. In other word, anything here is not written as anything official from the GIMP project itself, but from me only, a single contributor to GIMP.

GIMP 2.9.4

I am not going to rewrite all of the official news, because you may as well read it on gimp.org. Anyway I co-wrote the news with the rest of the team and provided several screenshots. So reading there is also partly same as reading here. 😉

I’ll just illustrate with this cool picture of the live preview of operations (here a gaussian blur) directly on canvas, split for comparison, implemented by Mitch, our own benevolent dictator (or are we all his dictators?). The image on canvas is by Aryeom, ZeMarmot‘s director.

GIMP 2.9.4 screenshot. Image on canvas is by Aryeom Han under Creative Commons by-sa.
GIMP 2.9.4 screenshot. Canvas image by Aryeom Han (Creative Commons by-sa).

Pretty cool feature, uh?

GIMP & ZeMarmot project

As you can read on gimp.org, ZeMarmot is a contributor to GIMP through my own contributions (which amounts to about 14% of commits for this specific release. Commits number is not always the most perfect metrics but as good as any).

Painting

So what did we bring to the table? Well there are the stuff which we like most first: painting. So I developed symmetry painting last year. Here are some symmetrical doodles drawn by Aryeom in just a few seconds, thanks to the symmetry modes:

Symmetrical doodles by Aryeom Han (Creative Commons by-sa).
Symmetrical doodles by Aryeom (Creative Commons by-sa).

I also helped on the integration of the MyPaint brushes, and in particular contributed upstream on a whole build system rework which, as a side effect improved the codebases of libmypaint and MyPaint (quote from Mypaint’s blog post):

Development of MyPaint will continue of course; in fact making this split happen has improved a lot of things in the codebases of both projects ☺ Big thanks to @Jehan for making this all work so well!

Internationalization

Also the fact that Aryeom is Korean, that we both lived in several countries in Europe, Asia and Oceania, that we speak English, French, Japanese, Korean (well my Korean is lacking!), and that I love languages and am a grammar geek made us good targets to notice anything wrong with GIMP’s support of non Western languages. So I have fixed some bugs and even crashes related to Input Methods and made the text tool finally compliant with input method engines (it used to have an ugly overlay box, not integrated at all in the input box, and without any standard formating).

Writing Korean (left) or Japanese (right) in GIMP 2.9.4's text tool.
Writing Korean (left) or Japanese (right) in GIMP 2.9.4’s text tool.

Of course, I did several other fixes related to languages since I contribute to GIMP like each language translated in itself in the list of language in the preference, or bugs with GUI with right-to-left languages, like Arabic (did I say I was a language geek? I love all these differences and particularities).
Other than this, both Aryeom and I are trying to build a more diverse community by engaging FLOSS and GIMP enthusiasts in Japan, South Korea (some tutorial videos in Korean even) or other countries in their native languages. A hard and long job but we are trying. 🙂

Code review and code maintenance

Well I code a lot of other stuff, smaller features (like the email plugin in GIMP 2.9.4, using xdg-email, implemented a few weeks ago) and bug fixes since I like GIMP hard-rock solid and as stable as possible but that’s obviously less visible. I am also trying to step up more and more for code review and maintenance of small pieces of the software, since Mitch really needs the help (apparently the whip is not enough help! Go figure!). Well this is still work in progress and I wish I could make time to bring more cool code into GIMP, but it still allowed the action search (equivalent to the space-menu of Blender), which I think is one of the coolest feature of GIMP 2.9/2.10 and making menus so old school. This was originally contributed by Srihari, then I reviewed, rewrote and fixed parts of it to fit our high standards on code quality. Well I think that’s one of the features I am the most proud as a reviewer (instead of as the original author). This is also very rewarding to work with other coders, especially when talented and with interesting ideas.

Searching an operation in GIMP with the action search.
Searching an operation in GIMP with the action search.

There are more code I reviewed and integrated, like lately the cool command line’s batch processing macro or even the whole revamping of the user interface (new themes and icons). Arguably this is less “useful”. Well it depends. I met some people who claimed it will change their life, while others would hate the new design direction (though note that old icons and theme are still available in preferences). But anyway this was an idea hanging around on mailing list for years, so I took on myself to attend to new contributors willing to help on the matter (Klaus Staedtler for the icons and Benoit Touchette for the themes). This is also an interesting adventure, I think.

New themes by Benoit Touchette and icons originally by Barbara Muraus and Jakub Steiner, heavily updated and completed by Klaus Staedtler.
New themes by Benoit Touchette and icons originally by Barbara Muraus and Jakub Steiner, heavily updated and completed by Klaus Staedtler.

In the end working on all these fronts is very cool but also exhausting. Hopefully the more time goes, the more I will be able to do! 🙂

Future of GIMP

GEGL everywhere?

I see a lot of good things happening around GIMP. And not just from me, but from all the awesome people in GIMP team and projects around. GEGL for one is a hell of a cool project and I think it could be the future of Free and Open Source image processing. I want to imagine a future where most big graphics program integrates GEGL, where Blender for instance would have GEGL as the new implementation of nodes, with image processing graphs which can be exchanged between programs, where darktable would share buffers with GIMP so that images can be edited in one program and updated in real time in the other, and so on.
Well of course the short/mid-term improvements will be non-destructive editing with live preview on high bit depth images, and that’s already awesomely cool right?

Painting again, better UI, export and much more…

Of course we want to go further for painting features and workflow improvement, but also the UI which really needs some reworking here and there (which is also why I created the gimp-gui mailing list, meant to discuss all sort of topics UI and UX related). That also includes improving support for graphics tablet and alike.
I also have a lot of ideas, some may come to be implemented in a form or another, or not (the export process for instance is still untouched for now). Even when this happens, it’s ok: contributing to Free Software is not just adding any random feature, that’s also about discussing, discovering others’ workflow, comparing, sometimes even compromising or realizing that our ideas are not always perfect. This is part of the process and actually a pretty good mental builder. In any case we will work hard for a better GIMP. 🙂
Among the many other features we are really keen on are the ability to select many layers at once (this is often a pain for Aryeom, since she usually works with many dozens of layers when animating), macros, improving the API to be able to customize the GUI (and not only adding menu items) and the behavior of GIMP, get more communication between GIMP and plugins and in general reacting to hooks, and much much more.
Now there are stuff which are also cool, like better HiDPI support but since we don’t own a HiDPI screen anyway, this is harder to test.

Also I like GIMP for being generic. While other programs choose to be specialized, which is a valid choice, we can notice most graphics programs end up with the same features in the end anyway. Indeed brushes and other painting features are actually very useful to photographers as well. On the other hand, painters regularly use filters and transformation tools originally thought for photographers. Designers use everything as well. So I think the approach of a program which aims to do everything well is quite acceptable too.

Well you see, we have a lot of plans about GIMP, that seems nearly impossible but that’s exciting. And of course, there are the plugins for animation that I am working on, on a good pace. I think I will be able to present the main GIMP plugin for animation quite soon on this website. Stay tuned! 🙂

Help us by helping ZeMarmot?

As often, I will conclude by promoting our permanent monthly funding of ZeMarmot. I know this is very annoying! We want to make a difference, something cool: a Libre animation film together with Free Software code. And trying to make this into more than just a hobby. Right now we are barely there.
I regularly talk about the more “artistic” side here, not often enough about the “technical” coding side. So I decided to use the opportunity of GIMP 2.9.4 release to make this small (non exhaustive) report of stuff I had been doing these last months and what are our goals on the software side (GIMP in particular). If you like what you read here about my contributions, then you like what ZeMarmot is doing, because this is all the same project. And therefore if ever you can afford it, we would welcome financial help so that we can continue software development as well as the production of the animation film.

We are on 2 platforms allowing monthly subscription (which you can stop anytime, as soon as you don’t like us anymore!): Tipeee where you can contribute in EUR (€) and Patreon where you can contribute in USD ($). Note that our pitch is written in French on Tipeee but that’s the same project anyway. Just read the official website in English or the Patreon page.

ZeMarmot on Tipeee (EUR).
Support ZeMarmot on Tipeee (EUR) »
ZeMarmot on Patreon.
Support ZeMarmot on Patreon »

That’s it for today! I hope you enjoyed my coding report on GIMP. Enjoy your week-end everyone! 🙂

37 Replies to “GIMP 2.9.4 and our vision for GIMP future”

  1. Why dont you make some croudfundings? I’m sure you’ll get much attention and interest, thus will succeed!

    1. Agree! I would support GIMP on some crowdfunding platform for some major plans! I think GIMP can easily raise lots of money this way…

      1. Hi Aram, Dmitri,

        I am confused. You are talking about making a crowdfunding… but this is exactly what we do. Now that’s not a 1-time crowdfunding where we request 30,000 € or something (we also did this to kick-start the project but are now trying for more long-term engagement). This is another approach as a monthly subscription. Yet in the end, this is exactly the same thing.

        Also this is not in the name of GIMP, if that’s what you mean. Yes because our goal is not to just improve GIMP for no reason. We improve it for a reason, and this reason is ZeMarmot movie. Working on GIMP is the cool side effect, and that actually also ensures that whatever we do, it is stable (we use GIMP all day long every single day so crashes are not acceptable to us), working and useful. Yet once again, this is exactly the same thing, and even probably better (as I said: stable, working and useful). If you really want to help me continue improving GIMP, you may as well contribute to our crowdfunding (either Patreon for USD or Tipeee for EUR). Otherwise we will have to stop soon. And everybody loses.

        Thanks anyway for the interest! 🙂

        1. Is not the same thing. The publicity is not the same for a patreon/tipee than for a big crowfunding.

          Btw, as a suggestion I would like that some options where placed in other menus, better installation of plugins like GMIC, (in windows is a pain, but in Linux is all smooth) and also a way to remove in history more than one item per time.

          thanks

          1. Hi,

            > The publicity is not the same for a patreon/tipee than for a big crowfunding.

            Yes but it is short lived. And I can really say that some patreon/tipeee funding can get some huge publicity (in more “artistic” world at least, not many hackers yet). Nothing is stopping anyone from doing it (especially not me!).
            Also these big crowdfunding are really taking a huge amoung of time and effort and all your energy to do mostly marketing for a month (or however long you choose it to last). This is exhausting and a terrible feeling. So I’m not saying that I won’t do more, but just that I’d prefer not to do this too often. On the other hand, the “subscription” type crowdfundings feel much less stressful and I can continue to code, which is what I prefer to do, rather than trying to reach a target at all cost. In the end, everybody wins (because for people funding us, it is also much better that we code and produce the animation rather than just making self-promotion which has absolutely no real value). I know it is possible for projects to be fully funded by subscription-type crowdfunding (many projects are funded with several thousands of euros a month).

            Anyway if we don’t manage to reach such a funding fully with subscriptions, we are planning a second big crowdfunding, but only once our upcoming pilote will be released, so that we can continue to the next part of the movie.

            > I would like that some options where placed in other menus

            Don’t hesitate to open a bug report if you have more specific info on the problem you have in mind: https://bugzilla.gnome.org/enter_bug.cgi?product=GIMP

            > better installation of plugins like GMIC

            G’Mic is a third party plugin (a very cool one). We don’t maintain it and can do nothing about its installation.

            > remove in history more than one item per time.

            Document history, I assume? That’s a valid request. You should open a feature request for this.

        2. I forgot another question. the action search is like the HUD in new versions of ubuntu?

          1. I don’t use Ubuntu, so I can’t say for sure, but making a quick research, I assume you are speaking of this: https://wiki.ubuntu.com/Unity/HUD ?

            Reading this page, I guess that’s similar. Though I guess this HUD can only see through menus whereas GIMP’s action search can also browse through any action. You can select tools for instance (even ones which you don’t show in your toolbox). Also I wonder which level of introspection it has into the actions. GIMP’s action search can also make use of the description for instance (often I get the right action through words in the description).

            In any case, this HUD stuff looks like a very interesting feature and having the possibility to use it on any software without it having its own search system seems very useful.

  2. Amazing gegl everywhere sounds great, cab you explain what’s difference between gegl and vips, which photoflow uses, and is also developing plug in for gimp, would that be an issue? Should it change to gegl? Are there advantages, disadvantages or compatability issues, with this?

    1. So first a disclaimer: I never used VIPS and I am not a GEGL expert (i.e. I use it in GIMP, and even though contributed a bit of code to GEGL itself, not that much and nothing algorithmic-wise). So I will try to answer from what I see but I may also be wrong. 🙂

      # Speed #

      VIPS seems very speed-focused, and is much older (apparently started as an European research back in 1989-92 according to Wikipedia).
      They have a benchmark page where they compare with various other libraries (http://www.vips.ecs.soton.ac.uk/index.php?title=Speed_and_Memory_Use). GEGL is performing pretty bad. In their results, it performs 74 times slower! Well I ran their same benchmark on my machine to make sure, and it was “only” 26 times slower here, but that’s still pretty bad.
      This said, as they say themselves (point (4) under the results):

      > GEGL does not really focus on batch-style processing — it targets interactive applications, like paint programs.

      This is quite true. The point of GEGL is not to do hyper fast batch processing (though it would be worth improving, I am not saying such a benchmark result is perfectly good!). Also just the init itself is probably a bottleneck. For a better comparison, it would be better to process many files. So I updated their benchmark (only the VIPS C and GEGL script) to loop over images in a folder with 54 1920×1080 PNG images (why this number of files, this size and this format? I had these in a folder on my drive, that’s all! :P) and do the same processing. Now GEGL is down to 7 times slower. That’s still bad but suddenly a little less down the results table (where it was second last when processing a single file). So what does it mean? Right now GEGL is more meant to be initialized once and used for a long running program, not for a 1-time program.

      It is clear there are a lot of work to do on GEGL speed. For instance VIPS makes good use of threads whereas multi-threading is still deactivated by default in GEGL because too buggy.

      GEGL can use OpenCL (so GPU processing) but it is meaningful of course only if you have a proper graphics card with OpenCL support (i.e. not my machine where I ran this benchmark) and if you run operations with an OpenCL implementation in GEGL. Of course I’m not so sure GEGL would suddenly win then but it could probably decrease the gap.

      # The Architecture #

      So what are the forces of GEGL then?

      ## API ##

      VIPS is apparently more of a common library architecture: it has an API (http://www.vips.ecs.soton.ac.uk/supported/current/doc/html/libvips/index.html) with a given set of operations doable on images. That’s it.

      GEGL is more of the modular type. It also has an API of course (http://gegl.org/api.html), but this one does not include any operation on images as you can see for yourself. Operations are separately built (and loaded at run time, which is probably also a speed-killer) modules. GEGL comes up with a whole bunch of operations (http://gegl.org/operations.html#GEGL%20operations) but your program can have its own (GIMP has implemented several GIMP-only ops). You could also create operations separately from any program (which could be installed as packages or whatever) and therefore making them available to any program making use of GEGL, which has a good introspection to detect operations (name, description, parameters, their type and their descriptions… everything to generate a proper UI on the fly).

      So GEGL is more a generic system where you build a graph where each node can be an operation with inputs and outputs. You can exchange graphs, edit them, switch inputs… You can edit and request the re-render of a small region of the image. Part of the graph can be cached so that when you add an operation in the middle, you don’t recompute everything (important for non-destructive processing). In other words, this is a completely different way to see image processing.

      ## Tiling ##

      The VIPS benchmark page explains that VIPS does not use tiles but regions (the difference being, according to this page, that regions can overlap).
      Well I’m not so sure how much it changes. I know that tiles are important on an interactive application, since you don’t want to redo the whole image processing if you changed 1 pixel somewhere. Now I assume you could do this with regions too.

      But that would mean that your API is meant for this. Since VIPS seems more destined to make one-time processing, I’m not sure it has such feature. Since you have used it: can you request a re-render on a region only, after you modified a piece of your image?

      ## Memory ##

      Memory-wise, the benchmark was also in favor of VIPS (well in the original one. In my second version, memory usage was very similar, probably because the image sizes were smaller).
      VIPS explain in their benchmark that:

      > it only needs to keep a few pixel buffers in memory, it doesn’t need to load the whole image. This reduces memory use.

      This probably explains the smaller memory on bigger images whereas smaller image processing have a similar memory use, but also means that this feature does not matter anymore on an interactive software where you are showing the image on screen anyway and need to constantly access its data. So if VIPS does not take care of keeping the data in memory for you, that’s up to you to either constantly reopen/close file descriptors from the disk (which would kill any speed you gained by using VIPS) or keep the image in memory yourself. Then you use a lot of memory and are limited by your RAM. So you can just use VIPS to do computation on huge images (potentially larger than your memory, I guess) and let it throw away data as it goes (you only want the result in a new file). But this becomes a dire problem if you want to be able to keep working on the image for a long time, display it on screen, and such.
      GEGL manages the whole image itself and is not limited by the RAM. Tiles can have various backends, can swap if necessary and so on. This is all managed by GEGL so you don’t have to reimplement memory management for huge images yourself.

      # Conclusion #

      Well I guess that’s it. It looks to me that if you need speed, don’t have too much interaction with the image, don’t need to edit it partially and VIPS features are enough for your use, then it’s the best choice.

      But if you want to go further with a whole framework which manages your operations graphs, allowing you to reuse them easily, as well as your memory, which can be extended easily (with yet unsupported operations), which can use the GPU (when it has OpenCL support), with tiling, etc. then probably GEGL is likely better suited. That’s what it looks like to me.
      Now as I said, I am no expert here.

      As a conclusion, I found this topic from GIMP’s mailing list: http://www.gimpusers.com/forums/gimp-developer/17886-vips-and-gegl-performance-and-memory-usage-comparison
      For information Øyvind Kolås is GEGL maintainer and John Cupitt is VIPS maintainer (so they are the experts). And they are discussing the differences between VIPS and GEGL and explaining why GEGL performs badly on some parts of the benchmark where compared operations are not actually similar algorithmically (with John agreeing that the benchmark is not very fair). Probably an interesting read for you. 🙂

      1. Disclaimer: I am not affiliated by any means to the VIPS project, I’m just an happy user…

        As the author of PhotoFlow, and a long-time user of VIPS, let me clarify a few points about VIPS and its use for interactive image processing:

        – “VIPS is apparently more of a common library architecture: it has an API with a given set of operations doable on images. That’s it.”
        That is actually not correct: VIPS is a framework for developing image processing operations, and provides the infrastructure for running the algorithms in a multi-threaded and memory-efficient way. It provides a set of built-in operations, however nothing prevents the user to extent the code with custom operations. Actually, each tool in PhotoFlow boils down to a VIPS operation, and many of them are custom-made or “assembled” from lower-level built-in operations. Like GEGL, VIPS allows to generate a node-based processing graph that can be easily re-arranged and re-built whenever needed. The stack of layers and layer groups in photoflow is just a convenient UI representation of the internal VIPS-based node graph. When a layer is dragged and moved into another place in the stack, the internal VIPS graph is quickly re-built from scratch to reflect the new layer arrangement.

        – “this feature (it only needs to keep a few pixel buffers in memory, it doesn’t need to load the whole image) does not matter anymore on an interactive software where you are showing the image on screen anyway and need to constantly access its data.”
        VIPS provides some API to keep in memory the portion of the image that needs to be displayed on screen, and automatically re-computes new pixels (and only the new ones) if you change the image region that is being previewed.
        So the memory requirement is limited to the dimensions of the screen, which are usually smaller (and eventually MUCH smaller) than the full image size.

        – “that’s up to you to either constantly reopen/close file descriptors from the disk (which would kill any speed you gained by using VIPS)”.
        No, VIPS has convenient interfaces to transparently read image data from disk buffers (formatted or unformatted). In this case, the disk buffer should contain the whole image, not split into tiles. File descriptors are opened only once.
        The reading from the disk buffer relies on the efficient memory caching of disk data performed by the operating system, and which is likely more sophisticated and better performing than a custom tile-based caching mechanism.

        – “this becomes a dire problem if you want to be able to keep working on the image for a long time, display it on screen, and such.”
        There is actually no problem at all, as PhotoFlow demonstrates 😉

        As far as I understand, the rationale behind using regions instead of tiles has to do with the muti-threaded processing: when using parallel threads with tiles, one has to add some thread synchronisation code to make sure for example that input tiles are fully processed before accessing them, or to avoid having two threads writing on the same tile, etc… This might be one of the reasons why GEGL multi-threading is still buggy.

        VIPS provides some tile caching mechanism, but the recommendation is to limit its use to reduce the thread synchronisation overhead. Instead, one generally uses overlapping regions. Nevertheless, for specific operations one can introduce intermediate tile caches if the overhead due to overlapping pixels is too large. That is something that has to be benchmarked for critical operations (large blurs or other convolutions, RAW processing, etc…) but is generally not needed.

        ———

        I think this is a very interesting discussion, and very relevant for GIMP. Conceptually speaking, VIPS and GEGL are very similar and address similar goals, however from the technical point of view they are very different. Which one is better for interactive image processing is material for debate… PhotoFlow has taken the VIPS way, and it might be interesting to try benchmarking and comparing the performances on large digital images (50 Mpx or more).

        1. Well. I knew I should not have answered since I apparently said a lot of stupid things. But well that was just a “first impression by looking at the website and API”.

          You say it also has a node-based architecture. I could not find anything even motioning graphs or nodes on the API (even checking the index just now by searching these keywords). Do they name these differently in VIPS?

          > I think this is a very interesting discussion, and very relevant for GIMP. Conceptually speaking, VIPS and GEGL are very similar and address similar goals, however from the technical point of view they are very different.

          Actually in the link I gave you in my previous comment, there was a start of “test implementation” using VIPS as the processing backend of GEGL (this was even done by the VIPS maintainer). Well I can see there have been no commit since 2011: https://github.com/jcupitt/gegl-vips
          But the results (described in the README of the github page) were promising.
          Apparently some features were still missing in VIPS to be fully usable in GEGL. I have no idea what would be the status nowadays if such a project were revived.
          Maybe we could end up having some day the best of both world with GEGL depending on VIPS and speeding up tremendously on some operations?

          1. Well, we cannot be experts of everything, right? It is always good to start discussing, and then things get clarified on the way…

            In the VIPS jargon “nodes” are called “operations”, and given that each operation can take as input the result of other operations, one can build a node graph, although this is not explicitly mentioned in the API documentation.

            As for the gegl-vips project, I have recently opened an issue asking about the status and possible future plans… but I think it mostly depends on the interest from the GIMP side. I doubt that John Cupitt will invest time on that if there is no clear demand and commitment from the GIMP side.

            As far as I understand, the VIPS backend involves re-writing the pixel processing code of GEGL nodes using VIPS operations, and this would represent a HUGE work. But I might be wring on that…

    2. “would that be an issue? Should it change to gegl? Are there advantages, disadvantages or compatability issues, with this?”

      There are no issues, the VIPS-based photoflow plug-in works fine with the GEGL-based GIMP. It simply needs to read/write the image data from/to the GIMP GEGL buffer, but then the processing is done with VIPS without any compatibility problem.

      1. Yes it is indeed easy to just plug any other processing system into a GEGL graph.

        Advantages of other software using GEGL are not for making plugins to GIMP. They are mostly for me:

        1/ it will be a lot better if all (bigger or not) software ended up using, hence contributing upstream to, the same graph-based processing software. So now why GEGL and not another? Well obviously I am biased since that’s what GIMP uses. So probably the why. :p
        Now when I hear that Blender is maybe reimplementing their “nodes” again (well someone told me this, but I can’t find much information on this. Didn’t search that well either) with custom code, if that’s true, that’s a little sad. It would be so much better if they used GEGL and whatever they are not happy with, they simply contribute patches to GEGL itself. GEGL, same as GIMP, could really benefit from more developers and would be even better very fast if many projects were contributing.

        – Sharing buffers: one of the feature I wish to really see in action some day would be buffer-sharing between applications. I found this old interview (http://libregraphicsworld.org/blog/entry/mypaint-and-gegl-porting-evaluation-begins) which explains this:

        > Øyvind Kolås (lead developer of GEGL — LGW) has said that GeglBuffer is designed with sharing between multiple processes in mind. So working on a single layer in a document from two applications should be possible with buffer sharing.

        So yeah I would definitely dream of a file opened in Photoflow (for instance! :P) and you want to do the kind of editing that is not possible in Photoflow but is in GIMP (note: it could be the opposite. whatever), then you open GIMP from Photoflow sharing the same GEGL buffers (which means not even using more memory, except for the software binary’s memory), you edit in GIMP, and it is all directly visible in Photoflow as well.
        For multi-layer, it can become tricky (the interview says) and I think nothing has been done about this yet, but that’s mostly because there is no other project which tried it out with us yet. If there was, it would be time to work together on a new format to pass document structure (probably working with OpenRaster?), and such.

        This kind of work would be great. Basically more communication between Free Software would be worth a try (not speaking of team communication, but really software which communicates data to each other) and would simplify a lot of people’s workflow.

        – Sharing graphs easily between applications. So you can start a work in an application and continue it in another (once again using good points on every application). See this for instance (especially the end of the news): http://www.jonnor.com/2015/01/imgflo-0-3/

        Basically it is not about GIMP. I look at the big picture. As user, working with Free Software on graphics and video is sometimes a pain in the ass when passing from one software to another. There is a lot to be done here, format-wise, protocol-wise…. And of course having a common graph and buffer framework would be another good start.

        1. Concerning the interplay between PhotoFlow and GIMP, for the moment I ended up with a different mechanism, which I’ll try to briefly explain.

          The PhotoFlow GIMP plug-in is non-destructive, meaning that all edits are applied on-the-fly without modifying the initial pixel data. When launched, the plug-in gets the image buffer of the selected layer from GIMP and uses it as the initial pixel data. Then you can add adjustment layers like curves, blurring, sharpening, wavelet decomposition, etc…

          When the plug-in is closed, it will send the result of the processing back to GIMP as a new layer on top of the input one. However, the plug-in will also store in this new layer the editing configuration used to generate it, in the form of an XML-formatted buffer that gets stored in the layer meta-data.

          If you re-run the plug-in the layer it previously generated, it will detect the presence of the meta-data and give you the choice to resume the previous edit. In this case, it will read the input from the previous layer and re-apply all the editing steps described in the configuration meta-data, thus re-creating the editing environment.

          You can see that in action in this screencast: https://youtu.be/945OnK93C1g

          What do you think? Does it make sense?

  3. GUI: Tool-settings and other settings need to take up less space and look better then they do now and the size of the tool-bars needs to be scalable. That would give a better and faster work flow with more canvas area which means less panning, scrolling and better view of the work.

    Looks like the tabs now takes up less space, good work!

    Tools: Vector tools needs to be added. Perspective tools/rulers needs to be added that let the user set perspective points and have a system that captures the drawing of lines in the direction of the perspective points. A layer color or a color filter for layers would also be nice as it makes a similar layer stand out from another.

    Nice with Symmetry painting. Does it include symmetry erasing?

    1. Hi,

      > GUI: Tool-settings and other settings need to take up less space and look better then they do now and the size of the tool-bars needs to be scalable. That would give a better and faster work flow with more canvas area which means less panning, scrolling and better view of the work.

      Yes lot of things can and should be done. But this all have to be properly researched and specified.

      > Looks like the tabs now takes up less space, good work!

      I don’t think tab size has changed since 2.8. Maybe through the theme, but then not that much (thumbnail sizes, in tabs, are the same, I think).

      > Tools: Vector tools needs to be added.

      GIMP has vector tools already (we call this “Paths” in GIMP). They are not as advanced as in a proper vector graphics editor though. Not that we don’t think it would be useful but since there already exist good Free Software for vector graphics (like Inkscape), and also because we are not that many developers, this is not in our priority list right now. We prefer to redirect people who want to do advanced vector editing to Inkscape for the time being.
      Now if someone comes up with very cool patches to improve our vector capabilities in GIMP, we are not against it at all and would welcome these patches with pleasure!

      > Perspective tools/rulers needs to be added that let the user set perspective points and have a system that captures the drawing of lines in the direction of the perspective points.

      Your propositions make sense. We’d need to set proper specifications though to make sure how such tools or rulers would work in details and for every use case.

      > A layer color or a color filter for layers would also be nice as it makes a similar layer stand out from another.

      There are several “filters” (nowadays reimplemented as GEGL operations) for coloring, like “Colorize”, “Levels”, “Color balance”… Aren’t they good enough? Or maybe I am missing something.

      > Nice with Symmetry painting. Does it include symmetry erasing?

      Yes. Any painting tool can benefit from symmetry. And the eraser is a painting tool (well in code paint of view).

      1. >> GUI: Tool-settings and other settings need to take up less space and look better then they do now and the size of the tool-bars needs to be scalable. That would give a better and faster work flow with more canvas area which means less panning, scrolling and better view of the work.

        >Yes lot of things can and should be done. But this all have to be properly researched and specified.

        Over many years I have talked to many people about the Gui of Gimp and no one can stand to work in it thanks to the Gui. It simply scares people away. Many who stays, like me, tries to costumize the looks of it as much as possible. But it’s not enough. Maybe a tiny bit better with the new version. Gimp is my second or third editor and worse as drawing app. My point is, it’s better to do something even if to start with just tightening it up a bit.

        >> Tools: Vector tools needs to be added.

        >GIMP has vector tools already (we call this “Paths” in GIMP). They are not as advanced as in a proper vector graphics editor though. Not that we don’t think it would be useful but since there already exist good Free Software for vector graphics (like Inkscape), and also because we are not that many developers, this is not in our priority list right now. We prefer to redirect people who want to do advanced vector editing to Inkscape for the time being.
        Now if someone comes up with very cool patches to improve our vector capabilities in GIMP, we are not against it at all and would welcome these patches with pleasure!

        I think I need vector tools in the same app I do the rest of the drawing. I will test the Paths tool someday and maybe do some writing why it does or doesn’t work for me. If I was a programmer I would fix or create things that I think are missing, but the only thing I can contribute are experience from how I work and what I need to create better and faster.

        >> Perspective tools/rulers needs to be added that let the user set perspective points and have a system that captures the drawing of lines in the direction of the perspective points.

        >Your propositions make sense. We’d need to set proper specifications though to make sure how such tools or rulers would work in details and for every use case.

        Thanks. Look at Manga Studio and Open Canvas. I think Autodesk Sketchbook have a similar tool in Perspective Guides.

        >> A layer color or a color filter for layers would also be nice as it makes a similar layer stand out from another.

        >There are several “filters” (nowadays reimplemented as GEGL operations) for coloring, like “Colorize”, “Levels”, “Color balance”… Aren’t they good enough? Or maybe I am missing something.

        I’m not sure what you mean. What I’m talking about is a simple toolbar switch that turns the active layer content blue. Press the button again and the layer is back to normal. When active, another button let’s you change the layer color. This feature is in Manga Studio 5 and it’s good for tracing and drawing something over another layer. Without it I sometimes have a hard time knowing what content is on what layer.

        >> Nice with Symmetry painting. Does it include symmetry erasing?

        >Yes. Any painting tool can benefit from symmetry. And the eraser is a painting tool (well in code paint of view).

        Nice. Manga Studio does not symmetry erase.

        Is there a way to support Gimp with one time donations?

    1. Seamless clone uses the clipboard data. In other words, you first copy (or cut) some image/selection (with Ctrl-c or Edit -> Copy menu), then you just click with the tool in your target image where you want to “clone” the copied data.

      Now there is a reason why it is in the “Playground” (i.e. deactivated as default), and the first one is that it is working but slow as hell, if I remember well. So that’s a cool PoC but hardly daily usable on huge images. :-/
      Unfortunately we are still hoping that the contributor who started it (and was telling us that it could be sped up at least 10 times) comes back but of course the best course of action were if someone interested could step up and propose a patch.

  4. The most important thing I want is GTK3.

    Having a sane interface that matches my dark theme and markets the app as a professional utility is so essential to me.

    I show up in multi million dollar facilities and if I open GIMP I’m embarrassed that it still looks like it’s from 2002.

    1. I agree. I am really looking forward to it. Some work has already started about this, but really the basics only (having the code compiling basically). The real work will start as soon as GIMP 2.10 will be out. Then we will target for GIMP 3.0, which will be GTK+3-based.

  5. Hi, I just want to say thanks for symmetry mode with tiling. It has been a sorely missed feature for a very long time. Nice job!

  6. Hi.
    I am using 2.9.4 but have not been able to get the darktable integration to work at all.
    I have tried it on both DNG and ARW files. I choose open, select the file and then tell it that it raw image data but still i just get a garbled image. Darktable doesn’t open.
    Am I doing something wrong.
    Regards
    Adam

    1. Darktable must be version >= 1.7 and in particular have lua support enabled. Unfortunately it seems some Linux distribution would build darktable without lua support (this is at least the case for Fedora 23. Hopefully they enabled the support in Fedora 24 but I have not upgraded yet).

      To check if this is your case, run:
      $ darktable –version

      In the output, you should read “Lua support enabled”. Otherwise it won’t work.

  7. Well it’s taken them years to get to 2.9 from 2.8 and still no adjustment layers still no recordable actions like photoshop and other programs have, so they introduced symmetry mode, big deal something more useful like being able to record your most used set of actions and play them back is much more useful. Other programs have had this for more than a decade.

Comments are closed.