Switch to full style
Post all Gimp scripts and script writing questions here
Post a reply

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 3:39 am

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

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 4:09 am

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.

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 4:12 am

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

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 5:14 am

Thank you again.
I acknowledge my stupid mistakes. :oops:

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

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 7:39 am

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
DIEGO_MOSAIC_GeglMosaicTEST.7z
(976 Bytes) Downloaded 84 times

GEGLasPYTHON neat 0.65.jpg
GEGLasPYTHON neat 0.65.jpg (431.62 KiB) Viewed 9514 times

my filter GEGL TEST neat 0.65.jpg
my filter GEGL TEST neat 0.65.jpg (464.63 KiB) Viewed 9514 times

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 7:44 am

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:
avinash-kumar-pdGd5N5J7UM-unsplash_1000square.jpg
avinash-kumar-pdGd5N5J7UM-unsplash_1000square.jpg (226.41 KiB) Viewed 9513 times

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 10:21 am

Comparing with the original Gegl:

Image

Image

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

Image

Image

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 10:41 am

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?

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 10:43 am

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

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 10:58 am

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

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 11:18 am

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?

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 1:39 pm

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.

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 1:53 pm

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.
:tyspin :tyspin :tyspin

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 10:16 pm

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

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 11:24 pm

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

Image

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

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Mon Nov 20, 2023 11:34 pm

Thanks for the clarification.

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Tue Nov 21, 2023 12:45 am

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.

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Tue Nov 21, 2023 1:05 am

MareroQ wrote:Changes in Ver.2:

- combined into one file gegl-python-fu.py and gegl-graph.py to gegl-python-fu & gegl-graph.py (standalone files: gegl-python-fu.py and gegl-graph.py must be deleted),
- change menu location (You can change it very quickly as you want using Notepad++),
- removed gegl-tile (because it doesn't work), gegl-nop (No operation),
- added: bump-map, component_extract, dropshadow, embos, mosaic, supernova.
- added: "Additional Information"
[ Image ]

A little about bump-map:

- bump-map: https://gegl.org/operations/gegl-bump-map.html
- about GEGL graph by Kevin and Tmanni: https://www.gimp-forum.net/Thread-GEGL- ... 0#pid19960. This was crucial to solving the aux problem - save aux.
- chanche offset: '+' up/right, '-' down/left
- gegl_graph_string + aux does not accept commas (that was problem number 2 but I don't know why at all),

I think that the save method (assuming that the 'd:' drive exists) will allow the conversion of filters from 2 pads: aux2 aux.
Tim wrote about 3 pads - which filter is it?

Edit:
Version 2.0 has been removed due to detected bugs
Reported bugs have been fixed in version 2.1 #55

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.

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Tue Nov 21, 2023 4:56 am

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


Bumpmap doesn't work on my Linux Mint 20.1
The message I get is this:
Code:
Traceback (most recent call last):
  File "/usr/lib/gimp/2.0/python/gimpfu.py", line 741, in response
    dialog.res = run_script(params)
  File "/usr/lib/gimp/2.0/python/gimpfu.py", line 362, in run_script
    return apply(function, params)
  File "/home/xxx/.config/GIMP/2.10/plug-ins/gegl-python-fu & gegl_graph.py", line 1865, in gegl_bump_map
    pdb.file_png_save(image, save, xchange, xchange, 1, 1, 1, 0, 0, 1, 0, run_mode=RUN_NONINTERACTIVE)
RuntimeError: Datei »/usr/image_1.png« konnte nicht zum Schreiben geöffnet werden: Keine Berechtigung


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

Re: GEGL operations exposed to Python-Fu - WIP 72 ops wrapped

Tue Nov 21, 2023 5:48 am

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")
Post a reply