Release of G'MIC 3.0

[David_Tschumperle (G'MIC staff)]

@Reptorian

As in opacity adds rather than using alpha composition?

Choose -value as the opacity when drawing J on I, to do I + J*value

[David_Tschumperle (G'MIC staff)]

@KaRo

see in your implementation of _gradient, that you already do the faking by resize for “xyz” in the deriche and vanvliet case!

Yes, but in that case, I know that the sigma is small enough so that I only need to add 1px-border to the images.
In the general case of deriche and vanvliet , the parameter sigma can be anything, and it’s kinda hard to determine the size of the needed borders. Actually, as the recursive filtering implies kernel with theoretically infinite support, the amount of borders to add could be really huge!

[KaRo (Karsten R)]

Ok, understood.
Thanks again, for all your work too.

[David_Tschumperle (G'MIC staff)]

• hessian has been converted to a custom command too, so with any kind of boundary_conditions.
• sharpen has been also converted (but without the choice for boundary conditions in this case, as it seems not really interesting).

[Reptorian]

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.

[David_Tschumperle (G'MIC staff)]

@garagecoder , with these new versions of gradient and hessian , do you think it could be possible to improve the seamless blending operator ?

[David_Tschumperle (G'MIC staff)]

@KaRo

Ok, understood.
Thanks again, for all your work too.

Karsten, I’ve changed my mind.
Commands deriche, vanvliet and the various blur now accept any boundary conditions.

[garagecoder]

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?

[samj]

@garagecoder

gmic sp g xy,1,2 works with the latest version of November 28 (tested under Win 64).

[David_Tschumperle (G'MIC staff)]

@garagecoder

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 ).

[David_Tschumperle (G'MIC staff)]

boxfilter now accepts all types of boundary conditions as well.
Working on erode and dilate now!

[KaRo (Karsten R)]

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.

[David_Tschumperle (G'MIC staff)]

@KaRo

Possibly the new custom functions rows, columns, slices could earn the boundary condition too?

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_conditions argument for these commands would be used a lot.
• Because, it’s always possible to use native command crop instead.

@KaRo

Also a _boundary global variable used if no boundary condition is given might make sense.

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!
• Global variables are evil

[Reptorian]

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?

[David_Tschumperle (G'MIC staff)]

@Reptorian

Besides, isn’t __variable a global variable declaration?

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.

[garagecoder]

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!)

[Reptorian]

With regards to the _ key, this is something to look at:

A variable definition is always local to the current command except when it starts by the underscore character _. In that case, it becomes also accessible by any command invoked outside the current command scope (global variable).
If a variable name starts with two underscores __, the global variable is also shared among different threads and can be read/set by commands running in parallel (see command parallel for this purpose). Otherwise, it remains local to the thread that defined it.

I personally don’t understand two underscores could be utilized, but might be that I’m not there yet.

[afre (Alan)]

Could be a new exercise for you. Don’t you already play with parallel processing?

[garagecoder]

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

[Reptorian]

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.