Hi, <snip> > concept. Basically the HDR/panorama source images are pretty > uninteresting on their own, so I want to move them aside and instead > only see the combined result.
Yes, that's exactly my reason for wanting this too, and judging from BugZilla #311550 this is not an uncommon wish. It seems like something that would be very useful even in an app entirely concerned with cataloguing photos. The question is whether to take it any further, if it could potentially improve on F-Spot's existing versioning support. <snip> > Before I found F-Spot one of the applications I'd wanted to do was a > Photography "work-flow" app. It's pretty much what you talk about > above, but a central idea was to have a lot of possible chaining of > operations. Basically make a simple "black box" of a photo operation > (like tuning channels) and let it accept one image and spit out > another. The box would then have a bunch of "dials" which would tune > how it worked. That's roughly what I was imagining, though it would be necessary to have a little worksurface or preview for certain blocks. It sounds like we both want something that works like chaining blocks into pipelines, like AV systems such as GStreamer use for example, but with a more intuitive UI, maybe some form of nested workspaces like I mentioned before. There's no reason why it couldn't be fully scriptable too, and have an optional advanced block-connecting view. If they ever get it done, GEGL (http://www.gegl.org/) might be useful. <snip> > I'm not sure if this would suit in the F-Spot idea of photo > management. I'm personally thinking it might be even better to have Yes, that's my concern, but I didn't really want to be writing a new app if the F-Spot developers are happy to see it extended instead. Writing another Adobe Lightbox or Apple Aperture would be very nice, but is way beyond me at the moment, and seems unnecessary if F-Spot could have the most important (and less esoteric) features. > multiple applications which cooperate instead of one big program which > does a little of everything. I don't know whether this would work in terms of keeping track of integrated workflow, versioning and metadata... You could however have an integrated management app with 'blocks' representing/invoking external tools, for example an Enblend block and a GIMP block. Something a little off-the-wall, but interesting to play around with, would be not to limit the architecture to pictures. If the database can track any media file and its metadata (not hard, especially using Beagle's filters), then there is no reason why it should not be possible to write blocks that can deal with video, or vector art, or text etc. The block interface could simply have to specify what input MIME types it accepts and outputs. While no-one would necessarily get around to writing anything beyond 'extract frame', it could make for a unique and interesting app if someone integrated a video editor or a video compositor... > If you are interested I can go over my notes (most are on paper) and > see if I can come up with a more coherent design. Yes, that sounds good. I will too, as it's a good way of procrastinating for exams ;-). I have commitments to a couple of other projects too, so it's unlikely to be a top priority for me for a while, but there's no harm in long-term planning. > It would also be nice to see some responses from the dev team on > F-Spot with comments on where you see the program heading in the near > (and far) future. Definately, as that would determine whether I plan for a new app or an F-Spot extension. Michael _______________________________________________ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
