That’ll come in useful for 3D rotations with three parameters (i, j, k).
Flagged by antivirus.
The top entries of https://gmic.eu/gui_filters.txt are duplicates of the English.
*** List of filters in the G'MIC plug-in (1111 filters, on 02/08, 22:40) ***
* List of filters, sorted by path:
パターン/ãƒãƒ¼ãƒ«ã‚·ãƒ£ãƒƒãƒå›³å½¢ (command: 'fx_rorschach')
パターン/迷彩 (command: 'fx_camouflage')
フィルムエミュレーション/インスタント [æ¥å‹™ç”¨] (command: 'fx_emulate_film_instant_pro')
フィルムエミュレーション/インスタント [民生用] (command: 'fx_emulate_film_instant_consumer')
フィルムエミュレーション/ãƒã‚¬ãƒ•ã‚£ãƒ«ãƒ [カラー] (command: 'fx_emulate_film_negative_color')
フレーム/フレーム[ã¼ã‹ã—] (command: 'fx_frame_blur')
修復/アップスケール [Scale2x] (command: 'fx_scalenx')
修復/インターレース除去 (command: 'deinterlace')
修復/ホットピクセル除去 (command: 'fx_remove_hotpixels')
修復/補修 [パッãƒãƒ™ãƒ¼ã‚¹] (command: 'fx_inpaint_patch')
修復/補修 [マルãƒã‚¹ã‚±ãƒ¼ãƒ«] (command: 'fx_inpaint_matchpatch')
修復/é€æ˜Žéƒ¨åˆ†ã‚’埋ã‚ã‚‹ (command: 'fx_solidify_td')
修復/Iain å¼é«˜é€ŸãƒŽã‚¤ã‚ºé™¤åŽ» (command: 'iain_fast_denoise_p')
å…‰ã¨å½±/ライトリーク (command: 'fx_light_leaks')
劣化/ã¼ã‹ã— [ガウス] (command: 'fx_gaussian_blur')
劣化/ã¼ã‹ã— [ã‚°ãƒãƒ¼] (command: 'fx_glow')
劣化/ã¼ã‹ã— [回転] (command: 'fx_blur_angular')
劣化/ã¼ã‹ã— [放射状] (command: 'fx_blur_radial')
劣化/ã¼ã‹ã— [ç·šå½¢] (command: 'fx_blur_linear')
劣化/ã¼ã‹ã— [被写界深度] (command: 'fx_blur_dof')
劣化/色åŽå·® (command: 'fx_chromatic_aberrations')
劣化/LOMO 風 (command: 'fx_lomo')
変形/レンズæªã¿ (command: 'fx_distort_lens')
変形/æ£è·å††ç’図法画åƒã‹ã‚‰å¤©é ‚ãƒ»å¤©åº•ã‚’ç”Ÿæˆ (command: 'fx_equirectangular2nadirzenith')
æç”»/ã‚ューピッド (command: 'fx_cupid')
æç”»/グラデーション [四隅] (command: 'fx_corner_gradient')
æç”»/シェルピンスã‚ーã®ä¸‰è§’å½¢ (command: 'fx_sierpinski')
æç”»/ãƒãƒ¼ãƒˆãƒžãƒ¼ã‚¯ (command: 'fx_heart')
æç”»/ãƒãƒ¼ãƒ³ã‚¹ãƒ¬ã‚¤ã®ã‚·ãƒ€ (command: 'fx_barnsley_fern')
æç”»/ボール (command: 'fx_ball')
æç”»/方程å¼ãƒ—ãƒãƒƒãƒˆ [パラメトリック] (command: 'fx_equation_parametric')
æç”»/虹 (command: 'fx_rainbow')
æç”»/雪片 (command: 'fx_snowflake')
æç”»/3D 押ã—出㗠(command: 'fx_extrude3d')
白黒画åƒç·¨é›†/彩色 [インタラクティブ] (command: 'fx_colorize_interactive')
白黒画åƒç·¨é›†/彩色 [コミック] (command: 'fx_colorize_comics')
白黒画åƒç·¨é›†/線画を自動的ã«è‰²åˆ†ã‘ (command: 'fx_autofill_lineart')
色/セピア (command: 'fx_sepia')
色/色を転写 [基本的] (command: 'fx_transfer_colors')
色/色をé¸æŠžã—ã¦ç½®æ› (command: 'fx_select_color')
色/é¸æŠžçš„脱色 (command: 'fx_selective_desaturation')
芸術的/四分木画åƒå‡¦ç† (command: 'fx_quadtree')
詳細/シャープ化 [テクスãƒãƒ£] (command: 'fx_sharpen_texture')
詳細/DCP 霞除去 (command: 'jeje_dehaze')
輪éƒ/å‰æ™¯åˆ‡ã‚Šå‡ºã— [インタラクティブ] (command: 'fx_extract_foreground')
é…列ã¨ã‚¿ã‚¤ãƒªãƒ³ã‚°/シームレス化 [パッãƒãƒ™ãƒ¼ã‚¹] (command: 'fx_frame_seamless')
I asked about the same almost 6 years ago … 
http://gimpchat.com/viewtopic.php?f=28&t=13119
G’MIC 2.9.3 brought an option:
[gmic-qt_293] New translation system has been set up to allow translations of all filter widgets, rather than just the interface widgets.
Can You ask for more details?
I don’t know why and I don’t know what to do. I doubt there is actually a virus. It’s just a bunch of library files and .dll with the G’MIC interpreter included.
AFAIK G’MIC itself is not a virus 
They are actually the translated versions of the filters in japanese.
I may remove them in the future, as we have a new translation system that should avoid duplicating filters when translating them.
Yes, basically, we need help for translating all the strings appearing in filters.
See : gmic-qt/translations/filters at master · c-koi/gmic-qt · GitHub
Files in this folder have been translated automatically, but the translation often sucks. We need help to fix those before being able to activate a particular translation.
The *.dll would do that, which could be used as an attack vector. Based on other threads, we can submit signatures to our antivirus overlords. Maybe @FossHub can help us resolve this issue.
One remark to new “bool” file option.
If I write an image with values [0,255] or [0,1] with “o bool:xxx.cimgz”, it is seemingly not possible to read it with “i xxx.cimgz”, the option bool has to be added!
I see just that writing a file with “o bool:xxx.cimgz” produces a png file, readable by png:xxx.cimgz, where “o xxx.cimgz,bool” results in a well-formed cimgz file!
gmic xxx.cimgz
[gmic]-0./ Start G’MIC interpreter.
[gmic]-0./ Input file ‘xxx.cimgz’ at position 0
[gmic]-0./ *** Error *** Command ‘input’: [instance(0,0,0x0)] gmicList::load_cimg(): CImg header not found in file ‘xxx.cimgz’.
gmic bool:xxx.cimgz
[gmic]-0./ Start G’MIC interpreter.
[gmic]-0./ Input file ‘xxx.cimgz’ at position 0 (1 image 5676x8083x1x1).
[gmic]-1./ Display image [0] = ‘xxx.cimgz’.
[0] = ‘xxx.cimgz’:
size = (5676,8083,1,1) [175 Mio of floats].
data = (0,0,0,0,0,0,0,0,0,0,1,1,(…),0,0,0,0,1,1,1,1,1,1,1,1).
min = 0, max = 1, mean = 0.70745, std = 0.454933, coords_min = (0,0,0,0), coords_max = (10,0,0,0).
that’s not how it should be used.
o xxx.cimgz,bool
is the correct way to use it.
Ok, as I edited just in my message, seemingly “bool:” is anywhere interpreted and written as png!
By the way, the “bool:” produces also a nicely packed image file only some 3% longer than the “,bool” cimgz! (and the pixel values are not [0,1])
Ach, another remark concerning “skeleton”
Two images of size (5676,8083,1,1) need 1420,18 s to process with “skeleton ,”. Some more compared to the cc app “pink skeleton,0,8” with 53,17 s.
Hum. I’m not suprised actually.
skeleton is a custom command based on an iterative Hit-and-Miss transform, which is quite time consuming.
Maybe the pink skeleton routine uses another kind of algorithms (or maybe the same, but as it is compiled, it is faster). I cannot say which algorithm they use.
I am not an enthusiast of programming, still in pink they seemingly use a tricky tree structure called RBT (Red-Black Tree). Michel Coupries explanation is here:
Fonctions pour la gestion d’un arbre rouge et noir
D’apres “Introduction a l’algorithmique”,
T. Cormen, C. Leiserson, R. Rivest, pp. 258, Dunod Ed.
Un RBT (Red-Black Tree, arbre rouge et noir) est une structure de donnes
arborescente permettant l’insertion, l’effacement et la consultation
d’un ensemble d’elements classes selon un ordre total, avec une complexite
O(log(N)) en moyenne pour une de ces operations, avec N = cardinal de
l’ensemble.
I’m pretty sure we could optimize the skeleton command a lot in G’MIC by using another algorithm. It’s just a matter of who wants to do this 
Ja, you are right. Its not only the programming, even worse, greyscale skeletons or thinnings like watershed would have to be discovered by some fantastic gmic filter programmers still. The binary skeleton I have mostly used for time tests!
- 2021/02/09 : Release of G’MIC 2.9.6
Ha! Just when I updated to 2.9.5. Oh, 2.9.6 has one additional false positive.
Considering that the code of the library is exactly the same for 2.9.5 and 2.9.6, this is really strange. The only difference between the two versions lies in the G’MIC-Qt code, not the core interpreter.
Now that MacPorts can install opencv(3) and opencv4, I’ve tried to change over to opencv4. I’m getting linking errors:
-
for whatever reason, cmake does not include the path to the libraries. I have to patch two instances to add
-L/opt/local/lib/opencv4 -
on one of my machines I get a link error that
/opt/local/lib/opencv4/libopencv_videoio.4.5.0.dylibdoesn’t supply symbols of there right architecture (x86_64). However
$ file /opt/local/lib/opencv4/libopencv_videoio.4.5.0.dylib
gives me
/opt/local/lib/opencv4/libopencv_videoio.4.5.0.dylib: Mach-O 64-bit dynamically linked shared library x86_64
1 Like
Hi Marius, for a local gmic cli built (with make) I have to give
OPENCV_CFLAGS="-Dcimg_use_opencv \$(shell pkg-config opencv4 --cflags)" OPENCV_LIBS="\$(shell pkg-config opencv4 --libs)"
to overwrite the Makefile settings.
AND I have to deactivate port opencv at least during build! As I stated earlier, with active both opencv and opencv4 ports, I had wrong header files. Possibly the second error comes from the wrong header files. For my local gmic cli build I do
make -B CXX=clang+±mp-11 OPT_CLI_CFLAGS="-march=native -O3 -flto -fopenmp \$(XSHM_CFLAGS) -Wno-c11-extensions" OPENCV_CFLAGS="-Dcimg_use_opencv \$(shell pkg-config opencv4 --cflags)" OPENCV_LIBS="\$(shell pkg-config opencv4 --libs)" OPT_LIBS="-lgomp \$(XSHM_LIBS)" clean cli
It should not be necessary to deactivate opencv. Both should be installable side by side. This morning I found out that I have to comment out the pkg-config script in FindOpenCV.cmake that finds opencv4 to correctly build against opencv, as opencv4 is the preferred version. I hope that’s temporary, only until I get gmic to correctly build against opencv4.