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 <islewind@xxxxxxxxx> wrote:
On Mon, Nov 23, 2009 at 3:46 AM, Tim Chen <timchen@xxxxxxxxxxxxxx> wrote:Time spent on graph traversal is neglible compared to pixel computation time.
> 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.
GEGL doesn't evaluate the full image at each evaluation, but only a
> 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?
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.
One of the goals of GEGL integration in GIMP is to make GIMP be a non
> 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?
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.
This is yet to be determined, but ideally GIMP builds the graphs it
> Ideally, how should GIMP build the graph to maximize the rendering
> efficiency?
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/
_______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
