My Camera Workflow Peter Teuben Last updated: 1-dec-2009 Here's my camera workflow and some comments how it has changed over the years. Some of the comments are somewhat camera (Nikon/SLR) and operating system (Linux/Fedora) specific. Summary: SHOOT - DOWNLOAD - EDIT - ALBUMS - ARCHIVE - BACKUP SHOOTING: I used to shoot with an Olympus with filenames P
.JPG, where would run 1..9,a,b,c for the 12 months,
the day number, and an increasing integer. Now I shoot with a Nikon SLR, with filenames DSC_.JPG, although you can pick the prefix. Extension .NEF is also an option, and depending on color model the DSC_ would become _DSC. I always have a 2nd charged battery with me, and I normally shoot in A (Aperture) mode. I also have a few spare cards with me, just in case. And often a few lenses as well, just not a spare camera. I usually shoot in JPG, but for certain projects i'll do raw (NEF), but usually have the camera setup to store both the NEF and JPG version. DOWNLOADING: Luckily most cameras now become a mounted VFAT filesystem when you attach a USB cable to a computer, so the first thing one might use is the 'cp' program, or drop and drag into a folder if that fancies you more. This simplest style of copy will quickly become cumbersome if you don't immediately delete pictures from your card afterwards. Or else how will you remember the last one you copied over? I'm just too nervous to delete them from the card, unless you immediately write them to CD or so, just in case something does happen to your computer. Been there, done that. In Haiti, of all places. So I don't delete pictures from the card after downloading. In fact, often around the house you shoot a few, download them, shoot more etc. I also have the USB card reader, which could be handy for those very special events where you have to keep shooting while downloading. This will generally require two people, but here you simply swap in another card while the camera is back on the floor for more shooting. Once wireless transmission becomes more common, this mode might disappear again, but with such a card reader shooting downtime will be very very short. I download my pictures in some directory YYYY/MM/DD, which I semi-automatically create (but see also below). A python script was written, somewhat Nikon specific but easy to tailor, that takes advantage of the fact that the filenames are something like DSC_NNNN.JPG, where NNNN is a number that keeps incrementing. The script will remember the last NNNN that you successfully downloaded and will start with that one and copy it to the /YYYY/MM/DD directory. The current version of this script has some minor issues, which I've been always too lazy to fix since you can work around them. You can see all too well in this script (get-nikon and get-nikon-now) how it has to be maintained when the folder inside the DCIM directory changed because more than 1000 pictures had been stored in the previous one... Also, you'll need a special clone of this script if you have multiple cameras (e.g. a D300 and D70s, or even a 2nd D300) So, this method has issues, and enter the rapid-photo-downloader (RPD) script, which i've only recently been using [November 2009]. It can be tailored to exactly do what i did with get-nikon, EXCEPT it will not remember the last downloaded file (via that NNNN number). The side effect of this is that if you didn't want to keep a picture and removed it from disk, RPD will fetch them again for you, unless you clean your card each time. I have not experimented much with picasa's download option. It looks nice, and makes a small mini-thumbnail summary per day of all pictures and puts a big red cross over the ones you've downloaded before. However, unless you take action, it will again download the ones you've deleted before, the same issue as the RPD script. Once import has been clicked, you have to select a new folder, which I find cumbersome, since i like the automated /YYYY/MM/DD structure. So i use an external program and picasa quickly guides me to this new directory in which pictures will appear. EDITING: As you will see below, DSC_NNNN.JPG pictures are eventually removed to make room on the disk, but anything I edit (mostly in gimp), will have a different name, usually DSC_NNNNa.JPG for the first one, and semi-automated scripts will not remove these files. A neat way in picasa, which i've been using more and more, is a simple edit (crop, horizon leveling, contrast/color). If you then export them in an album, those edits become part of the picture (which the unpleasant side-effect that you now have two versions of the same DSC_NNNN.JPG file) ALBUMS: Creating your own albums on your own web-server where you have full control over your html files. First there were some home-brewn c-shell an python scripts that created thumbnail summaries such as this one: http://www.astro.umd.edu/~teuben/pics/ams-1/ but then I heard about jigl (http://xome.net/projects/jigl/) to create albums, see e.g. http://www.astro.umd.edu/~teuben/pics/carma2007/ which the help of another script could really speed up album generation. But ever since I found out about picasa, where it can also make html albums, the time-saving has convinced me to use this,even though they are perhaps not exactly what I like in a layout. Here's two examples of the same: http://www.astro.umd.edu/~teuben/pics/GalaxyMasses09/ http://www.astro.umd.edu/~teuben/pics/GalaxyMasses09_800/ What is probably the biggest timesaver is the photocaptions. You type them into picasa, and these are added as the TPCX "Caption-Abstract" in the JPG image. The 'exiftool' program in Linux can also manually edit/change them as follows: exiftool -Caption-Abstract "Great view of the sky" sky.jpg but do not use the EXIF field labeled "User Comment", exifcom -w "Another view..." sky.jpg since picasa does not listen to it. ARCHIVING: As the pictures have been downloaded, picasa (assuming it's active) will show them in its folder. I can then start tagging/captioning and folder captioning. All pictures comments are writting into the JPG file. I should say this happens silently, except on my system the files will have the execute bit turned on before, and off after picasa has messed with it. Picasa is "sneaky" though and won't change the timestamp! BACKUP: When sufficient space is accumulated, collections of days/months/events are copied directly to a DVD or other big medium. After this the pictures are resized to a reasonable 1024 x 768,usually as sm_DSC_NNNN.JPG using the convert utility convert -quality 85 -geometry 1024x768 $file sm_$file and the original $file is then removed. The advantage is that convert retains the Caption-Abstract tag that picasa placed inside the JPG file, so picasa can still find all your pictures, but now taking up nearly 10 times less space. There's an issue (trick) with picasa and storing/moving pictures to an external hard drive. Under Tools->Folder Manager you will have added your own space where the pictures are maintained. picasa will auto-scan them each time (if you tagged this folder as such). But for an external drive you don't want to do this, as it will remove your wonderful secret database in one wipe once picasa runs and the external HD is not present. So, use the "scan only once" option for this. But you have to remember to do the expensive "scan" option from time to time, in case you want to find your pictures again. Another option is to try and keep using the smaller 1024 style pictures that "convert" created, and perhaps thin out series that look awfully similar (sometimes I wind up making a long series of shots meant for an animation or patiently waiting for an animal to do something interesting). <> TODOS: As I use mostly picasa and flickr, but occasionally some other places where the pictures (dis)appear, I figured it would be good to keep a mirror copy of the pictures I've submitted to these places. I don't have a good plan for this. Some others are nikonians, national geographic, flickr's scary Getty submission, and then even the batches I've taken to printing places such as Ritz.. Some mounting methods in Linux cause filenames to be upper case, I've programmed the RPD script to always upper case the files, as I'm now used to this. But it does happen sometimes that I get them lower case, which can be a nuisance. LINKS: http://www.astro.umd.edu/~teuben/pics/workflow.txt (this document) http://thomashawk.com/2009/05/my-photography-workflow-2009.html HISTORY: 30-nov-2009 First draft