shotwell

Yes :)

Yes, I like this feature in F-Spot

People

...

searching for the tag Grandparents will then show Nana & Grandpa Tags as well.

From what I remember there are a few issues on how the nesting is saved in the meta-data and exported.

If the nesting is only in the photo managers DB the photo meta-data could get all tags as single tags (e.g. Family, Grandparents, Nana) or only the top most Tag (e.g. Nana).

AFAIK F-Spot will write the nested Tag as one Tag, “Family, Grandparents, Nana” but I'm not 100% on this.

I second this – it's probably the last thing that prevents me from migrating from DigiKam.

+1

For me, it's probably the last thing missing before I move from F-Spot to Shotwell. =)

This would make shotwell really useful to me.

Thanks for the continuing interest from everyone about hierarchical tags in Shotwell. Although this feature won't make 0.8, this is near the top of our list for 0.9. It won't be trivial to implement but we want to build it anyway. :)

Maybe a wacky suggestion, just putting it up here for comments, but what about “hierachical events”?

Currently, the distinction is very clear: events are hierachical (year/month/day), tags are not. By implementing hierachical tags, tagging could start to overlap into the event hierachy, yielding conflicts.

To clarify with an example:

Say I've gone on a prolonged vacation (e.g. !event:“Australia backpacking trip”), but during this long event I will have been on sub-events (e.g. event:“Uluru/Ayers rock”, event:“Visiting friends in Melbourne”).

(To keep it interesting, say this was from December 2009 to Januari 2010, so splitting the main event over year-folders while the sub-events still fit single days). I don't think this is a very unlikely situation, so I thought I'd bring it to everyone's attention

The 'problem' I foresee happens because while events are self-contained album-like units with a representative key-picture, tags are random assortments of images, without a key picture.

In my example, with the current behavior if I select the “Australia trip”-tag I would get a long list of every photo in all Australia events (which could be thousands of pictures), but I would rather get the (much shorter) list of the albums/events grouped under that tag, so as to keep things manageable.

Problem is that currently, tags can only apply to photos, not events.

Some possible solutions I've come up with so far are:

Allow tags to have a key-picture which is shown when it or its parent tag is selected.

Unsatisfactory; it would fix my Australia-trip example, but would break the grandparents example (see comment 3, above) because clicking 'grandparents' would then give two albums, rather than the expected list of pictures with Nana and/or Grandpa

Allow tagging of Events themselves, in addition to tagging individual pictures in events.

Could work: If I applied a tag to pictures, clicking the tag in the sidebar would show the list of pictures (=current behavior), if I applied it to event(s), the clicking it would show a list of events/albums (similar to what clicking a year/month in the sidebar does now).

Problems: what if I apply a tag to both collective events AND individual pictures? how to display that? (probably a list of events-thumbnails first, followed by single photo results next) What if the tag is applied to all pictures in an event, but not the event itself? Should the tag be removed from the pictures and applied to the event (which is probably was what the user meant, probably)

Have a preference allowing to choose between “display tags as event with key picture” or “Display tags as long list of tagged pictures”.

Unsatisfactory: This would force the user to choose one solution for all cases, while in some cases the one option is better, and in some cases the other.

Make a distinction between “album tags” (with key-picture) and “normal tags” (without key-picture).

Album tags would directly overlap with how events currently work, except for the enforced date-hierarchy. This reeks of duplication of functionality, which is probably bad.

Also: should Album tags be allowed to contain non-album tags and vice versa?

Currently, option 2 has my preference, but that probably means some major reworking under the hood for the developers.

I just wanted to see if other people see this as a problem too, what they think and if they may have other possible solutions.

@jkerssem: Thanks for the suggestion. Actually we would like each tag to be able to have a key photo in Shotwell; see#1402. You raise a good point, though. Suppose that I select any folder in the Shotwell sidebar, e.g. “January 2011” in the Event tree, or “People” in the Tags tree (once we've implemented hierarchical tags). Then should Shotwell display (a) all photos contained in that folder or any of its children, or (b) all events/tags contained in that folder with a key photo for each? The team's current thinking is that the user should be able to select either of these – not as a preference, but rather as a on-the-fly view choice, perhaps enabled by a dropdown at the top of the window. That way you'll be able to see either the set of pictures of Nana and/or Grandpa or two tags “Nana” and “Grandpa” with a key photo for each. This is probably a couple of releases away, though.

The on-the-fly view selection I described in my last comment is ticket#2413, by the way.

@ #1402, #2413

Aha, very good suggestions!

I've been bouncing this issue around all night, and I think I have found why this is such a complex issue. The workaround/solution is a bit drastic though:

Drop the event functionality from the date-hierarchy, and move it to a tag-category of its own.

First off: I really like the way we are currently able to split/merge events in the date-hierarchy. It makes perfect sense in a flat-tagging model and is the best solution I can think of within a flat tagging scenario.

However, it's a sort of “tagging-lite”, and once you implement hierarchic tagging, you will have “tagging-pro”, so the need for “lite” vanishes. Say what you will but currently Events are NOT tags, they're a mixture of mostly date with a slight hint of tag.

This hint-of-tag makes us users want to treat Events as proper, top-level tags (renaming them, grouping them hierarchically, etc.), but that clashes with the very rigid date hierarchy where they're currently housed. (Re)naming was simple enough to work in (just name the date), splitting work okay too (multiple 'dates' per day..), but with nested events the clash becomes unavoidable.

Since the date-view makes a lot of sense to me, but nested events do too, the only workable solution I can see is to separate them completely.

This is one thing where looking at F-spot is probably a good idea. Their implementation of hierarchical tags just nails it with the notion of top-level 'tag-categories': places, events, people. (with the ability to add more).

It's a bit artificial for F-spot to have moved 'Date' into the time-line bar, that's where Shotwell does better again with it's date-folder hierarchy imho.

I hope I don't sound degrading or anything, I realise I may sound a like a fanatic, but I really feel dropping events from the date-view is the only way to solve things cleanly without creating an impossible mess down the road.

Once again: I'm not knocking down the way things currently work, the event-solution is perfect within the flat-tagging framework, but the core assumptions don't hold in a full hierarchical-tagging framework.

I think the F-Spot importer part have to be re-visited when this is finished, to ensure that we keep the F-Spot hierarchy of tags.

I will hold of converting (from F-Spot) until this one is implemented unfortunately :(

Previously I used digikam, but I now switched to shotwell. Most of my pictures still have hierarchical tags in them, that I made in digikam. The tags are for example: People/Family/John Places/Netherlands/Amsterdam etc.

It would be nice if these tags made by digikam would be recognized by shotwell as hierarchical tags.

Note related ticket #3100, which mentions feature to toggle display of the contents of sub-tags.

+1 When hierarchical tags are supported in Shotwell I will seriously consider importing my 25000 photos currently stored in F-Spot and a Gallery 1 instance.

@comments 27, 28 and 31:

I'm using photo tagging applications since a very long time, and it seems to me like you're trying to reinvent the wheel. I'm not against this whole discussion, but there are at least few applications that rely heavily on tags – why not look at them? IMVHO one of the best implementations can be found in Photoshop Elements (unfortunately it's Windows and Mac only) and digiKam.

The idea is quite simple – you have three independent selections, that can be joined using logical operators:

- the timeline, which enables you to restrict the date

- the event list, which enables you to select the specific event

- the tag list, with tags assigned to photos (only)

This way, with proper tagging, you can quickly find, let's say, all photos of Agnes, made in Australia between 2005 and 2006 – you select tags People->Agnes and Places->Australia, and restrict the date using timeline. This is one of the most important features when working with large collections of phots.

You may also want to simply see all photos from the 2007 trip to Australia, selecting '2007 trip to Australia' from events, but one can also restrict this set to see just photos of Agnes made during that single trip (additionally selecting 'Agnes' from tags).

I don't see a problem in situation when you're getting thousand of photos with 'Australia' tag – you just have to restrict them using specific dates or more tags.

Of course there are problems like: what photos should be shown when two tags are selected – those with both tags (logical AND) or those with at least one of them (logical OR). This is also critical and should be configurable.

I'm keeping my fingers crossed – lack of hierarchical tags is still the most important obstacle in my moving to Shotwell :)

Definitely another +1 here. I've moved my 25000 photo collection from F-Spot to Shotwell for two reasons – (1) because for reasons not worth going into, I now need to access my photo library remotely over a Samba share, and even with gb networking F-Spot was unusable, and (2) because I like to try out new stuff!

That said though, the lack of hierarchical tags is a major downer, and if I could have used F-Spot until they were added to Shotwell, I probably would have. I'm guessing that when the functionality is included, that I'll be able to re-hierarch-ise my photos again?

Am liking Shotwell alot and will like it even more when this development comes along. :-P

Like comment 40 above I also +1 the idea of a timeline, found that useful in F-Spot too.

For me, this is the only blocker left for switching to shotwell, would not even need the function seb1204 described in #3 just to have them in hierarch by dummys would be fine … I have 600+ nodes in my tag-tree, that makes a long list with out hierarchical tags

-->Events

-->-->Beach 2005

-->People

-->-->Parents

-->-->-->Dad

-->-->-->Mum

I would like to add my voice for hierarchical tags. I have 15,000 photos, 400 tags stored in the photos. I am using, and like Shotwell for small projects about 300 photos in each. My events do not take place on a single day although dates are a convenient way to store photos in folders so the event function is really a folder date function for me. I need to copy projects with their tags between machines and import them into other f-spot / Shotwell / digiframe systems.

One tag function f-spot does not have is the ability to export / import hierarchies of tags, you need to edit the imported tags to add the hierarchies.

I look forward to Shotwell having the hierarchical tag function and then I could migrate from f-spot.

awesome, will wait for 0.10 to make a testing report

+1

just tried shotwell and it looks great, but without this feature (and working import) I won't move away from f-spot ;) Looking forward to this being implemented

I'm excited about the prospect of hierarchical tags in shotwell. This is the main thing right now that keeps me on f-spot. I'd like to share a couple of suggestions / thoughts about such tags since it looks like you will be implementing them soon. I hope that you find these points at least useful to consider.

• These could potentially be a superset of your “events” so consider whether they would make the events redundant.

• Each level of the hierarchy should be applied to the photo along with the tag. For example, we could have

“People/Our Family/Smith/Jim”

. When the tag “Jim” is applied, what should actually be applied is

“People/Our Family/Smith/Jim”

. Then we could filter by

“People”

, or by

“People/Our Family”

, or by

“People/Our Family/Smith”

, or by

“People/Our Family/Smith/Jim”

, and this photo should be matched by each of those. This would also automatically resolve any concerns about confusion between tags with identical names but in different parts of the hierarchy. Note that this does come with some significant expense -- many files must be rewritten if we start dragging around subfolders in the hierarchy and redepositing them elsewhere in the hierarchy. So the updating of tags must most likely be queued in the background, in cases where they are updated in the image files or in sidecar files.

• Design this feature from the beginning so that it is compatible with the concept of tagging a region in a photo. That way when someone implements face recognition the hierarchical tags don't have to be rewritten completely.

• Should be possible to define a key picture for every level in the tag hierarchy. As far as what to show when clicking on a tag (key photos only or union of all child photos, etc), consider view options in file browsers as implemented in Nautilus Elementary or in Windows Explorer. Have a default setting for tags which haven't been visited, and have a couple buttons to click on to change the view from key photo thumbnails at this hierarchy level, to thumbnails of all child photos, to single photo (edit?). Then when someone visits a tag and changes the view, remember the view for the next time they visit the tag. Just like choosing thumbnail vs list vs details in a file browser. Could be made so it provided a nice visual cue about which view you are currently in.

• Export tag information in some useful manner to Zeitgeist and/or Tracker.

• Besides some kind of quickly selectable “and” or “or” option when one ctrl+clicks to select multiple tags, make it possible to build arbitrarily complex tag-based queries for saved searches. And perhaps such queries could get their own tag-like graphical representation in a query “folder” in the sidebar or something. Now that we're on that, perhaps we should be able to define subfolders to organize the queries as well. While queries could be used exactly like tags to browse photos, of course no metadata (about the query or the folder the query is in) would be written to the photos that are matched.

• Agree with the comment above that there should be a nice graphical way of time-based filtering as well that complements the tag capabilities.

@cometdog: One of the main advantages shotwell has over all other photo manager, its light weight and super fast. It would be nice to see more features, but only if the speed will not decrease, so i think that it is about time to start working on these heavy features, but as plug-ins … i already starting to get familiar with vala ^^

@xuedi: That's a good point that care should be taken to avoid slowing down shotwell's operation. I could be naive, and I'm not trying to assert that these things have to be done my way -- clearly I'm not developing Shotwell myself. But as far as the specific point of heavy features, I fail to see which of the above features would be “heavy.”

I guess my most important point above (in my view) would be the fact that the organizational structure should be accessible as part of the “tag” information. That kind of thing is really intrinsic to any useful implementation of hierarchical tags, I would think, although I grant there could be different ways to implement it internally. The only thing that seems “heavy” about any of this is the cost of writing the tag metadata to files, if enabled. But that's overhead which already exists once we have tags to begin with (which we already do), so someone must have a strategy for dealing with it. The possibility of applying a tag simultaneously to huge numbers of photos in a huge photo collection exists even in the absence of a hierarchy for organizing them. So maybe I didn't need to bring that up as a possible problem.

Or am I missing the point of your comment entirely?

Replying to [comment:59 cometdog]:

• These could potentially be a superset of your “events” so consider whether they would make the events redundant.

+1: the events are just tags (but less flexible)

• Each level of the hierarchy should be applied to the photo along with the tag.

I agree, but I have a big question:

Which tag fields will be written in presence of hierarchical tags?

AFAIK there are (at least) two options: Xmp.dc.subject, flat structure, one entry per tag, and Xmp.lr.hierarchicalSubject, full hierarchy in a single entry with values separated by “|”.

I think Shotwell should write both, for compatibility with non-hierarchical tags software (this way in the above example a photo tagged Jim would appear searching Our Family regardless of the photo managing software.)

I like simple. So just remove events and introduce hierarchical tags. Events are a type of tags.

Example tag hierarchies:

/Events/World Tour/Canada/Fishing Trip

/New Zealand/LOTR Tour

/Family/Pete

/Joan

I should be able to add both parent and child tags to photos.

Last but not least add a search “language” like “World Tour” and “Pete” and not “%(=caps)LOTR% Tour” meaning, give me all photos tagged with “World Tour” tag (including child tags) which also have a tag “Pete” including child tags" but excluding photos tagged “%(=caps)LOTR% Tour” (including child tags)