@David_Tschumperle is there any problem with the update mechanism?
I don’t see changes in gmic-community reflected in update264.gmic!
I’m still not sure why, but I’ve removed display0 in latest version 2.6.4. I’ll probably re-add it later today.
You can’t change the precision of the sliders. To me, if a slider with a wide value range requires lot of precision, then there is a design flaw in the filter. You cannot be sure what display size your slider will fill. A minimal step for the slider is chosen according to the value range it defines.
I’m not sure I understand the limitations you are talking about.
Anyway here is how the plug-in works : To get the list of .gmic files to parse for filters, the plug-in first invokes the command gui_filter_sources, which returns a list of images, each one being actually a string that contains the path of the .gmic files to load.
$ gmic gui_filter_sources , e "{0,t}" e "{1,t}" q
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./gui_filter_sources/*if/ Set local variable 'local=/home/dtschump/.config/gmic/update264.gmic'.
[gmic]-0./gui_filter_sources/*if/*if/ Import commands from file '/home/dtschump/.config/gmic/update264.gmic' (3668 replaced, total: 3707).
[gmic]-0./gui_filter_sources/*if/*if/gui_filter_sources/ Input image at position 0, with values (104,116,116,112,115,58,47,47,103,109,(...)116,101,50,54,52,46,103,109,105,99,1) (1 image 31x1x1x1).
[gmic]-0./gui_filter_sources/*if/*if/gui_filter_sources/*local/ *** Error (file '/home/dtschump/.config/gmic/update264.gmic', line #22999) *** Unknown filename '/home/dtschump/.config/gmic/gui_filter_sources'.
[gmic]-1./gui_filter_sources/*if/*if/gui_filter_sources/ Input image at position 1, with values (47,104,111,109,101,47,100,116,115,99,104,117,109,112,47,46,103,109,105,99) (1 image 20x1x1x1).
[gmic]-2./ https://gmic.eu/update264.gmic
[gmic]-2./ /home/dtschump/.gmic
[gmic]-2./ Quit G'MIC interpreter.
If a user wants to add its own additional filter sources, there are two options:
- Add a command
_gui_filter_sourcesin itsuser.gmicsource, that adds new sources, e.g.
_gui_filter_sources:
path="/home/user/toto.gmic"
({'{/$path}'})
- Or, add a file named
gui_filter_sourcesin$HOME/.config/gmic(or%APPDATA%\gmic\on Windows) that contains the strings to the new sources:
$ gmic string "/home/users/toto.gmic" o cimg:$HOME/.config/gmic/gui_filter_sources
Also, this is how this should work, but I must admit I’ve not tested it for ages 
This option I tried without success (under Mac gmic 2.6.4.)
Ok I’ll try. The second option works seemingly. Very good, thank you for the hint.
Probably my fault, as I’ve left one useless version of _gui_filter_sources in my community file david_tschumperle.gmic, but I’ve removed it, so it should work after an update.
I should’ve been a lot clearer since I see your point about the sliders themselves having an inherent inability to be precise enough. What I meant was the number of decimal places in the text box next to the slider (which I feel is the value that should be passed on even if in G’MIC it is not like this now). I agree that the slider itself shouldn’t return extremely-precise values if it has a large range since the step size itself would not be able to change, but I’m quite used to having text boxes which allow me to input numbers which have more decimal places.
Another solution that I can think of is having two sliders on the same line with different precisions. It would allow one to input very precise values without even touching a text box but it would also be a problem for smaller display sizes.
What I want is to avoid having to effectively double the lines used in the GUI without having half of them hidden with another option to show them (and doing it in this alternative way would get rid of any compactness when this option is checked).
I’ll forward your concerns to the developer of G’MIC-Qt, maybe he can do something to improve the precision in the value box.
1 Like
@David_Tschumperle Why does extract_region name the result [unnamed]? Necessitates an extra step on my part; i.e., reassigning its name after the command.
The suffix change is a positive one; however, I think I will still do the renaming for backwards compatibility.
Survey: How much compatibility do you aim to keep in your filters?
Brilliant, thanks!
gmic_gimp_qt 2.6.5 Gimp 2.10.10 kubuntu 18.04
Saw an update so compiled and tried. Everything going great until I used Interactive curves. (The one filter I use the most)
That little black window. Eventually gmic crashes. This the end of the log
[gmic]-5./fx_curves_interactive/*if/x_color_curves/*repeat/local/if/if/ e[0;31;59me[1m Error in ./fx_curves_interactive/*if/x_color_curves/(…)/*if/*if/*thread3/_x_color_curves/ *** Command ‘input’: Invalid argument ‘()’.e[0;0;0m
Of course might be my compilation, nothing to compare with.
2 Likes
My fault, I have the same problem here.
I’ll fix that and generate new binaries for 2.6.5_pre. Thanks for reporting!!
ultrawarp+++++ doesn’t work/ 2.6.7
Error in ./ *** Unknown command or filename ‘ultrawarp4plus’ (did you mean ‘fx_ultrawarp4plus’ ?)
I fixed that bug and I’m waiting for the changes to be merged into the main repo.
I compiled gmic_gimp_qt (linux) on Saturday, comes out as version 2.6.8 and both ultrawarp 2 and ultrawarp ++++ are working.
1 Like
Feature request?
Was working on a script and discovered that it wasn’t cooperating because
gmic (1) (2) +*[0] -[1] p
didn’t work as I assumed (1) (2) (-2) (i.e., C = A * -B) but resulted in (1) (2) (1).
already means something:
+*[0] # insert the result of the multiplication of all images in the selection (here [0]).
-[1] # Subtract all images in the selection together (here [1]).
The first command is actually equivalent to +[0], and the second does nothing on [1] hence the result. I’m not sure this behavior should be changed when the selection for a math operator contains only a single element, as it would introduce different behaviors for different kind of selections.
Especially since the solution here is simple:
gmic (1) (2) +*[1] -1 *. [0]
Not for me, for one of the gimpchat forum members.
gmic_gimp_qt plugin
In Testing → PhotoComix → Wild Cartoonizer gives this error
*** Error in ./fx_m_l_unsharp2/unsharp/*repeat/ *** Command
‘if’: Invalid argument ‘0[1]’: Value accessor ‘[]’: Array brackets
used on non-vector variable ‘0’, in expression ‘0[1]’.
I (wrongly) assumed that an operation with one index (e.g., +*[0]) would mean that it would look for another operator but you are right that -[1] is a command and therefore isn’t considered an argument. Before posing the question, I also tried silly things like +*[0] {-{[1]}} to see if I could extract the data from the index.
Of course this would work
but I was tempted to apply the unary negation; hence, the head-scratching before I discovered the bug in my code.
gmic_gimp_qt plugin
In Testing → PhotoComix → Wild Cartoonizer
Ok, photocomix wild cartooniser, up and running from last update
Now gives a duplicate layer, eg. output mode inplace gives 2 identical layers ‘New layer’ gives original + 2 identical layers
I am not too bothered, the delete key is handy but…
@David_Tschumperle is it possible to expand rorschach pattern with new options ?
How does rorschach pattern work ?