One more question to @David_Tschumperle:
Will the filter list in JSON format be part of each release or at least made available online?
I stumble upon this page:
https://gist.github.com/myselfhimself/f9a2735a98d2ff3b08116cfaf0d20771
There it claims that the JSON list will always be available under:
http://gmic.eu/filters290.json
(or the appropriate version), but this URL gives a 404?
The correct URL is : https://gmic.eu/updateXXX.json, where XXX is the version number with 3 digits. This file is update every hour.
So, current one is: https://gmic.eu/update293.json
Great, thanks!
Since I am on the 2.9.2 sources at the moment, I assume I should only use the update292.json, right? As the interal G’MIC updater will also look up only update292.gmic, since that is the version number it was compiled with.
I have extended the libcgmic library with a function to return the G’MIC version it was compiled with so this information is available to the caller/host and it can load the right JSON file.
Yes, actually the JSON file is duplicated and uploaded for each version number that remains compatible with the latest version. Currently, version 2.9.0, 2.9.1, 2.9.2 and 2.9.3_pre are compatible so they all have the same JSON file (but with different URLs).
OK then I will update my Gist
So happy that someone visits this Gist 
!!
so actually the gmic_version “2.9.0” key value has the meaning of last-compatible version for commands exposed in this json?
if so should not we rename it to gmic_version_min or so?
I am a bit confused with the update process/file itself.
If I run gmic parse_gui on a vanilla G’MIC 2.9.2 installation, the parser runs, but I get no results. I first have to run “gmic update” to actually download the update292.gmic file, then the parse_gui command works as expected.
I always thought the updatexyz.gmic files were for commands that have been introduced after a binary release x.y.z, but that is apparently not the case?
Even older commands like “fx_gb_cfx” will only work after running the update first. Can anyone please enlighten me here?
Isn’t the most current standard G’MIC library included with each G’MIC binary build?
No, it’s actually the version number of G’MIC that produced the json file. It’s not that useful, I admit.
1 Like
@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