Feature Request: Rectangle() function akin to polygon. Or maybe a way to define outline thickness and whether it’s inside polygon or middle or outside. See my G’MIC thread on the latest post to see why I want that. It’s a little harder to do stack polygon to create border. I think I like the second idea better now to think of it.
In G’MIC (not sure in Cimg / math interpreter - check yourself), rectangle is drawn by polygon. I would suggest you draw lines based on the coordinates you have. See linethick to investigate how to make lines have thickness.
For rectangle, to stimulate dilate in my use case, all I needed was to subtract, and then I made my recent filter 9 to 17.5 times faster. I’ll see how I can stimulate outline in the way I’m thinking of akin to Illustrator when I get to that though I think adding outline options would be much easier and less complicated.
In the math parser, you can still write:
rectangle(x0,y0,x1,y1,opacity,color) = polygon(4,x0,y0,x1,y0,x1,y1,x0,y1,opacity,color);
Yes, that was what I was getting at. Follow the example of G’MIC in terms of the rectangle and thickline commands, using as many base functions as possible.
EDIT: All resolved. It didn’t came to my mind to use the slash. Still on fixing the issue with arg with color space conversion though manually.
Bonjour,
Here are 2 problems with the GMIC-3.0.0_pre Win 64 version of October 17/18 :
-
The libjpeg-8.dll is not in the gmic_qt_win64.zip archive.
-
The operation of ‘Minimal Path’ demos of G’MIC CLI is very slow and/or bad.
Will be fixed in next pre-release.
Fixed after gmic update.
Thanks!
Bonjour et merci pour la réponse,
The latest version of ‘GMIC-3.0.0_pre-QT-WIN64’ save only in JPEG format. An error report is reported : https://github.com/c-koi/gmic-qt/issues/117
Linking gmic cli with latest opencv (4.5.4 from MacPorts) for “dc” and “apply_camera” there is a new error message from opencv, still it works. This is on MacOS 11.6. a git build of gmic cli.
gmic dc
[gmic]-0./ Start G’MIC interpreter.OpenCV: Couldn’t read video stream from file “check_opencv.mp4”
[gmic]-0./ Open camera stream viewer.
[gmic]-0./ End G’MIC interpreter.
During compilation there are lots of warnings, e.g.
In file included from gmic_cli.cpp:51:
In file included from ./gmic.h:247:
In file included from ./CImg.h:427:
In file included from /opt/local/include/opencv4/opencv2/opencv.hpp:52:
In file included from /opt/local/include/opencv4/opencv2/core.hpp:58:
/opt/local/include/opencv4/opencv2/core/mat.hpp:2504:5: warning: use of the ‘nodiscard’ attribute is a C++17 extension [-Wc++17-extensions]
CV_NODISCARD_STD static UMat eye(Size size, int type) { return eye(size, type, USAGE_DEFAULT); } // OpenCV 5.0: remove abi compatibility overload
^
/opt/local/include/opencv4/opencv2/core/cvdef.h:718:32: note: expanded from macro ‘CV_NODISCARD_STD’
# define CV_NODISCARD_STD [[nodiscard]]
^
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