Re: Photo grouping

["Michael Hutchinson" <m j hutchinson gmail com>]

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