Silvio, I've been able to reproduce the problem also on my virtualized machine.
I'm working on a fix.
Thanks again for reporting all these bugs !

Hi Silvio,

I think the bug is fixed now. You can try to download and test the new beta version.
As it seems this beta is becoming more and more robust, I've put it as the default download from the G'MIC plug-in for GIMP page :

http://gmic.eu/gimp.shtml

Let me know if that works for you too !

David.

Hi David,

Sorry for always being "late" with my replies (tests on G'MIC).
At work, we have plenty of computers but they are all 32 Bit systems.
All of them run Windows xp professional (sp 3).
At work, with my jpeg images (usually 4-5 Mb each), G'MIC 1.6.1.0 - 32 bit (installed on Gimp 2.8.14) does not work fine because, quite often, it "goes out of memory" and it stops working.
I can't compress my jpeg because they are pictures of samples (insects, fungi, bacteria etc) and they must stay "as natural as possible" (actually, most of my pictures are shooted as RAW - NEF > 9 - 10 Mb each...).

At home, on the contrary, I have two different 64 bit computers (both run Windows - 64 bit with an Intel CPU I7 and 8 gb RAM available).
I have thus tested today's version (Windows 7 - 64 bit):
- Gimp 2.8.14 - *G'MIC - 32 bit*: everything works fine with the extract foreground tool. I have re-applied this filter (shift+ctr+F) several times in a row and G'MIC always worked fine (no "crash" whatsoever);
- Gimp 2.8.14 - *G'MIC - 64 bit*: once again, everything works fine with the extract foreground tool. I have re-applied this same filter (shift+ctr+F) several times in row. I tested G'mic with jpeg of 7-8 Mb around each.

Tonight, I have even tested the extract foreground filter on Krita 2.9 (stable version, released yesterday) with G'MIC 1.6.1.0.
On Linux (Kubuntu 14.10 - Kde desktop) G'MIC 1.6.1.0 is already quite stable and powerful.
On Windows G'MIC still needs some little fine-tuning: this Krita improvement is planned on the roadmap.
In short, everything worked out of the box with Krita 2.9 - G'MIC (tested on Linux - Kde).
I have tried many other G'MIC filters and they all passed my tests :-)
Needless to say, for Krita users, the most appreciated G'MIC filter is probably the Colorize ( interactive) filter :-)

Once again, *THANKS* a lot indeed for releasing G'MIC for everyone: it is incredibly useful and powerful tool ! :-)

That is good news Silvio,
I've been able to improve G'MIC thanks to your tests and reports.
That is very valuable for me, so thank you again for all your efforts!

@Ronounours
I think there may be a multi-processing problem with Details>Spotify ..see: viewtopic.php?f=8&t=12062&p=163228#p163212

Strange color output with G'MIC's Painting preset. Before, at least the colors matched closer to the original, but now getting teal/green like color.

Yeah; hopefully David figures out what changed. Don't want to go back to 1.6.0.4.

Hmmm; wonder if it's one of the compiled dlls associated with 64-bit G'MIC?

No, it's happening on Linux too (Ubuntu 14.04 x64, Gimp 2.8.14, GMIC 1.6.1.0 x64).

If you use Gimp Colors>Components>Decompose you'll see that the red channel in the output image looks completely different from the other two ..like the histogram levels are all wrong ..anything lighter than dark grey comes out with max red.

The plot thickens..
After playing around with the Painting preset's parameters, I hit Reset and the output image is okay now. But the preview is still wrong! Still shows lots of red.

Thanks for reporting, this should be fixed now (after a filter update).

That it is David. Thanks for fixing this one.

as I said in a previous post, I downloaded and use currently the beta version.
No special tests, simply using it for all my filters.
Today I have a question:
- has something changed in the filter "Op Art"?
I currently use the Gimp-G'MIC interface thus i run each G'MIC filter as a call like

This morning I noticed that -on the contrary of many other G'MIC filters called in a similar way- the layer ID of the layer referenced by the G'MIC command is LOST, and I had to add a Gimp statement to get the ID back.
I say "this morning" because I'm quite sure (let's say: 99% sure) that yesterday also that call to that filter did not destroy the ID, but maybe I'm wrong; in the latter case I'm asking whether there in something special in that G'MIC filter to behave as such, while all other filters I called so far never destroy the layer ID.
Thanks for any support!

David,
did you have a chance to look at this filter? I guess it's one of yours.
Is it possible to have it behave like the others, i.e. without destruction of the layer ID?
thanks

Hi dinasset,

The layer ID is modified when the dimensions of the output image does not fit with the dimension of the input layer, and in this case, the filter deletes the input layer and create a new one (with a new id) to store the result.
When I say 'dimensions', it's not only width x height, it also includes the alpha-channel, e.g. if your input image is RGB and your output image is RGBA, a new layer will be created. If I remember well, the Op-art filter changes the width and height of the image, so it will probably *always* creates a new layer with a new id.

OK, I understand David, thanks!

Hi all,

I've posted new beta binaries of the plug-in today, still as the default downloads, because the beta is already better than the latest stable version 1.6.0.4.
I'm still looking for people wanting to test and report bugs if any !
Download link is here : http://gmic.eu/gimp.shtml

Here are the recent improvements I've made these last days :

- I've cleaned the code base a lot, so the G'MIC engine is more faster and light than before.
- I've improved the way the G'MIC plug-in for GIMP handles layers. The name of the layers are now kept as much as possible, as well as their position, blending mode and opacity (if you apply a filter in-place).
- There is a new 'Verbose (layer name)' mode for the 'Output messages'. It forces the output layers to be set with the invoked G'MIC command. Useful to do copy/paste from GIMP to the terminal for instance.
- The preview window is set automatically to a larger size than 'tiny' (was the default before) if your screen resolution is large enough.
- And a lot of small bug fixes.

Feel free to give a shot!. The compiled binaries for Windows are available as installers for 32bits *and* 64bits architectures, and were compiled with the quite recent g++ 4.9.2 compiler
(so probably with better code optimizations too). This is almost a pre-release version to be honest

Cheers,

David.