Re: [Gimp-developer] How to deal with pixel-per-pixel opera tions?

[Alessandro Francesconi <alessandrofrancesconi live it>]

Thanks for the answer, I’m not new on GIMP plugin’s development but I’m totally new on GEGL operations!

 

After a first look, it seems that none of the standard plugins from the GIMP’s procedure database use GEGL 
for their operations, and the only way to test a operation made with GEGL is to open this dialog: 
http://docs.gimp.org/it/gimp-tool-gegl.html

.... am I wrong? 


I mean, is it possible to define a new plugin using the classical method with ’gimp_install_procedure()’, 
making it accessible through the PDB and writing a ”complex” user interface with GTK, but using GEGL APIs for 
the image manipulation phase?


Where to find a documentation about those ’GeglOperation’ or ‘GeglBuffer’ APIs? Seems I need to learn a lot 
of new things...


Ale

 

 


Da: Øyvind Kolås
Data invio: ‎martedì‎ ‎11‎ ‎giugno‎ ‎2013 ‎01‎.‎48
A: Alessandro Francesconi
Cc: gimp-developer-list gnome org

 
On Tue, Jun 11, 2013 at 1:32 AM, Alessandro Francesconi <alessandrofrancesconi live it> wrote:


Hello, I'm starting to write a GIMP plugin and I'm facing the problem of "pixel-per-pixel" algorithms and 
their speed.
Without going on details, my algorithm should take every pixel in the image and for each one it must check 
its 24 neighbours, it does some simple calcs and finally it set a new color for the pixel.

How to speed-up the execution? I tried with the easiest approach with a classic "for-in-for" loop but the 
computation is really slow. Looking around, I've seen some GIMP functions like:

gimppixelfetcher — Functions for operating on pixel regions.
gimppixelrgn — Functions for operating on pixel regions.
gimpregioniterator — Functions to traverse a pixel regions.





All of the above functions are considered deprecated; even when developing a GIMP plug-in and not a GEGL 
operation you would be encouraged to use GeglBuffer APIs (search for "gegl" in gimp's plug-in directories.). 
Though for a filter plug-in like you describe, the most proper way to do it now and for the future is to 
write a GeglOperation that derives from the provided GeglOperationAreaFilter like for instance: 




https://git.gnome.org/browse/gegl/tree/operations/common/noise-spread.c




you'd probably want to fetch the entire neighborhood of the rectangular region being processed though; rather 
than doing like that particular plug-in which gegl_buffer_get's pixels one by one.


/pippin