On Mon, 2016-07-18 at 15:39 -0700, Gregg Hauser wrote:

I'm considering converting existing GIMP plug-ins to use GEGL, looking 
initially at  despeckle.c

Hi Greg,

that's great news, new contributors are very welcome :)

The algorithm changes the source buffer if "Recursive" mode is chosen.

Question: Is changing the source buffer returned by gegl_buffer_get  acceptable?

This plug-in falls in the "filter" category and you would get rid of the GIMP plug-in alltogether and write a GEGL op, which will then gets its GIMP GUI auto-generated. This is also the much easier approach, you can simply port such filters to float, drop the GUI and done.

Request for Comments: The basic algorithm in GIMP's despleckle chooses a 
pixel randomly from those pixels closest to the median in luminance,  avoiding pixels above and below user specified levels of luminance.  Colors may change as long as the luminance of the pixel chosen is close 
to median around the pixel being calculated. This seems like a disaster 
to me. The 3 channel median-blur.c algorithm in gegl/workshop seems a 
lot closer to what this plug-in should be than the original code in  GIMP. The literature is full of other despeckle algorithms, some of  which preserve detail better than the median technique. Some despeckle 
algorithms are appropriate for black and white images only.

I'm not the master of algorithms here, maybe somebody else can answer that question...

Question: Does the 2.10 or 3.00 version of GIMP need to slavishly mimic 
the existing plug-ins?

It is preferred, unless the GIMP plug-in code is broken or otherwise totally shitty. We'd like to auto-redirect scripts calling the plug-in to the new GEGL op, and that works best if they do exactly the same. It's not a strict rule tho and probably mostly depends on you own judgement, because having looked into the issue makes you the foremost expert on despeckle :) (GIMP plug-ins don't get a lot of attention usually).

Regards, --Mitch