Right now I'm trying to harmonize the gggl terminology towards the glossary I create a while ago, (that glossary now resides at http://pippin.gimp.org/gggl/glossary.html , in the processes of search and replace within gggl I have also turned to the GEGL sources to see whether the naming conventions hold there as well.

I have changed (almost) all occurrences of "node" in the gggl source with op (short for operation), this because the term node is very graph centric, and does not convey the notion that it has the capability to process something. It is possible to say a graph of operations linked by connections. It is easier to have a smaller vocabulary, and the term Op(eration) also work better on higher abstraction levels. Thus I think this is a search and replace that would work within the GEGL code base as well.

GEGL uses the term source/sink for the end points of connections, I think this is a bad term to use because the relation ships flips when you look at the model on different levels.

A simple graph that could be present in a web cam app illustrates this:

.-----. | v4l | ll leave the
term process in gggl for the time being.

/pippin

On 09/21/04 23:17:28, Øyvind Kolås wrote:

The act I call processing is called evaluating in GEGL, I feel this is an issue where I probably have a stronger bias towards the terminology
I have been using, both terms probably have merit, and I'll leave the term process in gggl for the time being.

I after spending some time today looking closer at the GEGL api, I have rediscovered more of the reasoning that it is called evaluate in GEGL, in GEGL you are only able to evaluate a ROI (region of interest) on a particular root node in the graph. The region of interest, and minimal recomputation which this approach advocates is interesting, but it has a shortcoming.

The approach doesn't easily facilitate multiplie active sinks at the same time, something that might be beneficial for rendering thumbnails in the composition treeview in GIMP. The approach needed with the current evaluation manager is to issue a seperate processing step for each thumbnail that one wants to generate. In bauxite I have been doing color correction of video where I render both color corrected video,histogram and chromatic diagram, to facilitate this with the GEGL approach you would have to composite theese images into a final larger image to be able to get away with a single invokation of the evaluation manager.

gggl has the facility of setting the "active nodes", this is actually just defining which sinks, and all their dependencies should be rendered. Perhaps the GEGL api could somehow be extended to allow multiple roots, and regions of interest? I fear the consequence would be a more complicated API.

/pippin

* Daniel Rogers [040923 19:20]:

On Sep 22, 2004, at 10:53 AM, Øyvind Kolås wrote:

On 09/21/04 23:17:28, Øyvind Kolås wrote: The approach [single root, ROI] doesn't easily facilitate multiplie active sinks at the
same time, something that might be beneficial for rendering thumbnails in the composition treeview in GIMP. The approach needed with the current evaluation manager is to issue a seperate processing step for each thumbnail that one wants to generate.

This isn't a limitation of the "ROI" processing concept. Ideally the results from any particular processing is caching, and only recalculated if something changes, the cache gets full, or it is faster to recalculate than draw from the cache. In which case, the second, thumbnail calculation doesn't take much extra time, since it can reuse the results of the first, Original calculation.

This is not orthogonal to the gggl approach of setting "active nodes" (which essentially is multiple root nodes). The caching approach though makes it harder to redefine root nodes, as well as collapsing affine transforms,.. unless the caching is done on a composition graph can take multiple roots into accounts when doing collapsing of affine transforms.

/pippin

* Calvin Williamson [040923 18:02]:

Anyway I think we commit to stick to double or float as the default, and decide which other types to support as well,

It makes sense to enforce this for most filters, but some source operations (mpeg4, png, v4l, svg (at least my cairo based thing)) it doesn't make sense, the plug-in system should allow for developers to just code for the pixelrepresentations they need, ignore the rest, and be able to expect things to just work.

In gggl I do pixel representation negotiation in a seperate pass before processing starts (this could be added as an additional pass in GEGL as well I guess), this pass does negotiation on every connection in the graph trying to find the best suited common format between the operations, if no suitable pixel representation is found a proxy operation is inserted proxy is my pixel representation "babelfish"

http://pippin.gimp.org/gggl/snapshot/ops/filters/pixfmt_conversions.h.html http://pippin.gimp.org/gggl/snapshot/ops/filters/precalc_order.txt.html http://pippin.gimp.org/gggl/snapshot/ops/filters/proxy.c.html

and try to make it as easy as possible to add new types, but without burdening it all with a code-generating tool right now.

Code generation is generally a good idea,. but a single standard is not a good idea IMO. For instance the porter-duff operators have a very similar structure, not using code generation / #include tricks or something similar the amount of code gets quite large, fast.

http://pippin.gimp.org/gggl/snapshot/ops/composers/porter_duff/generate.rb.html

is the ruby based code generator I use in gggl to generate them all (I should probably look into extending the porter duff code to be both 8bit, 16bit and float since it is a case where a little work on the code generator will provide a lot of functionality.)

Defining a scripting language as a prerequisite for generating the GEGL source (perhaps not true for tarballs?).

/pippin

* Calvin Williamson [040923 18:02]:

Active nodes is a great idea. Each active node means that is a node that is currently interested in pulling data from all its dependencies, right?

Correct this can also be considered "multiple roots"

Right. You do want to have some sort of minimal recomputation scheme and it would be great if it wasnt just setting one region of interest on a root node like it is now in current gegl cvs. This is not ideal. I agree you dont want just a single invocation style evaluation manager.

How does gggl handle multiple regions of interest that come from pulling on different nodes in the tree?

Or do you just recompute everything in all the dependencies?

It just passes full frames at all times, which works quite well for video editing (scanline based rendering could be added to the current model to gain some performance.)

A longer explaination of the gggl processing model follows, it has several shortcomings but I chose the path of least obstacles to get a working system.

---------

gggl processing:

step 1) clear active flag on all nodes, and then set activate flag on all nodes in active set (recursivly flag providers that are not flagged active for all dependencies of "active/root nodes"

step 2) validate various requirements (number of input pads set, lack of cycles,. etc.) bail out if there is a problem.

step 3) call the init function on all nodes in active set, (the only thing that comes to mind being very important being in the init part of processing, is setting of output pixel format, e.g. png can be either 8bit or 16bit rgb, rgba, gray or graya.

step 4) negotiate the color space of all connections, by requesting a prioritized list of supported pixel representations for in_pad / out_pad, insert a proxy node if no agreement could be reached between two nodes.

step 5) do a topological sort of the active set (should probably be replaced by a visitor used in step 6)

step 6) invoke the process method on each node in the active set

step 7) remove proxies inserted in step 4

----------

One should probably create a temporary graph, (in gggl a node is a small wrapper around the actual Op instance), thus it would be possible to work on temporary graphs instead, doing transformations on graphs (reordering operations, placing color space conversions at the more correct places, collapsing affine transformations etc. could then be done in an easier way, I have not studied in detail how GEGL does this bit.)

I had imagined that for a tile-based approach, you would be putting tasks on a work pile and these would correspond to tiles and an area desired on each tile. If multiple roots were requesting data then it could be that the same tile would have multiple regions being requested on it. Something like that seems like what you want.

One of the advantages of tile based processing is the locality,. reducing the amount of memory that is accessed when processing,. ideally when doing rendering of a standard image stack where all layers are aligned, one would process one tile at the time,. from bottom to top to keep the data in memory.

I have some problems merging these two thoughts in my head, but it would essentially be a scheduling problem.

/pippin