Sign up now! · Forgot password?
RSS/Atom feed identi.ca Twitter

Creating a new operation for GEGL

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

4 of 4 messages available
Toggle history

Please log in to manage your subscriptions.

Creating a new operation for GEGL felipeek2 05 Dec 15:50
  Creating a new operation for GEGL Øyvind Kolås 13 Dec 19:18
   Creating a new operation for GEGL felipeek2 27 Dec 05:04
    Creating a new operation for GEGL Øyvind Kolås 01 Jan 15:38
2017-12-05 15:50:55 UTC (6 months ago)
postings
4
contact
Send private message

Creating a new operation for GEGL

Hello developers,

I'm currently working on an implementation of a bilateral filter called "Domain Transform Filter" (for someone interested, the work can be found here https://dl.acm.org/citation.cfm?doid=1964921.1964964 and here http://inf.ufrgs.br/~eslgastal/DomainTransform/).

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.

Thank you very much, Felipe

Øyvind Kolås
2017-12-13 19:18:30 UTC (6 months ago)

Creating a new operation for GEGL

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/

2017-12-27 05:04:34 UTC (5 months ago)
postings
4
contact
Send private message

Creating a new operation for GEGL

Hello Øyvind Kolås

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.

Thanks! Felipe

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/

Øyvind Kolås
2018-01-01 15:38:56 UTC (5 months ago)

Creating a new operation for GEGL

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/