RSS/Atom feed Twitter
Site is read-only, email is disabled

GEGL ops: full-image processing (ignorance of ROI?)

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

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

6 of 6 messages available
Toggle history

Please log in to manage your subscriptions.

GEGL ops: full-image processing (ignorance of ROI?) Eugene Zagidullin 19 Feb 18:20
  GEGL ops: full-image processing (ignorance of ROI?) Martin Nordholts 19 Feb 18:53
  GEGL ops: full-image processing (ignorance of ROI?) Sven Neumann 19 Feb 18:58
   GEGL ops: full-image processing (ignorance of ROI?) Eugene Zagidullin 19 Feb 19:24
    GEGL ops: full-image processing (ignorance of ROI?) Danny Robson 20 Feb 02:05
     GEGL ops: full-image processing (ignorance of ROI?) Øyvind Kolås 20 Feb 04:01
Eugene Zagidullin
2010-02-19 18:20:38 UTC (about 15 years ago)

GEGL ops: full-image processing (ignorance of ROI?)

Is it possible to create full-image ops? A good example of such an op is exposure fusion technique by Mertens & Kautz. It's output depends of full-image Laplacian pyramid decomposition.

Martin Nordholts
2010-02-19 18:53:15 UTC (about 15 years ago)

GEGL ops: full-image processing (ignorance of ROI?)

On 02/19/2010 06:20 PM, Eugene Zagidullin wrote:

Is it possible to create full-image ops? A good example of such an op is exposure fusion technique by Mertens& Kautz. It's output depends of full-image Laplacian pyramid decomposition.

Processing in an operation is done on-demand. The operation is asked to "for these inputs, give me output for the rectangle R". So it doesn't make sense to write an op that ignores the ROI, how would it know what data to give?

Note that you can ask GEGL to process a whole node, which in effect will process "the entire image". For example, you could have this graph:

inputimage1 inputimage2 inputimage3 | | | +--------------+ | +-----------+ | | |
exposure-fusion
|
png-save

Then, if you process the entire png-save node, this will happen: GEGL will try to calculate the bounding box for png-save. This depends on the bounding-box of exposure-fusion, so GEGL will ask exposure fusion about the bounding box. The exposure-fusion node bounding box depends on the bounding box of the input images, so GEGL will ask about the bounding box of the images. This is a recursive process of course.

Once the bounding-box of the dependencies have been determined, the ROI will be set to exactly the ROI needed to process the full image.

HTH,

/ Martin

Sven Neumann
2010-02-19 18:58:03 UTC (about 15 years ago)

GEGL ops: full-image processing (ignorance of ROI?)

On Fri, 2010-02-19 at 20:20 +0300, Eugene Zagidullin wrote:

Is it possible to create full-image ops? A good example of such an op is exposure fusion technique by Mertens & Kautz. It's output depends of full-image Laplacian pyramid decomposition.

If I remember correctly a GEGL operation has a way to tell what regions of the input data it needs in order to calculate a certain region of output data. A blur operation for example needs an input rectangle that is by about the blur radius larger than the output rectangle. Your fusion technique could probably tell that it always needs the all input data, regardless of the ROI.

Sven

Eugene Zagidullin
2010-02-19 19:24:57 UTC (about 15 years ago)

GEGL ops: full-image processing (ignorance of ROI?)

On Fri, 19 Feb 2010 18:58:03 +0100 Sven Neumann wrote:

SN> Your fusion technique could probably tell that it always needs the all input SN> data, regardless of the ROI.

Yes, it's just what I mean. But this decomposition is a very CPU-intensive operation. Is there a way to process whole image only once, store output in a kind of cache and later update requested region with cached data? Performing decomposition again and again until whole image will be covered with ROIs and thus cached is waste of time.

Danny Robson
2010-02-20 02:05:58 UTC (about 15 years ago)

GEGL ops: full-image processing (ignorance of ROI?)

On Fri, 19 Feb 2010 21:24:57 +0300 Eugene Zagidullin wrote:

Yes, it's just what I mean. But this decomposition is a very CPU-intensive operation. Is there a way to process whole image only once, store output in a kind of cache and later update requested region with cached data? Performing decomposition again and again until whole image will be covered with ROIs and thus cached is waste of time.

I ran into the same problem with gegl:openraw-load. If get_bounding_box and importantly get_cached_region both return the entire image, then GEGL will submit one process request for the entire image and cache the result.

I'm using this trick in a couple of ops currently, and while it doesn't appear to be explicitly documented anywhere, it always works.

Øyvind Kolås
2010-02-20 04:01:48 UTC (about 15 years ago)

GEGL ops: full-image processing (ignorance of ROI?)

On Sat, Feb 20, 2010 at 1:05 AM, Danny Robson wrote:

On Fri, 19 Feb 2010 21:24:57 +0300 Eugene Zagidullin wrote:

Yes, it's just what I mean. But this decomposition is a very CPU-intensive operation. Is there a way to process whole image only once, store output in a kind of cache and later update requested region with cached data? Performing decomposition again and again until whole image will be covered with ROIs and thus cached is waste of time.

I ran into the same problem with gegl:openraw-load. If get_bounding_box and importantly get_cached_region both return the entire image, then GEGL will submit one process request for the entire image and cache the result.

I'm using this trick in a couple of ops currently, and while it doesn't appear to be explicitly documented anywhere, it always works.

This isn't a trick but how it is supposed to be done.

get_bounding_box returns the rectangle that has defined output pixels according to this operation with its given inputs.

The documentation of get_cached_region used to say:

/* Adjust result rect, adapts the rectangle used for computing results. * (useful for global operations like contrast stretching, as well as * file loaders to force caching of the full raster). */
GeglRectangle (*get_cached_region) (GeglOperation *operation, const GeglRectangle *roi);

I have changed it, and hopefully improved it, by making it:

/* The rectangular area that should be processed in one go, by default if not * defined the output roi would be returned. This is useful for file loaders * and operations like contrast stretching which is a point operation but we * need parameters as the minimum/maximum values in the entire input buffer. */
GeglRectangle (*get_cached_region) (GeglOperation *operation, const GeglRectangle *output_roi);

/Øyvind K.