Release of G'MIC 3.0

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

[David_Tschumperle (G'MIC staff)]

@garagecoder

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

[Reptorian]

Here’s another idea: distance, but for positive integers with/without zero rather than binary integers. Or different shapes.

[garagecoder]

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.

[David_Tschumperle (G'MIC staff)]

• Release of G’MIC 3.0.0.

[garagecoder]

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?

[David_Tschumperle (G'MIC staff)]

@garagecoder

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)

That is a bug then Just after the 3.0.0 release… it hurts…

@garagecoder

Edit: also, are changes to double underscore globals instantly visible to all other threads?

It should yes, as these variables are shared between threads.

[Reptorian]

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

[garagecoder]

@David_Tschumperle

That is a bug then

A shame indeed that I only discovered this today! I’ve decided not to do anything complex with threading for now, it would make fixing my own bugs more difficult.

[David_Tschumperle (G'MIC staff)]

@garagecoder

A shame indeed that I only discovered this today! I’ve decided not to do anything complex with threading for now, it would make fixing my own bugs more difficult.

Well, looking at it more closely, I’m not that sure this is a bug, after all

The fact is, there is a rule that should be written in bold on the wiki page :

A G’MIC pipeline run in a thread should never modify the size of the global image list.

Otherwise, there is a risk that at one particular moment, one thread sees an image list with M images (and M associated names), while another one is removing one (or several images) from the list. Hence the error message you get with the example.

The example is bad, really. In particular, one the thread that is doing this:

-do 300,100 -text[-1] @{com,0}\",\"@{com,1},5,5,13,1,255 -w[-1] -rm[-1] -wait 200 -while 1

It just doesn’t stop creating and removing a temporary image that is put on the list. No surprise that it finally interfere with the other threads.

A probable solution (not tested) would be to isolate this thread in a local environment:

-do str={com,@0}\",\"{com,@1} l[] 300,100 -text[-1] $str,5,5,13,1,255 -w[-1] -rm[-1] endl -wait 200 -while 1

So that the size of the global list is not modified, but only the size of the sub-list associated to the local environment.

EDIT: A “correct” way to write the multi-threaded example at the end of the wiki page:

bug :
  (0,0) nm. com
  parallel "repeat inf =[com] $>,0 wait 200 done",\
           "repeat inf =[com] $>,1 wait 100 done",\
           "do str={com,@0}\",\"{com,@1} l[] 300,100 text $str,5,5,13,1,255 w rm endl wait 200 while 1"