Getting comfortable using GPS when I travel and shoot has been creeping up on me for several years now. It is a slightly peculiar beast, and putting your finger on the exact purpose GPS serves in photography can be a bit tricky. Combine that with the somewhat obscure nature of how timestamps work, and you’ve got a subject you can sink your teeth into. (And just as quickly, you can get it wrong. Which unfortunately, is what I found today in a tutorial on the esteemed AdobeTV.)
Ever since the early versions of Lightroom, we’ve had an innovative feature that linked GPS metadata to Google Maps, and it was that feature that first prompted me to purchase a GPS unit and start working with it. But you still had to encode your images with GPS metadata before you could do anything with it. At the time, geocoding photos was not nearly as easy as it is today. Looking around for a little help, one of the engineers on the Lightroom team recommended that I try a program from Houdah Software, and that got me moving in the right direction. (HoudahGeo is still my favorite way to pull .gpx tracklogs from my Garmin GPS unit, which surprisingly, Lightroom does not yet do.)
With Lightroom 4 we now have the Map module, which adds its own special twist to the mix. The Map module lets you drag photos directly onto the map, embed GPS metadata, reverse geocode location information, filter and select photos within any visible map area, and all sorts of other cool tricks. And in general, they’ve made it all pretty easy to use.
But there is one, small fly in the ointment. When I first started sniffing down this path, I was having a bit of trouble figuring out how to use Lightroom’s Time Zone Offset feature. And it goes back to that timestamp thing. The heart of the problem is that a timestamp is just a timestamp, and can only tell you what time a photo was shot, in some local time. Most cameras do not store the time zone that it was in at the moment of exposure. And if they do, it’s stored in a proprietary metadata tag that is not readable by most software. So the timestamp is completely ambiguous.
From what I understand, this incredibly inelegant situation is not the fault of Adobe software engineers, or of Japanese camera manufacturers, or anyone else you might think to point your finger at. But rather, timestamps are what they are because the EXIF specification simply does not allow for a local time zone entry!
Are you kidding me?
Some cameras do allow you to set a time zone on the menus, but really that’s just a red herring. There is still no context recorded in camera metadata to give the timestamp meaning. (Nothing in EXIF, anyway, that is used by Lightroom. See Manfred’s comment below.)
GPS units take a slightly different tact on the problem. They ignore the crucial idea of context too, but they do that because they can. GPS units simply record all timestamps as if they were in one time zone that never changes: UTC. (UTC = Coordinated Universal Time. Same as GMT or Zulu time, whatever you want to call it.) Sure, it’s true that you can set a time zone on your GPS unit, but that’s just so that you can read a local time on the GPS display that makes sense. This time zone setting has absolutely nothing to do with how the GPS understands where you are, or how it records that position into the tracklog. It simply records everything in UTC. Which makes sense. After all, it is a global system.
Crater Lake, OR
Given all of that, the problem should be coming into a bit better focus now. In order to match up the timestamps created by your camera to the timestamps recorded by your GPS unit, your computer needs more information. It needs to know what the timestamps in your photos mean, or… put another way, it needs to have the context that comes from the time zone.
HoudahGeo has a very straight forward way of obtaining that bit of info. The moment you try to load any photos into it for geocoding, it pops up a small dialog and simply asks for it. It also provides a starting point (an assumption), by looking at your computer clock, and pulling the local time zone from there. And it puts the assumption right in front of you for your approval. The text in the dialog says “Camera time zone:”, and there’s a pop-up menu, conveniently set to your local zone. Or whatever time zone your computer is currently set to.
Not My Motorcycle!
So it’s unmistakable. HoudahGeo is asking you to verify the time zone of the photos you’re loading, the moment you try to do anything with it. There’s no escaping it. If you’re sitting in your hotel room in China, and you’ve been diligent enough to set your computer clock to the local time zone, (and… you’ve set your camera’s clock to the correct local time, before you started shooting) then geocoding is a slam dunk. You just load the photos, then load up the .gpx tracklog from your GPS device, and HoudahGeo matches them up for you, calculating the offset from the unit’s GMT-based timestamps to your photo’s ambiguous EXIF timestamps.
But then we come to Lightroom. Once you’re in the Map module and you’ve loaded up your tracklog, if you’re still in the same time zone that the photos’ timestamps are in, Lightroom’s Auto-Tag feature will work perfectly for you. My trouble with it is that there’s not a hint anywhere that Lightroom is making the same assumption as HoudahGeo, but that’s exactly what it does.
Now, I agree that the software has to start somewhere. But there are two major problems here. First, Lightroom doesn’t give you a clue that it’s making an assumption about the time zone, or that you might need to match these two things up. (Especially for beginners, that’s a problem. HoudahGeo asks you to verify the camera time zone every time you use it.) Second is that, in general, when I’m traveling and shooting, I don’t want to be thinking about GPS metadata and time zones. I want to think about those things once I’m back home.
After doing a bit of thinking on the subject of timestamps, and after polling dozens of my friends and customers who regularly shoot with GPS, I found that I was not the only one. Most photographer’s would rather worry about this stuff when they get home. Which means that Lightroom’s assumption about where to get a useful time zone will nearly always be wrong.
This means that if you want Lightroom to auto-tag your photos to a tracklog, you’re going to have to tell Lightroom where the photos were taken relative to the computer’s current time zone. Thus, the Time Zone Offset feature, which is not exactly self-explanatory. (Also confirmed by my poll.)
Now, I’m not writing this to point fingers at the UI designer or the engineers. There are lots of other aspects of Lightroom that will ensure my job security as an educator. But I’m writing it because just this morning I watched one too many video tutorials that got it so utterly wrong, I couldn’t stop myself.
This feature is not that complicated, and it deserves to be understood because it’s incredibly useful. It’s just been hindered by a really bad user interface, and further obscured by tutorial jockeys who won’t take the time to do a little research. The easy way to think about it is that you have to tell Lightroom how many hours apart the time zone of the photos is (or was), from the time zone your computer clock is currently set to, before auto-tagging will work. And rather than show you a step-by-step here on the blog, I’ve taken 6 minutes out of tutorial #7 from my Catalog Management series, that shows you exactly how to do it.
It’s a free video, and you can watch it by clicking here.