RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

How to deal with pixel-per-pixel operations?

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.
How to deal with pixel-per-pixel operations? Alessandro Francesconi 11 Jun 09:05
  How to deal with pixel-per-pixel operations? Øyvind Kolås 11 Jun 10:49
Alessandro Francesconi
2013-06-11 09:05:03 UTC (over 11 years ago)

How to deal with pixel-per-pixel operations?

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

Øyvind Kolås
2013-06-11 10:49:27 UTC (over 11 years ago)

How to deal with pixel-per-pixel operations?

On Tue, Jun 11, 2013 at 11:05 AM, Alessandro Francesconi < alessandrofrancesconi@live.it> wrote:

Thanks for the answer, Im not new on GIMP plugins development but Im totally new on GEGL operations!

After a first look, it seems that none of the standard plugins from the GIMPs 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?

Take a look at goat-exercise.c in gimp/plug-ins/common, it shows how to get and manipulate image drawables as GeglBuffers. For documentation on GEGL see http://gegl.org/ or the docs dir of your own GEGL build.

/

The future is already here. It's just not very evenly distributed
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/