I managed to get FFTW3 partially detected somehow, replacing “pkg_check_modules(FFTW3 fftw3>=3.0)” by “find_package(FFTW3 REQUIRED)”
But then for FFTW3 there is a problem similar to this, moving the files like hinted push the thing further but it ends up with same error as on the link at the end, might be fixed one of those days… Or I’ll try the fixes proposed that apparently are not merged yet.
OpenCV however using this method seems to be detected, but i have no more time right now to see if it will work at the compilation step or not, something i’ll try in the next days.
Still a lot to dig for all this but it offers the occasion to learn a bit more.
PS : sorry for hijacking this thread, not sure if i should start a fresh one about compiling gmic with vs2017, might help some others too, idk.
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.
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).
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.
@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 :
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.
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.
)
