Re: [Gegl-developer] basic concepts and usage of gegl in gtk

[Debarshi Ray <rishi is lostca se>]

Hey Vincent,

On Wed, Dec 28, 2016 at 11:34:25PM +0100, Vincent wrote:
> I'm evaluating gegl to replace the image display part of siril, a free
> astronomy image processor [1]. Siril is a GTK+3 application, so I
> naturally tried gegl-gtk which seems to have be abandonned for some
> time. I have updated it to compile with gegl 3.10, and examples are
> apparently working, if someone is interested the code is available [2].
>
> I have a hard time understanding the basic concepts of GEGL, in
> particular the graph. I could not find a clear documentation for GEGL so
> my knowledge comes mainly from the gegl-gtk examples,

There is some documentation on http://gegl.org/. If you are looking
for real world GTK+ applications based on GEGL, you can look at GIMP
(https://git.gnome.org/browse/gimp) or GNOME Photos
(https://git.gnome.org/browse/gnome-photos).

As for GTK+ widget to render the output of a GEGL graph, GNOME Photos
started out by using gegl-gtk (it actually had a copy of the code to
avoid depending on a weakly maintained library). Since then the code
has evolved a bit and can be found in src/photos-image-view.[ch].

> so please tell me
> if the following is right: some nodes of the graph are data producers,
> some are data processors,

Right. GEGL uses 'source' and 'sink' instead of 'producer' and
'consumer'.

> some are data consumers like saving to disk or
> displaying. In general, there's one data producer and one data consumer
> in the graph, and there can be many data processors, the image
> processing operations.

It is not that uncommon to have more than one data producer (or
source) in a graph. eg., if you want to apply a gradient or vignette
to an image.

Similarly, you may have multiple sinks connected to a source.

> The fact that there seems to be a root to all
> graphs,

Note that the root node is optional, but, yes, nodes usually have one.

> from which all other nodes are instantiated as children with
> gegl_node_new_child() is very disturbing because that would mean that it
> is a tree, not a graph, so I assumed that nodes are automatically
> connected from parent to child, which doesn't seem to be the case at
> all.

The root is mainly for convenience. For example:

(a) The root node usually takes over ownership of the other nodes in a
graph, so you don't need to destroy them individually.

(b) A node can have a meta-operation constructed from several other
operations. As long as the internal nodes are connected to the
input/output/... proxies of the parent, it will behave like any other
node.

> I will need two types of graphs for image data display: one for grey
> images channels display with at least a basic brightness/contrast
> control duplicated for each of the R G and B channels, one that displays
> colour images recombined from the three greys. Anybody has an idea about
> how I can recombine the resulting images from the three grey graphs and
> display it into a new gegl-gtk widget?

You will need a composer to re-combine the three channels. Since you
have 3 inputs, you will need an operation that sub-classes
GeglOperationPointComposer3. There might be something already
available in GEGL (grep for GEGL_OP_POINT_COMPOSER3), or you can write
your own.

I hope this helps.

Happy hacking,
Rishi