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. sounds good. 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 fantastic. > 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).. seems wise. > 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 default). 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. Later Alan _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
