After refresh:
Solved. My (old) “user.gmic” file is the culprit. Oh now I feel stupid. I apologize. (Also to @garagecoder)
2 Likes
Don’t feel bad, it’s no problem at all. You’ve just given everybody a solution if they face the same trouble!
And a fix where I do nothing is my favourite kind 
3 Likes
gmicky looks old with the forehead furrows and eye bags in the tinted image.
After looking at What’s New?, this come as part of the list:
- ????/ ??????????
Could be picking up a translation. E.g. ..[Scale2x] appears at least twice (once in ?? and EN).
I have in the prerelease git built an error, not appearing in gmic 2.9.4:
The cmd offended:
=[vertices] {1,t},1,$>
Error message:
[gmic] *** Error in ./input_pinklist/*if/*repeat/*local/ *** Command ‘set’: Invalid argument ‘253.708,1,0’.
[gmic] Command ‘set’ has the following description:
.
.
.
Changing the cmd to
=[vertices] {{1,t}},1,$>
helped! ?
By the way, its in line 192 of my file in gmic-community. It was sufficient to change only the first two set cmd:
=[vertices] {{0,t}},0,$> =[vertices] {{1,t}},1,$> =[vertices] {2,t},2,$>
Interested in this.
I’ve done some changes in 2.9.5 to avoid useless string substitution, and this may be related.
Do you have the simplest possible example that can reproduce the issue ?
That would help a lot ! Thanks @KaRo
test1.txt (2.0 KB)
gmic input_pinklist test1.txt,0
It will/should produce a 3d Object generated from Pink delaunay exec. With “,1” there is a list of images instead. No need for Pink, input_pinklist is gmic base script. Don’t hesitate to improve my list reader!
You have to change update295.gmic , I have added the 2 {}s in my gmic-community file, line 192!
1 Like
Right, I’ve been able to reproduce the issue. I’ll investigate. Thanks !
Latest git build don’t throw the error anymore!
Yes, hopefully, this is fixed.
This was quite harder than expected, so it took me a bit of time to figure out what was going on.
I hope the fix won’t introduce regressions in other places.
- 2021/02/05: Release of version 2.9.5.
I love the new copy to clipboard feature idea. There’s another idea that I had for a while:
A refresh button for individual gui input.
See those U arrow buttons next to min/max number input? That’ll refresh to default.
There is already a filter reset button. I suppose, with @Joan_Rake1’s and your parameter rich (in the dozens!) filters, individual controls make sense.
Not a big fan of this idea.
It would make the interface heavier, while the space for the sliders is already quite small if you want a large preview (and if you don’t have a large screen as it is my case).
Also, the values of parameters often dependent on each other, and having the possibility to reset only one won’t reset the ones that are correlated.
To my knowledge, there were never any correlated parameters with the G’MIC plugin GUI. I would’ve liked a double slider for range parameters. I guess I’d need to make an interactive window GUI somehow, but that seems horribly complicated.
I meant not “explicitely correlated”, but correlated anyway.
It’s actually hard to have completely independent parameters for each filters, even if personnally, I try hard doing so.
Note that it’s actually possible to have explicitely correlated filters, as a filter can always set the values of sliders, with the u "{val1}{val2}" trick at the end of the filter.
Hi @David_Tschumperle, after all those trials with gmic-py I was encouraged to try to build gmic with clang+±mp-11 and opencv4. Besides several warnings of type
/opt/local/include/opencv4/opencv2/core/mat.inl.hpp:542:9: warning: ‘_Atomic’ is a C11 extension [-Wc11-extensions]
CV_XADD(&u->refcount, 1);
the cli was finally build! Actually I see with openMP testing thread max 3 (my four kernels) and similar timing compared to clang+±mp-6.0 build (a bit slower).
What do you mean should I stay with this build method or are there any arguments against?
As long as it works correctly, what could be the arguments against ? 