Sent: 2010-02-19 18:20:38 UTC (almost 2 years ago)

From: Eugene Zagidullin

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

permalink

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.

--
Best regards,
Eugene mailto:e.asphyx@gmail.com
xmpp://asphyx@jabber.ru
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2010-02-19 18:53:15 UTC (almost 2 years ago)

From: Martin Nordholts

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

permalink

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

--

My GIMP Blog:
http://www.chromecode.com/
"Multi-column dock windows and 2.8 schedule"
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2010-02-19 18:58:03 UTC (almost 2 years ago)

From: Sven Neumann

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

permalink

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

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2010-02-19 19:24:57 UTC (almost 2 years ago)

From: Eugene Zagidullin

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

permalink

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.

--
Best regards,
Eugene mailto:e.asphyx@gmail.com
xmpp://asphyx@jabber.ru
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2010-02-20 02:05:58 UTC (almost 2 years ago)

From: Danny Robson

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

permalink

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.

_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Sent: 2010-02-20 04:01:48 UTC (almost 2 years ago)

From: Øyvind Kolås

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

permalink

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.

--
«The future is already here. It's just not very evenly distributed»
-- William Gibson
http://codecave.org/ http://ffii.org/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer