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 ?
That’s a quite old command yes, so it could be improved.
What kind of options did you have in mind ?
Adding size variations of some parts and noise of the whole pattern.