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 <islew...@gmail.com> wrote: > On Mon, Nov 23, 2009 at 3:46 AM, Tim Chen <timc...@cs.nthu.edu.tw> 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/ >
_______________________________________________ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
