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 ?
I am using the v2.4.4 final release from git.
I also cloned the latest version of the CImg repository from framagit and attempted to compile the examples with MSVC 2017 and 2010.
The default command quoted below compiles on both versions of MSVC.
cl /W4 /wd"4127" /wd"4311" /wd"4312" /wd"4512" /wd"4571" /wd"4640" /wd"4706" /wd"4710" /wd"4800" /wd"4804" /wd"4820" /wd"4996" /Ox /Ob2 /Oi /Ot /c /EHsc /D "_CRT_SECURE_NO_WARNINGS" /I"\Include" /I"..\\" CImg_demo.cpp
But if that command is changed to build CImg with OpenMP.
cl /openmp /Dcimg_use_openmp /W4 /wd"4127" /wd"4311" /wd"4312" /wd"4512" /wd"4571" /wd"4640" /wd"4706" /wd"4710" /wd"4800" /wd"4804" /wd"4820" /wd"4996" /Ox /Ob2 /Oi /Ot /c /EHsc /D "_CRT_SECURE_NO_WARNINGS" /I"\Include" /I"..\\" CImg_demo.cpp
Both MSVC versions fail with errors due to the fact that CImg is using OpenMP 3.0 and MSVC only supports OpenMP 2.0.
C3005: 'collapse': unexpected token encountered on OpenMP 'parallel for' directive
As mentioned in the posts above, even after fixing that error in the header you still have the issue that OpenMP 2.0 does not support for loops using pointer indexers.
I do not expect you to change CImg to support OpenMP 2.0, the fact MSVC does not support OpenMP 3 and later when GCC and many other compilers do is something that Microsoft needs to fix.
I am building the Release version that is stripped during linking, I also checked to make sure that Qt and the other binaries were stripped.
The difference in size between the Gimp and Paint.NET downloads is due to the fact that the Paint.NET plugin download has to include libpng, zlib and all of the other Qt dependencies that are already present as part of the standard Gimp installation.
For some reason Qt and its dependencies are smaller when built by Visual C++ using VCPkg.
I guess that is because you need to define the macro cimg_OS=2 to avoid CImg.h trying to parallelize loops that use pointers. I’ve done changes recently to ensure it compiles on Windows with OpenMP 2.0, instead of OpenMP 3.0.
I can ensure I’ve compiled G’MIC on MSVC with /openmp enabled, after I did the changes.
Same here. We provide all the required .dll with the installed and .zip package, as the GIMP plug-in is installed in its own directory, and we want to avoid dll conflicts. Qt is not used in GIMP, so we provide it as well (and it’s quite big as you say). Anyway, we still have an installer around 25-30 Mb.
You must be using a more tolerant version of MSVC than 2017.
Even after setting the cimg_OS=2 define, MSVC throws a number of errors when it finds more OpenMP 3 directives.
Any parallel for collapse directives (such as line #13121) trigger an error.
I managed to fix those with by replacing it with the following define on MSVC.
#define cimg_openmp_for_collapse(x) parallel for
The remaining errors I encountered were due to a few ‘for’ loops that use unsigned integer indexers (such as lines 29702 and 34068).
After commenting out the OpenMP statements on all of those lines it finally was able to compile.
That’s interesting, thanks for the details.
I’ll then also remove the collapse() directive for Windows, when using MSVC.
It’s a bit a pity MSVC doesn’t support collapse(), as it is a part of the OpenMP 2.0 standard.
I’ve just tested once again, with Visual Studio 2012, to be sure I didn’t forget anything.
I’m using these compilation flags:
/GS /W4 /wd"4127" /wd"4244" /wd"4311" /wd"4312" /wd"4512" /wd"4571" /wd"4640" /wd"4706" /wd"4710" /wd"4800" /wd"4804" /wd"4820" /wd"4996" /Zc:wchar_t /Zi /Gm /Od /Ob0 /Fd"x64\Debug\vc110.pdb" /fp:precise /D "gmic_build" /D "gmic_main" /D "gmic_is_parallel" /D "cimg_display=2" /D "_CRT_SECURE_NO_WARNINGS" /D "_MBCS" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /MDd /openmp /Fa"x64\Debug\" /EHsc /nologo /Fo"x64\Debug\" /Fp"x64\Debug\gmic.pch"
Everything seems to compile fine:
What I don’t understand is actually this page : c++ - omp for with collapse clause is not compiling - Stack Overflow
says that collapse() is an OpenMP 3.0 directive (not 2.0 as I thought).
So if MSVC is inly supporting OpenMP 2.0, why did I succeed in compiling G’MIC with the latest CImg code ?
OK, so I’ve followed your suggestions, and did some changes in files CImg.h and gmic.cpp to only use OpenMP 2.0 directives when compiled with MSVC.
@PDN_GMIC, could you check my changes and tell me that everything is OK with the current version from the git ? Thanks!
It looks like your command line may be missing the /D "cimg_use_openmp".
It compiles after fixing one more ‘for’ loop that was using an unsigned int (line 47289).
With that fix it looks like you will be able to close issue 7.
Ah that’s it, thanks , silly me !
I’ve been able to make the changes this morning. Along with the recent optimizations on the patch matching algorithm done with @heckflosse, that seems to be a good reason for an official update to new version 2.4.5