The Dark Side of Tagging in Windows Vista

I don’t want to rain on everybody’s parade, but there is a really significant fly in the ointment when it comes to the gee-whiz media tagging feature in Windows Vista’s Photo Gallery application.

The idea behind tagging photos and other media files is compelling: you can instantly filter non-textual content by keyword. Photo Gallery in and of itself is primarily an organizing and viewing application with some very basic photo editing features, but is capable of launching other applications that have registered themselves with Vista as knowledgeable about the particular file type you’re working with. For example, we have Adobe Photoshop Elements 5.0 installed, and when you highlight a jpeg image, Photo Gallery is smart enough to have “Edit with Photoshop Elements” on the image’s context menu. Cool.

But think carefully about how you’ll use this coolness, long-term. Consider: you will, over time, tag and organize potentially thousands of files. What happens when you migrate to another system? And what if you need to tag and organize the same media in other applications, such as Elements? Over time, you’re going to make a substantial work investment in getting everything organized. You’re going to get very dependent on tagging, and you’re not going to want to lose that investment every time you work with a different image editor or buy a new computer.

There are two ways to store metadata (data about data) such as tags. One is to use a database of some kind to track what tags go with which files (to associate tag(s) with each file location). The other way is to embed the tags directly in the image files themselves.

In an excellent screencast, Jon Udel interviewed one of Photo Gallery’s product managers to show how tagging works in Photo Gallery. Jon has pushed the concept of “The Truth is in the File“. Unlike, say, the Mac, which keeps tags in a database, Photo Gallery keeps them in the files themselves. That way, when you move the files to a new machine, or upload them to the Internet or share them with others, the tags stay with the file.

Or do they?

The answer is, sort of, usually, provided that certain conditions are met.

Let me explain.

While it’s true that Photo Gallery stores your tags in the file, it takes quite a bit of time to update image file metadata. Sometimes a (potentially huge) image file must be completely or partially rewritten. The actual image data is never molested, but room must be made for more metadata and this can mean time-consuming copying of the file to a new “version”. This is all transparent to the user, even to the point that the operating system “last modified” date doesn’t change. However, were you to tag, say, a thousand photos at once, you’d have a long wait for all those files to be updated.

So Photo Gallery actually tracks the files internally in a database. That way you get instantaneous performance: add a tag to a thousand jpegs, and it happens, boom, just like that. But if you were to pay close attention to the lower left corner of Photo Gallery’s UI, you’d see a tiny icon that indicates Photo Gallery is working in the background to update that thousand files while you continue to do other things.

If you were to quit Photo Gallery before it was done with this background update, it will resume its work the next time you load it.

This works great, for a specific use case: (1) You will use Photo Gallery exclusively to organize your photos; (2) all of your photos are in a format (such as jpeg) that support embedded metadata; (3) you are willing to limit yourself to Photo Gallery and its descendants plus whatever other applications may (or may not) happen to evolve to be Photo Gallery-compatible in the future.

The first problem is, how does Photo Gallery recognize that a file has metadata that needs to be in its database? The answer is, if you use Photo Gallery to import photos from your camera, Photo Gallery will read existing camera metadata into its database; if Photo Gallery encounters a photo that it has never seen before somewhere in the directories it scans, it will add any existing metadata to its database; and of course, if you manually tag a file, that goes into the database.

However, in my experience at least, if some other application updates a file, Photo Gallery will not notice. So if you tag a file in Elements, or copy a new version of the file that is tagged differently from another machine, Photo Gallery will not (or at least often does not) notice. Now you have the interesting situation where a photo has a tag that Photo Gallery doesn’t know about. You can’t find it using a tag search in Photo Gallery.

If you bring up that file in Windows Explorer, and look at the file properties, the new tag is there. In fact, if you launch that file in Photo Gallery from Explorer, the new tag is there. But the new tag does not appear in the tag list of Photo Gallery and cannot be used to find the file in Photo Gallery. Clearly the internal database is out of sync with the file. When launched to view a single file (from Explorer, for instance), Photo Gallery actually bothers to read the tags from the file and display them all, apparently ignoring its internal database, and not updating it with the file’s new info, either.

The only way I can figure out to fix this is to rename the file, or copy it to some directory that Photo Gallery doesn’t scan, delete it from Photo Gallery, then throw the saved copy back into its old location. Anything to make it look “new” to Photo Gallery. Not exactly a recipe for getting work done quickly!

It gets worse. Just because you tag a file in another application doesn’t mean that Photo Gallery would ever see it. That’s because for some applications, “the truth is in the database”, not the file. They don’t even update the file.

Adobe actually originated the metadata format that both Elements and Photo Gallery use, but Elements does not actually write the metadata to the file unless you tell it to using File | Write Tags to File. In other words, Elements, for all its features, lacks Photo Gallery’s background update functionality, so tagging is a two-step process: tag one or more files, then explicitly tell Elements to write those tags to the files. Guess how often you’re going to forget that.

Of course, even if you remember to write the tags to the files, it’s at best questionable whether Photo Gallery will ever see the change. At this point in my experimentation, I’d say most of the time, not — unless you take still more clumsy and error-prone steps to force it to notice.

The fix for this would be for Photo Gallery to either have a background process for scanning continuously through files it has in its database, looking for tagging changes, and resolving differences; or for Photo Gallery to use some sort of FileSystemWatcher to respond in real time to writes to files in its catalog that are not done by Photo Gallery itself.

Even better, both the background checking and background writing of database changes to files should probably be abstracted out into separate Windows services so that this activity can go on whether or not Photo Gallery is actually running. Hopefully this can be on a low enough thread priority that it does not contribute to slow system performance, so that everyone turns those services off when tuning their machine, like they do today for file indexing in Windows XP.

Perhaps what we have in Photo Gallery is some trimmed-down functionality due to the cancelled WinFS initiative. I don’t know, but I’ll tell you one thing: the first image manipulation software, such as Elements, that solves these problems will win lots of customers.