Failure to follow the output mode when filtering multiple layers.

This is all under the latest stable release, not the dev version. I did, however, try with the dev version as well and the exact same behavior is still present.

I often use this software as a plugin for GIMP to process a lot of loaded layers and then re-export the layers afterwards. This relies on this plug-in being able to take all visible layers as input and modify them without making new layers so that I can export them all without having to slowly go through and delete the duplicates and rename the new layers to make sense. I’ve been using a rather old version of the gmic plug-in for a while now and decided, randomly, to update it today. My first impressions were pretty great, but quickly faded.

  • First is the fact that it takes a lot longer to load the dialogue now.
  • Second is that it won’t save the check mark as to whether I want to preview the image or not. With a lot of layers being used, the preview takes a lot of time to generate that I don’t want to deal with.
  • Third, and this is the most important one here, the output mode “In Place” works only, maybe, 20% of the time. Most of the time, when output is set to “In Place”, I get new layers anyway. Occasionally it will work properly but, frustratingly, it usually does not do what I am asking it to do.

Now I really would like to return to the old version that worked properly and didn’t take an extra 5 seconds to load itself whenever I wanted to filter a new set of layers but I can’t find the old version anymore. I really need the output mode to work correctly. Everything else is just annoyance. Without a properly functioning output mode selection, I cannot continue with what I am doing effectively.

Hmm even on an old atom netbook it doesn’t take this long for me, so maybe some extra details would help:

How many layers and what image size?
Which operating system & version of gimp?
How much ram do you have, which cpu?

The other thing I wonder is whether it’s essential to use gimp, because it’s possible to process lots of images with gmic from command line (much less overhead).

I suppose it would be possible to do it from the command line, but that robs me of the chance to review the results. I’m not exactly top of the line, but earlier versions of this plug-in functioned properly so I’m unsure why it would break simply due to weaker hardware now. I’m not even filtering as many layers as I have at a time previously.

Number of layers ranges from 2 to 20 layers, no more than 1024x1024 each. I’m just doing a tone enhancement on each layer.

Hardware is a dual core CPU, 2.8 ghz. 4 gigs of ram. Running Windows 7. The output in the plug-in doesn’t indicate that the image ever gets close to that. Older gmic plug-in versions have been able to run upwards of 100 layers, similar or greater resolution, with less capable hardware. I don’t do that anymore because it takes a freakish time to load that many layers into GIMP.

The only thing I’m really worried about is that the output mode doesn’t function properly really. The lack of saving the settings of the filter and/or the preview mode is annoying but hardly a game changer here.

Thanks for the info, very strange indeed! I’ve done some testing with 4 to 6 layers and not been able to reproduce the in-place problem (on linux atom + 2gb ram). Sadly I’ve run out of time tonight so can’t try this on my other windows 7 PC until tomorrow.

4 gigs of ram is you problem, I’d bet. Open the Windodws Task Manager and watch your swap space and ram as you run the commands. If you’re ram gets full and you start swapping, that’s a speed killer.

Hello @Gaalidas,

Thanks for your feedback, it is really interesting.
Maybe there are a few things we have to improve, we have to look at this more closely.
What I can say right now is :

  • We have already noticed that the plug-in dialog takes more time to appear with the new version. We have investigated a bit but haven’t fount anything in the plug-in code to improve that. It seems to us that the reason is the loading of the required shared libraries and we don’t have any control on that part (system-related). We noticed also that this is longer mostly on Windows, not Linux. Once the plug-in has been opened once, then re-opening it i way faster.

  • Remembering the state of the preview check mark should be probably doable, that’s a good idea.

  • Here again, we would be really interested by a ‘minimal’ case that exhibits this issue. I’ve not been able to reproduce this bug so far. How many layers are you using ? Does this happen with a single filter in particular, or with all filters ? Could you describe a step-by-step instruction to reproduce this problem ? Any help is welcome :slight_smile:

  • The ‘older’ GTK-based version of the plug-in is still available, and somehow maintained, you can find it on this download page : Index of /files/prerelease
    Choose the ‘gtk’ suffixed package of your choice. The GTK and Qt versions of the plug-in can both be installed at the same time.

This is also true for the CLI. First time after reboot is noticeably slower. Same with each new cmd instance albeit less so.