Misdirection For Using GPS Tracklogs And Lightroom’s Time Zone Offset Feature…

by George on November 14, 2012

GPS: 46°2’42″ N 9°21’23″ E

Looking Into Switzerland

Photographs © George A. Jardine

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.)

GPS: 39°41’49″ N 104°58’9″ W

Early Frost

Early Frost

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.

Pull Quote

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!

GPS: 33°49’32″ N 116°32’49″ W

Pink Scarf

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.

GPS: 42°56’45″ N 122°10’9″ W

Crater Lake

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.

GPS: 36°53’7″ N 104°25’59″ W

Decals

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.

Danger, Will Robinson

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.

GPS: 38°48’51″ N 115°17’46″ W

Desert Love

Desert Love

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.

{ 11 comments… read them below or add one }

Brian November 15, 2012 at 5:46 PM

A timely intervention George. Well explained. Does this mean that we have to wait for camera manufacturers to start adding in time zone info before this all becomes easy.

Brian

George November 15, 2012 at 6:22 PM

Thanks, Brian.

Don’t hold your breath for camera manufacturers to “add in time zone info”. There’s no place in EXIF for time zones! Still researching “built-in” GPS units, and I’ll update in a few weeks.

George

Paul Beiser November 16, 2012 at 6:22 AM

Excellent background on a complicated subject – as usual, you explain it all so well.

Manfred November 16, 2012 at 1:19 PM

Hi,

I use a Canon 5D MkIII where I can set the timezone in the camera.

I just dumped the metadata of a 5DIII image with exiftool. This dump contains these lines:

TimeZone : +02:00 TimeZoneCity : Paris

For me this means: in principle LR could automatically set the correct time. All necessary information is there…

Manfred

George November 16, 2012 at 1:28 PM

True that the newer Canon and Nikons have a menu item for Time Zone. But there is no place for it in EXIF, and LR does not use it when calculating the “assumed” time zone the photos were taken in. As of 4.3, LR simply uses the computer time zone.

Where is the new Canon metadata for time zone stored? What field?

It would be great if the LR team would update the way the offset is calculated for newer cameras that have this metadata, but I wouldn’t expect to see it coming any time before 5.0.

Also, it’s actually slightly more complicated than that, because of DST. This is from C. Newman’s “Date and Time on the Internet” draft of 1997……

4.1. Coordinated Universal Time (UTC)

Because the daylight rules for local timezones are so convoluted and can change based on local law at unpredictable times, true interoperability is best achieved by using Coordinated Universal Time (UTC).

– - – - – - – - –

It is for this reason (and because GPS units only record UTC) that I always leave my camera set to UTC, and correct timestamps once I’m home editing. Further, I include the local time zone abbreviation and offset in keywords, so that there will never be any ambiguity later, when (not if…) some local government decides to change their DST rules.

http://mulita.com/blog/?p=2746

George

George November 17, 2012 at 10:49 AM

Second update for Manfred. Just received my Canon GP-E2 for the 5DMKIII. The good news is that simply putting a battery into it, turning it on and taking photos, works perfectly. Despite the fact that my camera clock and time zone are set to GMT! (I’m in Denver, CO) Which confirms that no offset is required when a dedicated unit puts the GPS coordinates directly into file metadata, and that the time zone is simply not taken into consideration, at least with LR. At that point, the timestamp and the GPS coordinates are completely independent of each other, and no correlation is needed.

Next test is to try it using the log feature, convert the track to .gpx, and see what it contains.

G.

Bob Mazor November 19, 2012 at 7:25 AM

I will be taking a family vacation to Italy in 2013 so your location workflow dvd was a god send! I am considering purchasing an external GPS unit for my Nikon D7000 and am looking forward to your update on GPS when you get a chance to try your Canon GP-E2. Do the external units automatically give us a track in the map module? Bob

George November 19, 2012 at 7:31 AM

Bob, I’ve been working with the GP-E2, and it is spectacular. It’s truly plug-and-play, when it comes to embedding GPS metadata as you shoot. But no, it does not automatically give you a track in the Map module. Getting the tracks into Lightroom is a bit more work, but worth it if you need to tag photos taken with a second camera or something. But in the end, if you’re only shooting with a camera attached directly to the unit, you never really need the tracklog.

George

Cornelia November 20, 2012 at 4:35 PM

I, too, was trapped during a recent vacation in Japan. I adjust my phone=GPS-tracking device plus my camera to the time zone I am in, but not my laptop – I would consider this very weird. LR does a poor job of this auto-assumption according to computer time zone. Jeffrey Friedl shows how it should be done in his Geoencoding plug-in: just asks in what time zone the photos should be interpreted in! Answer for Japan is UTC+9 hours, and everything is correct. Whereas in LR’s map module I had to take into account that my laptop had changed from summer time to MEZ again in the middle of my vacation…

Hub January 23, 2013 at 1:50 PM

The major reason Lightroom fails is that LR does not deal with timezone properly. It would pretty easy to implement. When downloading images from your camera, LR should ask (and remember) what timezone you have set your camera too. And you never touch it in the camera. I choose to do UTC so I never have to deal with either daylight saving or timezone – also because that’s what GPS uses. From there, you have a reference time that can be mapped on the GPS tracklog. Bonus point it would also be possible, with that to determine the timezone of the photo to display the time for it as it was on location.

FWIW, the Maps feature in Aperture 3 deal with it properly – beside a few quirks / bugs – is it ask camera and actual timezone, etc.

George January 23, 2013 at 1:57 PM

This is incorrect. The point is not that Lightroom “does not deal with timezone properly”. Lightroom does not look to metadata for a time zone because there is no place in EXIF for a time zone. Additionally, many cameras still don’t have a time zone setting! Those that do, store it in a private maker note, in the absence of a formalized place for it in EXIF.

George

Leave a Comment

Previous post:

Next post: