On Tue, 26 Oct 2004 22:18:08 -0400, Jean-Sebastien Senecal <lord_tatien@xxxxxxxx> wrote: > Øyvind Kolås wrote: > >On Sun, 24 Oct 2004 14:13:54 +0200, Sven Neumann <sven@xxxxxxxx> wrote: > > > > > >>Hi, > >> > >>Jean-Sebastien Senecal <lord_tatien@xxxxxxxx> writes: > >>> I'm working on an open-source software for real-time mix-medias, > >>> similar to Puredata. We've started using part of the Gimp code for > >>> image processing. For now, I was able to move the composition > >>> functions in paint-funcs. However, since the functions are not > >>> documented, I find it often difficult to know what this or this is > >>> doing. Plus, I don't understand well how the files are organized. > >>> > >>> > >>You are trying to reuse the part of the GIMP code that we would like > >>to get rid of the sooner the better. The basic image manipulation > >>routines date back to the early days of GIMP development and haven't > >>seen the refactoring that all other parts of the code have gone > >>through. I would not suggest to use this code at all. You should > >>consider to use GEGL instead. But then, GEGL is probably not at the > >>point yet where it would fulfill your needs. > >> > >> > > > >gggl ( http://pippin.gimp.org/gggl/ ) might be a starting point, since > >gggl aims to > >be API compatible with a future GEGL. If you are going to use such functionality > >from a higher level programming language a future migration should be easy. > > > >At the moment I've been mainly focusing on high quality, rather than high speed > >and thus implemented most of the image processing only for floating > >point buffers. > >The system is designed to allow for optimizations in the form of > >adding 8bit/16bit versions of operations alongside the floating point > >versions. > > > >My intention is to port my abstractions on top of gggl to GEGL, and thus my > >tool chain from gggl to GEGL, after that porting the operations is one > >of my priorities. > > > >Depending on how urgent your needs are,. if you have some time to > >spend helping out with GEGL development in the near future, that would > >also be greatly appreciated. > Actually, part of the software we are currently developping is pretty > similar to gggl. However, what we fear is that : > 1) gggl as well as GEGL are not implemented with real-time processing in > mind I have been successfully using gggl in interactive displays, at the moment I focus more strongly on being correct than being fast, adding 8bit support; in addition to floating point, to the needed/most used operations is all that would be needed for software optimizing. It might also be feasible to hardware accelerate some operations. > 2) none of them tries to integrate audio Work has started on integrating audio in gggl, my initial approach works for non real time rendering,. (dropping video frames is acceptable, dropping audio fragments is not). Thus audio and video needs to be separated, the simplest robust way to implement synchronized playback is to have audio and video in separate threads syncing the video thread to the audio time. Having them in separate threads would be easiest by splitting audio/video handling. >> What we're really looking for, and would like to contribute to in the > near future if such a project takes place, would be a library that > generalizes the concept of graphical flow to both audio and video (and, > maybe, other inputs like signals from sensors or even chains of words) > and that tries to integrate very efficient processing algorithms for at > least the basic effects (like image compositions). I haven't heard of > such a project for now. Another project you maybe haven't heard about that can be interesting to look at is: http://mlt.sourceforge.net/ Although the intentions of those projects somewhat differ from the things you plan to do. /pippin | Øyvind Kolås -- Software patents hinder progress | http://swpat.ffii.org/ Web : http://pippin.gimp.org/
