Rohit's Realm

// / archive / 2006 / 07 / 12 / iphoto-no-more-part-1

July 12, 2006

iPhoto No More, Part 1

It is a veritable truth that since my dive into the (mostly) wonderful world of Apple products in Sept. 2003, I have rapidly degenerated into a state of Apple-fanaticism bordering on contemptible fanboy status, seemingly supporting each and ever Apple product to hit the market. As such, it may seem downright heretical for me to write an article describing how I purged iPhoto from my life, but then again, irreverance has always been a strong suit.

Now, don't get me wrong. It's not that I don't like iPhoto; it's that I hate it. And, I'm not saying iPhoto doesn't work at all; I mean, it did work for me--the first time. At that point, I was even deluded into thinking it might help my workflow in processing photographs. Boy, was I wrong! My second attempt to use that memory-hungry, unresponsive piece of shit, iPhoto froze and had to be forcibly terminated.

Pretty soon, uploading routine sets of 150-200 photographs began to take hours, not minutes. Sorting, classifying, or deleting photos became virtually impossible. My photo processing workflow went from focusing on the quality of photographs to focusing on the stupid rainbow-colored Macintosh equivalent of the hated hourglass spinning incessantly everytime I moved the mouse. This pitiful state of affairs lasted for years, until finally, this summer, I had started dreading uploading photographs so much that all my memory cards were filled to the brim. Something had to be done. The cursed iPhoto had to be purged from my life.

The first thing I realized was that without an omnipresent tool such as iPhoto, I would need to get very serious about managing my ever-growing photo collection. I probably have about 5-10K photographs in my collection right now, with a good 2K added in light (i.e., one's without major travel) years. The helter-skelter means by which I formerly kept track (or not) of photographs was not sustainable; copious, tedious, painstaking addition of metadata was necessary to make my collection manageable in the long-run (i.e., my lifetime).

Why not simply use Gallery to manage my photos, one might wonder? Well, for me, there were many reasons, but the most pressing were, in no particular order:

  • Gallery is public1, and I certainly don't intend to publish all the photos I proof, let alone all the ones I take;
  • Gallery2 has become increasingly complex, and it is not possible to run simple arbitrary SQL queries (yes, I'm old school like that), such as What are my top quality photographs? or Which photographs did I use a 50mm focal length? without a lot of API studying;
  • There is no means of embedding semantic data within the image using XMP, EXIF, or IPTC in G2 that I am aware of;
  • Given the timeframe I'm looking at (half a century), a relatively simple data storage format (a single table) seems less prone to obsolescence than a large application schema; and
  • G2 currently only handles the presentation aspects; other, unrelated, but vital activities (e.g., retrieval, archival) are not addressed by this software directly.

Given these points, I decided a better route would be to continue to use Gallery solely as a presentation mechanism (a task at which it is unparalleled, in my humble opinion) and design my own workflow process around managing photographs. After some research, I came up with the following process for managing my photograph collection:

  1. Upload photographs from my camera to my file server.
  2. Catalog photographs and store information in a relational database (e.g., assign unique id; determine title, caption, description, quality, type; extract aperture, focal length, shutter speed, and iso settings from EXIF data, etc.).
  3. Generate thumbnails and an HTML index for quick, portable viewing of an album.
  4. Upload photos of moderate quality or better to my gallery.
  5. Archive all photographs to CD (in case I decide some day that life ain't worth it).

In my next post, I will discuss the technologies I used to enable this process. Obviously, given my nearly exclusive use of FreeBSD at home, my solution has a decided *nix-bent to it. For those interested in solutions for Windows, I refer you to an article from earlier this year.

1 Obviously, one could configure various permission sets to create access restrictions, but no security mechanism is foolproof; I'd much rather not have personal--read, career-inhibiting--photographs suddenly become public through some bug.


Interesting that you posted on this topic. I just posted an entry on photo workflow, too.

What about post-processing? Or are you uploading your final photos? One of my peeves about iPhoto is that there's no integration with Photoshop which I believe exists in Aperture. Sometimes I'm too lazy to drag the file into PS, retouch/post-process, and import the new version into iPhoto, that I end up using iPhoto's editing tools which aren't as great, but it is quick.

You should build a gallery-type system that will generate albums based on metadata. I suggest it because I don't have the time to build it myself, but have been wanting something like that for a long time now. ;) I'm using and iPhoto/Coppermine set up in the meantime.

So I also despise iPhoto but the new iPhoto got rid of the thing I hated most, the crappy iPhoto photo cataloging. At least I can create my own directory structure now which is a good thing.

My workflow usually consists of:
1) Upload pictures to a machine
2) Clean out crappy photos and flag the ones I want to upload in Photoshop. If I crop/tweak an image, I add a,b,c... to the filename. The browse feature is super handy.
3) Run my export to web macro to create uploadable pictures.
4) Upload to either gallery or Flickr. (I wish there was an easier way here to upload to multiple services so I didn't have to re-caption my photos.)
5) Backup to DVD/server (soon to be properly implemented)

Have you tried running Picasa for Linux? I haven't played with it a bunch but I was quite impressed with my install at work as a possible solution to managing photos *properly*.

Were you at least using iPhoto 6? It's not fast, but it is much faster than earlier versions.

Don't backups on CD-R. They only live a few years at most, and with offline backups there's no way to continuously verify that they're intact. I've been burned by this in the past, going to recover from removable backups and discovering that 2% were corrupt after less than a year.

Jen: I don't do a whole lot of post-processing, so I didn't immediately think about incorporating it into my workflow. However, if I had to add a step, I think I would probably still catalog the photograph as is, and then do any post-processing before generating the HTML index. The semantic data (hopefully) wouldn't change; only the image.

Brandon: the status of my home computers is a whole mess in and of itself, but to make a long story short, neither my Gentoo desktop nor my FreeBSD file server work right now due to various hardware issues. I've only got my PowerBook. However, I'll be sure to check out Picassa once I get my machines up and running.

Cody: I wasn't using iPhoto 6, but I don't think at this point it would make a difference to me. I'm just filled with hatred over that program. I didn't realize the degradation rate on CD-Rs was so poor. What's your experience with DVDs; I've heard their a lot more robust.

Add Comment





* required field

E-mail addresses will never be displayed. The following HTML tags are allowed:
a abbr acronym address big blockquote br cite del em li ol p pre q small strong sub sup ul