I’ll fix that, but the code was already wrong before.
You cannot put spaces directly without quoting them, because the space character is the item separator in G’MIC, so having spaces in formula without double quotes is just wrong.
1 Like
OK 
My trial concerned only syntax. I am still not aware about the semantics. This is also true for scripts from @afre and @Reptorian.
I am also not convinced about @afre statement that the location of a script, either in user.gmic or any other gmic file makes differences. I think hidden errors are more probable. The help facility of gmic makes differences where a script is located. But these are comments for the script!
Also the idea that cli and gui comments should not be mixed is IMHO wrong. There again the syntax (of the comments) must be correct!
The fact is that these gotchas make it difficult to code. I wish for parity regardless of the location of the code and which interpreter is reading it.
The trouble with UltraWarp++++ was 2 fold. 1 When I put it into user.gmic, the plugin didn’t raise an error in spite of it being syntactically incorrect. 2 The plugin didn’t tell us which line number the error occurred in update*.gmic.
nobody else got the bug with display0 ?
It happened on my Mac too. Shortly appears a possibly not-normalized version!
1 Like
@garagecoder I haven’t forgotten!
I get the same issue with dp0 too. When I do a z d0 or d0 with 2+ images, it remains dark until I select to view one of them for the latter.
1 Like
Interesting @afre!
For 1
Did you put all scripts concerning UltraWarp++++ into your user.gmic file? For locating the error it might be helpful to rename the routines that there is no overlay possible. Assuming that user.gmic is compiled after updatexxx.gmic this could make some differences.
For 2
Most probably the plugin compiles the script with debug=0
command (+):
_add_debug_info={ 0 | 1 },{ filename | http[s]://URL | "string" }
Hence no line numbers are stored! Still no different compilation or parsing.
I did both.
In my experience, user.gmic is closer to updatexxx.gmic than using other *.gmic but still doesn’t match in outcome. I wish I could write code in any one of them and still get the same strictness and behaviour. A semantic example (since I have already given a syntactic one) is that the plugin ignores #@gui when searching *.gmic. However, I don’t know if anything has changed since I last mentioned it, given the fast pace of G’MIC development.
2 My point is that line numbers help with bug reporting and make fixes easier to do.
I don’t understand you. The plugin does IMHO not search for files. AFAIK the plugin is only using updatexxx.gmic and user.gmic (Windows). You can add in user.gmic “command file” for additional scripts.
Point 2
I understood the “system routines” located in updatexxx.gmic as tested. Still some sort of debug mode (with line numbers) in the plugin could be helpful. One could also try “verbose 101” in a script to get some more output. But best is to test routines under cli!
Another question I want to ask: how do I change the precision of the GUI sliders? I want to include more decimal places in the CubeHelix script because I’m going to include options to customise how the colours vary with the angle parameter, but the default profile has 5 decimal places while the sliders can only show 2.
Well, seems I started something here - hope it can get resolved, meanwhile I’m using Windows (Linux) Subsystem Ubuntu bash to do my batch processing, the only way I can use the cli for this filter! (G’mic 2.4.5)
Happy days…
The code has to be in user.gmic proper and cannot be in another file linked by command.
There’s a workaround to this. Just like I did with Nebulous, I added 2 sliders to affect one variable. It’s not something I like doing for one variable. Could use 2 integer. One that about the larger amount and the other is divided by 10000.
It’s not a workaround that I particularly like given that it would require me to double the numbers of variables in a lot of cases, which would make the GUI for each plugin a lot more difficult to navigate without a further option to enable more precision.
You are right. The mechanism in the plugin is different to cli. For the latter one can define a routine cli_start to install further script files.
Maybe @David_Tschumperle is willing to describe the mechanism for plugins including/defining further/private (gui-)script files again. Perhaps some sort of gui_start routine could make sense?
Hmm, I tried a bit with your UltraWarp++++ directly in Gimp (2.10.10) with gmic plugin 2.6.4 Custom Code to avoid the fruitless exchange concerning differences of cli and gui.
I deleted some space in your script part. But I am not sure about the result. Does the example fulfill some expectation or is it completely incomprehensible?
The input image is a piece of a Sorolla painting.
Those examples are pretty good demonstrations of what the filter’s purpose is, though it works best with large areas of similar colours. I made it when I was interested in producing highly-distorted art using displacements. It would be nice to have the modified script too so that I can see what’s changed and I can use it.
A bit of history that no-one asked for: almost as soon as I heard that there was a warping command, I started building a filter that could quickly perform multiple randomised self-warps. It’s my first major filter and when I was getting high off the progress that I was making, I kept on cramming features into it until it turned into the poorly-named UW4+ that we know and love(?) today. With this thing and its predecessors, I’ve made countless horrors which are somewhere on an old and damaged hard drive that I can’t be bothered to fix. I know that others use it too for some reason.
In fact I could not decide what should be an acceptable result!
I don’t know your tools, here is a screenshot of the differences I made in the copy of update264.gmic:
Left is my version! You have to locate the lines in your files.
On the old and damaged hard drive, you probably can’t fix them, but there’s little chance to recover those. Always keep external backups whenever possible.