@David_Tschumperle: can you explain how/when the update gmic file is constructed? Right now the JSON file for 2.9.2 for example contains commands that are not in the vanilla 2.9.2 release of the G’MIC binary, unless I do an update of the filters for 2.9.2 using G’MIC (which in turn generates the update file).
There are two different things:
-
The G’MIC standard lib, which is entirely defined in file
gmic_stdlib.gmic(in main G’MIC repository) , and which contains all the standard G’MIC commands and filters. The commands/filters defined there have a special status, as I ensure they are maintained as long as they are present in this file. -
The community commands and filters, available here : gmic-community/include at master · dtschump/gmic-community · GitHub. The quality of the ‘community’ commands and filters are really variable. There are great things in it, and also all the ‘testing/’ filters (some works, others not). And for those, I don’t ensure a strong maintenance, so they work as long as they work.
This difference of status (and possibly code quality) is the reason why the vanilla G’MIC is compiled only with the G’MIC stdlib hardcoded (in file gmic_stdlib.h).
But of course, to provide all the cool filters present in the community repository, the updateXXX.gmic file is generated from the entire set stdlib+community. When running the G’MIC-Qt plug-in for the first time, the update file is downloaded to make all the filters available. Sometimes, people are behind a firewall and this initial download of the update failed, so they have to do the update ‘manually’ (download the updateXXX.gmic file and put it in the G’MIC resource folder).
The JSON file is also generated from the full set of commands/filters.
The commands parse_cli and parse_gui actually expects you provide them a text file to parse before invoking the parser (usually, with command it filename.gmic). But if no file is provided, they load the local file $_path_rc/update$_version.gmic by default. That’s why the parsing commands return nothing when you didn’t get the update file, from a vanilla G’MIC.
Now it makes sense to me. Thank you for this explanation!
1 Like
@David_Tschumperle
Would it be possible/make sense to have an optional parameter for the update command that also downloads the latest JSON filter file to the local resource directory?
I don’t know… The JSON file is actually unused in G’MIC, so I’m not sure having this option in a command could be useful right now.
This could be done easily, eventually with the command:
update_json:
it https://gmic.eu/update$_version.json
ot $_path_rc/update$_version.json
Wohoo, that is even better if I can do it just from within G’MIC! No change is necessary then, I will just add this command to the OFX plugin start if the JSON doesn’t exist.
The latter (input for parse_cli and parse_gui) could be added in the command description concerning the selected (image) textfile.
Unfortunately, I ran into another problem.
The downloading of a file and the updating of the G’MIC filters all works fine when used from the standalone G’MIC interpreter, but fail when used from within the libcgmicstatic library, since it is not compiled and linked with CURL. As far as I remember, we had to disable this because there was no easy way to link CURL statically with g++. Unfortunately the internal fallbacks by calling wget.exe or curl.exe directly on Windows also fail with errors.
Does anyone have an idea how to fix this so we also have internet connectivity from withing the G’MIC library? I tried switching the linking of CURL to static, but had no success.
Another solution would be to make this download task done by the interface that embeds libgmic ? In the G’MIC-Qt plug-in, this update is done using the Qt API for downloading the file.
I didn’t remember there were difficulties having a static libcurl linked. According to the CURL developer Curl: Re: Curl as static library with dependencies, “Building curl static should “only” be a matter of making all the libraries as static versions and then link with those. In the right order. Specifying all the dependencies correctly.” 
That is an approach I actually wanted to avoid, since I don’t like duplicating functionality and want to keep the usage of the library as simple as possible and without any unnecessary third-party libraries. Also, I think it will lead to confusion and possible problems if the library behaves differently than the CLI version.
Ah, I remember now what the problem with CURL was (and which still persists): MSYS2/MinGW come with a static CURL library that was however compiled to link to the shared nghttp2 library instead of the static one, which leads to all kind of problems down the line.
The solution is to either rebuild CURL yourself (adding the missing NGHTTP2_STATICLIB define in the compilation process), or using the official static prebuilt CURL libraries from here (which are built correctly): curl for Windows
vcpkg provides the “curl” package but compiled with msvcc
msys2 provides the “mingw-w64-x86_64-curl” package which actually contains a fresh libcurl+libcurl-devel+curl sort of mix
This is my msys2 set of packages, except I gave up on msys2 in favour of vcpkg+msvc because my target is to have an ABI compatible python non-pure .dll library for MSVC python.exe intepreters.
I prefer to use Microsoft compilers on Windows natively, but the problem is that G’MIC itself (the CLI and its libs) can only be compiled with MinGW, not with MSVC, so I have to resort to this on Windows. 
Libcurl for MSVC is not a problem, I am even maintain a library package for all common Visual Studio versions myself, both static and shared libs, in all kinds of variations.
Libcurl for MinGW is also not a problem if used as a shared library, only when using the static library you will run into errors, which is a long-lasting discussion as only a tiny flag would need to be added during compilation to fix this. Replacing the Libcurl libraries with the official ones from curl.se in the MinGW lib folder makes the static libraries work.
1 Like
That’s not expected. You recently made me change a few things in the G’MIC source code to make it compile on MSVC. Is there anything else I have to do to make it work with MSVC ?
I’m interested to have G’MIC work on many compilers btw.
Sorry, my wording was not quite correct. Yes, it can be compiled with Visual Studio, but still only with optimisations turned off, as even VS2019 has the bug if optimisations are enabled with the template resolution and stack recursion that exists since almost 10 years now. Not sure about OpenMP, but I think that feature is also still not available in the free editions of Visual Studio.
The resulting G’MIC CLI or lib is therefore awkwardly slow (a factor of 10 up to 100 compared to the MinGW release, which in turn is several times slower than the same compile on Linux).
I am close to giving up compiling of gmic-py on windows, despite my last hopes on finding vcpkg which spares me from the pain of finding & checking the proper msys2’s pacman packages.
Here is a recent failed MSVC build of gmic-py – a very thin wrapper around libgmic, with several C++ related errors.
Related to my wrapping code only:
memcpy maybe needs more types casting on my side
the cimglist_for macro should have been included from gmic/src/gmic.h which includes CImg.h but isn’t
CImg::size does not seem to be found…
libgmic seems to build OK (at least for its intermediate objects)
The related CI build script relying on vcpkg and Python’s msvc-autodetection-setup.py compiling script is here: gmic-py/build.yml at 3c4b4411d38904524a464d658668bd89ba5f9ea5 · myselfhimself/gmic-py · GitHub
I have no problems compiling G’MIC on Windows using either MinGW/g++ under MSYS2 or Visual Studio (using a solution in the IDE or MSBuild). VS2012-2019 all had the problem that no OpenMP and optimisations were supported, so the library was very slow, but that has changed with the latest VS update.
With MinGW, all the required packages are available via pacman, for Visual Studio, I just compile them as needed for the target compiler (e.g. libpng, libjpeg, fftw).
I prefer to use the prebuilt libcgmicstatic.dll and call this from my application code, as it does not have any external dependencies.
I haven’t used CMake, vcpkg or gmic-py yet at all though.
ok… the fact that libcgmic is fully static is interesting… where are its .dlls downloadable on the internet, do they follow the gmic releases? Still unsure of my strategy…
As I said, the library (in dll/lib format) is always included as part of the regular G’MIC binary releases, so in the same download file as the G’MIC CLI binary. Latest release is on the G’MIC download page or here: Download GMIC latest release