Tom Dibble’s Nuggets of … Wisdom?

Geocoding and Aperture Workflow

Posted on May 14, 2008. Filed under: Apple, GPS, Photography |

Geocoding Aperture

I have just recently started down the path of adding geocoding to my Aperture workflow. This doesn’t apply to all the pictures I take yet; I only bother taking the GPS tracker out with me when going on a family hike, not to a sports field or such. Below is a summary of what my geocoding workflow looks like today. Keep in mind that it is still somewhat fluid and will likely evolve over the next 6-12 months.

Why Geocode

Why geocode?

Well, let’s take a step back. Why take pictures at all?

For me, the root answer is an obsessive compulsion to document what I’ve seen, where I’ve been, and how I look at life. This compulsion stems as much from innate narcissism as from the desire to provide a history for my children and grandchildren better and more complete than the one provided to me. My parents kept scrapbook after scrapbook of pictures, but they were never organized enough to look through and never complete enough to tell a cohesive story. This, however, was a huge improvement over the handful of photos with cryptic captions their parents had preserved.

A picture in a shoebox can be a treasure trove of information, but often is missing key details. Who is that person in the front? Maybe someone wrote something on the back. When was it taken? Maybe the clothes or age of some recognizable face will reveal this. Where was it taken? Maybe there’s a landmark visible in the background. If these questions can not be answered, then the photo generally falls into the “art” category: its only value is as something to look at, not as a historical document. Art, of course, is great. But connecting artistic photos to real people and places and events brings them to life and makes them relevant.

My father, in his last years, spent many nights poring over sepia-toned pictures of his parents and their families, trying to identify people and places and form a cohesive story of where we came from. Most of those pictures ended up remaining in the “unidentified” pile, with us unable to determine who was in them or where they were taken or even approximately when.

A digital picture combined with a well-heeded workflow fills in many of those unknowns, and, with a little luck, will keep my grandchildren from going through a similar ordeal (should they in fact care about where our family comes from). Who is the person? If a keyword was attached to it, that might say. When was it taken? Look at the timestamp. Where was it taken? Maybe a keyword or location tag was added to tell us that too. What other pictures include this person? A click of the mouse and a few keys can summon them all. What other pictures were taken in that town that year? Another few clicks, a little more typing, and all is apparent.

Who is in the picture, and where it was taken, rely on how well I as a photographer and post-processer stick to my workflow. As an engineer, I know that any process relying on human attention to detail is bound to fail in some measure some times. So, where possible, I want to remove those manual-workflow-reliant bits.

So, on a macro-level, I want to geocode my images so that I can look back a few years from now and say, “That image? Yeah, it was taken on the Hidden Falls trail.” That much, I could capture in my workflow. What is highly likely to not get captured is, “It was taken just below the falls in the pools of an adjoining creek”. Geocoding my pictures (with an automated workflow) gives reliable answers to both levels of the “where” question.

So, back to the original question: why geocode? Fundamentally, it is to automatically and reliably infuse an image with data to answer the “where” question. This is one crucial aspect to the larger goal of placing each picture in its historical context.

Geocoding Goals

• Geocoding should be attached to the master file, not kept in Yet Another Side Database
• Geocoding should be as automated as possible
• Accuracy of geocoding should be verified immediately in the workflow

Overall Geocoding Workflow

First, let me review my overall setup.

For trail equipment, I take along with me my trusty Canon Digital Rebel (300D, the original model), while my wife and/or children will often have their own digital cameras, and a Garmin eTrex Legend GPS tracker. The eTrex takes on two roles here: as a track logger (pertinent to this discussion) and as a trail map/guide (very useful out on the trail, but doesn’t affect this workflow). A more limited-display GPS track logger would work just as well as the eTrex where geocoding is concerned (and we’ve used my wife’s Garmin ForeRunner as a track logger just as effectively).

At home, I have my Mac set up with Aperture, where I do all my photo editing and library management. For this particular workflow, Aperture 2.1 (the latest version as of this writing) is required; earlier versions would require the GPS log mapping step to take place prior to importing into Aperture, which generally meant it would not get done.

On the trail, I start up the eTrex, let it acquire the satellites, then mount it on the shoulder strap of my pack. I’ve found that it needs to be high and unobstructed at all times to get a good track. I’ve also found that I needed to change the logging settings to log “more often” to avoid “jumps” in the track log. Occasionally, prior to clipping it onto my shoulder, I’ll take a picture of the eTrex screen to give me a “clap board” to sync up the camera’s clock and the GPS’s clock. Of course, this is only to-the-second accuracy, but that’s generally good enough for the GPS tracks (unless, say, you’re snapping pictures while tumbling down a hill or somesuch). Generally, though, I just set the clock in my camera to match that on the GPS if it’s more than a second or two off. This pretty much only happens when Daylight Savings Time starts/stops, as the camera (thankfully) doesn’t handle that changeover by itself.

From there on, I just take pictures whenever and wherever I want. Note of course that the GPS is capturing my location, not that of the subject, and not even the direction I am pointing the camera. It’s also not capturing the specific locations of my wife and kids as they take pictures, which isn’t a big deal when we’re all together.

At home, my first priority is always getting the pictures into Aperture, getting a first cut pass through them, getting any gross adjustments made, and syncing them up with the Apple TV so we can all revisit the day while sitting on the couch downstairs. I’ve talked about that particular aspect of my workflow previously, as well as the nuances that come into the mix thanks to the AppleTV, so won’t go into those topics here. There is, however, one minor change (or major change, depending on your perspective) introduced by the desire to geocode the source images.

Canon’s CRW format does not allow for geocoding. By this I mean that it physically will not allow storage of the “Latitude” and “Longitude” EXIF tags. Kind of puts a damper on the whole geocoding source images idea.

The two options available, then, are:

1. Put the geocoding data in an XMP sidecar. Aperture doesn’t support this today, so for today at least, it is out. Sorry. Will revisit in the future.
2. Transform Canon Raw into something which does allow geocoding tags, like Adobe DNG. Now that Aperture supports DNG, this is a viable option.

I chose the latter. For this, I needed to install the Adobe DNG Converter, then put together a little script which locates all *.CRW files on my flash disk, copies them to the hard drive, then runs the DNG converter on them to produce a separate directory full of *.DNG files; this folder is then, by the script, loaded into Aperture as a new project.

Of course, all of the above could be done by hand instead of by script, but being a highly repetitive bit of the overall workflow I see no reason to not automate it.

When I get around to it, I attach the eTrex to my computer using a Prolific USB Serial Port (drivers available for OS X at Prolific’s site – click on the md_pl2303… file), then run a second script which asks for a name for the hike (optimistically defaulting to today’s date; I typically correct the date then add a hyphen and the name of the trail we hiked) and runs LoadMyTracks to download all the logs to my track logs folder with that name.

Next, I load up GeoPhoto and open a new “scrapbook” for this trip’s photos. I tend to name this identically to the track name I gave the LoadMyTracks script, using copy/paste.

The next step is to load the Aperture-managed .DNG files into GeoPhoto. This isn’t so easy, though! We need to get the Aperture-managed Master files, not the Aperture-generated JPEG previews, so we can not just drag and drop from Aperture to GeoPhoto and expect it to work! To get the master files, I go into Finder (or PathFinder), use Show Contents on the Aperture Library, then open the blue folders to my project (“2008” then “05 May”), then Show Contents on the project package. From there, I do a spotlight search to get the list of all .DNG files below. Finally, I select all the found .DNG files and drag them over into GeoPhoto, into the prepared album.

An enterprising soul might notice that if one were to just drag the image from Aperture to an application or script, the file which gets loaded is “…/Previews/SomeVersionName.jpg” (as evidenced by dragging a photo from Aperture to Preview). The master file is the .DNG (or .CRW or .JPG) file at ../. Surely, this information could be used to select the master files to drag into GeoPhoto or the like!

Inside GeoPhoto, I select all the pictures in the album, then use the “Map Items to GPS Track” option off the Item menu. In the resulting dialog, I select the saved .gpx file from LoadMyTracks, then select Manual timestamp correction (none), then select the timezone of my camera (Americas/Los Angeles), confirm that all the images got mapped, check the “store location” checkbox, then click “okay”. Maddeningly, then I need to re-select all the images and use the “Save locations to original files” option.

Once geocoding information has been added to the .DNG files, I go back into Aperture and update it’s database by using the “Update EXIF from Master” menu option (under Metadata).

Voilà! Now, clicking on an image from Aperture, the “Show on Map” option is available, and loads the image up in Google Maps. From here, a host of tools is available, including Google Earth and Flickr synchronizations.

Geocoding Application Alternatives

I use LoadMyTracks to copy my GPS data from the eTrex to a .gpx file in a file hierarchy. Another popular tool is GPSBabel, although I could not get it to reliably download from the eTrex. I am sure the fault is user error there, but with a much more usable free alternative (LoadMyTracks) I don’t see the point in trying to find out what I was doing wrong! Note that other tools using GPSBabel as a library (HoudahGPS and GeoPhoto) likewise failed to get tracks from the eTrex, so perhaps the library just doesn’t really support eTrex and/or my USB-Serial adapter.

I have settled on Ovolab’s GeoPhoto as my track-matching tool of choice. I also looked into HoudahGeo, which seemed just as good (and avoided some of the GeoPhoto usability quirks). I don’t find the embedded Google Earth clone compelling, although I do appreciate the (fleeting) view GeoPhoto gives me of the imported track overlaid on a map (HoudahGeo only indicates which pictures overlap with the track, giving no way to know if they matched properly). At the same time I was put off by GeoPhoto’s insanely crippled demo which doesn’t allow testing of the single most important feature of the application: how well and compatibly it writes geocoding information to the files. I almost didn’t buy it for this reason. However, thanks to a Euro-US$ 1:1 conversion in their pricing structure, GeoPhoto was almost half the price of HoudahGeo, so I went with GeoPhoto. Not exactly a ringing endorsement, and I have quite a few problems with GeoPhoto overall (see the Wishlist section), but do note that all those nits so far as I can tell also would have applied to HoudahGeo.

As glue for the repetitive tasks, I have two scripts.

The first script is used to import photos from my card, encode them into DNG format, and import them into Aperture.

The second script is used to pull the log files from my GPS tracker into an organized folder structure on disk.

The real fun, of course, comes in viewing these geocoded images. For that, I use Google Earth.

Wishlist

Geocoding on the Mac, and especially when trying to keep the geocoding information attached to a permanent Master file rather than a fleeting exported version in Aperture, is very rough. I am told that smoother workflows exist on the Windows side of the fence, which is a shame because so much else about organizing and editing photos is so much better on the Mac side.

Aperture Wishes

• Keep project-level non-photo information. Specifically, give me a place to put the damned .gpx track log! Bonus points for specifically handling the .gpx attachments to a project below, but a general “project-level data store” mechanism would be highly useful in many many ways!
• Support geocoding internally. Really. Embed the likes of GeoPhoto right into Aperture, or even just “blind” track log matching.
• Alternatively, better integration with geocoding tools like HoudahGeo or GeoPhoto.
• Alternatively, allow me to drag a reference to the Master file directly from the interface to the likes of HoudahGeo or GeoPhoto.
• Better integration with a visualization tool (ie, Google Earth or Google Maps if you must). Bonus points for being able to click on a handful of versions, click a “Show in Google Earth”, and have the .gpx track loaded into Google Earth along with the photos!
• Better location-based searching, such as “all pictures within the boundaries of Sacramento County, CA”, or “all pictures within 2 miles radius of Lake Tahoe”.

GeoPhoto Wishes

• Better integrate with Aperture. Bonus points if you could take a .jpg dragged in and automagically translate that to the matching master image (go up one folder and find the .DNG or .CRW etc file).
• Support Applescripting. Every one of the complaints I have here could be remedied in Applescript, if only you supported it!
• Remember the time zone I selected for my camera. This is the one item which would not apply to HoudahGeo. There is no reason at all, given the fact that every single one of my photos has “PDT” set as its timezone, that you should have me pick from a 1,000-item drop down which city best represents my location. There is certainly no reason why I should have to do that every single time I use the tool!
• Support “pasting” of images from Finder. I can only drag images in. If I could paste them, then I could put together a quick applescript to put the master file references on the clipboard.
• Allow information to automatically be written to the original files once the “match” sheet is dismissed. There’s no reason I should have to tell you again that I want that done. I know, I could set the option to do this when I quit the app, but I like to make sure everything was written and readable by Aperture before clearing an app from memory.
• Rethink the UI to be more workflow-based (or allow for a workflow-based view). It’s a nice interface for viewing photos on a globe, but it really sucks for actually coding those locations. HoudahGeo’s UI is more along the right lines there, although its inability to show the track we are matching up to counters the workflow benefits.
• Include elevation data (altitude) when saving latitude and longitude.
• If an image already has geocoding data and is added to your database, use it’s location information!
• Fix the stupid, short-sighted, crippled trial demo which keeps us from actually trying GeoPhoto in any geocoding workflow. Anyone buying your product is buying it completely based on the faith that you actually are capable of writing EXIF data out to their files and that this will work in their imagined workflow. Imagine how many more customers you’d have if they could verify your product worked before shelling out their money!
• Give error messages when writing to files doesn’t work. After buying GeoPhoto I thought it just didn’t work because it wasn’t writing lat/long to the CRW files. It wasn’t until I tried the same in HoudahGeo, which gave a meaningful error message that I learned of the CRW file limitation. Driving your customers (who buy your product on vague descriptions and good faith) to your competition to figure out what went wrong is not good!
• Get the forum your web site talks about up and running.

Geocoding Wishes

• Add “accuracy” information to geocoding tags
• Somehow, allow the location not only of the photographer, but also of the subject(s), or at least the directionality of the picture. Often, these are close enough to not matter; sometimes, though, the picture is of a distant mountain or a sunset over the water.

Make a Comment

7 Responses to “Geocoding and Aperture Workflow”

Comments RSS Feed

Where's The Comment Form?