Hi,
I've been asked by Øyvind Kolås <pippin@xxxxxxxxxxxxxxxxxxxxx> to
forward this proposal to the list on his behalf...
Sven
--- 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
author
title
tags/parasites
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
filters
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
usable.
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.
test.xcf2
|`-gegl.xml
|`-logo.png
`-shadow.png
[ 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
needed.
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"?>
<gegl>
<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>
<parameter name="width">
<value float="512" />
</parameter>
<parameter name="height">
<value float="384" />
</parameter>
</node>
<node filter="fill">
<input ref1="1" />
<output id1="2" />
<parameter name="color">
<value color="1.0 1.0 1.0" />
</paramter>
</node>
<node filter="png_load">
<output id1="3"/>
<parameter name="file">
<value string="shadow.png" />
</parameter>
</node>
<node filter="composite">
<input ref1="2" />
<input ref2="3" />
<output id1="4" />
<parameter name="x">
<value float="0.0" />
</parameter>
<paramter name="y">
<value float="0.0" />
</parameter>
</node>
<node filter="png_load">
<output id1="5"/>
<parameter name="file">
<value string="logo.png" />
</parameter>
</node>
<node filter="composite">
<input ref1="4" />
<input ref2="5" />
<output id1="6" />
<parameter name="x">
<value float="0.0" />
</parameter>
<paramter name="y">
<value float="0.0" />
</parameter>
</node>
<node filter="return">
<input ref1="6" />
</node>
</graph>
</gegl>
---
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 ---
