RSS/Atom feed Twitter
Site is read-only, email is disabled

Public GEGL API Reference

This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

5 of 5 messages available
Toggle history

Please log in to manage your subscriptions.

Public GEGL API Reference Øyvind Kolås 25 Jan 13:18
Public GEGL API Reference Håkon 26 Jan 11:42
Public GEGL API Reference Øyvind Kolås 26 Jan 13:37
Public GEGL API Reference Martin Nordholts 26 Jan 21:19
Public GEGL API Reference Øyvind Kolås 27 Jan 00:40
Øyvind Kolås
2007-01-25 13:18:14 UTC (about 17 years ago)

Public GEGL API Reference

Work is under way on documenting the GEGL API. The core of the API is rather small (less than 15 entry points for the core of creating and processing image compositions, and the rest is syntactic sugar or state queries).

Please also look through this API with a critical eye and report thoughts on the API back to the mailing list.

Improvements to the text itself are best sent as a patch against gegl/gegl.h.

A snapshot of the documentation can be found here: http://gegl.org/api.html

Later this will contain the api reference for the actual release and be a part of the GEGL documentation (as it is in SVN now if you run autogen.sh / make api.html in docs. After a checkout (assuming you've got ruby installed).

/Øyvind K.

Håkon
2007-01-26 11:42:06 UTC (about 17 years ago)

Public GEGL API Reference

Right, some questions. I'm not familiar with the code, sorry for asking about anything obvious.

What does one node being a child of another do? Why wouldn't you just create all your nodes at top level and connect them? Can you only connect siblings? Does a top level node have an operation?

gegl_node_connect_from and gegl_node_connect_to seem to work opposite from what I'd expect.
Having two operations that do the same thing but with different argument order is usually bad. If they aren't unambiguously named it certainly isn't going to improve readability, which seems to be the intention.

From what I understand one output can be connected to several input. Can one

input also read from several outputs, or does a connect_to to an occupied input disconnect the previously connected output? If so, is there any way for a node take an arbitrary number of inputs?

gogl_node_detect seems to have somewhat limited use... I see how it would work for a simple concatenation of images or non-transparent overlays, but what should it return if several inputs are merged?

What are proxies used for? "Route between nodes of a subgraph contained within a node"? Isn't that what normal connections do?

- Håkon

On 1/25/07, Øyvind Kolås wrote:

Work is under way on documenting the GEGL API. The core of the API is rather small (less than 15 entry points for the core of creating and processing image compositions, and the rest is syntactic sugar or state queries).

Please also look through this API with a critical eye and report thoughts on the API back to the mailing list.

Improvements to the text itself are best sent as a patch against gegl/gegl.h.

A snapshot of the documentation can be found here: http://gegl.org/api.html

Later this will contain the api reference for the actual release and be a part of the GEGL documentation (as it is in SVN now if you run autogen.sh / make api.html in docs. After a checkout (assuming you've got ruby installed).

/Øyvind K.

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

Øyvind Kolås
2007-01-26 13:37:27 UTC (about 17 years ago)

Public GEGL API Reference

On 1/26/07, Håkon wrote:

Right, some questions. I'm not familiar with the code, sorry for asking about anything obvious.

What does one node being a child of another do? Why wouldn't you just create all your nodes at top level and connect them? Can you only connect siblings? Does a top level node have an operation?

A node that is a child of another node will be destructed when the parent is destructed. This is similar to how memory management works in a GUI toolkit with containers, destroying the container destroys the child nodes as well. I also want to add the ability to unref a child node directly which would break the parent/child relationship.

There is nothing that stops you from connecting non-sibling nodes, the parent/child relationships are mostly there to organize code/data structures in a manageable way.

gegl_node_connect_from and gegl_node_connect_to seem to work opposite from what I'd expect.
Having two operations that do the same thing but with different argument order is usually bad. If they aren't unambiguously named it certainly isn't going to improve readability, which seems to be the intention.

Both of the methods work on a node, thus for connect_from you connect an inputs pad of a node from the output pad of the other node. And opposite, the first argument to the method is "self", the object being acted upon. connect_from
is the one that is used internally and makes most sense from an OOP point of view.
But when writing code it is perhaps more natural to think that one wants to connect data from an output pad of a node to the input pad of another node, hence gegl_node_connect_to exist in the public API to allow writing code that reads
more naturally.

From what I understand one output can be connected to several input. Can one input also read from several outputs, or does a connect_to to an occupied input disconnect the previously connected output? If so, is there any way for a node take an arbitrary number of inputs?

A named input pad for instance "input" can only read from a single source, composer nodes like "over" or "difference" also have an input pad named "aux"
which other data can be connected to.

gogl_node_detect seems to have somewhat limited use... I see how it would work for a simple concatenation of images or non-transparent overlays, but what should it return if several inputs are merged?

At some point it will probably be extended with options to specify whether the current mode of operations should be used, or if it should have pass the request through transparent regions of the overlays.

What are proxies used for? "Route between nodes of a subgraph contained within a node"? Isn't that what normal connections do?

Proxies are used when creating a node that is a graph. This allows you to create a sub graph that can be reused as a node in another graph:

The following ASCII art illustrates an example, here we load an image, and have inserted a node that applies a watermark (it could be more complex than this). The sub graph is a node that has two normal children and two proxies, one for each pads, the proxies are siblings of the other children of the graph and thus can be connected. These proxies act as middle men making it possible to use the watermark node directly in the top-level graph.

.----------. | png-save |
`----------'
|
.--[output]----. );
gegl_node_link_many (in_proxy, over, out_proxy, NULL); gegl_node_link_many (load, watermark, png_save, NULL); gegl_node_process (png_save);
g_object_unref (gegl);

The operations in the meta category are implemented using this internally, operations that are graphs themselves http://gegl.org/operations.html#cat_meta

Martin Nordholts
2007-01-26 21:19:42 UTC (about 17 years ago)

Public GEGL API Reference

I think gegl_node_disconnect feels more 'safe' than passing NULL to gegl_node_connect_from, because I think connect_from implies that it expects something, i.e. that passing it NULL would cause a segfault.

If the method was named gegl_node_set_input, then passing NULL would feel more 'safe'. I still think connect_from is a better method name though, hence I think having a gegl_node_disconnect makes sense.

Well, that's all, maybe because I'm semi familiar with the API already. I think the docs seems to cover the API nicely; more questions will probably arise when I have time to start using the API more extensively.

- Martin Nordholts

Work is under way on documenting the GEGL API. The core of the API is rather small (less than 15 entry points for the core of creating and processing image compositions, and the rest is syntactic sugar or state queries).

Please also look through this API with a critical eye and report thoughts on the API back to the mailing list.

Improvements to the text itself are best sent as a patch against gegl/gegl.h.

A snapshot of the documentation can be found here: http://gegl.org/api.html

Later this will contain the api reference for the actual release and be a part of the GEGL documentation (as it is in SVN now if you run autogen.sh / make api.html in docs. After a checkout (assuming you've got ruby installed).

/Øyvind K.

Øyvind Kolås
2007-01-27 00:40:44 UTC (about 17 years ago)

Public GEGL API Reference

On 1/25/07, Øyvind Kolås wrote:

Please also look through this API with a critical eye and report thoughts on the API back to the mailing list.

I have now changed the arguments (added some, and reordered them into an order I think makes most sense for gegl_node_blit). A rough outline for the documentation of the arguments has also been added.

void gegl_node_blit (GeglNode *node, GeglRectangle *roi, gdouble scale, void *format, gint rowstride, gpointer *destination_buf, GeglBlitFlags flags);

See for further documentation of the new arguments.

The change came about due to integration of the projection cache into the node. Having caches integrated with nodes will be needed for internal cache handling anyways, and the API's for requesting data from the cache/vs the node might not be the best approach.

The argument list might be considered to be a bit long, but I think we can live with it.

/Øyvind K.