2008/9/25 Martin Christensen <[EMAIL PROTECTED]>: >>>>>> "Trond" == Trond Danielsen <[EMAIL PROTECTED]> writes: > Trond> All of the described plug-in classes fit into a flow graph type > Trond> of architecture: > > Trond> Input -> Filters -> Tools -> Output. > > Why can't I have Input -> Filter1 -> Output1 -> Filter2 -> Tools -> > Output2?
Of cause. There is nothing that would prevent you from creating a flow graph like that. I just want to mention that this architecture is taken from the GNU Radio software radio framework design. GNU Radio consist of two parts: 1. A collection of independent block which are described by their transfer function and their I/O signature. 2. A runtime system which connects the blocks together and controls the data flow through the system. I think this could be a useful approach to a raw converter and photo processing application. Remember: Radios and image processing are not that differenct; you just have to go from scalars and vector to two-dimensional matrixes :-) > Trond> These blocks could be described by their input and output > Trond> signatures. > > Why not just have one input/output signature, or, as it might be > necessary, two in order to handle pre/postdemosaicing? Is any more than > that necessary? The number of signatures needed is not clear to me, but I do not think that is a problem. As long as a base class exist that can be extended from new types of can be added to the system without breaking existing blocks. A new block with a obscure signature would just not have anything to connect. Blocks can also be input or output only block for file I/O. -- Trond Danielsen _______________________________________________ Rawstudio-dev mailing list [email protected] http://rawstudio.org/cgi-bin/mailman/listinfo/rawstudio-dev
