Thanks @KaRo , but it seems the warnings occur directly in the OpenCV include files, so nothing that can be fixed directly from the G’MIC/CImg source code. The simple fact that we include those headers will trigger these warnings.
Question, is it a bug if * outputs image faster than : when using JIT compiler? : lags a bit in output.
Any chance you provide a simple enough example ?
My first tests do not exhibit this behavior:
$ gmic sp lena,4096 tic f ":x*cos(y)+y*sin(x)" toc tic f "*x*cos(y)+y*sin(x)" toc
[gmic]-0./ Start G'MIC interpreter.
[gmic]-1./ Input sample image 'lena' (1 image 4096x4096x1x3).
[gmic]-1./ Initialize timer.
[gmic]-1./ Fill image [0] with expression ':x*cos(y)+y*sin(x)'.
[gmic]-1./ Elapsed time: 0.415 s.
[gmic]-1./ Initialize timer.
[gmic]-1./ Fill image [0] with expression '*x*cos(y)+y*sin(x)'.
[gmic]-1./ Elapsed time: 0.41 s.
No. It’s not the timer result that differs. It’s the preview that lags. I actually don’t know why it happens, and it doesn’t happen all the time. I think it happens when my CPU is more active with other application, and if it does, I can show you a video of it as I will record it. Right now, it isn’t happening.
Do you mean display? Are the images/data identical but the times for the windows to pop up and display are different? I ask because the time depends on the data being displayed. Even a slight blip would change things.
Yes, display is exactly what I mean. Yes, the images/data are identical.
compiling got this
./gmic/src/gmic.cpp:2050:10: fatal error: gmic_stdlib_community.h: No such file or directory
#include “gmic_stdlib_community.h”
Give me a clue please
Does this happen when compiling the plug-in or the cli tool ? (or something else?).
Maybe a make clean cli in the gmic/src folder could fix the issue.
There is actually an issue for the plug-in. I’ve created a pull request for that : https://github.com/c-koi/gmic-qt/pull/120
This can be fixed easily, just by $ make gmic_stdlib_community.h in subfolder gmic/src, before compiling the plug-in.
It is Gimp plugin for kubuntu 18.04 / gimp 2.10.22 appimage
and make gmic_stdlib_community.h in subfolder gmic/src works very nicely
thank you very much
1 Like
This embeds the updatexxx.gmic file into the compiled plugin. Is that correct.? Seems to be, if I delete that file. However using the interface ‘update’ still downloads the update300.gmic file. Is this just a ‘legacy’ feature or is the file needed for future ‘small’ tweaks?
This is correct. Now, every plug-in user will get all community filters by default, not only those defined in the stdlib.
Could there be a nice way to reference an “image variable” in a command, as if it were an image in the stack?
For example, this is something I don’t think is currently possible:
sp +mirror x
store. my_img_var
add[0] $my_img_var
Yes, obviously you can restore the image first with i $my_img_var and store after. But what I’m thinking about is storing non-image data structures in a way which can easily be passed to other commands which know about it. I suppose the general principle is expanding the use of images as variables, outside of the image stack.
Edit: perhaps multiple image stacks is out of the question too? 
It’s currently not possible indeed, and I’m not sure that would be a good thing after all.
I need to think about it
I clearly see pros and cons. But cons are more ‘technical’ reasons (so maybe not good ones).
A question, is it possible to implement circular dial for gui version of gmic?
Two One apparent bug related to display windows:
- I’m probably being stupid, but I can’t hide the mouse pointer with
cursorfor anything other than window 0 -
Fullscreen mode only: occasional corrupt display when switching between images on a single window (e.g. window 0). This one needs a better bug report, but it looks like a threading problem sometimes still displaying pixels from the previous image. Could also be display driver problem though, so I need to test on other machines.
Update regarding fullscreen problem (it’s my display driver):
I tested on another machine, it does not happen. Weirdly it’s only when the resolution is exactly that of the display, reducing by even 1px (e.g. 1919) makes it go away. Here is a test line if anyone else cares to test it (obviously replace with your screen native resolution):
gmic repeat 20 sp k. r 1920,1080 w. 100%,100%,0,1 wait done
For screen width, height. This might help - G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Substitution Rules .
Is this on Windows ?
At least on Linux, this seems to work as expected:
bug :
sp lena,256
sp colorful,256
sp earth,256
w0[0]
w1[1]
w2[2]
cursor[2] 0
do wait 100 while 1
opens 3 windows and the mouse cursor disappears only when mouse is over the window containing the earth image.
Will test on Windows ASAP.
Works for me also on Windows (Windows 7).
Works for me on 2.9.9 (win10, pre-210824) as David describes: