If I might interrupt, a couple of other comments on plugins. First, sounds like a great idea, especially when combined with factoring "standard" elements of RawStudio itself out into plugins: both an example and a validation of the mechanism.
Regarding the choice of technology, I'd ask that porting be kept in mind please. One of these days I'll finally get around to doing a win32 port, if nobody beats me to it. It would be a shame for the plugin design choices to block this. Things that would probably be easiest from the porting standpoint are .so (==DLL) or a separate process. However, on the LightZone web page this comment leapt out at me: > All operations are live and have an immediate effect Sounds like a really cool usability feature. However, I think it might demand a bit more of the plugin architecture. [Haven't tried LightZone but as I read that line, it means that, e.g., moving a slider would have immediate visual effect in the displayed image.] At the risk of indulging in premature optimization, I'd suggest that if this feature is desired it leads to 1) .so / DLL to avoid process spawning / communications overhead and 2) possibly a split plugin processing interface offering one "fast" API for rendering at screen resolution and another for doing full-resolution rendering. I share the concern raised earlier about tightly integrated plugins causing stability problems, but I suspect that anything less than tight integration wouldn't support a dynamic UI experience. Not sure how hard it would be to introduce some sort of plugin disable facility, perhaps with automatic disable of plugins which are recognized to have behaved improperly in previous invocations (hang / crash). regards, Eric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Trond Danielsen Sent: Wednesday, September 24, 2008 9:59 PM To: [email protected] Subject: Re: [Rawstudio-dev] Plugins and librawstudio 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 _______________________________________________ Rawstudio-dev mailing list [email protected] http://rawstudio.org/cgi-bin/mailman/listinfo/rawstudio-dev
