Hi all,

Recently, I have spent my time reading source code of both GIMP and GEGL, and got few questions about GEGL and its future role in GIMP.

1. Why DAG in GEGL? Intuitively, say if we have two operations that are applied on two independent regions, they should be located in two separated sub-tree (sub-graph), so that we can save save some traverse time and potential redraw time. However, it seems like that there is no such mechanism (correct me if I misunderstand the code) and all operation cache/reuse are determined according to the spatial relationship between the rectangle associated with the operations. If that's the case, won't a simple link-list suffice?

2. Following question one, it seems like that GEGL has not been fully integrated into GIMP (2.7) yet, and I am wondering that for some common image manipulation case, say red-eye removal or skin smooth, what will the DAG in GEGL look like? Will it look like a tree with height of two (connecting all operations to the root display node) or a simple 1-D list? Ideally, how should GIMP build the graph to maximize the rendering efficiency?

Thanks for your answering, Tim Chen

I am particularly interested in the topology of the graph generated by GIMP for I am considering the possibility of implementing a plug-in that can allow user to directly manipulate the DAG itself. I can already foresee some interesting use case such as non-linear undo/redo, operation reuse...etc

However, to make it feasible, a DAG visualization with readable and reasonable topology has to be built on the fly during the image editing process. At least, DAG should clearly show the dependency between nodes with overlapped region and remove or hide unnecessary edges.

I am wondering is there any related projects or on-going effort for building such DAG editor?

And of course, all comments and brainstorm are welcome :D

Thanks, Tim Chen

On Tue, Nov 24, 2009 at 8:08 AM, Øyvind Kolås wrote:

On Mon, Nov 23, 2009 at 3:46 AM, Tim Chen wrote:

Recently, I have spent my time reading source code of both GIMP and GEGL, and got few questions about GEGL and its future role in GIMP.

1. Why DAG in GEGL? Intuitively, say if we have two operations that are applied on two independent regions, they should be located in two

separated

sub-tree (sub-graph), so that we can save save some traverse time and potential redraw time.

Time spent on graph traversal is neglible compared to pixel computation time.

However, it seems like that there is no such mechanism (correct me if I misunderstand the code) and all operation cache/reuse are determined according to the spatial relationship between

the

rectangle associated with the operations. If that's the case, won't a

simple

link-list suffice?

GEGL doesn't evaluate the full image at each evaluation, but only a smaller region of interest (roi). This allows GEGL to compute the minimall needed roi of the input nodes to reduce the amount of needed computation, in addition caches might allow GEGL to skip some of the pre-computation needed to satisfy the demands made by a single node.

2. Following question one, it seems like that GEGL has not been fully integrated into GIMP (2.7) yet, and I am wondering that for some common image manipulation case, say red-eye removal or skin smooth, what will

the

DAG in GEGL look like? Will it look like a tree with height of two (connecting all operations to the root display node) or a simple 1-D

list?

One of the goals of GEGL integration in GIMP is to make GIMP be a non destructive image editor. This means that instead of destructing a layer (and saving the previous state in undo tiles), the layer will be augmented with an operation that performs, and perhaps retains a cache of the result for the operation(s) applied to it.

It is also possible, if I understand the idea you propose correctly to feed the result of applying an application back to the original buffer, this is what GIMP already does for its tentative GEGL integration for the color tools.

Ideally, how should GIMP build the graph to maximize the rendering efficiency?

This is yet to be determined, but ideally GIMP builds the graphs it needs, and it is GEGLs responsibility to restructure and/or evaluate them efficiently.

/Øyvind K.
--
«The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/