Tagging Digital Photos – Part III

As a result of my last post on tagging, I’ve had a couple of questions, so I thought I’d answer them in this post. The questions were:

1. Say I went on vacation and came back with a whole bunch of pictures. How do you relate those pictures to each other? I.e. is there a way to do some kind of “Description tree structure” effectively?
2. I’ve seen that many users of JRiver Media Center (JRMC) use the hierarchy structure in keywords that you describe above (they usually call it nesting). In JRMC this is displayed nicely in a tree structure. How portable is this hierarchy structure? How does it display in IdImager, WPLG, or in any of the Adobe applications?

Question 1 is a bit like a combination of “how long is a piece of string” and “what’s the best way to skin a cat?”. I can only answer it by describing what works for me, but I would not claim that it’s the most effective for everyone.

So, here’s what I do when I get back from a vacation… First, ingest all the photos from my camera(s) into the tool that happens to be my choice for the heart of my digital workflow: IDimager. (Note: IDimager is no longer available. Its successor is Photo Supreme, which I am now using) Other folks will have their own choices such as Adobe Lightroom, or even free tools such as Picasa or Windows Live Photo Gallery (WLPG). I’ve ended up with IDimager simply because, for me, the combination of its flexibility and power combined with a reasonable cost gives me the biggest bang for the buck of all the tools I’ve looked at.

During the ingestion process, IDimager renames all the photos from the camera’s IMGnnnn format to my preferred date/timestamp format of yyyymmdd-hhmmss-nn, and also places the photos into a folder structure that is ordered by date to three levels: year, month and day. If a particular folder does not already exist, IDimager will create it on the fly. At the same time, the first pass of assigning metadata to every image is done by IDimager. This is to add the Contact Info, Copyright Notice, Usage Rights, and Title fields to the images.

The next step is to cull the obvious failures from the set of images using the Light Table view of IDimager. Then I’m ready to do the first pass of assigning the detailed metadata to the working set of images. Since these are vacation photos, they will all have the Events/holidays/vacation Keyword assigned. I will also add location information, simultaneously to both the IPTC Core Location metadata fields, and as a structured Keyword; e.g. Places/Europe/Spain/Catalunya/Barcelona/Las Ramblas.

Then I’ll do a few more passes, adding further Keyword metadata as appropriate, until I feel that sufficient metadata has been added. The last step at this stage will be to add geotag metadata, if I’ve had my GPS logger with me.

The “Description tree structure” (a.k.a. the “Keyword” or “Tag” tree structure) that I have is as I described in the last post. It’s effective enough for me, but I won’t claim that it will work for everyone. Still, if you build up your structure following David Rieck’s suggestions, then I think you’ll have a good start. I’ve also just found a short article that gives some guidelines about how you might go about designing your own controlled vocabulary and taxonomy for digital images.

Now I have the starter set of vacation photos. Further steps in the workflow will be to choose the best, with further processing and editing as necessary, by assigning ratings, using the “power of 10” or “pyramid” rule. This is described in Peter Krogh’s “The DAM Book” . The rule is that each additional “star” rating will have an order of magnitude fewer images in it. For example, if you have say 100,000 images in your total collection, then 10,000 might be rated with 1 star, 1,000 rated with 2 stars, 100 rated with 3 stars, and so on. Of course, at this rate, I’ll be lucky to have even a single image that is worthy of 5 stars, but that’s the idea – be aggressive to drive up your idea of quality.

Because this starter set of vacation photos has sufficient metadata (for me), I’m able to select them quickly out of my total collection using either IDimager or WLPG. For simple queries, either will do; e.g. select vacation photos taken in 2006 in Barcelona. But for more complex queries, then I have to use IDimager; e.g. select vacation photos that show ball games but not tennis…

There are other things that IDimager can do that less capable tools (e.g. Picasa and WLPG) simply can’t. Synonyms and relationships, for instance. Synonyms mean that if I search my image collection for cars, for example, IDimager will also suggest synonyms for the search term, e.g. automobiles. Relationships means that, for example, People/Family/John is related to People/Family/Anita as “husband to wife”.

By creating relationships between your keywords, you are able to switch instantly to related keywords. If the keyword John is selected, you get instant access to Anita because Anita will be included in the sub list of John.

Question 2 is somewhat difficult for me to answer, because I don’t use JRiver Media Center (JRMC). So I can’t say for certain how JRMC will expose the keyword structure to other tools. But any application has in theory two possible approaches to this. The first is a static approach, whereby you can export the structure from tool A into an intermediate file that can then be imported into tool B. The intermediate file usually takes the form of being in CSV or XML format. These two formats are pretty widely understood by a variety of Digital Asset Management (DAM) tools. Being static, it’s generally best used to set up a new tool, or to take a snapshot of your current structure, either for archiving purposes, or for sharing with other people.

The second approach is a dynamic interchange, whereby all the DAM tools being used will track changes to the keyword structure preferably themselves, or with minimum user intervention. Because we are dealing with photos here, we do in fact have the possibility of achieving that dynamic interchange by using the photo metadata in the files. So, for example, if I make a change to the keyword structure in IDimager, I will then synchronise my image collection with the new structure. IDimager then writes out changes as necessary to the metadata of files that are affected by the change.

WLPG monitors for changes in the metadata of images and reflects those changes in the metadata and keyword structure displayed in WLPG and held in its database. This means that both tools should show the same keyword structure. Here’s an example looking at part of the Places hierarchy with both IDimager and WLPG (click on the pictures to see the full-sized images):

You’ll notice that although the subtrees for the Glenfaba and Michael Sheadings (the Manx equivalent of State) are shown expanded in the IDimager screenshot, and not in the WLPG screenshot, both do have the same structure. And on the right, you can see that both have the same keywords. Also note that in IDimager, the full delimited keywords are shown (e.g. Places/Europe/Isle of Man/Middle Sheading/Baldwin, whereas in WLPG only that leaf of the full delimited keyword is shown, e.g. Baldwin.

WLPG is reading the whole delimited keyword, and using it to recreate the keyword structure shown on the left (in this case under the Descriptive Tags heading). So in this case, IDimager and WLPG are able to share the keyword structure dynamically. I’ve been able to set it up this way, because I’m able to tell IDimager to use delimited keywords, and that the delimiter character to use is “/” (which is required by WLPG). If JRMC can write out delimited keywords into the IPTC Core metadata of your image collection using “/” as the delimiter, then WLPG should be able to reconstruct and track the keyword hierarchy on the fly.

Be aware that not all tools use the same delimiter. For example, Lightroom always uses the pipe character ( | ) as a delimiter for its hierarchical keywords. In addition, Lightroom uses a separate XMP property to store these hierarchical keywords separated from the normal keywords. That’s why IDimager also supports the hierarchical keywords method as used by Lightroom as well as delimited keywords written to IPTC Core specs. So portability between tools is by no means guaranteed, but often a way can be found if at least one of the tools is flexible enough. Hope this helps.