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

[Stephane Delcroix <stephane delcroix org>]

Hi,

Some of your needs are already work in progress.

Check http://bugzilla.gnome.org/show_bug.cgi?id=338558 for
fully-qualified tag uniqueness, it's a strong request but solving it
will require re-coding the 'Tag Typing'.

Check http://bugzilla.gnome.org/show_bug.cgi?id=139796 for advanced
queries. It's one of the oldest bug request / patch in f-spot.

You can CC your email address to follow the discussion about them.

I like the idea of displaying more info about the selection (items per
tag, ...). You can probably submit a enhancement request in bugzilla and
attach a mockup of the UI. As always in F-Spot, the problem is not
writing code to solve an issue, it's about writing good code and give
the user a nice experience.

Thanks for your report,

Stephane 


On Tue, 2006-06-20 at 11:12 +0200, Neilen Marais wrote:
> 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 
> 
-- 
Stephane Delcroix
stephane delcroix org