RIP Photo Management Application Aperture, Gone but not Soon Forgotten

One of my favorite articles here at the W&M Academic Technology Blog is Mike Blum’s 2012 post “What Do You Do When Your Favorite Tool Goes Away?” In that piece Mike dealt with, not altogether tongue-in-cheek, the stages of grieving when one of your favorite applications goes away. Specifically he was referring to the early demise of Jing, a fantastic application that had no real price-equivalent competitors at the time.

If the loss of a tool like Jing is painful, however, it can be devastating when your mission-critical tool — and one in that you have put in hundreds or thousands of hours of work into — is abandoned by its developer and you are faced with the loss of much of your work. Unfortunately, dealing with such losses in academia is fairly common, where specialized software packages and/or combinations of software and hardware are abandoned by manufacturers with no clear migration paths forward.

Planning for My Own Application Loss

I’m currently in the midst of going through such a loss myself, following the recently announced demise of Apple’s Aperture, and its apparent replacement with a cloud-centric and much less powerful application. Apple’s “pro version” of iPhoto, Aperture was released in 2005 and was the original professional photo management/editing application. Along with Adobe’s Lightroom (b. 2007), it has been the mainstay tool for managing and editing very large photo collections of professional and serious amateur photographers. For nearly ten years in photography circles, the Aperture versus Lightroom argument has only been superseded in volume (perhaps) by the Nikon versus Canon bickering.

One of my six large Aperture Libraries… with over 32,000 images!

A screen capture of one of my six large Aperture libraries… with over 32,000 images!

In the early years, Aperture seemed to be the clearly superior application, and in terms of image management, but certainly not editing, it remains so today. Like many serious photographers, I decided to use Aperture as my go-to tool very early on, and chose to continue to do so even during the past couple of years when it became increasingly apparent that Apple (strangely) was not committed either to the ongoing development of this application or its large and loyal professional user base.

As is often the case in these situations, planning for my post-Aperture photography world at this point in time is made much worse due to the uncertainty regarding what I stand to lose and what can be salvaged.

Taking Stock

While Apple’s recent announcement is certainly a downer and will certainly cost me some sweat (and possibly some tears) to recover from, there is no reason to panic and rush to some ill-considered action plan at this point. I think that in these situations the first reasonable action is to do a fast inventory of what I have, and what is “safe” or at risk of being lost in the future. So, here’s what I have:

  1. Thousands of original photos. My collection includes approximately 100,000 photos — some are scans, but most are original digital photos.
  2. Lots of metadata. In addition to all of the standard data on digital photographs (Exif data), almost all my photos are rated, “tagged” with keywords — keywords for geographical locations, type of photo, people’s names, etc.
  3. Geolocation data. Many of the photographs are also geolocated either directly by the camera or manually.
  4. Different edits of the same photo. Often individual photos have been used to create multiple variations, but because of how Aperture works these variations take up no additional storage space.
  5. Printed books using Aperture’s layouts. Photographs have been used to generate many printed books using the program’s internal page layout capabilities.
  6. Facial recognition information. Photos of certain people as automatically determined by Aperture’s facial recognition system.
  7. Photo groupings and organization. Individual photos can be grouped in several independent ways including “Projects,” “Stacks,” “Albums,” and “Smart Albums.” In database terms, individual photos have a one-to-many relationship with groupings.

What Is Safe, What Is Not

Regardless of future developments, all of my original photos can easily be migrated into a new management system. After doing quite of bit of research into how Aperture stores and manages metadata, I am almost certain that all, or at least almost all of the metadata, including geocoding, that I have added to these images will also migrate with the corresponding images. However, getting all of the metadata to migrate with the images to a new system will almost certainly require many, many hours of fiddling, testing, and file regeneration before the task is done.

I am also almost certain that there will be no problem in exporting the variations that I have generated over the years. However, each variation will need to be saved as a final product. This will take up much more storage space, and unlike the variations within Aperture, I will not be able to selectively edit the changes I have made in each of the pictures (i.e. sort of like having a final printed paper text rather than the word processing file that was used to generate it). By losing this flexibility in editing, I will in effect have lost a great deal of work done to these images. The situation with the printed books will also most likely be very similar — the final product will be saved but the capacity to edit will be lost.

The last two items on my list, the facial recognition system data, and the “grouping” of images will almost certainly be a complete loss once I migrate to any non-Apple management system. Future Apple products may well maintain the ability to display these groupings, but at the significant cost of much less powerful editing capabilities.

Remain Calm and Carry on or Jump Ship?

The situation I find myself in is fairly common to the users of these dedicated systems during periods of change. Broadly speaking, at this time I see three options before me.

  • Carry on (aka stall). Continue to use my existing solution, Aperture, as there is no immediate reason to not do so. This means that new photos will be added to my existing Aperture library, with metadata added just as I have done for the past nine years or so. In the short term this should be fairly easy to do, but in the future I may find myself having to freeze system updates and even hardware upgrades as they may affect the stability of the application. As time passes this “solution” will become less and less tenable.
  • Jump ship (aka cut losses). With currently one only really viable replacement, Adobe Lightroom, the die seems to have been cast as to what needs to be done… migrate the existing collection as well as possible, and write off the losses. However, by jumping too early I risk losing more data than if I wait a bit longer because new and improved migration paths may become available. However, based on history, waiting to jump can be a risky game because in the long term these migration paths eventually become extremely convoluted and sometimes even impossible.
  • Hybrid of the above. Probably my least favorite option, as it probably entails the most overall effort, is to freeze my current Aperture library as is, and begin to use Lightroom or some other future management system for all new photos. The “frozen” library would eventually need to be migrated at some future point to the new system. Wait too long and there may be no way to migrate it, or even worse to even access the collection with existing systems.

Given that Aperture, in the words of the Princess Bride, is only “mostly dead” right now, I think I’ll follow the “carry on” approach for now. But I will need to jump to a new system (with all associated loss and pain) within the next six months to a year and hope for the best. Fortunately there have been some recent efforts (not yet mature) that seem to indicate that migration may become less time consuming and less “lossy” in the future.

P.S. Thanks, Apple!

About Pablo Yáñez

Pablo Yáñez is the Academic Technologist for the Sciences. He studied Geology at the University of Maryland (BS) and University of Arizona (MS), where he specialized in Geochemistry. He joined Information Technology at William and Mary in 2000, and has since worked with nearly all of the academic departments on campus in some capacity or another. Beyond his "normal" Academic Technologist duties, during these years he has been involved in several projects/initiatives including: the use of the College's Public Access Labs; the creation of the Center for Geospatial Analysis, the Swem Media Center, and many technology-enhanced classrooms; and in the review and planning of campus-wide software procurement.