On Tue, Dec 5, 2017 at 4:50 PM, felipeek2 <for...@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/ _______________________________________________ gimp-user-list mailing list List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
