Hi, > 2008/1/20, Burkhard Plaum <[EMAIL PROTECTED]>: >> The main weakness of the frei0r and other filter APIs is, that they >> are strictly synchronous i.e. one frame in, one frame out. >> >> This brings 2 important restrictions: >> >> - It's impossible to convert frames in-place > > This would be trivial to add, it's mostly a matter of adding another > flag and one more update prototype, or just reusing an existing > prototype. > > btw. do you have any code readily available that would justify such an > extension of the spec. I think that the spec should only be extended > when there is actual code that would benefit from that feature > IMMEDIATLY. But as always, this is only my opinion. :-)
I wrote a colormatrix module (which multiplies the channels of each pixel by a matrix), which does in-place processing. I wrote quite a number of filters based on the colormatrix, see here: http://gmerlin.sourceforge.net/plugins.html#plugin_fv The nice thing is, that you can specify a certain transformation (e.g. Hue/Saturation/Brightness) in YUV coordinates, transform the matrix into RGB coordinates and do the actual processing on RGB images. It works for all gavl pixelformats, with at least 8 bits per components and no chroma subsampling. > Indeed, and there are a couple of other deficiencies that I know of, > for example it is not possible to have a different input format and > output format, for example: I would like to send a 32bit per pixel > image to the filter and get an 8bit per pixel luminance map back. Or I > would like to have an arbitrary number of input channels and output > channels. but this is all not in the specification. Different input/output formats is no problem for me. Pixelformats are however, limited to what gavl supports. > It doesn't matter that much however, because even without those > features, frei0r serves a PURPOSE. And in my opinion an important one. > It is EASY to add support for frei0r to an application. And it is EASY > to write frei0r plugins. Frei0r is a playground that is fun to play > on, because the barrier to entry is so low. If a plugin spec would > require me to change my application, than it would have to provide > much more value and much cooler plugins for me to consider its > adoption. Sure, sometimes a limited (but simple) API is better than more complicated interfaces. > I was thinking about creating "Float0r", as a reference to Frei0r, and > while hinting on the possiblity of operating on Float-based > colorspaces, but it could also be Gmerlin Plugins or something else. Gmerlin plugins already support float RGB(A). I would consider adding float YUV(A) support as well if that would be needed. It seems, that on modern CPUs, floating point processing is faster than 16 bit ints. IMO the only disadvantage of gmerlin filters right now is for applications, which rely on plugins to be strictly synchronous. But most gmerlin filters are actually synchronous, they just aren't flagged as such by now. I also have a local tree of effecttv (http://effectv.sf.net) plugins ported to gmerlin. It's mostly fun stuff, but many plugins (e.g. AgingTV) were also ported to cinelerra. Burkhard _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
