Tags used the wrong way

In general I do not regret my switch from Mac OS X to FreeBSD/Linux. But when it comes to managing my pictures I have to say that I miss iPhoto and Aperture. And this not for the fancy features like face recognition or all the beautiful GUI stuff, but for a very basic one, and that is organizing pictures.

Low-level

On Mac I started with iPhoto and then switched to Aperture. Now I stay with F-Spot, I also looked at Digikam and Shotwell, but I do not see any real advantages over F-Spot right now.

All programs allow you to either copy your pictures to an internal database or just reference them in your own filesystem layout. While the library format of iPhoto and Aperture is rather complicated and somewhat proprietary, the open-source programs do it a lot simpler. F-Spot and Shotwell just create a fixed folder structure by date for year, month and day to organize the pictures. In F-Spot you have a low level folder view, while in Shotwell you never see that structure directly. Digikam allows you to manage the folders from within the program and change the structure.

When it comes to metadata all programs in recent versions allow you to choose between storing tags, captions, and other data inside the original pictures or in their internal database. When switching between different photo management software storing the metadata inside the pictures is the only way to migrate. The internal formats are not compatible between programs.

Tags are not enough

Where iPhoto and Aperture allow you to create arbitrary folder structures with virtual albums and assign each picture to any number of albums, the other programs clearly lack some basic functionality. Shotwell has, like iPhoto, an event based primary organization of pictures. But each picture can only be in exactly one event. And the folder hierarchy has a fixed structure. Beyond that all open-source programs rely on the concept of tags to do further grouping of pictures.

So what is the problem with tags? Well, they are not intended for building hierarchies, but all open-source programs use them for exactly that. The tag field in the metadata is just a set of strings with no relations to each other. For example, if you create the tags /Subject/Animals and /Testing/Animals it will just assign the tag Animals to the picture. Or maybe Subject, Animals, Testing since it is not clear if parent tags should also be assigned. Parent tags and child tags can both be assigned, whereas for example in filesystems there is a distinction between folders for building the hierarchy and files that contain the actual content. In the case of tags, the hierarchy can not be rebuild from the tags, so it is stored in the internal data of the software and lost when only taking the picture metadata. Moreover you might get a conflict for using the same tag twice in different hierarchies because a tag without hierarchy can only exist once.

One could try and use a special encoding to store the full hierarchy of a tag, but since there is no standard for this I doubt it would really help. Shotwell currently abandons hierarchical tags completely, while F-Spot and Digikam try to implement them with some issues.

Conclusion

While this is an old hat for filesystems with symbolic/hard links, where everybody agrees that multiple different folder structures are needed to navigate to the same file, this does not seem to be solved in the world of photography management software. While Apple has a solid solution in my eyes, it is of course (again) their very own way, and not exportable. But part of the blame also goes to the lack of a meta data standard for this. The open-source world tries to rely on an open protocol and uses tags. But since tags are not really intended for the job some drawbacks and issues result.

The discussion on hierarchical tags is on, may there be a solution soon!