Thanks, this actually works. I didn’t know that this accept negative values. It’s not specified on the document or the h reference. The only real downside to this approach as opposed to shift is that the latter enables subpixel processing in context of Fragment Blur.
@garagecoder , with these new versions of gradient and hessian , do you think it could be possible to improve the seamless blending operator ?
Karsten, I’ve changed my mind.
Commands deriche, vanvliet and the various blur now accept any boundary conditions.
1 Like
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?
Yes, because to enable the new custom command gradient, you have to use a binary where the native version is not present (so from yesterday 
).
boxfilter now accepts all types of boundary conditions as well.
Working on erode and dilate now!
1 Like
Congratulation to this progress!
Possibly the new custom functions rows, columns, slices could earn the boundary condition too?
Also a _boundary global variable used if no boundary condition is given might make sense.
I was thinking about that yes. But :
- 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_conditionsargument for these commands would be used a lot. - Because, it’s always possible to use native command
cropinstead.
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_conditionscould cause, if such a global state variable existed! - Global variables are evil
Considering I use boundary as local variables and other similar variables, count me out on global variables.
Besides, isn’t __variable a global variable declaration? And a single _ implies global, but only applies to the local command?
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.
Ah OK, then I suppose I can wait for a build or try to build from source (I have a lot less patience for build problems these days!)
With regards to the _ key, this is something to look at:
I personally don’t understand two underscores could be utilized, but might be that I’m not there yet.
Could be a new exercise for you. 
Don’t you already play with parallel processing?
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 
I forgot to mention this.
On global variable: It’s a good idea to avoid common name when using global variable so that they’re not easily accessible.
I just started doing that as of now when working on a command that needs it. So, basically _shortcommandname_variable is what I use.
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
Here’s another idea: distance, but for positive integers with/without zero rather than binary integers. Or different shapes.
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.
- Release of G’MIC 3.0.0.
7 Likes