Big Collections/Complex Meta-data/Is F-Spot (going to be) for me?

[Neilen Marais <nmarais snowisp com>]

Hi

I have a pretty big image database (about 12k photos) with fairly
complex meta-data maintained in KPhotoAlbum. I've been eying F-spot for
a while, since it has a very active community, looks pretty and seems
quite nice to use. I'm quite excited by F-spot's ability to handle
picture versions and RAW files. I also prefer GNOME apps all else being
equal.

KPhotoAlbum is not quite as smooth, but it's interface seems more
"scalable" to me, while F-spot tries (and manages very well) to make
easy stuff easy. I don't think scalable and easy need to be mutually
exclusive though.

I'll list some features in KPhotoAlbum that I find makes it very useful
for large/complex collections, and why they are useful. Perhaps I can
convince the right people that it may be useful to implement something
similar (if not identical) in F-Spot.

These comments refer to F-Spot 0.1.11, as shipped with Ubuntu Dapper.
I'll refer to KPhotoAlbum as KP from here on to save typing.

Separate "Namespaces"
=====================

F-spot seems to require the last level of a tag to be unique. Besides
offending my personal sense of logical aesthetics, it also poses
practical problems ;P 

In KP, each top-level tag is called a Category, and the tags within each
Category are completely independent. In my KP database I have a "People"
category for people visible in the photo, and a "Photographer" category
for the person who took the picture. Of course People can also be
Photographers, but usually not at the same time. Also the total number
of photographers aren't the same as the total number of people.

It's also possible that unrelated tags can coincidentally have the same
name. E.g. if you travel all over the world and meet people from all
over the world, it's not unlikely that some placename in one country may
be the same as someones name in another. 

In fact, identical placenames are quite common.
Places.USA.Alabama.Greenville is not the same as
Places.USA.California.Greenville (see
http://en.wikipedia.org/wiki/American_cities#Most_common_city_names for
more fun.) One can disambiguate by having Greenville_CA, but I already
told you it's in California, damnit ;)

Actually this is a problem in KP as well, since it's doesn't do any
hierarchy within a category. It does have membership groups that does
something similar, but that does not solve this problem. 

Membership Groups
-----------------

I think F-Spot's hierarchical tags can fill the same need, but I'll
describe them so its clear what I'm talking about.

I'll use the Places category as an example. Say the location is
"Friendly Bob's House" in Pinelands (the town), Western Cape (the
state), South Africa. In KP I can make the location "South Africa" a
membership group. Then I can assign all the states in South Africa (that
I have in my DB anyway) to this group (e.g. Western Cape, Gauteng,
etc.). Then I make Western Cape another membership group, and assign all
the cities to it (e.g. Pinelands, Cape Town, etc.). I make Pinelands a
membership group, and add "Friendly Bob's house" to it. 

Now I tag the picture with only "Friendly Bob's house". Because of the
membership groups, KP knows the picture also belongs to "Pinelands",
"Western Cape" and "South Africa", and will be found by searches on any
of those 4 locations.

Of course, Locations.South Africa.Western Cape.Pinelands would do just
as well. It will also be more explicit (good), and if F-Spot supported
it, would be separate from Locations.South Africa.Kwazulu
Natal.Pinelands (which also exists!)

Default "And" searching
=======================

>From reading the list it seems that F-Spot will get more searching
options soon, but IMHO if you can have only one choice, "and" would be
better than "or". I hope that when the more featureful searching comes,
there will be an easy way to make the default "and".

Restrict Tags when Searching
============================

This kind of goes together with the default "and" searching. KP's main
interface shows you a list of top level tags, along with how many
entries each has. e.g.

Locations - 10
People - 6

Then you select People -> "Friendly Bob"

You can then look at all the pictures containing Bob, or keep selecting
search tags. However, all the tags that never occur with Bob are
removed, e.g.

Locations - 4
People - 3

I.o.w. you see only the Locations that Bob's been photographed at and
only the people that have been photographed with Bob.

Now select Locations -> "Friendly Bob's House", 

and look at the pictures of Bob at his house, or continue:

Locations (greyed out, since there are no others)
People - 2

Then you could choose to look at pictures of Bob with his wife, or Bob
with his son.

I like this feature for two reasons. 

1) If you're and-searching, there's no point in seeing the tags that
will result in no pictures being found.
2) Its nice to see, for instance, how many people you have photographed
at a certain location.

Scalable Tag Selection
======================

It's hard to compare KP directly to F-Spot here, since the
interface paradigms are quite different, so I'll just sketch my problem.
In KP I have 9 Categories (i.e. top level tags), and some of them have
many subtags. E.g. 

Events - 143
Keywords - 21
Locations - 237
Persons - 203
Photographer - 33

I've only had a camera for about two years, but found I like both
photography and detailed tagging. I'm sure these numbers will have grown
considerably in 10 years time!

I will always have at least one tag from each of the 5 categories I
listed here attached to every picture, so it is critical that tags can
be selected from a large selection easily. KP makes the default way of
finding a tag incremental search, and also sorts tags in order of last
use by default. It also manages each category completely separately
which means the 100's of "Persons" tags don't make it hard to pick a tag
from the "Keywords" category.

While I haven't dealt with that many tags in F-Spot, my feeling is the
tag toolbar/tree on the left of F-Spot will be fairly well suited to
dealing with many tags. Other places, where there are flat lists with
all tag hierarchies exploded, will probably be unpleasant to use.

What I'd need to switch
=======================

Like you care ;P Anyway, my needs in order of priority are

1) "Fully qualified" tag uniqueness (i.e. People.A != Places.A)
2) "And" searching
3) Tag Restrictions while and-searching
4) Improved UI for selecting from large numbers of tags

1) is completely critical, since I can't losslesly  move my current data
into F-Spot without it.
2) is pretty important.

3) and 4) would be nice to have, but not that important.

If other people think it's a good idea, should I make feature requests
on the F-spot bugzilla, or how should I go ahead?

Thanks for listening
Neilen 

-- 
you know its kind of tragic 
we live in the new world
but we've lost the magic
-- Battery 9 (www.battery9.co.za)