GIMP Forums » For GEGL developers
GEGL ops: full-image processing (ignorance of ROI?)
Jump to message:
-
GEGL ops: full-image... —
Eugene Zagidullin,
19 Feb 2010 06:20 PM
- GEGL ops: full-image... — Martin Nordholts, 19 Feb 2010 06:53 PM
-
GEGL ops: full-image... —
Sven Neumann,
19 Feb 2010 06:58 PM
-
GEGL ops: full-image... —
Eugene Zagidullin,
19 Feb 2010 07:24 PM
-
GEGL ops: full-image... —
Danny Robson,
20 Feb 2010 02:05 AM
- GEGL ops: full-image... — Øyvind Kolås, 20 Feb 2010 04:01 AM
-
GEGL ops: full-image... —
Danny Robson,
20 Feb 2010 02:05 AM
-
GEGL ops: full-image... —
Eugene Zagidullin,
19 Feb 2010 07:24 PM
As a registered user, you can subscribe forum threads in order to get notified when replies are posted. Just log in at the right top of the page if you already have an account, otherwise you can register for free.
| Permalink: | 20100219202038.6b85cadc@pandemonium |
|---|---|
| Date: | 19 Feb 2010 06:20 PM |
| From: | Eugene Zagidullin |
| Subject: | 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.
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
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
| Permalink: | 4B7ED093.8080503@gmail.com |
|---|---|
| Date: | 19 Feb 2010 06:53 PM |
| From: | Martin Nordholts |
| Subject: | 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
> 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
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
| Permalink: | 1266602283.23843.14.camel@bender |
|---|---|
| Date: | 19 Feb 2010 06:58 PM |
| From: | Sven Neumann |
| Subject: | 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
> 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
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
| Permalink: | 20100219212457.1dcf8e6e@pandemonium |
|---|---|
| Date: | 19 Feb 2010 07:24 PM |
| From: | Eugene Zagidullin |
| Subject: | GEGL ops: full-image processing (ignorance of ROI?) |
On Fri, 19 Feb 2010 18:58:03 +0100
Sven Neumann <sven@gimp.org> 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.
Sven Neumann <sven@gimp.org> 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
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
| Permalink: | 20100220120558.71f7fd4a@spectre |
|---|---|
| Date: | 20 Feb 2010 02:05 AM |
| From: | Danny Robson |
| Subject: | GEGL ops: full-image processing (ignorance of ROI?) |
On Fri, 19 Feb 2010 21:24:57 +0300
Eugene Zagidullin <e.asphyx@gmail.com> 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.
Eugene Zagidullin <e.asphyx@gmail.com> 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
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
| Permalink: | 7bf6f2dc1002191901g6f924ad4td888d90ec... |
|---|---|
| Date: | 20 Feb 2010 04:01 AM |
| From: | Øyvind Kolås |
| Subject: | GEGL ops: full-image processing (ignorance of ROI?) |
On Sat, Feb 20, 2010 at 1:05 AM, Danny Robson <danny@blubinc.net> wrote:
> On Fri, 19 Feb 2010 21:24:57 +0300
> Eugene Zagidullin <e.asphyx@gmail.com> 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.
> On Fri, 19 Feb 2010 21:24:57 +0300
> Eugene Zagidullin <e.asphyx@gmail.com> 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
«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


