Hi, I've been asked by Øyvind Kolås <[EMAIL PROTECTED]> 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 ---
_______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
