Here it is : https://gmic.eu/update293.json
This file will be updated every hour, just like the update293.gmic is.
Great, thanks!
Already put it into my new parser and it seems to work!
Not sure if you can answer this, but any reason why the options for a choice parameter are an object instead of a list/array in the JSON output? Seems a bit weird to me to do it like this :
{â0â, âfirst choiceâ, â1â, âsecond choiceâ, â2â, âthird choiceâ}
instead of this:
[âfirst choiceâ, âsecond choiceâ, âthird choiceâ]
1 Like
No idea, I donât really know anything about JSON except how to format it. I donât use it myself. The output format has been mainly proposed by @myselfhimself, maybe he has an answer for this.
Found one more thing: the parameter type âbuttonâ is not correctly exported to the JSON, it gets set as âunknownâ.
While we are at it, I think there is a mistake in âtemplate.gmicâ in the first example for the âjdoe_aboutâ filter: the last line with the closing curly braces is unnecessary, it does not have a matching opening brace.
1 Like
@Tobias_Fleischer
hello the ids are due to my computer science experience - eg. in html forms where choices are machine-processable keys to be digested by the remote endpoint - and it was my requestâŠ
they are much easier to track than the values themselves⊠by asking for this in the JSON format specification, I also wanted a unique permanent id for each choice string, especially as the choice string are object to change or internationalization
if we were using a list of just values without immutable keys, ids/keys would be there, but implicitly only⊠and gmic-community contributors may think that items are flippable, while some programmatic applications may depend on those ids or implicit indexes
json does not allow for non-string dict keys unless I am mistaken, hence the string integer keys
I hope this is clear and makes sense to you
this is really open to change anyways, as few people use the gmic json output for now
Thanks for your reply, @myselfhimself
Well, I was asking because GâMIC relies on the index, not the string itself, so the string contents of the choices array do not matter at all, only the index does, therefore these lists always have an immutable order. But I donât care much tbh, I now just skip every second entry then when parsing the JSON. 
1 Like
@Tobias_Fleischer the latest compiling setup by @David_Tschumperle for building libgmic is using msys2 ⊠I am trying to replicate the environment for gmic-py the new Python binding for GâMICâŠ
I am struggling on a build error here, after having forced cimg_OS==2 (ie. Windows) within MSYS:
where it seems that gcc does not look up and use windows-version of stdio.h, process.h etcâŠ
If you end up with a satisfactory MSVC setup that I could reproduce in a Github Workflow recipe for a Windows docker host (already packed with Microsoft compiling sdks, envsâŠ)⊠Iâd be glad to to reuse it⊠Here is the recipe I am working on for example
Should be fixed now.
Fixed as well.
never mind, gmic-py now compiles for windows in a msys2 docker⊠I will add missing .dll and we should have something portable and released on pypi.org soonâŠ
fixed in gmic-pyâs build environment too
I have now also set up a new Windows compilation environment with MSYS2/MinGW.
Using the latest 2.9.3pr sources, I get lots of warnings like these when compiling the CLI:
gmic.h:261:8: warning: type âstruct gmicâ violates the C++ One Definition Rule [-Wodr]
gmic.h:261:8: note: type âlong long unsigned intâ should match type âlong long intâ
gmic.h:345:9: warning: type of âadd_commandsâ does not match original declaration [-Wlto-type-mismatch]
gmic.h:473:15: note: a field of same name but different type is defined in another translation unit
gmic.cpp:2657:1: note: code may be misoptimized unless â-fno-strict-aliasingâ is used
As far as I can see, most of these come from the enabled LTO, right?
The generated CLI file seem to work fine (although unfortunately still rather slow/sluggish on Windows compared to Linux).
Iâll check that, but I didnât have these warnings last time Iâve set up the MSYS2 compilation environment.
Iâve installed the latest update for all packages with pacman, then compiled GâMIC once again, and I get absolutely no warnings:
with g++ 10.2.0 from MSYS2.
I am also using g++ 10.2.0 with MSYS2, everything up to date.
I just download the source from the GâMIC website, then change into the âsrcâ folder and call âmake cliâ, just like you did. The only difference is that I also include and link OpenCV, maybe that is causing the warnings. Will test it again later.
Also, a difference is that Iâm using the sources from the âdevelopâ branch of the GâMIC repository, so latest source code for 2.9.3.
Wooooow, big news! I updated my free Visual Studio 2019 Community Edition to the latest version 16.8.1, and it seems this one can now compile GâMIC natively, even with OpenMP support and full optimisations! And it only takes a couple of minutes, just like MinGW/g++. And the speed of the resulting binary seems to be even a bit faster than the MinGW build!
Is there a good performance measurement/stress test I can run with GâMIC? Like a command that requires quite a bit of power, but also does parallel processing if available? Then I could directly compare the versions.
1 Like
Good news!
Yes, all commands listed there can be used for performance comparisons :
1 Like
Weird, I get lots of warnings once I try to compile it like you do. Somehow I doubt just the slightly newer source base you are using is the issue here.
would you agree to paste your cl.exe or other compiling/linking commandsâ output? (for gmic-py)
I use a very fresh Github docker image using windows 2019 for building, but control it in the blind through a .yml file and python optionsâŠ
Have you used the CMake approch for building or just click-based configuration?
I have no problem sharing any information that might be helpful to you
But I donât know what you need exactly. For Visual Studio compiles, I just call msbuild or open the solution with the IDE, then hit âbuild allâ.