@pippin: Regarding arbitrarily large frames: ============================================
I know your software(gegl) supports arbitrarily large frames, but just think about it, one day in the future we will have to map the complete spectrum of visible and unvisible wavelengths into a giant HDR Image, and then one pixel will too large to fit into the memory, so if we want to be truly flexible, we want to make our architecture flexible enough to handle that by making it such that we can have parts of a pixel in memory and perform operations on that ;-) I am only joking of course and playing devils advocate. I agree that there is a need of having huge frames, especially in Movie Production, and thinking about the "RED" and things. I just want to mention that maybe the approach of using proxies for editing and a dedicated rendering engine for those huge files might be a more "viable" approach. Just have the editor spit out an XML file for GEGL and have it sent to a render-node/farm. :-) I am all for doing little baby steps, and working on simple stuff first instead of trying to do everything and the kitchen sink in one huge monolithic software package. :-) Seperate the hard projects into separate sub packages. (GEGL and huge frame rendering, could be such a sub-project) ;-) Pull vs. Push in Video Effects: =============================== In my opinion, there is no one size fits all: It makes no sense to require a callback if the operation always works on a single frames. Ideally, it would be desirable to completely seperate such plugins, because think about using image processing plugins in image editors (gimp/krita) etc, and using plugins from such apps. Ideally plugins and effects should be interchangeable between image and video apps. (But then we need tiled rendering again, because image apps want huge frames. :-( Ignore that for a little while. ;-) ) Maybe we want a "Stack" of plugin APIS? simple ones for simple things, and complex ones that are able to "wrap" simple plugins? I will be working on the following, mainly because I need/want it: a Plugin-API that is similar too Frei0r, but defines more colorspaces. Additionally I will add support for "more" inputs/outputs per plugin, mainly to cater to node-based compositing apps. Therefore I would need the ability to support single channel frames, like for example: a RGBA seperator plugin: it has 1. 32bit RGBA input and 4. 8bit single channel outputs. As for parameters and plugin descriptions, I will also add Individual Names for each Input/Output Port. This what I will be doing. I am happy to cooperate with anyones Plugin API to create an "Ecosystem" of APIs that is each specific to its purpose, while promoting as much interoperablity as neccessary. Evolve, Extend and Proliferate. :-) Btw. I am very interested to get MathMap and Frei0r into one boat, but currently I don't have too much time left for pursuing that. Anyone interested in that on in general? Or even able to help out? ;-) Cheers -Richard _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
