Re: [Gimp-user] Creating a new operation for GEGL

[Øyvind Kolås <pippin gimp org>]

On Tue, Dec 5, 2017 at 4:50 PM, felipeek2 <forums gimpusers com> wrote:
> Well, it turns out that we've decided to try to implement the filter in GEGL, so
> it would become easy to use with tools like GIMP, for example. Since GEGL is
> open source, I've been trying to understand the code that is used to generate
> new operations and understand how could I carry the filter to the platform.
>
> I've made some tests, and I figured out that the standard behavior of GEGL is to
> split the image in several tiles, which are usually rectangles, and process all
> these 'tiles' independently, even using different threads. With some inspection
> of the existing GEGL code is easy to, for example, make each thread processes
> its own tile and return the result. However, for the specific filter I'm
> implementing, this is not enough, since it is a recursive filter.
>
> The implementation I am using of the Domain Transform filter is a recursive one,
> in which each pixel will always depend on the value of the previous pixel,
> already processed. That said, I could only process a tile if the previous tile
> was already processed, which is a problem. Moreover, to generate good results,
> the filter must be applied several consecutive times, and each time it must be
> performed top->down, bottom-up, left-right and right-left, again consecutively.
> Since GEGL automatically divides the image into tiles and feed them to the
> operation, I'm not sure how is the proper way to force the filter to be executed
> in several steps.
>
> With all these restrictions, I'm having some difficult to find out how can I
> achieve that inside GEGL. I would be very grateful if someone could give me some
> hints or even show me a code where a recursive filter is implemented as a GEGL
> operation.

I didn't originally see your email, since it went to the gimp-user
mailing-list rathern than to gimp-developer or gegl-developer.

For an example of an operation that needs the full input to be
available to be able to do processing, have a look at
gegl:stretch-contrast
https://git.gnome.org/browse/gegl/tree/operations/common/stretch-contrast.c

Worth noting, in particular, is that it sets operation_class->threaded
to FALSE to opt-out of base classs automated thread parallelization,
and that it sets the methods get_required_for_output and
get_cached_region to specify which areas (all) need to be computed for
input buffers, and what extra data to compute when computing one
sub-rectangle, (also all).

/pippin - http://pippin.gimp.org/