2008/9/24 Martin Christensen <[EMAIL PROTECTED]>: >>>>>> "Anders" == Anders Brander <[EMAIL PROTECTED]> writes: > > I'll take the liberty of returning to the original post. In another > post, I've just proposed an architecture based on simply piping > configuration and image data through a daisy-chain of plugins/filters. > That leaves me with some questions and comments that are relevant here. > > [...] > Anders> I see at least four types of plugins: > Anders> INPUT plugins: Raw-loader, jpeg-loader, live-capture, ... > > This kind of input filter would certainly need to be unique in the > daisy-chain, but does it have to be first? Aren't there noise reduction > algorithms, for instance, that work on the image before demosaicing? If > so, two separate protocols (or two subprotocols) would be needed in my > proposal, one before and one after demosaicing, I suppose, because there > must be rather large differences between a mosaiced and a demosaiced > image, right? > > Anders> FILTER plugins: Exposure/saturation/etc, sharpen, ... > Anders> OUTPUT plugins: Savers, previewers, printing, ... > Anders> TOOL plugins: Geo-tagging, red-eye-removal, special effects, ... > > Logically these are distinct types of plugins, but technically I don't > think they need to be. If it's all just configuration-and-image in, > configuration-and-image out, anything can be put anywhere in the chain. > Of course, it might not always make perfect sense, but it could be done.
Hi everyone, this is my first post to this list! All of the described plug-in classes fit into a flow graph type of architecture: Input -> Filters -> Tools -> Output. These blocks could be described by their input and output signatures. As others have mentioned, for many non-linear filters the order in which they are applied make a lot of difference. The user should therefore be in control of both which filters are applied and in which order. Take a look at how this is done in Lightzone. > Anders> I think a roadmap could be something like: > Anders> - Move as much as possible of Rawstudio into librawstudio. > > What does that mean in this context? What is, at its heart, > librawstudio? > > Anders> - Implement some sort of plugin manager. > > Obviously necessary. > > Anders> - Move basic features from Rawstudio into seperate in-tree > Anders> plugins. > > This, as I see it, would be almost everything except the GUI and the > plugin manager. > > Anders> - Party with beer! > > Now, THAT makes sense to me! :-) Are you guys still living in or near > Aalborg? > > Martin > > _______________________________________________ > Rawstudio-dev mailing list > [email protected] > http://rawstudio.org/cgi-bin/mailman/listinfo/rawstudio-dev > -- Trond Danielsen _______________________________________________ Rawstudio-dev mailing list [email protected] http://rawstudio.org/cgi-bin/mailman/listinfo/rawstudio-dev
