On Fri, 8 Aug 2003, [iso-8859-1] Øyvind Kolås wrote:
> Date: Fri, 8 Aug 2003 21:36:05 +0200
> From: "[iso-8859-1] Øyvind Kolås" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Ideas for Gimp/GEGL file format.
> 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.
> 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.
it makes sense, a GIMP file is more like a project file than a merely
final image format. Being able to use popular file formats directly as
layers would probably be very useful to help prevent unnecessary decoding
and reencoding of files.
> 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.
"Eventually", that worries me deeply however the idea of doing this
through GEGL and having a clearly documented standardised file format that
third parties can use, and more importantly would want to use sounds
> some random ramblings follow,..
my favourite kind of ramblings :)
> 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,..
seems very wise.
ideally would use SVG for the XML backend to allow for better
interoperability with other tools, ideally GIMP and Sodipodi will
eventually play together even better than Adobe Photoshop and Illustrator.
For expediency you might allow legacy gfig files to be embedded (and
include the associated brush information for rending the line).
i have been playing with gfig quite a lot and since noticing that you can
tell gfig to render as a new layer instead of on top of the current layer
I have not gone back (and i seriously think it would be a much better
Given the limited undo stack in the GIMP, having it as a seperate layer
makes it so much easier to remove the whole layer rather than to try and
undo each and every stroke (although again because of the limited undo
stack I have tried try to make my gfig stencils using as few continuous
lines as possible).
I wonder why gfig even has render to current layer, users could merge
layers if they really wanted. Rendering each line to a seperate layer
seems like overkill for simple drawings but for much more complicated
drawings or if anyone was trying to turn a gfig drawing into an animation
I see how it could be useful.
Gimp-developer mailing list