* Todd Relyea <brewer13210@xxxxxxxxx> [060130 10:17]: > - Has there been a clear delineation made between the > functionality of the future GIMP front end and GEGL? All image processing (pixel modifying routines) should _eventually_ be moved to GEGL. The interface to GEGL should be the Directed Acyclic Graph describing processing operations. (A way to look up available nodes, and their parameters is needed as well, it might be possible to recycle some of the PDB (Procedural Data Base) in current GIMP to do this. > The todo and bugzilla: > > There are 7 bugs listed in bugzilla, but they're all > pretty old. Do they actually reflect things that need > to be done against the current code base? I have not even looked at the bugzilla, my guess is that if we are going to start using bugzilla again it probably makes sense to start with a clean slate. I'll try to find time to go through the list and figure out which bugs can be closed. > Same question for the 'todo' on the gegl web site and > CVS. That TODO was written during the code cleanup this summer and can be seen as a tentative roadmap written while trying to orient myself in the code base. > Lastly, what is the absolute minimum that needs to be > done in order for gegl to be minimally usable? > Reading through the docs and mailing list, it looks > like some work needs to be done on the buffers. Yes the buffers is the main outstanding thing right now, this summer/beginning of the autumn I coded babl http://pippin.gimp.org/babl/ for generic and extendable pixel format (bitdepth and color space) conversions. This has some overlap with what is already in the gegl/image/ code which also has code dealing with color models and color spaces, babl does work (it evolved from code in gggl, and my gggl is currently using babl). I do not feel confident enough to attack the gegl/image folder, and thus have started working with buffer representation elsewhere. http://pippin.gimp.org/horizon/ contains my buffer experiments. The result is that I know understand most of the issues that gegl/image is trying to solve but I have not exercised the code enough to have a firm grasp of API requirements. The currently nice aspects of my tile based bufffer in horizon is that the buffer is unbounded, and it contains an automatically updated image pyramid for efficient scaled down views. > then maybe create a very basic front end so people can > actually play with the library, even if all of the > functionality isn't implemented yet. Once it is possible to set up graphs and process them. A first minimal set of ops would quite probably be png_load, png_save, display, over and a single point based op. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ _______________________________________________ Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
