Hi Diego

Thank You for reporting the error.
In line 1798 the letter s is missing
Change: tile_type_m= "square"
to: tile_type_m= "squares"

For those writing programs in Python/Gegl, my observation: if the value of the enum type is incorrect, Gegl will adopt the default value - clever for operation, but makes it difficult to detect the error.
The fix will be included if I write a few more plugins, I will update the download to the next version (including Bump-map for Linux and likely other bugs).

Thanks. Applied the suggested change. Problem of type solved.
But what about the problem of neatness?
Whichever value you enter from 0.00 to 0.99 the resulting neatness is always the same.

It is like neatness is taking as an integer: 0 or 1, i.e. NOT neat, TOTALLY neat.

Thank you again.
I acknowledge my stupid mistakes.

Replace this:
line 1742 opacity=%d ➤ opacity=%f
line 1815 tile-neatness=%d color-variation=%d ➤ tile-neatness=%f color-variation=%f
line 1870 elevation=%d waterlevel=%d ambient=%d ➤elevation=%f waterlevel=%f ambient=%f

This may be useful:
%d - will reduce to an integer,
%s - will keep formatting,
%f - will display as floating point
%g - is used as a general number

Thanks a lot.
I made the indicated changes.
Now I have a different question:
it seems that the filter called from GEGL as Python produces a neatness different from
the filter called from inside my personal test.
I attach here:
- my test program
- the result from GEGL as Python
- the result from my test program

If you are interested, you could repeat my experiment.
If you will do so, please note that the tile size in my filter is specified as "divisor of the width+height of the image", to get consistent outcomes.
In my test I used an image 1000x1000 to simplify comparison.
Here it is:

Comparing with the original Gegl:





From a quick analysis:
Your filter has an incorrect tile-neatness value.

Thanks for your test.
In my filter neatness is the parameter regularity and is passed as 0.65 in the "neatness" position, as you can see in the filter code.
I've seen that it is NOT taken into account. But why?

I've tried also to set the fixed value 0.65 instead of the internal parameter "regu", but no change.
Any idea?

I tried to call the mosaic interface in my filter adding the parameter
run_mode=RUN_INTERACTIVE
to check what it passes really to the executor,
but it only shows the last 8 parameters, so I do not see what it has taken as neatness value

I found that the gegl-mosaic interface used by the filter has again the problem of considering integer instead of float the parameter neatness; in fact if I enter the value 0.65 it produces the same as 0, while if I enter 1 is is executed with full neatness.
Is there another point to modify or did i miss something in GEGL as Python code?

Sorry, but my next mistake (if the number is a floating point value, it is not enough to use %f for this parameter, but also PF_FLOAT)
Please download version 2.1.

Fantastic, solved !
Now both the function called from the GEGL as Python menu entry as well as from my filter produce similar neatness.
Many many thanks.

Tested a different function: Edge Laplace.
It doesn't show any parameters panel and gives a black outcome.

Looking into the code it seems an empty function

Gegl Laplace has no parameters, and "python_fu_gegl_edge_laplace" works like the original GEGL for me (although the result is "almost" black).



I'm looking for a Bump-map tester on Linux (included in version 2.1) - my Ubuntu doesn't work (temporarily?) after updating.

Thanks for the clarification.

I will kindly wait for someone to port these 24 plugins of mine to python.

https://github.com/LinuxBeaver/Special_ ... le_plugins

All the other plugins of mine will not work in python.

I see you removed gegl:nop, Its okay to remove it from the GUI (where the user sees stuff) but that operation (gegl:nop) is critical to make connnections in GEGL known as id and ref. Many plugins of mine depend on gegl:nop to do this.

To put things simple gegl:nop exist to put filters inside blend modes while calling a copy of the original image.

Bumpmap doesn't work on my Linux Mint 20.1
The message I get is this:


Looks like it wants to write to /usr where it has no permisssions.
A user's home dir would be /home/username in Linux

Hello Contrast
Plugin gegl-python-fu & gegl_graph.py is a helper for people writing plugins or scripts, and I don't see any way to use gegl:nop outside of Gegl proper.
Single Gegl plugins are registered in the PDB and this is very good, but if you only want to use one operation, it is better to use GEGL directly (advantage in preview).
Practically, gegl-python-fu & gegl_graph.py does not need to be registered in the Gimp menu at all (only in the PDB).
I assume plugin developers have knowledge of how to use gegl-python.

What do you think about not registering gegl-python-fu in menus (except gegl-graph)???

Hello Nelo.
Thank you for trying the plugin.
The idea behind this game is to temporarily save the Aux image in a location that will be publicly available to users of different versions of Linux.
Could you try with the tmp folder (replace "/usr/image_1.png" twice with "/tmp/image_1.png")