Hi, for your information, I've compiled a list of popular or interesting Filter Plugin Specifications, that are available for implementation in Linux and Open Source/Free Software Applications.
*=* First of all there is frei0r, that I think everybody knows by now, since I've been pushing it for a while. ;-) http://freshmeat.net/projects/frei0r/ Implementing frei0r as a host is especially easy, particularly so if you already work with RGB or RGBA formats internally. Frei0r has its limitations, but it also has a decent selection of plugins available, which imho is one of the most obvious reasons to implement a host for a plugin format. *=* Then there are the Gmerlin Plugins, a list of them is available here: http://gmerlin.sourceforge.net/plugins.html#plugin_fv The API is slightly more complicated than frei0r, but it also allows for different colorspaces, and the available plugins can be operated in a range of different colorspaces. The plugins are also more technically focused, and some of them such as the colormatrix filter can be used as a backend for building other kinds of filters. btw. Gmerlin has a frei0r wrapper, and it also has ported a number of EffectTV filters. PS.: Gmerlin has a VERY broad plugin API, that also offers tasks that are for beyond simple video filters, this is why I don't think it necessarily competes with WEED for example. *=* There is Weed of course, which salsaman introduced recently: http://article.gmane.org/gmane.comp.video.piksel.user/3635 I am not really in a qualified position to discuss how Weed compares to gmerlin, although I would love to find out, or hear about the differences and advantages vs. disadvantages. Weed as far as I've seen has a decent selection of plugins available too, also based on EffectTV I think. *=* FreeFrame, an effect/filter API that seems to be widely popular in the visualists community is distinct due to its huge selection of hosts as well as plugins, lots of which do not qualify as free software though. :-( http://freeframe.sourceforge.net/ It appears to be simple and limited in its approach, although it has one technical feature that differentiates it from the others. Namely it specifies an extension that allows for OpenGL based filters. Using OpenGL, and especially the OpenGL Shading Language will likely have a significant impact in the near future of video processing, especially when performance is critical. Not only for realtime processing, but also for background rendering of High-Definition footage. As you might be aware, that both ATI and nVidia are massively pushing their GPUs for GPU based general purpose computing, and indeed the performance figures are impressive, when compared to CPU based designs. And especially for tasks as video filtering, GPUs are very well suited, and I guess that they can give you a lot more bang for the buck than CPUs. And since we care about free software, we should also care about enabling people to spend as little money as possible for as much performance as possible. *=* Ok, and now for something slightly different. The MathMap project is not a video filter API, strictly speaking. http://www.complang.tuwien.ac.at/schani/mathmap/ MathMap is a domain specific language for writing image filters. It is a nice environment to rapidly experiment with different algorithms and ideas, and I think that this can be a key for getting much more reusable video filters to the Open Source and Free Software community. Actually there is already a large collection of scripts available for it. I've already toyed with the idea of compiling mathmap plugins into frei0r or other videofilter plugins, but I've never had enough time or passion to make it happen. :-( There is however a blender-plugin generator in the MathMap source that might serve as a starting point for any takers. :-) (*hint*hint) ;-) And if someone happens to be into it, a translator that compiles the mathmap language into the OpenGL Shading Language would be very much appreciated. ;-) I guess those languages are slightly similar to begin with. *=* Where to go from here? What is still needed? Ok, we are getting higher resolution camera images, and multi-core CPUs, what in my opinion is still missing in all those approaches to plugin design, is a solid parallel multi-processing strategy. While it is up to the author to implement threading inside a plugin, I suggest that a reusable approach is more viable, and is ultimately less work for anyone involved. Considering that image processing is for the most cases a task that is very easy to parallelize, I think its only a matter of finding a common set of conventions and best practices to get it done. What do you think? Second: plugin composition. Combining basic plugins into more complex filtering networks can yield powerful meta-plugins, that can add a huge value to our video filter "offerings" :-P However, how can we pull together on the same string to achieve this? Ideally would be tools that allow to "compile" meta-plugins in a performance effective way, which might work with mathmap? And additionally, for plugins where this is not possible, some alternative mechanism would be useful. And of course as many apps as possible should benefit from such an effort. Any Ideas about how to pull this of? Sketches? Design-Document Brainstorms? Everything helps. ;-) *=* That's all folks, If I missed things or if you feel you have to add/debunk/flame anything, get it on. :-D Cheers, and have fun -Richard _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
