RFC: Non-Destructive Layer Effects/Adjustment Layer Groups Project

Hi all! I’ve put together a GSoC project proposal to implement basic/“essential” non-destructive editing with layer effects and adjustment layer groups. The full write-up is available on GIMP’s GitLab page: Project Proposal: Non-Destructive Layer Effects and Adjustment Layer Groups (#9244) · Issues · GNOME / GIMP · GitLab

I’m interested in feedback on how this should work from a user’s standpoint. If you’re willing to share your thoughts, it’d be much appreciated!


Dang you’re going to be an internet legend when all this is done


Heh! As with the CMYK project, it’s largely building on what’s already there. GEGL can already do this and more - it just needs some focused work I think. Fingers crossed!

I just read non-destructive and:


I would like GIMP to have it. So, I support this.

1 Like

As a user I feel the development of GIMP feels stagnant. But rather than that being a negative comment I feel programs like GIMP and Photoshop have both pretty much got everything they need and that is why there is possibly little momentum. However, adopting the idea of non-destructive editing is a really good sugestion, but I always presumed that is why programs like Darktable have such sluggish processing times. Would non-destructive editing make GIMP sluggish?

As for adjustment layers in Photoshop I rarely used them because they were very limited in what could be corrected and I rather chose to stick to layers and masks to make my edits sort of non-destructive. However, working in Darktable I feel the use of multiple instances of modules such as exposure is in principle like adjustment layers and I have come to embrace that method of working.

So a big YES from me and lots of thanks if you pull this project off. Also many people coming from Photoshop will appreciate adjustment layers.


That’s essentially why some stuff like Clone Layers and File Layers exist in Krita, but even with NDEs, local adjustments has to be done with a destructive layer at some point. I am able to dodge that to some extent with those in conjunction with filter masks (not to be confused with filter layers) in Krita. I personally enjoy how flexible Krita is in the non-destructive department, and ignoring the number of filters Photoshop have, Krita literally have the most flexible non-destructive layer system there is.

Not by itself, but non-destructive editing is inherently sluggish. Still is the standard and that problem will go away with time.


The GIMP team is made up of ~6 regular contributors and has been that way for a few years. That is not very many for one of the older and large code basses in FOSS.

1 Like

Hi! There’s actually a lot of activity in GIMP development right now - but the last items on the 3.0 checklist are rather invisible to the user (fixes for Wayland, porting plug-ins to the new API, etc). Hopefully the results will be visible soon!

As @Reptorian said, NDE is slower than destructive editing (I’ve noticed this with Krita as well). But if you don’t apply any layer effects or adjustment layers, it shouldn’t affect your workflow.

That’s why I can imagine that it would make sense when every non-destructive filter layer has different trigger modes:

  • manual (default) - trigger once the filter is applied, when the filter parameters change, or when an update button is pressed.
  • continuous - run whenever a change at the inputs, e.g. lower layers, is detected.
  • smart - for continuing input change, recompile every once in a while, or when input did not change anymore for a while. The two delay parameters could be derived from measuring the actual complexity/computation time at the initial run.

I am e.g. missing the latter mode in the foreground selection tool, where it is too easy to accidentally block gimp for minutes with every paint stroke.

In a second step, a roi concept could be introduced for some effects, which then run only on the region of interest where the actual change was made. But this is only for effects where the spacial extent can be precomputed cheaply. E.g. colour effects or those with deterministic spacial extent such as blur. Of course, the latter category needs some blending overhead, therefore this may be the last step.

1 Like

I am not knocking the dedicated people maintaining gimp. I hope it didn’t come across that way.

1 Like

I’d rather not have different trigger modes. Sounds like a complexity nightmare.

You mean for the ux/usability or code maintenance?

If because of the latter and the devs decide like this, I agree.

If because of the usability, I don’t. There is imo enough software out there that’s so user friendly by being simple that it does not get the job done. Imo, gimp should be as complex as required for a general purpose image processing tool, and if it eases maintenance, even more complicated.

Anyway, for me, the manual trigger is the most important one, because a free running filter stack could mean a non responding ui too quickly. Everything else I would categorize as nice to have rather than mandatory.

This is what I meant by my earlier comment that both Photoshop and GIMP have all the essential tools already. I feel Photoshop try throwing in a few fancy items to justify a lifetime subscription base but all the really important stuff is already in GIMP. However, if someone is willing to add new and improved features my thanks go to them.

Some notes from someone who has been doing NDE in Photoshop since (almost) the dawn of adjustment layers. We are talking late 90ies here, machines with 2GB of RAM, files with the image layer up to or even more than 400MB - that’s beyond 100 megapixels for you young ones. These days I only do this kind of work for very select customers on a very rare basis.

So, out with the myth first:

NDE with adjustment layers is not sluggish.

It’s faster and less stress on the hardware than working with image layers. The way this was implemented in Photoshop was and still is the gold standard. I hate that software with a passion but this is where I wish that all adjustment-layer-editing application developers would have taken notes.

It. Just. Works.

At the studio I worked and later as a freelancer there always was a need to go back to previous edits, to improve, to change. We have had files with a single image layer and 50 or more adjustment layers each with a mask. We have done massive dodge & burn sessions that way. We even did beauty retouching and skin corrections that way.

The key to the power of using the adjustment layers is the mask on each layer and how you can interact with the masks. Grouping, inversion, show mask, select mask, substract/add selection from/to mask.

Even for rather complex edits all you need are a few basic tools: curves, levels, color-hue-saturation, and so on. And then to work on the masks: gradients, selection with feathers and brushes. All with opacity from 1 to 100%.

And this is where I see the biggest challenge with GIMP. All that brush resizing, brush strength setting, layer and mask actions and so - GIMP has these massive underlying problems where focus in one part of the GUI will totally block other parts of the GUI from receiving keystrokes. It’s like working with five different apps at the same time, but there is not even the equivalent of Alt-Tab to cycle through them. It’s a pain.


Thanks a lot for your insight! Another person in the GitLab report also stressed the importance of layer masks with an adjustment layer workflow - it’s something I’ll definitely look into.

While NDE may not be inherently sluggish, I definitely noticed some slowdown when applying layer styles in Krita. I’m hoping GEGL will have good performance, at least with only a few effects or adjustments applied. The split view feature of the current destructive filters works well on my machine so I’m optimistic, but I’ll find out when I’ve got a working prototype.

Hm, but that’s probably not what I meant … I’m not a native English speaker so maybe I struggle to get the message right. With my comment, I was only referring to possible trigger modes of a future gimp nde filter implementation.

My hack raw processor presents a tool chain (equivalent to layers), and I simply implemented an enable/disable checkbox for each tool (layer). Then, most tools have a “do-nothing” default (I can changed that in the properties), so they don’t automatically impose their processing when added to the tool chain. Food for thought…

I think “smart” is not a good idea; will just beg unproductive questions about “why won’t this work?” when the smartness kicks in…


When Gimp does get non-destructive editing my GEGL plugins will be usable within it.

I am very excited about this project

GEGL is faster then Krita. But it will go slow if a dozen or so filters are chained. That is why the layer should be rasterized then non-destructive filters reran and recalculated when the user does an edit.
Adobe and Pixelitor do this in their “smart objects”.