On Tue, Dec 5, 2017 at 4:50 PM, felipeek2 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/

On Wed, Dec 27, 2017 at 6:04 AM, felipeek2 wrote:

Thank you very much for your help! The filter is working now.

Is it possible to manually create/manage threads inside a GEGL operation? This would improve our filter a bit.

When opting out of threading, like outlined in prior response, you are free to manage threads; ideally using the multi- threading APIs of glib which are platform independent. The GeglBuffer API itself is written to be thread safe.

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