GIMP wishlist

I use the GIMP almost every day when making graphics on Linux, and I’ve been doing so for a long time.

Of the top of my head, here is a list of things I wish the GIMP had:

# *Layer grouping*
# *Recovery of unsaved and recently-not-saved files*; there is a temporary swap space, and GIMP should be able to retrieve files from it
# *16-bit/channel support*
# *Easy record & playback actions*
# Refinement of some of the dialogs to save space
# Along with the previous point, possibly a small version of most widgets (small scrollbar, small sliders, etc.), also to save space
# Less default filters & add-on filterpacks (there are so many filters by default, and I only use a small handfull, so it’s sometimes hard to find some)
# Combine some of the filters in a filter browser preview thing, or at least have a consistant preview among filters
# Proper packing of dialogs (resizing totally breaks on most filters, usually in the preview window, but also in other places)
# Layer “comps” (Photoshop added this a couple versions back, iirc — it’s a saved state of layer status including visibility, opacity, and layer mode)
# The ability to save workspaces, as I hate accidently closing my custom layers dialog window group and losing the layout and custom dialog tabs I tossed in there
# Versioning of files would be nice, could possibly be handled outside of the GIMP too
# Compression of XCF files by default, instead of having to do filename.xcf.gz (which, thankfully, *is* handled in the GIMP transparently)

I’m sure there are many more things that could be listed, but these are the features I can think of right off the top of my head.

By-the-way, It has nearly been a decade of the GIMP! Hooray! (:


14 Responses to “GIMP wishlist”

  1. I like some of those too. My #1 would probably be an option to save the current state of the image you’re editing, so that next time you open the file, Undo still works. It’d probably have to be XCF-only, and would definitely have to be disable-able because the file would be potentially much bigger on disk. But I would love to see that implemented.

  2. Tom says:

    Personally im more concernced with 10bit/channel colour, but that is pretty much a side effect of 16bit on most hardware.

  3. Sven says:

    Nothing really now in your list, but let me nevertheless comment on some of your points:

    (2) I don’t see how recovery of unsaved images is supposed to work. The temporary swap space you are referring to is only used if you are actually running out of memory. It is usually not used and even if it is being used, it would be very unlikely to contain enough to even attempt to recover an image from it.

    (5) It would help if you could point to dialogs that need such refinements. Saying that you would like to see some dialogs refined is about as useless as telling us what you had for breakfast.

    (6) You know, there’s a small theme, don’t you? It would probably be possible to improve this theme further and tweak some of widget style properties. Someone just needs to do it.

    (7) This is a maintainance problem. If we had people willing to maintain plug-in packs, then we could do that. But since the whole GIMP project is currently done by a handful of people, plug-in packs would waste the few resources that we have.

    (9) Huh? Please show me what’s broken here. We usually put quite some attention on proper resize behaviour. Of course with so many filter dialogs, there are certainyl some that could be improved. Again, it would help if you could be more specific.

    (11) This could certainly be improved and we discussed exactly this issue last week at the usability meeting over here in Berlin. For now, I suggest you create a copy of your sessionrc file. You can also use named sessions using the –session command-line option.

    (13) There is compression in XCF and it is enabled by default. If someone wants to add a better compression algorithm, that should be easy to do.

    BTW, is your blog a good place for such a wishlist? I think not.

  4. bisho says:

    I would like to add “Filter layers” and “Vectorial objects support” to the bold entries at the top of the list.


  5. Sven,

    First off, I had a nice long reply written up and I was about to click submit when my browser crashed. This is a quick post that should cover much of the same points and hopefully does so well enough, considering.

    Why isn’t my blog a good discussion ground for something like this? It’s what people use blogs for — and many people use Planet GNOME in the same way for things they’d like to discuss. This being said, it’s not the best place for such a list, nor is it pretending to be official in any sense of the word.

    I do know that many (if not all) of these points already exist in Bugzilla (and some have for years), but I wanted to make a list of things that are important to me and then talk about that and see if anyone has any useful comments regarding items on the list before proceeding further.

    You should note, however, that many people in many different communities (such as GNOME, for instance) use their blogs in a similar way.

    This list isn’t meant to be exhaustive. For instance, concerning filter dialogs with issues: there are many, and I plan on documenting some of the issues further. I did mention packing problems, and many things like the blurs, the sharpening, and color to alpha have issues in this regard.

    Thanks for the suggestion in #11; I’ll go ahead and do that from now on.

    I know that XCFs are somewhat compressed already, but using gzip compression makes the file size much smaller. Tuomas and myself both save .xcf.gz files. Jakub does a similar thing, but uses .xcf.bz2 instead (which, while somewhat better compression, is a little slower). Most people (other than us who have used GIMP for so long) do not know about this, however. It should just do the right thing by default.

    The small widgets theme is a work-around. Small widgets need to be implemented properly. I can navigate GIMP’s preferences, but did you know that there are many out there who wouldn’t even think to look in the preferences at all? Even if they did look in the preferences, there are a lot of things in there and it doesn’t make sense to not do the right thing by default. I use a 1600×1200 screen and there still is too much real estate taken up by the GIMP, even with the small theme enabled. Most people are using something like 1024×768 with the defaults.

    The recovery implementation doesn’t really matter to users, but there really needs to be some sort of file recovery feature which saves the user some of the frustration when GIMP crashes.

    If such a list was posted on one of my co-workers’ blogs (such as Tuomas‘, Jakub‘s, or Ryan‘s), would that be just as inappropriate as writing it on my blog? This is a list of requests comes from one of the most long-time and prominent users of the software you work on.

    The whole point of this list is to type up something that is user-focused, with many of the points coming from something that Tuomas, Jakub, Ryan, myself, and many others have mentioned over the years — and discuss it before moving it to some more official place.

  6. Sven says:

    The only problem with having this list in your blog is that it is not likely to be seen by any GIMP developers. You are lucky that I caught it. Apart from that, this kind of feedback is of course very much appreciated.

    However I would have preferred a lot more details. Details is what makes a bug report useful. I could list hundreds of things that I would like to see added to GIMP. But there is not much point in preparing such a list unless I also go into details on each of the points. So I can only hope that you will file detailed bug reports some of the topics in your list.

  7. Sven,

    Totally understandable. I’m planning on providing details in the not-too-distant future. (I have been and still am quite busy with work, travels, dealing with a car wreck, and, now, moving… I will try to address the points I raised above in more detail sometime hopefully soon.)

  8. Good suggestions. One I’d really like to see would be support for Photoshop Layer Effects. It would probably be difficult it implement and maintain (as it’s not a standard or anything) – but it would make work-flow with my Photoshopping co-workers much easier.

  9. Steven: Yes, that’s a great suggestion. It would totally rock to have something like that.

  10. Carsten says:

    Photoshop Layers: isn’t that supposed to be available with gegl ( And I think supporting more than 8 bits per channel shall be in their too. Or is gegl dead?

  11. Sven says:

    No, GEGL isn’t dead, but it is somewhat stalled. Or maybe it’s more accurate to say that it is still in early design stage and that no usable code exists yet. But it is true that we believe that we need some of the ideas behing GEGL in order to be able to cleanly implement layer effects or adjustment layers.

  12. Eric says:

    1. Adjustment layers – they make working with adjustments awesome because you may do two adjustments and then go back and try to change the first one while keeping the second one – not something you can do with undo alone.

    2. PS CS quality RAW plugin

    3. Perhaps second-most crucial to me after (1) is built-in XMP support.

  13. Paul says:

    With reference to recovery.
    What is important is often not the recovery of the image itself but the work involved in doing it. (some of )This information is stored anyway in the history.
    Saving the history on a regular basis for recovery would enable a large amount to be recovered after a crash.
    OK there may be occasions where the information is too large for this to be feasible eg copying a bitmap from the clipboard. I will come back to this.
    This could also be the basis for creating macros/actions(is this already here in Gimp, I have only recently started using Gimp. I think you have to do some script writing to do this sort of thing currently) so that repetitive tasks can be saved to a file to be actioned on other images.
    If the mechanism for actions is used large memory requirements such as clipboard activity can be overcome by bringing up a dialog requesting the source of the data at the required point in the recovery process (or repeated action.) This would enable a designer to develop quickly and simply a library of tools that can be applied to images very quickly.
    I am writing this because I use photoshop at work and the bloody thing has just crashed out losing three hours of work unneccessarily. Which could have been completely recovered just by saving the history since it was all work on paths.

  14. Greg says:

    Since I am licking fresh wounds (I just lost 45min of work isolating an image when Gimp crashed). I would like to see the recovery option as well, or at least a timed save work. I was vigilant on the image before this one, saving every so often but I got wrapped up in the work this time, and now it’s lost 🙁

Leave a Reply