A Linux-Based Photography Workflow (Part 2: Image Ingest and Organization)


Key: Key: R20101207-141738

This is part of a series of posts on Linux-based software tools for a photography workflow. Please read that first if you are coming to this series fresh–it will provide the necessary background information to explain the purpose of this series. In this particular post I’ll talk about general photo storage, organization, ingest and viewing.

As I have mentioned before, I do not currently use a database to organize and keyword search my images. The reason is that I do not frequently need to keyword search my images. Sometimes I will tag them when I upload them to Flickr for web use and disaster archiving (more about that topic later)–in that case I can simply search my own photostream for candidate images. And sometimes I will make XML files with some metadata (including keywords) that I can search. But I am not a selling stock imagery, or getting calls from some editor looking for such and such kind of an photograph. No, I typically work on my recent images from the last two years or so, printing, entering contests/exhibitions, uploading to the blog or whatever artistic outlet I might have in mind. For my purposes it is not difficult eyeballing a couple years worth of folders to find what I am looking for. If I was needing to search my collection frequently then I probably would be using a database. All this is a long-winded preface to saying that I use simple Linux filesystems to store my images and nothing more. I typically use the ext3  (and soon, probably ext4) file systems.

I store images in folders in an archive area of my RAID. The folders are named by year, and also after special trips, physical areas and/or projects. In addition to these I have a few special folders that constitute a “staging area”: these are named by camera (e.g. “ep1”, “gh1”, “gx100”, “iphone”, etc.). When I am ready to ingest some new images, I connect the camera by USB cable, or pop the card into a reader, which automounts the flash disk. I use nautilus to open one window of thumbnails to the named camera folder in the staging area and one window to the camera flash drive as a mass storage device. Scrolling down to the bottom of each pane I can quickly see which files I need to drag off the camera and into the staging folder.  A quick marquee selection and a drag and I have the images safely copied onto my RAID.  I then right-click on the flash drive icon and unmount it, disconnect and turn off the camera.

After copying the images to the staging area, I need to rename them to match the key system that I use (i.e. by time, primarily). For this purpose I have written a Python program that uses an EXIF library to examine the header and find the date of capture for each file whose name matches a certain naming convention (you know the typical ones used by manufacturers: PNNNNNNN.JPG, DSCNXXXX.DNG, etc.  It is a very easy and quick task for the program to locate the files and rename them by time. I simply run this program on the staging area camera folder after the initial copy.

Geeqie screenshot

Once the files are renamed, I will open an image viewer/sorter/organizer to examine the take.  The most important factors for me in an image organizer are speed, color management, speed, the ability to losslessly rotate JPEG images, speed, easy toggling in and out of full screen view, speed, and the ability to quickly launch an image editor or raw converter on a photo. Oh, and did I mention speed? I used to use gthumb for this purpose, but since they have not yet integrated color management into the viewer and generally stopped maintaining it I have now almost wholly switched to geeqie, which has gotten very good in the latest versions. Geeqie also has features for batch RAW conversion (using ufraw), assigning scores to images for your “selects”, and has a decent histogram and EXIF pane. It even has a half decent contact sheet printing function, and multiple version viewing option. Using geeqie I can easily scan the take, compare images and click to open the ones I want to work on in post.

The images tend to live in the staging folders for a while, and after a few months I will move them to a more permanent home in one of the other folders. I will only delete photos that are badly (and unintentionally) blurred; I save all the rest. Since I primarily shoot JPEG, storage is not as huge an issue for me as it is for some photographers. I try not to delete the images from the card until I have backed up from one RAID to my NAS or to an external USB drive. I rotate external drives for this purpose, and occasionally take them to the bank and swap them for ones in my safe-deposit box. For selects, I usually upload them to Flickr as well (pro account–full res), making sure that I have several disaster scenarios covered.

That pretty much covers the first part of the workflow: getting the images in. Next time I’ll discuss raw conversion and image editing.

3 thoughts on “A Linux-Based Photography Workflow (Part 2: Image Ingest and Organization)

  1. Thanks Eric for mentioning geeqie. Now, only if it would also deal with compressed files too, much like GIMP … I wonder if there are hooks to deal with them, much like mutt …

  2. Hi Eric, not the compressed raw type that a camera creates, but the kind created by gzip & bzip2 I was referring to.

    So if geeqie had some hook to read from a pipe, so bunzip2, e.g., could be run on a compressed file, output of which would become input of geeqie something like “bunzip2 -c %s | geeqie-hook -“.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: