Yes, based on my own experiments with periodic boundary I think blend_seamless and related GUI filter has room for improvement. It removes any need to expand_xy first, there are simply no flaws. It may not be a dramatic visual change in the end, but worth investigating at least.
It’s really great to see the recent activity in g’mic, thanks for your efforts/time!
Edit:
A note to say I get an error with: gmic sp g xy,1,2
*** Error *** Command 'input': File 'xy', format does not take any input options (options '1,2' specified).
That’s with hirsute Version 3.0.0 (pre-release #211119), do I need a newer one?
It’s better to keep these custom commands as fast as possible, as they are used a lot.
On the contrary, I don’t think an extra boundary_conditions argument for these commands would be used a lot.
Because, it’s always possible to use native command crop instead.
I don’t like this idea.
First, we don’t have many global “state variables” like this in G’MIC. Except a few for the 3D rendering properties, and even those I don’t like them. It’s too easy to forget about their values, get a weird result when invoking another command, and just spend hours finding the cause of the ‘bug’.
With the existing 3D rendering state variables, it’s just about manageable, because it basically modifies the 3D rendering, so it’s quite fast to get an idea about what it’s going on. But I cannot imagine what a undesired value of boundary_conditions could cause, if such a global state variable existed!
Yes, it is of course possible to define global variables in G’MIC, with _variable=something
(and it still avilable outside the scope of the command that defined the variable).
Anyway, if you have the choice to avoid it, it’s probably better, as this is often a source of problems when you want to track the value changes of such a variable through all the functions that can potentially modify it.
On the new gradient: it’s obviously a lot more pleasant now to use periodic boundary and it works well of course. What I do notice is it’s about 10% slower than my own 2px kernel versions for forward/backward gradient using convolve. I guess I’ll live with that
Actually, I guess the parsing of arguments takes a bit of time, unfortunately.
As this command may take 0 arguments, the argument parsing must be precise enough to detect if an argument fits the command syntax or not. This part of the code is almost as long as the actual processing part!
It could be something else anyway, and if you find a trick to optimize it, you’re welcome
Hello again, I’ve been trying out some things with (user mouse controlled) window resizing. In general, the window behaves in quite an erratic way: flickering, jumping around, different aspect behaviour depending on the side/corner being dragged.
This is on two different gnome3 systems. I don’t expect miracles, but was wondering if this is normal/expected. Has anyone else experienced this? Even just doing gmic sp and trying to resize the standard display window causes it.
General questions about threading: is it possible to do something more complex like GUI thread & worker threads, trigger events, wait for thread completion etc? Or should we stick to non-dependent threads? How should we use mutex effectively?
The github wiki page about multi-threading looks out of date - it doesn’t mention “double underscore globals” or the mutex command. The example at the end randomly fails with: G'MIC encountered a fatal error (images (1) and images names (2) have different size)
Edit: also, are changes to double underscore globals instantly visible to all other threads?
There’s no zc option for either polygon or ellipse? What I wanted to try is to draw eclipse on different z on a volumetric image. draw() could work as well. This also gives me the idea of ellipsoid(), and cube().