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
archive/directory):
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
used.
<gegl>
<node id="bg0">
<property name="filter">blank</property>
<property name="width">640</property>
<property name="height">480</property>
</node>
<node id="bmp0">
<property name="filter">png_load</property>
<property name="resource">layer1.png</property>
</node>
<node id="vector0">
<property name="filter">svg_load</property>
<property name="resource">layer2.svg</property>
</node>
<node id="txt0">
<property name="filter">text</property>
<property name="resource">joke.pango</property>
</node>
<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>
<node id="layer0">
<property name="title">Background Layer</property>
<property name="filter">nop</property>
<input pad="0" idref="noise0"/>
</node>
<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>
<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>
<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>
<node id="out0">
<property name="filter">image</property>
<input pad="0" idref="layer3" />
</node>
<property name="author">
<property name="fullname">OEyvind Kolaas</property>
<property name="email">[EMAIL PROTECTED]</property>
</property>
</gegl>
<!--
and an ascii rendition according to ids:
bg0
|
noise0
|
layer0 bmp0
| /
| /
| /
| /
| /
layer1 vector0
| /
| /
| /
| /
| /
layer2 txt0
| /
| /
| /
| /
| /
layer3
|
|
out0
-->
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
larger.
<property name="brightness">
<curve interpolation="linear">
<key time="1.0" value="0.4 />
<key ../>
..
</curve>
</property>
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:
http://schweden.mine.nu/bauxite/userdir/new.xml
I think this catalog format is capable of expressing most (ALL?) things
needed,. it is kept minimal but allows easily extending within the
framework.
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
text.
/Øyvind K/pippin
--
.^.
/V\ Øyvind Kolås, Gjøvik University College, Norway
/(_)\ <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>
^ ^
_______________________________________________
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
