GIMP 2.9.2 Released, How About Features Trivia?

GIMP 2.9.2 Released, How About Features Trivia?

In a surge of long overdue updates the GIMP team made the first public release in the 2.9.x series. It's completely GEGL-based, has 16/32-bit per channel editing and new tools. It's also surprisingly stable enough even for the faint of heart.

Obligatory disclaimer: I'm currently affiliated with upstream GIMP project. Please keep that in mind when you think you stumbled upon biased opinion and thought you'd call LGW out.

One might expect a detailed review here, which totally makes sense, however writing two similar texts for both upstream GIMP project and LGW would seem unwise. So there: the news post at briefly covers most angles of this release, while this article focuses on features trivia and possible areas of contribution.

The GEGL port and HDR

Originally launched in 2000 by a couple of developers from Rhythm & Hues visual effects studio, the GEGL project didn't have it easy. It took 7 years to get it to GIMP at all, then another 8 years to power all of GIMP.

So naturally, after years and years (and years) of waiting the very first thing people would be checking in GIMP 2.9.2 is this:

First and foremost, 64-bit is there mostly for show right now, although GIMP will open and export 64-bit FITS files, should you find any.

That said, you can use GIMP 2.9.2 to open a 32-bit float OpenEXR file, adjust color curves, apply filters, then overwrite that OpenEXR file or export it under a different name. Job done.

The same applies to PNG, TIFF, and PSD files: respective plugins have been updated to support 16/32-bit per channel data to make high bit depth support actually useful even for beta testers.

All retouching and color adjustment tools, as well as most, if not all plugins are functional in 16/32-bit modes. There's also basic loading and exporting of OpenEXR files available (no layers, no fancy features from v2.0).

GIMP also provides several tonemapping operators via the GEGL tool, should you want to go back to low dynamic range imaging.

Mantiuk06 tonemapping operation

There are, however, at least two major features in GEGL that are not yet exposed in GIMP:

  • RGBE (.hdr) loading and exporting;
  • basic HDR merging from exposure stacks.

This is one of the areas where an interested developer could make a useful contribution at a low enough price in the time currency.

In particular, adding a GEGL-based HDR merge tool to GIMP should be easier now thanks to a widget for using multiple inputs to one GEGL operation (which would be exp-combine).

GEGL operations

Currently 57 GIMP plugins are listed as completely ported to become GEGL operations, and 27 more ports are listed as work in progress. That leaves 37 more plugins to port, so the majority of the work appears to be done.

Additionally, GEGL features over 50 original filters, although some of them are currently blacklisted, because they need to be completed. Also, some of the new operations were written to implement certain features in GIMP tools. E.g. the Distance Map operation is used by the Blend tool for the Shape Burst mode, and both matting operations (Global and Levin) are used by the Foreground Select tool to provide mask generation with subpixel precision (think hair and other thin objects).

Various new operations exposed in GIMP, like Exposure (located in the Colors menu) and High Pass (available via the GEGL tool), are quite handy in photography workflows.

Note that if you are used to "Mono" switch in the Channel Mixer dialog, this desaturation method is now available through a dedicated Mono Mixer operation (Colors->Desaturate submenu). It might take some getting used to.

Mono Mixer

It's also worth mentioning that 41 of both ports and original GEGL operations have OpenCL versions, so they can run on a GPU.

And while immensely popular external G'MIC plugin is not going to become GEGL operation any time soon (most likely, ever), since recently it's ready to be used in conjunction with GIMP 2.9.x in any precision mode.

There are some technical aspects about GIMP filters and GEGL operations in GIMP 2.9.x that you might want to know as well.

First of all, some plugins have only been ported to use GEGL buffers, while others have become full-blown GEGL operations. In terms of programming time, the former is far cheaper than the latter, so why go the extra mile, when GIMP 2.10 is long overdue, and time could be spent wiser?


Porting plugins to use GEGL buffers simply means that a filter can operate on whatever image data you throw it at, be it 8bit integer or 32-bit per color channel floating point. Which is great, because e.g. Photoshop CS2 users who tried 32-bit mode quickly learnt they couldn't do quite a lot, until at least CS4, released several years later.

The downside of this comparatively cheap approach is that in the future non-destructive GIMP these filters would be sad destructive remnants of the past. They would take bitmap data from a buffer node in the composition tree and overwrite it directly, so you would not be able to tweak their settings at a later time.

So the long-term goal is still to move as much as possible to GEGL. And that comes at a price.

First of all, you would have to rewrite the code in a slightly different manner. Then you would have to take an extra step and write some special UI in GIMP for newly created GEGL op. The reason?

While the GEGL tool skeleton is nice for operations with maybe half a dozen of settings (see the Softglow filter screenshot above), using something like automatically generated UI for e.g. Fractal Explorer would soon get you to lose your cool:

Old vs. new Fractal Explorer

The good news is that writing custom UIs is not particularly difficult, and there are examples to learn from, such as the Diffraction Patterns op:

Diffraction Patterns operation

As you can see, it looks like the former plugin with tabbed UI and it has all the benefits of being a GEGL operation, such as on-canvas preview, named presets, and, of course, being future-proof for non-destructive workflows.

FFmpeg support in GEGL

If you have already read the changelog for the two latest releases of GEGL, chances are that you are slightly puzzled about FFmpeg support. What would GEGL need it for? Well, there's some history involved.

Øyvind Kolås started working on GEGL ca. 10 years ago by creating its smaller fork called gggl and using it for a video compositor/editor called Bauxite. That's why GEGL has FFmpeg support in the first place.

Recently Øyvind was sponsored by The Grid to revive ff:load and ff:save operations. These ops drive the development of the iconographer project and add video capabilities to The Grid's artificial intelligence based automatic website generator.

The FFmpeg-based loading and saving of frames could also come in handy for the GIMP Animation Package project, should it receive much needed revamp. At the very least, they would simplify loading frames from video files into GIMP.

New Tools

The new version has 6 new tools—2 stable, 4 experimental. Here's some trivia you might want to know.

GIMP is typically referred to as a tool that falls behind Photoshop. Opinions of critics differ: some say it's like Photoshop v5, others graciously upgrade it all the way to a CS2 equivalent.

If you've been following the project for a while, you probably know that, anecdotally, the Liquid Rescale plugin was made available a year ahead of Photoshop CS5 Extended. And you probably know that Resynthesizer made inpainting available in GIMP a decade before Content-Aware Fill made its way to Photoshop CS6:

But there's more. One of the most interesting new features in GIMP 2.9.2 is the Warp Transform tool written by Michael Muré back in 2011 during Google Summer of Code 2011 program.

It's the interactive on-canvas version of the venerable iWarp plugin that looked very much like a poor copy of Photoshop's Liquify filter. Except it was introduced to GIMP in 1997, while Liquify first appeared in Photoshop 6, released in 2000.

Warp Transform reproduces all features of the original plugin, including animation via layers, and adds sorely missing Erase mode that's designed to selectively retract some of the deformations you added. The mode isn't yet functioning correctly, so you won't restore original data to its original pixel crisp state, but there are a few more 2.9.x releases ahead to take care of that.

Unified Transform tool is a great example of how much an interested developer can do, if he/she is persistent.

Originally, merging Rotate, Scale, Shear, and Perspective tools into a single one was roughly scheduled for version 3.6. This would prove to be challenging, what with the Sun having exploded by the time and the Earth being a scorched piece of rock rushing through space, with a bunch of partying water bears on its back.

But Mikael Magnusson decided he'd give it a shot out of curiosity. When the team discovered that he had already done a good chunk of the work, he was invited to participate at Google Summer of Code 2012 program, where he completed this work.

Unfortunately, it's also an example of how much the GEGL port delayed getting cool new features into the hands of benevolent, if slightly irritated masses.

Internal Search System

Over the years GIMP has amassed so many features that locating them can be a bit overwhelming for new users. One way to deal with this is to review the menu structure, plugin names and their tooltips in the menu etc., maybe cut most bizarre ones and move them into some sort of an 'extras' project.

Srihari Sriraman came up with a different solution: he implemented an internal search system. The system, accessible via Help->Search and Run a Command, reads names of menu items and their descriptions and tries to find a match for a keyword that you specified in the search window.

Searching action in GIMP

As you can see, it does find irrelevant messages, because some tooltips provide an overly technical explanation (unsharp mask uses blurring internally to sharpen, and the tooltip says so, hence the match). This could eventually lead to some search optimization of tooltips.

Color Management

The news post at casually mentions completely rewritten color management plugin in GIMP. What it actually means is that Michael Natterer postponed the 2.9.2 release in April (originally planned to coincide with Libre Graphics Meeting 2015) and focused on rewriting the code for the next half a year.

The old color management plugin has been completely removed. Instead libgimpcolor, one of GIMP's internal libraries, got new API for accessing ICC profile data, color space conversions etc.

Since GIMP reads and writes OpenEXR files now, it seems obvious that GIMP should support ACES via OpenColorIO, much like Blender and Krita. This has been only briefly discussed by the team so far, and the agreement is that a patch would be accepted for review. So someone needs to sit down and write the code.

What about CMYK?

Speaking of color, nearly every time there's a new GIMP release, even if it's just a minor bugfix update, someone asks, whether CMYK support was added. This topic is now covered in the new FAQ at, but there's one more tiny clarification to make.

Since autumn 2014, GEGL has an experimental (and thus not built by default) operation called Ink Simulator. It's what one might call a prerequisite for implementing full CMYK support (actually, separation into an arbitrary amount of plates) in GIMP. While the team gives this task a low priority (see the FAQ for explanation), this operation is a good start for someone interested to work on CMYK in GIMP.

Digital Painting

Changes to the native brush engine in GIMP are minor in the 2.9.x series due to Alexia's maternity leave. Even so, painting tools got Hardness and Force sliders, as well as the optional locking of brush size to zoom.

Somewhat unexpectedly, most other changes in the painting department stem indirectly from the GIMP Painter fork by sigtech. The team evaluated various improvements in the fork and reimplemented them in the upstream GIMP project.

Canvas rotation and flipping

Canvas rotation and horizontal flipping. Featuring artwork by Evelyne Schulz.

Interestingly, while most of those new features might look major to painters, they actually turned out to be a low-hanging fruit in terms of programming efforts. Most bits had already been in place, hence GIMP 2.9.2 features canvas rotation and flipping, as well as an automatically generated palette of recently used colors.

Another new feature is an experimental support for MyPaint Brush engine. This is another idea from the GIMP Painter fork. The implementation is cleaner in programming terms, but is quite incomplete and needs serious work before the new brush tool can be enabled by default.

MyPaint Brush tool

Some Takeaways For Casual Observers and Potential Contributors

As seen in recently released GIMP 2.9.2, the upcoming v2.10 is going to be a massive improvement with highlights such as:

  • high bit depth support (16/32-bit per channel);
  • on-canvas preview for filters;
  • OpenEXR support;
  • better transformation tools;
  • new digital painting features;
  • fully functional color management;
  • improved file formats support.

Much of what could be said about the development pace in the GIMP project has already been extensively covered in a recent editorial.

To reiterate, a lot of anticipated new features are blocked by the lack of GIMP 2.10 (complete GEGL port) and GIMP 3.0 (GTK+3 port) releases. There are not enough human resources to speed it up, and available developers are not crowdfundable due to existing work and family commitments.

However, for interested contributors there are ways to improve both GIMP and GEGL without getting frustrated by the lack of releases featuring their work. Some of them have been outlined above, here are a few more:

  • Create new apps that use GEGL (example: GNOME Photos).
  • Port more GIMP filters to GEGL or create entirely new GEGL operations (both would be almost immediately available to users).
  • Create OpenCL versions of GEGL operations.

All of these contributions will directly or indirectly improve GIMP.

With that—thanks for reading!

Was it useful? There's more:


Leave a comment
  1. Hi Alexandre, thanks for the info here.
    I think you talked about “mipmaps” for faster filters preview in another entry. Is currently some developer working on it?

  2. Thanks for the “immensely popular” Alexandre :)

    Mitch has played a key role to help porting the code of the G’MIC plug-in to use high-bits depth GEGL buffers.
    This was finally almost child’s play with his advices.

  3. Hi,
    seems to be great work on this.
    What I am waiting for is some speed improvement - I couldn’t find any word about this in the text.
    When comparing darktable for example with gimp it takes gimp clearly more than 10 times the time for a preview for a simple curve adjustment of a recent photo in the 16 to 24MPx-Range. This is way too long for such a kind of interactive operation.
    Is there anything significant in the roadmap that would lead to improvement?

  4. Alexandre Prokoudine 02 December 2015 at 10:20 pm

    @YAFU, mipmaps are currently only used in projection and for thumbnail generation. They are still not used e.g. in on-canvas preview.

    @Bernhard, see my reply to YAFU ;)

  5. @Alexandre: thanks. I don’t understand the technology in detail but I learn from your answer that hope for improvement is based on realism rather than optimism :)

  6. Alexandre Prokoudine 03 December 2015 at 6:24 pm

    @Bernhard, well, mipmaps is a common technology that allows to speed up perceived speed of rendering/processing. Basically, software creates at least one smaller copy of the original image you are working on and runs all previews on it. That way you can make a reasonable choice of processing settings without waiting for the whole image to be processed. Meanwhile the full resolution image will be processed in the background.

  7. thanks a lot! (That’s why I love OSS :) )

  8. the builds of 2.9 on windows has better performance.

  9. Interesting. I was following git development but totally missed this.

    Something that is definitely features trivia but you understandably didn’t include (or probably even notice) : All painting tools work in indexed mode too, with the result being automatically quantized to the image colormap. Compositing (layer modes eg Multiply, lowered opacity, etc) also works for indexed images, with quantization to the image colormap being done when the image is merged down.
    And finally, non-binary alpha channel for indexed images is also supported (though I’m not sure if it is exportable yet..)

    Previously, some tools (like color adjustment tools) simply ‘didn’t work’ (gave a message like ‘Colorize only works on RGB images’), whereas others were heavily restricted (clone was always hard-edged; airbrush was also hard-edged, which is not as weird as it sounds but also not very useful)

    AFAICS this is a general result of moving to the GEGL framework. Other filters that were annoyingly specific to input type, like Color To Alpha, now work on all image types too. (c2a wanted RGB images, even though using it on a greyscale image would make just as much sense (convert a B/W lineart to a layer with lines only))

    One question that is probably of more general relevance: Do you happen to know whether the Python interface (PyGimp) has been adapted to allow Python plugins to support high bit depth, yet?


    “Even so, painting tools got Hardness and Force sliders, as well as the optional locking of brush size to zoom.”

    I am curious about this—do you know what Force actually does? When it became an option in the GUI, I tried to figure it out but couldn’t get it to do anything (I initially thought perhaps it influenced hardness of the brush.)

  10. @David Gowers, all good points! I’m generally not a big time user of indexed images (optipng just about covers all I need), so I didn’t cover this part of changes. So thanks for your summary!

  11. Have you tried Pixeluvo? Why can Pixeluvo show realtime previews of the filters (which is immensely useful) and GIMP or Krita can’t come even close? Let me remind you that Pixeluvo is developed by a single guy, so resources are even scarcer at that project.

  12. @Aleve Sicofante, I’m not sure if you even read the article :) No, GIMP does have real-time previews on canvas now. For a whole bunch of filters.

    Also, writing software from scratch is a whole different story. Pixeluvo has been around for at least two years. darktable was usable after a year of its development and had non-destructive editing, mipmaps, 32bit per channel processing, and plugin architecture. And just one developer.

  13. @Alexandre:

    First of all, it’s you who should read criticism with a more open mind and attention to written words. Recheck my post: I didn’t say GIMP or Kirta don’t do so-called “realtime previews”. I said they don’t come even close to Pixeluvo. (I can actually say the DO NOT do realtime previews whatsoever, but in my own particular view, a realtime preview provides full screen/full window video-like fluency while previewing actions. GIMP developers and you seem to use a different definition.)

    Second of all: you’re a blog editor. I suggest you leave that aggressive tone against people who criticize your beloved GIMP. At least if you want some respect from your readers.

    Now on your reply:

    I have not only fully read the article, but have also installed GIMP 2.9.2, only to see those “realtime previews” crawling sadly. Try Pixeluvo and see it performing like 10 times faster (at least) with true realtime (i.e., at some 20 FPS or more) plugin previews. The difference is not just “technical”. The amount of fine tuning you will do to pictures is directly proportional to the speed you get at previewing your actions. It’s easy to adjust a picture with Pixeluvo BECAUSE it’s fast. It’s harder to adjust a pixture in GIMP BECAUSE it’s slow.

    (I’m using a slow computer, a Lenovo T400, for these comparisons. Maybe a last generation Core i7 would blur the differences, but the issue remains: Pixeluvo code is MUCH faster than GIMP’s.)

    I honestly don’t understand what you mean by your second paragraph. If you mean Pixeluvo or Darktable have an advantage over GIMP because they’re young projects, I don’t follow. If that were the case, all GIMP had to do, seemingly, was to start from scratch and leave that 20 year old code behind, right? Can you please elaborate?

    Actually, what really disappoints me is that a 20 year old project hasn’t had the time to grok true realtime previews and fast (pre)processing. I expected exactly that form the GEGL transition, but it’s simply not there.

    On a side note, I don’t quite agree with your description of mipmaps and its use. In my 3D years I learned they were used to overcome moire issues when rendering textures at an angle and far from the point of view (by using a smaller PRE-FILTERED picture of the original texture), but maybe they can be used for viewport acceleration too (although I can’t quite see how).

    The bottom line, anyway, is the GIMP is offering very poor filter preview performance and there’s little reason to even publicize such a poor performance.

  14. Alexandre Prokoudine 11 December 2015 at 5:24 pm

    @Aleve, “Why can Pixeluvo show realtime previews of the filters and GIMP or Krita can’t come even close?” was an ambiguous statement that could be understood in different ways. Now that you explained what exactly you meant, it’s finally clear. Thanks.

    However, I’m afraid that if you keep your patronizing tone, you will soon discover that you talk to yourself only.

    “I honestly don’t understand what you mean by your second paragraph. If you mean Pixeluvo or Darktable have an advantage over GIMP because they’re young projects, I don’t follow.”

    No, darktable doesn’t exactly have advantage over GIMP, because it’s a different kind of software. The principle, however, is the same. When you start anew, you don’t have to make the same mistakes again, and you don’t have to fix a huge amount of code.

    It took darktable a year to become functional software that could be used. It took darktable another 3 to 4 years to become comparable feature-wise to proprietary software of its kind.

    Likewise, it took Affinity Photo about 5 years to get where it is, from scratch. Likewise, it took Krita ca. 5 years to stabilize after all internal changes. Personally, I see a certain pattern.

    So whether you start anew or rebuild inside existing code base, it takes time to either reach feature parity (new project) or rewrite and stabilize (old project).

    The benefit of starting anew is that it’s relatively cheap to build something functional that makes use of new technologies and give it to users. And then, with the right architecture, your progress will be fast. Although it still will take years to become truly competitive.

    To answer another question, Pixeluvo has been installed on my computer for a while, but fails to even launch. How that makes it amazing software I couldn’t possibly tell.

  15. Aleve Sicofante 12 December 2015 at 5:09 am

    I’m using a patronizing tone? LOL Pot meet Kettle, etc.

    (I’ve tried Pixeluvo on a dozen systems flawlessly. Always Ubuntu, though.)

  16. Gimp is getting closer to the Photoshop, but still, I think one online tool ( could be more comfortably.

  17. Gimp has always been my favorite alternative to Photoshop. I’m really excited to see that it’s still getting new features after all these years. Having used Photoshop in the past I can say that Gimp is slowly creating some competition.

    Though lately, I’ve found myself using because of it’s simplicity. Though I’ve just been drawing lens diagrams…

  18. Here is the missing link to the aforementioned FAQ in the CMYK chapter:
    Perhaps you might want to link it to make it easier for readers seeking more information about CMYK support in GIMP.

  19. @aleve-

    Pixeluvo? You’re joking right? Have you actually used GIMP?

  20. I haven’t tried this new release, but it’s seems very powerful. I’m gong to download and try it!!

  21. Hi Alexandre, thank you for this awesome post.

    I really like the new Warp Transform tool.

    Hopefully we will see CMYK support added in the future.

  22. @Aleve Sicofante, sorry but I miss why you really value pointing out that a commercial software beats GIMP on previwes, on this site (“libre graphics”)...

    There could be a ton of other software doing faster previews, out there. Being completely free and sharing the code is a complete, different, tougher game, imho. And, really fast preview code routines could also be patented…

    Of course having benchmarks (even other commercial apps) is always useful, to aim for the best, but the whole point of FLOSS software is about being Free (speech), giving code and choice and share, to learn and improve. Sometimes even best features or performances are included :)

  23. “Hopefully we will see CMYK support added in the future.”

    Yes, but without true CMYK support, GIMP is just a fun toy for me, but I cannot use it for serious productive work. Same problem with Inkscape. I love them both, but I have a workflow that dictates precision, and these tools are just not there yet for the kind of work that will pay me well, unfortunately.

    Why the developers (of both applications) have made this not one of their highest priorities is beyond my understanding.

    I truly wish someone with a lot of dough, like Mark Shuttleworth, could come up with a way to make a FOSS based suite using code from these apps, to create a design suite that can compete with Adobe—not only the actual functionality (which is highly necessary) but also the workflow (Adobe’s CC workflow is unmatched by anyone).

  24. @ brentini
    I’m with you on CMYK support, but I’m sure they’ll add it at some point. There just aren’t that many developers, so these things take time.

    For non-professional work, GIMP is already great as it is imo. Especially if you consider all the cool plugins like Resynthesizer.

  25. Alexandre Prokoudine 26 January 2016 at 5:04 pm

    @brentini, “Why the developers (of both applications) have made this not one of their highest priorities is beyond my understanding.” — because you didn’t read the FAQ that’s being linked to from this article? The explanation is very clear — I made sure that it is :)

    “I truly wish someone with a lot of dough, like Mark Shuttleworth, could come up with a way to make a FOSS based suite using code from these apps” — and he would make a profit on that how, exactly?

  26. This is very long article but I like it very much.

  27. @none: Yes, I have used GIMP for years and still use it.

    @m.ardito: That’s one way to see it. Another way to see it is “a single guy developing an alternative in a couple of years makes an order of magnitude faster full previews than the team behind a 20 year old project”. Open vs closed has nothing to do with it. No patents involved here. Just better development skills.

    @brentini: You’re quite right, but open source people are very picky and get offended quite fast. Don’t ask for anything or you’ll be attacked.

  28. Pixeluvo? You’re joking right? Have you actually used GIMP?

  29. @sua may chieu: I’m pretty sure you can read. Go ahead. I already answered your duplicate post.

  30. Alexandre Prokoudine 04 February 2016 at 11:02 am


    You’re quite right, but open source people are very picky and get offended quite fast. Don’t ask for anything or you’ll be attacked.

    Oh, I dunno. just look at 2.9.x. People asked us for canvas rotation. Done.

    Canvas flipping? High bit depth precision? On-canvas filters preview? Less jaggy interpolation? Better PSD support? Better transform tools? Better color management? All requested by users, all done.

    It’s amazing how many things people get after asking us, “open source people”, and they don’t even get attacked. There’s got to be an explanation to this! :)

  31. @Alexandre Prokoudine

    People asked for those features, got attacked for years, then you finally implemented it. Weird procedure if you ask me.

    CMYK support is in that exact process right now. You will display your arrogance to anyone asking for it. Then, some years from now, you’ll announce it done.

    Maybe GIMP will be an interesting application in another 20 years. People needing to do their work in the interim will look elsewhere.

  32. @Aleve
    Where exactly do you feel offended by ‘the arrogant and picky open source people’?

    To me it looks like misleading expectations. GIMP is not a product one pays for and can then sue the manufacturer if it doesn’t fulfill any empurpled promises. It’s the product of a few enthusiastic volunteers doing the work in their spare time besides work and a real life.
    CMYK is on the roadmap. For known reasons there are other more important things to do, but anyone who is willing to make this feature happen will get help.
    If you are missing something crucial and it fits into the scope of GIMP’s product vision feel free to make things better and contribute:
    You’ll probably find out then that the GIMP people are anything else than arrogant.

  33. @Alexandre Prokoudine

    “Where exactly do you feel offended by ‘the arrogant and picky open source people’?”

    This very discussion is full of it. You have a constant defensive attitude that leads you to attack anyone asking for reasonable features, not just in this particular post/discussion, but all over your blog. (That’s not just you, BTW, it’s a constant in open source development.)

    No one can sue a software developer, be it open or closed source. Not for not doing what’s expected, at least. All the software is released “as is”, including the most popular applications and operating systems in the world. The nice thing about commercial software is that developers work to please users, whereas in too many open source projects (which tend to have no business model at all, hence don’t need to please anyone) the developers seem to work to please just themselves, and it shows through all that arrogance, suggestions to “code it yourself” (like you just did) or “RTFM”.

    Sure, some users may sound entitled (that probably includes me), but that’s just because we expect developers are working for the good of their users (us). That’s probably a wrong assumption.

    Maybe you (the GIMP team) should specifically state that you develop just for yourself and have no expectations to please anyone. It wouldn’t sound nice, but it’s more or less how you sound anyway without explicitly saying so.

  34. Alexandre Prokoudine 05 February 2016 at 1:12 am


    Well, it seems that you understand any response other than “I will do as you say, master” as arrogance towards you and other users. There is nothing I can do about it. There is nothing I want to do about it.

    This website has always been for people with give-and-take mindset and respectful attitude towards developers and non-coding contributors who make free software in their spare time and give it away. I will never repurpose this website for you.

  35. Aleve Sicofante 05 February 2016 at 8:13 am

    WTF? What’s that logic?

    Whatever, Alexander.

  36. Long time coming. All the fantastic new tools make a great software even better!

  37. @Aleve

    Lets play with your argument logic so…

    Taking your logic, Pixeluvo developer is a lot incompetent to still not having an animation system. Why if he prove to be more competent than a team! with fluid interface sorcery!

    Or because it has a limited number of filters compared to gimp…

    Or because It can’t:

    work dynamically over HDR with ocio;
    support sophisticated brush engine;
    do sophisticated color management wit OpenColorIO support;
    it did not have transformation layer (it did not have a sophisticated layer system at all.. (groups, clone, transform));

    And I’m sure I’m letting a lot of features we see in Krita+Gimp pass..

    Just going back to reality, Krita an GIMP are software that have started in a time where those ideas were not a focus (canvas, interface supper responsiveness). Now they have tons of features they have to maintain and that add a huge burden when rebuilding base features like canvas or filters preview system.

    Krita in a example, it is passing by an framework update, an canvas update, mipmap is in test fase, it will turn possible to work much better with huge brushes and canvases, and is adding features (animation being the biggest shift).

    There is nothing to do with “better programmer”, its more a question of focus and all that each program has to offer and support. Wait 10 years and come here to talk about… Things can change…

    In a plain example we have some critic dynamic changes in HDR paint on Krita, they have born with those concepts in mind and are very responsive and fluid. The just have being put on with opengl in mind…

    Locking today all us and every single developer from those projects know it is plain achievable with OpenGL… But on such sized programs it is painful and based on user base requests (at last on krita request lists that I follow), there exist just much more important/interesting/isefull featuresto bring than porting all filters to a fancy OpenGL pipeline now…

    Sure, pixeluvo is a sweet responsive peace of software, that myself for example can’t use for near nothing as a painter (Krita and MyPaint are my bread from day to day), maybe for some cool effects and color correction… Ah yes, Gimp just doo this and much more if I need some hard post paint edit…

  38. I do not like it and I can not adapt to GIMP, but I still have to use it.

Tell us what you think

Submit the word you see below: