I've been asked by Øyvind Kolås <[EMAIL PROTECTED]> to
forward this proposal to the list on his behalf...


--- Begin Message ---
Sven could you forward this to the list, my mailing possiblities from the 
camp is kind of braindead.

What follows is a proposal for a format to save a GEGL processing graph and
it's associated data. It is not completly thought through, but it could serve
as a starting point.

The total amount of information required to store a processing graph contains
many different forms of information. Amongst these are:

        processing graph
        main graph
        sub graphs
        project meta data
        image data
    video data
    textual data
    audio data (unsure about this one, but it might be necessary)
    other data,. (it could be feasible that e.g. a 3d model might be stored)
Since a GEGL processing graph is basically somethings that ties different kinds
of data together and describes how they relate to each other, separate files
seems like a good idea, the files should be bundled together either in an
archive, or directory. As a baseline directory access should be supported, and
some other archive format like tar or ar should be chosen.

The processing graph should be an XML file that refers to the files in the
archive/directory relative to the base path. A graph can include subgraphs
these can either be defined in the same XML file as the main processing graph,
or be references to other XML files within the archive/directory containing
GEGL graphs. (a naming scheme like #subgraph for same file references and
file.xml#subgraph for external references could be used).

Since different applications using GEGL can have differing needs, some kind of
complexity level should be stored.

Aspects that might differ between applications are things such as:
        number and type of node operations permitted
        which might be things such as
                image sources
                file format loaders
                blank providers
            compositing methods
                like changing opacity, or rendering stuff into an image.
                blurring and other filter layers
    "grammatical" rules about the topology of the graph
        the graph sketched at the end of this description is a simple layer based 
        graph, which is easily translatable into the GUI of gimp

For example gimp 1.3 uses a quite reduced topology in it's compositing graph,
and the number of operations allowed on the image data is quite limited, and
only needs the ability to describe a layer stack, the layer modes allowed and
loading of png files.

In order of increasing complexity I propose the following levels:

        level 1  -  layer-stack topology,
        level 2  -      free topology
    level 3  -  key-framed parameters for the filters, not useful for gimp
                but very useful for an video compositor or a NLE
When loading a file that uses "illegal" graph topologies, but known operations,
gimp could either render the layers and channels dialog unusable, (possibly
replacing it with a graph editor), or "semi-flatten" the graph into something

The case of unknown operations is harder since the application won't be able
to perform the needed operations.
All implementations should implement some simple operations like loading a png
file and normal over compositing.

Using png as one of the standard "layer formats" gives the benefit of
8bit->16bit color-spaces, in gray and rgb both with and without post-multiplied
alpha. It does however loose the ability to read tiles directly from disk, this
could be accomplished by having an internal "raw" image format used by gimp,.
this would however probably break compatibility with other applications,.
unless this is a GEGL standardized format. For floating point image buffers 
something like this will probably be needed anyway.

Example for replacing current XCF format:

Gimp will eventually use GEGL for compositing images, it almost makes sense to
define the format used as a GEGL format instead of a gimp format, by doing this
applications using GEGL, will have an easy time importing and exporting
processing graphs.

Here follows the compositing graph needed for a simple image, a logo with a
blurred shadow over a white background, a total of three layers.


[ new "rgb-8bit" "512x384" ]    ( this new operator, and fill, is actually 
   |                              not existant in current gimp xcf format,
[ fill 1.0 1.0 1.0 ]              but it is a really basic feature )
   |                         [ load "shadow.png" ]
   |                             |
   |                         [ opacity 0.5 ]
   |                             |
   |    ________________________/
   | /
[ composite 0.0 0.0 ] 
   |                         [ load "logo.png" ]
   |   _________________________/
   | /
[ composite 0.0 0.0 ] 
[ return ]

The XML graph describing the above ascii art representation.

    this file doesn't use features like keyframing, or references to subgraphs,
    but the format seems quite versatile, even tough some adjustments are
    The format should be changed by someone versed in the sorcery of xml, into
    using xlinks,.. and perhaps clean up the verboseness in some places..

<?xml version="1.0" encoding="ISO-8859-1"?>
    <parasite name="author" value="Øyvind Kolås" />
    <parasite name="project" value="dropshadow" />
    <parasite name="comment" 
              value="logo with dropshadow, actually just a xcf import" />

        <graph name="main">
        <node filter="new">
                <output id1="1"/>
                <parameter name="colorspace">
                <value string="rgba" />
                <parameter name="width">
                <value float="512" />
                <parameter name="height">
                <value float="384" />
        <node filter="fill">
                <input ref1="1" />
            <output id1="2" />
            <parameter name="color">
                <value color="1.0 1.0 1.0" />
        <node filter="png_load">
                <output id1="3"/>
                <parameter name="file">
                <value string="shadow.png" />
        <node filter="composite">
                <input ref1="2" />
            <input ref2="3" />
            <output id1="4" />
            <parameter name="x"> 
                <value float="0.0" /> 
            <paramter name="y">
                <value float="0.0" /> 
        <node filter="png_load">
                <output id1="5"/>
                <parameter name="file">
                <value string="logo.png" />
        <node filter="composite">
                <input ref1="4" />
            <input ref2="5" />
            <output id1="6" />
            <parameter name="x"> 
                <value float="0.0" /> 
            <paramter name="y">
                <value float="0.0" /> 
        <node filter="return">
                <input ref1="6" />


some random ramblings follow,..

a text layer?,.. (thats kind of easy with a text filter, font parameter, and
  text parameter)..
a vector layer?,.. could be just a vector filter,. taking a long list of 
coordinates,.. vectors in text files aren't very human readable anyways,..

--- End Message ---
Gimp-developer mailing list

Reply via email to