Can you check whether 2.4.3 and 2.4.4 used the same ‘CImg.h’ file at the time you build them to compare?
That would explain the equality in speed.
OK, so good news.
I’ve been able to fix the various speed issues I had on Windows, and will release new stable version 2.4.4 of G’MIC tomorrow 
Thanks to @heckflosse for his precious suggestions that permitted to fix this issue.
3 Likes
Thanks, but that’s definitely too much honour. It’s more about 4 eyes seeing better than 2 
1 Like
The two builds were using different ‘CImg.h’ versions.
It turns out that none of my builds were using OpenMP, I had forgotten that CImg requires a separate define to use it.
I am currently fixing compiler errors in ‘CImg.h’ related to the OpenMP support in Visual Studio.
Visual Studio 2017 as of version 15.9.4 only supports OpenMP 2.0.
I managed to fix an error with the ‘parallel for collapse’ directive by changing it to a define that uses ‘parallel for’ on MSVC, but I am still trying to determine how to fix an OpenMP ‘for’ indexer must be a signed integer error in CImg<T>& max(const T& val) (line 25033).
Any suggestions?
Have the pre-released installed now; look forward to the stable update as well (though I’ve not seen any real issues with the pre-release but with OpenMP re-enabled, it may speed up those presets that require it). Thanks again, David and crew.
No unfortunately, I don’t see a “simple” way to do that. I don’t know why MSVC is not able to parallelize this kind of loops (using a pointer as a loop indice), whille g++ does.
Changing all these loops to make them use signed integers as loop indices would be cumbersome, they are plenty of those loops everywhere in the CImg code.
About this: Apparently this was a limitation in OpenMP 2.0 standard.
In OpenMP 3.0, this does not hold anymore : c++ - Why must loop variables be signed in a parallel for? - Stack Overflow
I admit I’m not really in favor of rewriting the code just to be compatible with an older OpenMP standard
1 Like
I do not blame you, the CImg code looks to be fairly complex.
It looks like building G’MIC with Visual Studio will have to wait until Microsoft upgrades the OpenMp version used by Visual C++. 
Well, I’ve started working on this “issue”.
I’ll try making it compile with MSVC and OpenMP enabled.
@PDN_GMIC, so it should be OK now.
I’ve been able to compile the latest version of the G’MIC code with VisualStudio2012 and OpenMP enabled without errors. Only tested the CLI version though.
I’m releasing a new version today, numbered 2.4.4, with all these recent fixes.
Also, we have a small concern. In the Paint.NET forum, we have seen this screenshot:
where it is displayed : Plug-in G'MIC-Qt v.1.0.0.0, Author: null54, Copyright (c) 2018 Nicholas Hayes (aka null54).
We think it would be fair to add the names of the two main developers of G’MIC-Qt, that is Sébastien Fourey and myself to the Author/Copyright fields.
You have indeed done the interface between G’MIC-Qt and Paint.NET, but all the interface and all the filters have been done by us (and it took us years to do so).
Thanks.
Tried last portable QT x64 binaries for Gimp with Stylize filter:
- v2.4.3 rendered it in 4mn51s , in seconds 270.6s
- v2.4.4 rendered the same picture with the same settings applied in just 14.54s o_O
wow… talk about a gain of performances… this is ultra boosted performances !
Thank you very much for this.
( still trying to find time to get it compiled by myself, slowly going on this but will eventually manage to get it done one of those days 
)
PS: I’m not sure if it is supposed to be like this with this filter since it implies a lot of randomized stuff and i never took too much time to test deeply due to long rendering times it needed until now but the results i got are different from one version to another :
2.4.3
2.4.4
Thank you very much for the hard work and making this plugin better release after release
1 Like
How does the result compare to the online service that utilize AI to transfer style that’s the question. If the result are different, is it better or worse? Ultimately, I think the time to generate the result is far more relevant than the little difference in result changes. More usable with slightly worse results beats not usable, but generates better result. Object detection is out of question though.
Posted already at you entry at GIMPChat, David. So far all’s well and fast. Fantastic.
1 Like
Visual Studio requires the /openmp compiler option to be set before it will parse the OpenMP directives.
After enabling that option, I got the same compiler errors due to Visual Studio only supporting OpenMP 2.0.
Although I am curious to see whether the Visual C++ compiler offers any other improvements besides smaller file sizes, investigating that will depend on Microsoft adding support for OpenMP 3/4 in an future version of Visual Studio. 
Just being curious why you need to use MSVS to build G’MIC on windows instead of simply using MSYS2.
I am guessing it has to do with what one is used to using.
I currently use MSYS2 to build the G’MIC plugin for Paint.NET, but Visual Studio offers smaller executable sizes and fewer required DLLs than GCC and MSYS2.
The G’MIC plugin for Paint.NET with its dependencies is around 75 Mb (~30 Mb zipped) when compiled with MSYS2, this drops to ~40 Mb (~15 Mb zipped) when compiled with Visual Studio.
This is less of an issue for Gimp and Krita because they already include many of those DLLs as part of their standard installation.
As mentioned above the main reason I want to be able to build the G’MIC plugin for Paint.NET with Visual Studio is the smaller file sizes, but being able to use the IDE features is a bonus.
Please check that the CImg.h file is really the latest one from the git repo ( make clean should help).
I’ve enabled the /openmp flag and the compilation succeeded (I’m using Visual Studio 2012).
I’m a bit surprised by the difference in size. The plug-in executable we provide for GIMP takes “only” 10Mb (and 28Mb with all dependencies , zipped), and it is compiled with MSYS2.
Have you stripped your executable after compiling it ?