It's been quiet lately,. are everybody asleep, cramming for exams or busy at work? I've been thinking about gegl, hoping that the project will start it's engines again soon,.. here are some of my experiences from a toy app/library thing that I'm coding to crystallize some of my ideas about what gegl could or should be: I'll try to give a brief tour of the source in this mail,.. http://phpweb.hig.no/~oey_kola/ggfx/filter.h http://phpweb.hig.no/~oey_kola/ggfx/image.h and http://phpweb.hig.no/~oey_kola/ggfx/csp.h contains the functions exposed to plugins, for an example plugin (.so) http://phpweb.hig.no/~oey_kola/ggfx/plugins/bcontrast.c or http://phpweb.hig.no/~oey_kola/ggfx/plugins/avg.c is a nice small example altough it doesn't use the api to the full extent yet. Short description and calling order for the functions a plug-in can provide are at http://phpweb.hig.no/~oey_kola/ggfx/doc/plugin_api Key features of the API, the image struct is rich on information and thus should be useful for generalising over many formats. The API provides wrapper malloc/free and related functions to avoid leaks in plug-ins. Images are the only thing passed along the edges (as suggested for gegl,. ) Parameters are passed and serialisable as strings. The same api for sources, sinks, filters, multiplexors and demultiplexor plug-ins. ------ the layer above the filter is the graph, using the graph api it should be possible to build interesting applications,.. the graph level is probably where the gegl domain would end if you compare it to this thing. http://phpweb.hig.no/~oey_kola/ggfx/graph.h contatins the graph API The code snippet below is enough in the current implementation to change the brightness and contrast of an image and display it. void main () { Graph *graph=graph_new(); int loadpng_id = graph_add (graph, "loadpng"); int bcontrast_id = graph_add (graph, "bcontrast"); int display_id = graph_add (graph, "display"); /* link up the nodes in the graph */ graph_link (graph, loadpng_id, 0, bcontrast_id, 0); graph_link (graph, bcontrast_id, 0, display_id, 0); graph_node_setparams_id(graph, loadpng_id, "test.png"); graph_node_setparams_id(graph, bcontrast_id, "0.2 0.8"); graph_init (graph); /* call init functions (checks png type)*/ graph_csp_negotiate (graph); /* inserts needed proxy filters for colorspace conversions */ graph_execute (graph); /* execute the graph */ graph_free (graph); /* free memory used by graph and filters */ } ----- in the current implementation I've got a not quite as tidy implementation of a text file based description language able to read files like: (the actual script I used for a music video thing I recently helped create) # ascii-art representation of graph # # loadpng $frame:8:0.png # | # forcefmt rgbP8 # | # tee # |\_____________________________ # | \ # quadtree $high quadtree $low # | _____________________________/ # |/ # avg # | # bcontrast -0.03 0.85 # | # forcefmt rgb8 # | # clone # |\_____________________________ # | \ # savepng output/$frame:8:0.png display $frame:0:0/$timend:0:0 # # # forcefmt is currently used to force the conversions before the splits. # the negotiation algortihm should be made smarter and do as few # conversions # as possible, then forcefmt should be unneccesary most of the time. # ############################################################################ # the actual processing graph, plugin [parameters] [inputs] | # [outputs] png_load gfx/abon/$frame:8:0.png | % forcefmt rgbP8 % | % tee % | %low_in %high_in quadtree $low:0:0 %low_in | %low_out quadtree $high:0:0 %high_in | %high_out avg %low_out %high_out | % bcontrast -0.02 0.85 % | % forcefmt rgb8 % | % clone % | %todisp %todisk png_save gfx/abon/output/$frame:8:0.png %todisk | display $frame:0:0/$timeend:0:0 %todisp | - # start value, end value and stepvalue for looping over the graph timestart 1 timeend 4407 timestep 1 # interpolated values, time=value pairs frame 1.0=1.0 4407.0=4407.0 high 0=145 229=145 449=130 487=187. 488=225 510=171 526=160 high 661=160 662=155 858=155 859=155 1027=155 1028=200 1173=200 # many more time=value pairs,.. low 0=64 229=64. 432=89 449=94 470=34 487=34 low 488=24 509=111 510=49 526=72 661=72 662=92 858=92 859=117 # many more time=value pairs,.. ----- the thing should compile,. and a tarball is located at http://phpweb.hig.no/~oey_kola/ggfx/ggfx.tar.gz Some things I'm considering/ realizing: - colorspaces and csp conversions should be completly pluggable - which needs a rich image structure to be extendable,.. I think the one used in image.h is approaching something useful,.. of course tiling/multires? and such could be added later. - I'm trying to think whether logical clocks (plain incrementing counters) could be useful for stating that parts of the graph has changed (for buffering and such) - By allowing some arbitary data to follow the frame would allow passing audio samples, but that is not a concern of the image graph IMHO,.. for a video app,.. the audio and video pipelines should be seperate,.. or gstreamer could be used, albeit that would probably limit other things. - If possible plain C should probably be used for the plug-ins,.. GUI should be seperate,. could be arranged by automatically marshalling serialized data,. or by hand coding an interface. This will make it easier for others to start coding, and will keep things simple at that level. (where things _should_ be simple),. magic happens in higher levels. any ideas on the general design of this, and my comments on experiences drawn from this mini project? /Øyvind K. -- .^. /V\ Øyvind Kolås, Gjøvik University College, Norway /(_)\ <oeyvindk@xxxxxx>,<pippin@xxxxxxxxxxxxxxxxxxxxx> ^ ^
