Re: How to deal with pixel-per-pixel operations?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx

 
On Tue, Jun 11, 2013 at 1:32 AM, Alessandro Francesconi <alessandrofrancesconi@xxxxxxx> 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
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gimp-developer-list





[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux