Half a year ago I submitted a proposal for an XML based catalog, for
usage within an archive or directory of some sort. Here is an update on
my musings, I will reiterate some of the ideas from back then, and try
to include some of the clarifications that was made afterwards.

The catalog is meant to describe how the resources are meant to be 
interpreted, and processed in relation with each other, the resources 
themselves are represented as files that are designed for each kind of 
resource. The XCF2 format would thus be a more of a project file when 
working with a IDE, than what is usually considered a file. Depending 
on how advanced the user is, this is something that can be totally 
ignored,. or be really nifty.

Examples of things that will be in seperate binary files (within the

    image data in various formats (png, jpg, raw,. )
    ICC profiles 
    fonts   (sure would be nice to check off 'include' font, when sending off
             a file that someone else will adjust)
    SVG vector graphics
    ChangeLog   (why not?)
The main reason I'm writing a new proposal is that development on my
video editor, based upon a GEGL philosophy is getting a richer feature
set, and that have provided me with some insight on what could be a good
approach to scale that format down, whilst keeping the structure open
for future extension.

The document http://schweden.mine.nu/bauxite/src/libgggl/Terminology.html
could be read as an introduction to gegl terminology if you know the
ideas it uses, but are unsure about which specific set of terms are

   <node id="bg0">
      <property name="filter">blank</property>
      <property name="width">640</property>
      <property name="height">480</property>

   <node id="bmp0">
      <property name="filter">png_load</property>
      <property name="resource">layer1.png</property>

   <node id="vector0">
      <property name="filter">svg_load</property>
      <property name="resource">layer2.svg</property>
   <node id="txt0">
      <property name="filter">text</property>
      <property name="resource">joke.pango</property>

   <node id="noise0">
      <property name="filter">noise</property>
      <property name="xscale">2.0</property>
      <property name="yscale">2.0</property>
      <property name="turbulence">0.4</property>
      <input pad="0" idref="bg0"/>
   <node id="layer0">
      <property name="title">Background Layer</property>
      <property name="filter">nop</property>
      <input pad="0" idref="noise0"/>

   <node id="layer1">
      <property name="title">Untitled layer</property>
      <property name="filter">over</property>
      <property name="hor">50.0%</property>
      <property name="ver">50.0%</property>
      <property name="opacity">69.0%</property>
      <input pad="0" idref="layer0" />
      <input pad="1" idref="bmp0" />
   <node id="layer2">
      <property name="title">Untitled layer</property>
      <property name="filter">over</property>
      <property name="hor">85.0%</property>
      <property name="ver">5.0%</property>
      <input pad="0" idref="layer1" />
      <input pad="1" idref="vector0" />
   <node id="layer3">
      <property name="title">Untitled layer</property>
      <property name="filter">over</property>
      <property name="hor">0.0%</property>
      <property name="ver">0.0%</property>
      <input pad="0" idref="layer2" />
      <input pad="1" idref="txt0" />

   <node id="out0">
      <property name="filter">image</property>
      <input pad="0" idref="layer3" />

   <property name="author">
       <property name="fullname">OEyvind Kolaas</property>
       <property name="email">[EMAIL PROTECTED]</property>


 and an ascii rendition according to ids:

    layer0  bmp0
     |      /
     |     /
     |    /
     |   /
     |  /
    layer1  vector0 
     |      /
     |     /
     |    /
     |   /
     |  /
    layer2 txt0
     |      /
     |     /
     |    /
     |   /
     |  /


This is the graph definition subset of the XML structure I'm currently
using in my implementation. It feels flexible,. and there are many
extensions that are easy out of the box, but doesn't neccesarily apply
to gimp's usage of gegl.

The decision to use <property name="">value</p> instead of 
<property name="filter" value="blur" /> is to keep the syntax as
consistent as possible,. the value of a property might be the actual
Pango markup,. inlined SVG,. or other applicable values. Currently I'm
using it for animation in my system. Allowing <p name="name"
value="value" />, is possible without conflicting, but it makes the DTD

<property name="brightness">
  <curve interpolation="linear">
     <key time="1.0" value="0.4 />
     <key ../>

For storage of layer stacks,. (like the example),. small graphs,. and
trees (layer groups) the outlined format is adequate. But if you make a
large graph,. or perhaps want to reuse parts of the graph. a <graph
id=""></graph> container tag taking nodes should be added,. allowing to
hide parts of the tree etc. If only nodes are referred to in the idref's
the file would be interpretable without the graphs,. but them the whole
graph would be "flattened".

For an example of a edited video project including an EDL from my application,
take a look at:


I think this catalog format is capable of expressing most (ALL?) things
needed,. it is kept minimal but allows easily extending within the

Since this format is wide open, a baseline format should also be
defined, the way to define the baseline would be to define a standard
set of filters that need to be supported by an application to load
baseline files,. this set of filters would probably map to the core
gegl filters for compositing, blurring, basic color adjustments and affine
transformations. In addition to some data Sources like, png, svg and pango

/Øyvind K/pippin

  /V\    Øyvind Kolås,  Gjøvik University College, Norway 
  ^ ^    
Gimp-developer mailing list

Reply via email to