Why I didn't continue my Project 365 this year

After doing Project 365 (where you take at least a picture a day for a year) from 2008 through 2013 (cf), I decided to not continue it on into this year. Since Project 365 is what got me into photography in the first place, I feel like writing a little bit about why I didn't continue mine. Ultimately there are two major reasons for it.

The first reason is that I'd become more than a little bit tired of going out into grey days and bad weather in order to get a picture. Having done this for six years I think I've more than proved that I can do it if I want to; I just don't want to any more, especially since on bad days Project 365 easily turns into a grind. By the end of 2013 I was really tired of it and I think it showed in my photography on such days.

The other reason is that I want to genuinely experiment with some things, for example black and white photography (I have a vague plan to spend at least a month shooting only black & white in order to train myself to see good B&W pictures). The problem with real experimentation in the context of a Project 365 is that if you are really experimenting and trying to learn something new, you can fail totally and spectacularly and wind up with no usable pictures for your project for that day. Project 365 half-encourages experimentation, but it's safe experimentation, experimentation where you're pretty sure that you'll wind up with a usable picture even if it's not spectacular. I want to do more wild things than that (and I don't want to do two rounds of photography in a day, one focused on a Project 365 picture and then another on the real photography I want to do).

Also I have to admit that I've spent basically every day since January 1st 2008 carrying a camera around and thinking at least a little bit about photography, and I'd like to see what it's like to not do that (and especially what it's like to routinely bike places without my camera bag on my back). The results so far is that it's liberating and I sometimes miss taking pictures.

(I'll see how weird it feels to bike without a camera bag when the weather is actually biking weather.)

Darktable versus Rawtherapee

When I wrote my entry on Linux RAW processors I said that Rawtherapee was a better choice than darktable. I have to take that back because it turns out my quick tests weren't a good representation of using either program for real.

I formed my initial views after test-processing just a couple of photos with each program. Now that I've used both to process batches of photos for real (and in one case I've run the same batch through both), I've had to change my opinion. It turns out that darktable is what you want to use, not Rawtherapee. For all of darktable's irritations, it works better. I summarized the main reasons why in a tweet:

Darktable drives me up the wall and I hate the experience of using it, but it delivers better results than Rawtherapee and does it faster.

(I've since become more acclimatized (or numb) to darktable's interface issues.)

The first issue is that Rawtherapee turns out to be relatively terrible for sorting through a bunch of photos and figuring out which ones are worthwhile. I could do it, but it took too long and was a pain in the rear in all sorts of ways because Rawtherapee has fumbled multiple aspects of doing this efficiently. Darktable is not great at this but in practice I can go through a bunch of photos much quicker and more efficiently with it. Since this is a major part of my daily workflow, this matters a lot to me.

(For example, Rawtherapee has absolutely and utterly terrible downsizing of thumbnails in its directory overview, to the point where they are basically useless for telling you anything about the quality of the photos. Think of the most crude and jagged downsizing you've seen; that's Rawtherapee.)

The other part is that I get better processed photos with darktable, in that I like how they look and it's (much) easier to produce what I think of as good looking photos. Again, darktable is not perfect and there are some things that Rawtherapee unquestionably does better, but darktable wins overall for me. I find it very hard to argue with clearly better results, especially when I can get them surprisingly rapidly and easily.

Now I'm going to say something that may make people especially unhappy, because there's a third advantage to darktable. Namely, it's under much more active development than Rawtherapee (I track the source repositories for both and darktable sees multiple commits a day whereas Rawtherapee moves much slower). I know that development activity doesn't necessarily equal quality, but both programs are highly imperfect right now so the one that's under much more active development is much more likely to improve into something good (or at least have your favorite irritation fixed).

(Note that with either program you want to be using the latest version compiled from the project's source repository. Both are under active development and improvement and yes, it really makes a difference. Probably not as much a difference as in my initial tests (where the then-current release versions produced bad output), but you'll find that both are better experiences.)

(As before, you should pay attention to the publication date of this entry if you're coming here through a web search. It's quite possible that things will be different in a year or two. I certainly hope that Rawtherapee improves substantially over time and at least some of its issues should be relatively fixable.)

Sidebar: what happened to make me discover this

I didn't set out to try out both on a batch of real photos; instead, I set out to process a batch with Rawtherapee because I thought it was the program for me. After slogging through the whole process and getting a trio of processed photos that I wasn't really enthused with, I decided to re-run the same batch through darktable just to see. Much to my surprise I was able to do so much faster and I was uniformly much happier with the results, to the point where I immediately replaced all of the Rawtherapee versions I'd uploaded to Flickr with the darktable versions.

(The extra speed with darktable didn't come because I immediately zeroed in on the 'best' photos and only dealt with them. I reconsidered all of the batch from scratch in darktable, although I wasn't surprised to wind up with the same set of selects.)

Why I have a camera slingbag but you probably shouldn't

Camera slingbags are inherently a compromise. Backpacks (and some belt systems and the like) provide better support, while shoulder bags and belt systems provide faster access to gear. This compromise nature is why I think you probably shouldn't get a slingbag since you can do better on either aspect and in the long run I think the compromises inherent in a slingbag will prove irritating.

(Especially I would not get a big slingbag because slingbags just don't provide enough support for carrying a relatively heavy load.)

Why I have a slingbag, and specifically why I have a Lowepro AW-series slingbag, is that I am an impatient bicyclist. As a bicyclist I need to carry my camera in some way that keeps it both stable and out of the way; this rules out both belt systems and anything like a plain shoulder bag. As an impatient bicyclist I want my camera to be relatively quickly accessible so there is not a big time-consuming production involved in stopping to take a picture; this rules out backpacks. So I'm left with the Lowepro slingbag; it's stable enough to stay in place even with relatively aggressive bicycling and being able to just unhook the stabilization strap and sling the bag around keeps the camera accessible enough to make me happy when I stop to take pictures. I live with the relative lack of support (which I can definitely feel on long days with relatively heavy loads) and the relative lack of fast access because I need the particular combination in the middle.

(Why the Lowepro specifically? Because it has a second stabilization strap that holds the slingbag firmly in place when it's clipped on to the main strap. I've been unable to find any other slingbag with such a stabilization strap, although I haven't looked everywhere.)

PS: in some ways I'd be better served by a handlebar bag that was big enough for my camera (and lens), padded enough so I could trust it to not rattle the camera too much, and detachable so I could take it with me when I get off the bike. Unfortunately you really want drop handlebars to create the cable-free space for such a relatively large handlebar bag and, well, I don't have them on my current bike.

(Update: it turns out that I'm wrong about the Lowepro being the only slingbag with a stabilization strap; they're actually reasonably common if you look around and read specifications in detail. Due to not having seen or played with any of the alternatives in person, I have no opinions on the relative merits of my Lowepro versus the alternatives.)

A brief, opinionated summary of Linux RAW processing options

For reasons that don't fit in the margins of this entry, I've been looking at and doing brief tests with a bunch of Linux RAW processing programs lately. Rather than have all of this fall out of my mind in a bit, here's my views written down.

(If you're coming here through a web search you should pay attention to the publication date of this entry. The information here will probably be out of date in six months and will definitely be out of date in a year or two. I'll put in a link to any future updates I make.)

Update (April 16 2013): I now recommend darktable over Rawtherapee. See DarktableVsRawtherapee.

As a starting point I will note that I do not want a program to do catalog management for me. I have my own system for that and I've got no interest in shoveling all of my photographs into some opaque black box. What I want out of a RAW processing program is processing a directory of RAW files and generating output; I will take it from there, thanks.

• Bibble 5: Apart from not being buyable any more, not having been updated for any cameras released since mid to late 2011, and a certain paucity of plugins, this works great. It's what I use now and will be using for as long as possible (ie, until I get a new camera that it doesn't support). Yes, it costs money; it was worth it (on Linux).

• AfterShot Pro: This is what Bibble 5 was upgraded into after Corel bought out Bibble Labs. It may work well for some people but for me it was strictly worse than Bibble 5 (except for some plugins). The straw that broke the camel's back was realizing that its handling of white balance was so broken that I couldn't change white balance or use spot white balance at all (if I did, it added bonus colour casts and white wasn't). This bug was known and had not been fixed across multiple updates and releases.

  (If ASP did not have this bug I would probably be using it today as my best option. But the other problem with ASP is that there is a great deal of uncertainty over whether Corel will keep updating it to, for example, add support for new cameras. That they fired the entire Bibble development team is broadly not seen as good news.)

• Rawtherapee: Tolerable (assuming that you're using the latest source code or 4.0.10; 4.0.9 mangled colours in some of my D90 NEFs). I have various gripes with RT and it's often rather clunky and nowhere near as fluid as Bibble, but it ultimately does work. I could use it, although I would grit my teeth periodically. Rawtherapee is your best current option on Linux even though it doesn't fill me with enthusiasm.

  (One problem is that RT offers you too many options for doing things and no guidance on which one is usually the best approach. I feel fairly strongly that RAW processors should pick one best option for as many things as possible and then put it front and center, relegating any other versions to the distant sidelines.)

• darktable is my dark horse hope. I'd like to love it but I just can't in the end because every time I use it I'm left with very divided opinions. On the one hand, there's a bunch of stuff that it gets right (and better than Rawtherapee). On the other hand there's also a lot of things that I feel it gets wrong and some things that are plain out in utter left field. It's also even more complex and scattershot than Rawtherapee, which makes for a very frustrating experience; at one point I almost gave up on it over my inability to find basic adjustments for saturation.

  (It turns out that in the darktable way there are several different saturation adjustments; one in 'Velvia', one hiding inconspicuously in the colour correction module, and one in 'Vibrance'. I had to Google this to find a blog entry from the darktable people. RAW processors should have a prominent panel of standard image options like brightness, saturation, contrast, etc, all using the best version that the processor has.)

  Although I'm sure that it's an illusion, darktable really feels to me like no actual photographer tried to use it for serious work (even more so than Rawtherapee, which has some of the same issues). It has so many usability issues and things that I think should be different that it feels more like a project by enthusiastic programmers who shoved as many nifty image processing tools into it as they could without sitting down to process photographs and then ask themselves 'does this actually work in practice?'.

  I can imagine using darktable and in some ways I feel that it's better than Rawtherapee but I don't think I'd really enjoy it in the state that darktable is in today. Also, every so often in my testing I ran into UI glitches and bugs. One way to put this is darktable is a program that you love despite itself.

  PS: the best way to make darktable just process a directory of files instead of trying to import everything into a collection is 'darktable --library :memory: /your/dir'. (Thanks go to <hanatos> on the darktable IRC channel.)

• Lightzone is the great white hope of Linux RAW processors, a commercial RAW processor that failed in the marketplace but was then released as open source (see the Wikipedia entry). Unfortunately there are no actual opensource builds yet. But lots of people quite liked the commercial version, so maybe someday.

• rawstudio is either too basic or too good at hiding its more advanced options. I stopped looking at it after I couldn't find an option for spot white balance.

• fotoxx: I found the version of this packaged by Fedora 17 to be clumsy, awkward, annoying, and limited. I think its interface is a terrible mistake for getting real photo processing work done and I dislike its habit of silently writing out .tiff files for any RAWs that it appears to look at. I consider it unusable in practice.

• digiKam: I don't want a 'photo management application' that insists on swallowing all of my photos. I just want to develop my RAWs. In the interests of fairness I gave it a basic try and it immediately failed the 'has spot white balance' test, which is not surprising when they basically steer you very hard away from actually processing your RAWs when you import them.

• Photivo: Not evaluated.
  The Fedora 17 package that they supply failed to run due to a missing file that should have been included. But the documentation on their web site doesn't make me encouraged about the program's likely features and power.

  Update, April 16 2013: I built Photivo from source and it turns out that it's purely for processing a single file at a time. This makes it useless for me regardless of any other merits it might have.

• UFRaw offers no viable way of going through a directory of RAWs to select which ones are worth working on; it's strictly oriented to processing a single one. This fails my usability criteria regardless of any actual RAW processing features it may have.

While this is every current Linux RAW processor that I know about, I probably don't know about them all. Please feel free to mention any that I've missed in the comments.

(Explicitly not considered: using Wine or some other Windows virtualization method to run various Windows software options.)

Sidebar: Macs and Windows are better for this

I'm going to say it straight up: the overall quality of the RAW processing software you can get on Macs and Windows clearly exceeds any of these Linux options. The closest that Linux can come is AfterShot Pro, and that is somewhere around third tier software in the Mac and Windows worlds. If good, high quality photo processing is a significant priority for you, you should not be doing it on Linux.

(My vague impression is that Macs are currently a somewhat better choice than Windows for reasons that do not fit in the margins of this sidebar.)

I don't process my photos on Linux because it's a good idea; I do it because I'm welded to Linux for other reasons and I'm not yet at the point where I'm willing to buy a second system (it'd be a Mac) and find the space for it. If I was more committed to my photography, this would be one of the things that would change.

Using automatic exposure locking

Back in 2008 when I set up my D90 and wrote down my settings, I said this about the AE-L button:

I don't know enough to use exposure holding, but if I do 'tap to hold' seems to be the least obnoxious way of doing it.

Boy, I was kind of innocent back then. Nowadays I have learned what autoexposure locking is for the hard way and I use it reasonably frequently. The simple way to put it is that locking the exposure is the quick way to deal with the importance of watching your exposure from shot to shot.

If you're not in full manual mode, the camera can change the metering during a sequence of photographs; it can do this even if all you're doing is changing the exposure compensation. Locking the exposure with AE-L counteracts this, giving you a stable exposure that you can make consistent adjustments to. Otherwise your attempts to adjust the exposure to get the picture right can be happening on top of quicksand, so that you dial in some negative exposure compensation to correct things but then the camera decides to expose more so in the end your exposure winds up just the same. This is both pointless and frustrating when it happens (and very puzzling if you don't notice the exposure shifting on you; here you are adding exposure compensation yet nothing is happening, or the wrong thing is happening).

I've repeatedly stubbed my toe on this so these days I've learned that if I'm taking a sequence of pictures of the same thing the first thing I should do is hit the AE-L button, especially if I'm just working to get the exposure right. Otherwise, even if I'm just lowering the camera to look at the histogram after I've taken a picture the composition can be just different enough when I bring it back up to my eye that the Nikon matrix metering changes the base exposure.

I maintain that my choice of 'tap to hold' is absolutely the right option for this on Nikon cameras, at least for what I want to use AE-L for. It would be very hard to have to keep one finger on the AE-L button all the time, even when I'm doing things like checking the histogram for specific areas of the picture.

How long an exposure can my camera meter?

A friend and I were talking about long exposure photography today, which brought up the issue of determining how long an exposure you needed. Like most DSLRs, my Nikon D90 will only automatically expose out to 30 seconds; if you need a longer exposure than that, you have to time it by hand in Bulb mode.

(In my opinion this is a pointless limitation, probably reflexively carried forward from the days when there was only so much space on a physical shutter speed dial. Since cameras are computers these days, you could even limit automatic exposures to no more than 30 seconds while still letting the camera count the time for longer manual exposures.)

But that's just how long an automatic exposure the camera will do, not the limit of what it will meter for you. If the exposure is at the 30 second limit and the viewfinder is still reading 1 EV of underexposure, you can fix that with an exposure that has 1 EV more time, ie a 60 second bulb exposure. So how long an exposure can I actually meter with my camera?

• in my normal settings, the viewfinder will show up to 2 EV of underexposure. If I change the camera to use 1/2 EV steps for exposure compensation instead of 1/3 EV steps, this increases to 3 EV of underexposure.

• I can extend the range of the viewfinder meter by adding negative exposure compensation (a 1 EV underexposure with -1 EV of exposure compensation will read as a correct 0 EV exposure). My camera allows up to +/-5 EV of exposure compensation, pushing metering to an effective 8 EV of underexposure.

  (The allowed range of exposure compensation doesn't changed based on the step size used.)

Since every EV is a doubling of the exposure time, 8 EV of exposure past 30 seconds is 128 minutes; call it a two hour exposure. If this isn't enough, I can start pulling the viewfinder meter back by metering with a high ISO but actually photographing with a low ISO. My camera has a base ISO of 200 and is easily raised to ISO 3200, giving me another 4 EV of metering range (a total of 12 EV); that takes me to an exposure duration of over 30 hours.

So the real answer here is that my camera battery is going to die long before I get to an exposure that I can't meter. (Probably the sensor would overheat from continuous use, too.)

(In theory the D90's meter is only specified to work down to -1 LV. In practice this isn't even moonlight and I've metered without problems in much darker conditions.)

PS: since I'm unlikely to sit still for a one hour exposure, much less a two hour one, I don't even need to change the exposure compensation step size. My normal settings still give me 7 EV of exposure past 30 seconds, which is already just over an hour. Mind you, using 1/2 EV steps makes the eventual time calculations somewhat easier.

The importance of watching your exposure

One of the things I've learned over the time that I've been doing photography is the importance of watching my exposure. Not in the usual sense of noticing when the camera is putting you at a too low or absurdly high shutter speed (or ISO, or aperture), although that's important too. What I mean is watching your exposure from shot to shot.

Modern cameras in matrix or evaluative metering can and do change how they decide to expose a scene depending on just how it looks to them, regardless of whether or not the actual light has changed. Or in other words, if you change your composition the camera can change to a bad exposure. If your first photograph of a mixed scene with the clear sky visible has the sky correctly exposed at 1/200th at f/11 at ISO 200, you then recompose to show more of the shadowed ground, and the camera suddenly wants to be at 1/100th at f/8 at ISO 200, you are probably going to completely blow out the sky if you just automatically click the shutter.

(As they say, I've been there and done that.)

The same thing is true in more extended circumstances. If you're strolling along a path in a park taking pictures of different things, your exposure often should be fairly constant regardless of how much of the sky or sunlit ground is visible in each photograph. And if the camera's metering seems very off, you probably have a choice you need to make; you can let the camera more or less expose for the darker areas you're looking at (and accept that the bright areas may well blow out), expose for the sky or other bright area and live with the darker areas (possibly doing tricks in postprocessing), or add fill flash or the like. Or decide that there's too much contrast in the picture and you can't get a decent version of what your eyes are seeing.

This is why I say you want to watch your shot to shot exposure; you want to realize that the 1/100th at f/8 at ISO 200 exposure has to be wrong before you click the shutter. Even if you routinely check your histograms after taking a photograph, getting a good exposure to start with will save you the aggravation of immediately re-taking a shot (and trying to narrow in on the right exposure).

(Some people will say that the answer is clearly to use manual mode and maybe center-weighted or spot metering. Both are too much work for me and tend to blow up in my face in their own ways; in practice it's easier for me to watch shot to shot exposure and correct the metering with exposure compensation when necessary.)

Link: A demonstration of an issue with ETTR

This link requires a bit of explanation (if only so that I can remember it later). The person I'm linking to took a standard colour checker test target and took a properly exposed shot then a series at increasing positive exposure compensations (ie, exposing to the right), postprocessed all of the overexposed photos to correctly expose them again, and then cropped strips of the colour targets and stacked the same strips from each exposure. The goal is to clearly see any colour shifts caused by ETTR.

(As he notes, some are deliberately overexposed, going beyond what you should theoretically do with ETTR. Of course they do represent what happens if you accidentally overexpose in the course of trying to do ETTR.)

Part of what I like about this is that it's an experiment that anyone can do (if you have a colour checker test target). Your camera and processing system may well give you different results than his, but either way you'll have learned something interesting.

So: Experiment: ETTR hue shifts and now the revised Experiment: ETTR hue shifts (reformatted).

PS: obviously you should do this test with the camera on a tripod and locked at a single ISO, unless you also want to test the effects of ISO on colour shifts. Although that too may be a useful test, depending on how you're thinking of using ETTR.

My current photo processing workflow (as of June 2010)

In Thom Hogan's June 14th update (now here), he wrote:

Tonight's homework: document your workflow. Really. Write it down. Include everything that happens from pressing the shutter release to looking at the final image (wherever it may have ended up, e.g. on a wall, on Facebook, etc.).

I have some spare time today for once, since I already wrote today's techblog entry, so I feel like tackling this one just because.

To start with, a note. My workflow is strongly influenced by two things. First, I'm a Linux user, which means a limited choices for software and tools (and a bunch of scripting, because I'm comfortable with that). Second, it's strongly oriented around my Project 365 work, with an inevitable time-based focus on how I organize and approach things.

So:

• the camera puts the picture in the default Nikon directory structure on my 4GB SD card. I have my camera set to the defaults, where it just numbers images sequentially and only resets the numbering when it rolls over every 10,000 images.

  A bit of negative workflow: I've learned the hard way that I can't tell a good picture from a bad one from just looking at the camera LCD (and it goes both ways; good pictures have looked bad on the LCD, and bad pictures have looked great). So I almost never delete pictures in the camera and generally it has to be completely and obviously a bad picture before I will.

  (The common causes are accidentally taken pictures or pictures where it is clear that the exposure is nowhere near where I want it.)

• when I want to pull things off the camera, I use a script to rsync the entire card to my current master directory. This happens every day, generally only once.

  (Note that when I say 'the entire card', I really mean it; the master directory is an exact image of the card's directory layout.)

  I don't reformat the card when I do this. Instead, pictures stay on the card until the nominal remaining capacity drops below somewhere in the 90 to 50 images range (I typically take around 50 pictures a day, so this gives me at least a day's margin on card space). At that point I move the current master directory to my archival area, start a new one, and immediately reformat the card. Master directories are numbered sequentially as d90-pool-NN; I'm going to have to go three digits soon.

  (This is why I have to use rsync; I need something that will not re-copy already copied images.)

  My iron rule on card reformatting is that I must have run the card sync script a second time immediately before I reformat, and it must have reported nothing synced. This is designed to avoid accidentally reformatting a card with un-transferred photos.

  Yes, this does mean that I have every photograph I've ever taken (and not immediately deleted in the camera). Disk space is cheap at the low-ish rate that I photograph.

  (I am not claiming that I have a useful archive of every photo I've taken, because it's not. But if I really want to find something, at least it hasn't been deleted so it's possible.)

• at the end of each day I use an exiftool-based script to copy all of the day's photographs to a temporary staging directory. Usually this happens at the same time as I'm pulling them off the camera.

  (This is also the point where I pop the camera battery out and drop it in the battery charger. Also, I clear the staging directory of the previous day's pictures before running the script. This is not scripted, because I don't script things that delete pictures.)

• I use Bibble 5 on the staging directory in a multi-pass approach to decide on my selects and completely process them (all in the staging directory). At the end of this I have Bibble 5 write the 'developed' JPEGs to a subdirectory and I go through them with xli to make sure that I'm happy with them; if not, I process them some more until I am.

  The actual details of how I work in Bibble 5 are far too long (and variable) to go into this entry, which is already long enough.

• I use a script to copy all of the bits of the final selects from the staging area to my Flickr archive area (which lives inside my general photo archive area). This is broadly organized by day (and by month and year once each is finished and I archive it). By 'all of the bits' I mean the original raw file from the camera, the Bibble data file about the edits I did, and the final generated JPEG.

  (The script picks out what to copy based on what pictures have generated JPEGs.)

  If I had to use chromatic aberration correction, I use the GIMP to trim off the last few pixels on the sides of the picture if they need it, because the current version of Bibble 5 corrupts the very edge of the picture in this case. (If I have cropped an edge in it doesn't need this, so I don't just hit every CA-processed image with an ImageMagick script or the like.)

  (In theory I could crop the image by those few pixels in Bibble 5. In practice, Bibble 5 on Linux is currently unusably slow when cropping in magnified view. So I get to use the GIMP.)

• I upload the JPEGs to my Flickr using Flickr's basic uploader page in Firefox. After this finishes, I blank out the default filename-based titles that Flickr has given the pictures and add tags for appropriate things if they're missing.

  (Then I agonize over what to chose as my Project 365 photo, except on days when the choice is completely obvious or I only had one thing that was worth uploading to start with.)

On some days, I'm selecting images for more than just my Flickr uploads; the most common case is that I am also selecting for TBN's website. In these cases I generally repeat the last three stages for each separate reason, sometimes entirely independently and sometimes interleaved (where as I look at each image, I decide both if it's good for Flickr and if it's good for TBN).

(Note that I have two completely separate photo archive areas, one for the master directories, and one general photo archive area for all of the pictures that I've selected for various things. The second area has subdirectories for the thing, like flickr and tbn and family, and then generally date-based within each reason. If I had a higher volume of pictures, I would probably want to be more organized and consistent about my directory structures.)

As a Linux user, my strong impression is that Bibble 5 is about my only good choice for processing anything more than a few photographs in raw format. There are some free programs that will process individual raw format pictures, generally not really very well or fast, but I haven't found one that does a decent and acceptably fast job at browsing through them so I can make my selects.

(At this point I am nowhere near willing to either give up Linux or to get a second computer just to do photo processing.)

I could simplify a bunch of this workflow if I could bring myself to trust Bibble 5's 'catalog' asset management features. I would probably use multiple catalogs, with one for my master archive and then one for each reason I pick out photographs (a Flickr one, a TBN one, etc), and switch to formatting the card every time I copied the pictures off it (even though this makes me nervous; leaving the pictures on the card is vaguely reassuring just in case something disastrous happens on the computer). However, this would mean giving up the principle that nothing except my own scripts gets to go anywhere near the master archives.

(I'm a sysadmin. No, I don't trust your program.)

With a more complicated copying scheme I could change my master archives over to a date-based directory structure while still not reformatting cards immediately. I would have to rsync to a staging area, then hard-link the files into their final destinations (chosen based on their EXIF dates); anything that was already hardlinked wouldn't need to be looked at a second time, which would make it reasonably efficient.

Sidebar: looking back at the history of this

A lot of the dance around my master directories is because when I started out, I was planning to burn each master directory to DVD when it was 'done' as a backup archive; this is also why I got a 4GB SD card, because it went well with wanting roughly DVD-sized chunks of work. I never actually implemented this plan; my backups are instead just rsync'd to an external USB drive every so often.

(Don't panic, my machine has mirrored drives to start with.)

It's interesting and a bit depressing to see how pervasively this never implemented backup plan has shaped the rest of my workflow.

Back when I was using Bibble 4, my theoretical workflow was to use the staging area only to make my selects, then have Bibble 4 copy the selects to the per-day P365 archive area, re-point Bibble 4 to it, and process them there. This never entirely worked; every so often I would have to do most of the processing before deciding whether something was a select or not, and every so often I would get pulled into processing an image before pausing to copy it.

When the Bibble 5 beta came out, it forced my hand by not supporting directory based file copying (it could only copy files around inside its asset-management catalogs). If I was copying the files outside of Bibble 5 anyways, it was much easier to do all of the processing in one directory instead of theoretically splitting it across two separate ones.

The Nikon DSLR trick with Auto ISO and Manual mode

Nikon DSLRs have a reasonably smart automatic ISO mode, where you set your minimum shutter speed and maximum ISO and when the camera has hit the minimum shutter speed it starts raising the ISO. They are also famous (or infamous in some quarters) for not turning off Auto ISO if you go into Manual mode, contrary to what you might expect.

(What happens in this semi-Manual mode is that the camera works out its idea of the correct exposure and then attempts to get there purely by changing the ISO.)

I actually sort of like this, because it enables a trick: it essentially turns Manual mode into a combined Aperture+Shutter priority mode, and in turn what this does is give you a convenient way to vary auto ISO's minimum shutter speed as conditions change:

• if I am shooting braced or with better support than expected, I can switch to M and drop the shutter speed down to lower the ISO.
• if I switch from one end of a zoom to the other I can either drop or raise the shutter speed as necessary (depending on how I set my minimum shutter speed).
• if I am suddenly taking pictures of action or something else where I want a fast shutter speed, I can increase the shutter speed without moving from my preferred (or necessary) aperture.

(Life would be somewhat simpler if Auto ISO also let us pick a minimum aperture; even though I can shoot a 50mm f/1.8 wide open, I often don't want to and I'd rather raise the ISO a bit and be at, say, f/2.8.)

Using Manual mode this way means that you really want to be able to control exposure compensation, and in turn this probably makes this trick unusable on bodies with only a single control wheel (where you lose access to exposure compensation in M mode).

The one thing that I really have to remember when doing this is to pay attention to the ISO and to the exposure meter, because the camera can overexpose if you push it. Generally if I'm doing this I want the ISO to always be above base ISO; the ISO going to base ISO when I'm at a comfortable shutter speed is a sign that I should switch to another exposure mode, because M mode probably isn't getting me anything useful.