Choosing Photos

I’ve spent a lot of my life picking photos—the ones to keep, the ones to print, the ones to give a client, the ones to put online, the ones to show friends. All sorts of different constraints and considerations apply. (To confuse things, this process is sometimes called “editing”; traditionally a photo editor at a newspaper, or highschool yearbook, is responsible for selecting the photos to publish.)

I found some years ago that housemates looking over my shoulder often want me to display a larger percentage of the photos I shot than I generally do. I, on the other hand, think I ought to be considerably more selective than I am for the snapshot album exhibits.

So, here are some examples and thoughts on the question, based on part of one roll I scanned this last week. The photos are from Keycon 7 (1990), in Winnipeg.

I’m discussing these as snapshots (pictures of people you know) or photojournalism (snapshots of people you follow at a distance), not as art!

I’m going to show you the contact sheet, and then the ones I scanned, and for a few of those explain why they don’t show in the final collection, or why they do. (The scan decision was made with this article in mind; I scanned some just so I could exhibit them in this article.)

(A “contact sheet” used to be made by putting the negatives on a sheet of photo paper in the darkroom, putting a sheet of glass over them, exposing for a measured time using the enlarger or some controllable light source, and then developing the sheet of paper. This gave you a nice index of all the negatives on that roll on one sheet, all at the same exposure so you could predict exposures for later pictures once you’d made a good print of an earlier picture. This so-called contact sheet is a scan of the negatives in their Print File archival storage page on a flatbed scanner with transparency capability.)

What’s on this roll

We’ll just go through them in order. I’ll be identifying them by the negative number, which you can see below the photo in the edge printing (also above, except on the first row where it was cropped off).


This one is mediocre, but I ended up including it. Nobody shows their face that well (the two at the edges are both looking quite a bit down, and Geri in the center is looking sideways. Also Peter on the right isn’t at all interacting with the other two. Still, they’re all in focus and decently exposed.


Didn’t scan this at all. Ruth is half behind the head of hair in the foreground. There really doesn’t seem to be much point to this photo as it turned out. Probably I didn’t see the foreground person coming.


This is a bit sketchy technically; underexposed, and I haven’t manage a great job on color correction. However, the two people in back are clearly interacting, plus what makes it, the person sitting on the floor smiling up at the camera.  This ends up being a semi-decent picture.


Alternate version of 16; the lighted wand in the back is interesting but doesn’t really communicate anything. However, the great expression in the front is missing, so this was not the one I chose.


The flaw here is the person in yellow in the background. They’re too hidden to contribute anything, but the bright yellow and enough face to get your attention are still there. However, the three in front are great; Geri’s eyes are closed, but she’s so clearly laughing hard that’s okay, and the two flanking her are clearly engaged. This is pretty decent.


Wanted a photo of Dave Clement, and this one is decent, but Nate’s eyes are closed, so the photo as a whole doesn’t do much good. If photos of Dave were seriously rare I’d just crop this down or something, but while I don’t seem to have another on this roll, I’ve got hundreds through the collection as a whole; not rare. I scanned this so you could see for sure Nate’s eyes are closed, I could tell from the contact sheet.


Best one so far, I think. Fairly nice of both Kara and Ruth, and they’re clearly having an interesting conversation as well as eating dinner. Distracting background, but the flash exposure has brought the foreground up enough that the background is rather suppressed, and that’s generally unavoidable in snapshots anyway.


This could have been interesting, but my timing was off, so the guy on the chair completely disappears behind his arm.


Missed this one first time through, but it’s actually quite nice, and shows us who the person on the chair in the previous shot was.


No scan, no hope. Victor’s hand blocking Beth’s face, Polly a bit out of focus.  Again, if Victor was a terribly rare find I’d use this in some way, but he isn’t.


Ruth getting something out of a bag. Fairly nice.


Mostly bad. Victor could probably be extracted if pictures of Victor were rare, but we just dealt with that above. Beth is interacting with the person behind Victor’s hand, and that person is, um, not looking their best in this shot. No point in this one.

Still no Moon Colonies

Here’s how I was marking the occasion, 48 years ago:

Shot off my parents’ B&W television

While we’ve done amazing things with remote sensing and with robotic exploration, we haven’t done much more with manned exploration. Given the success of the robots, we couldn’t have gotten that much information for the same money with men. But as somebody who grew up on “the conquest of space” it’s still a major disappointment.

I have several rolls of such shots. They’re all Kodak Tri-X, bulk loaded, shot with my mother’s old Bolsey 35 I believe (I didn’t get my Miranda Sensorex until December of 1969). Developed with stainless steel tanks in a dish pan down by the laundry sink, contact printed in the waterless darkroom the other side of the basement.

The white bands diagonally across many pictures shows that the shutter speed of the camera wasn’t well-enough synced to the scan rate of the TV. The TV scan rate would be extremely accurate or the picture would be complete hash, so the shutter was off.  This was a leaf shutter, not a focal-plane shutter, which affects the symptoms.

This was roll 108; I started the numbering system at 100 to make room for filing older negatives as I found them and organized them.  This was so long ago that the negatives were in glassine sleeves.

Glassine sleeves!

A few of the individual photos:

Whinging About Dirty Negatives

Every time I scan a few rolls of my old photos, I’m reminded what the most important message I could send myself back in time is: Get a water filter!

At least, I think that might be what the underlying problem is. I have vaguely similar amounts of junk on films I developed in my home darkroom, in the Photo Coop darkroom at Carleton, and in the Alumni Office darkroom there. I’m not really sure, though.

Here’s a bit from a 1973 roll of Plus-X:

Lots of white mess!  Much of it elongated, but not precisely parallel to the edges of the film. The full-size image is my full scan resolution for that bit of the film.

So, what’s my real problem?

  • Too much Photo-Flo?
  • Not enough Photo-Flo?
  • Wiping film with fingers instead of sponge?
  • Dirty water?
  • Storage since then?
  • Angered the gods?

It’s basically simple in Photoshop to use the healing brush to eliminate most of this. It’s not fast and it’s not very interesting, but it’s simple.   I mean, I can easily spend 45 minutes cleaning up one shot in this sort of condition.  And unfortunately it’s slower and less simple, and less good, in Lightroom.



All the points! We does not have them!

(Promoted from a comment elsewhere, original context not needed for this to make sense.)

Being aggressive, brave, feeling privileged, or whatever it is that makes me speak out in almost any circumstances doesn’t actually correlate well with knowing things useful in a discussion or in having ideas of value to a discussion. It’s worth some effort to me to avoid driving away people who have stuff to contribute to the discussion even if they are “timid” or easily scared off. Brash, outspoken people don’t really lack for opportunities to make their points; but we don’t have “all the points”.

Elevator Buttons

Both for the call buttons at each floor, and the floor buttons in the elevator car, we expect them to respond to pushing by some change in state to show that our command has been received.  Nearly always this is some form of a light coming on (background of the button, surrounding the button, rarely a little light right in the button). I will refer to this as the “state indicator”.

In addition to acknowledging our immediate command, the state indicator conveys information to other users of the elevator. When we come to the doors we can see from a distance that the “up” call button has already been pressed, so we don’t have to force our way through the crowd to push it ourselves; and the same thing for the floor button once we’re in the car.

All these buttons have to talk to a central controller (well, or to distributed controllers which talk to each other, thus achieving the same goal as a central controller). For the elevator to actually come when the “up” call light is on, the elevator car itself has to move to that floor, stop, and open its doors.  For me to arrive on the 11th floor after pushing that button, the car has to go there, stop, and open its doors.

But there’s a weird thing that happens with many elevators, including the ThyssenKrupp elevator system at the DoubleTree Park Place (where I was for Fourth Street Fantasy Convention last weekend, and where Minicon will be for the first time this coming Easter). Often, if I push a button rather briefly, I will see the state indicator come on briefly, and then go off and stay off.  My push does not seem to have “taken”, at least the central controller has not accepted it.  (If I wait, the elevator never comes in response to the call I thought I made, but which after the brief blink is not acknowledged. It may of course come to the floor to drop somebody off, and may then continue in the direction I want, but it never comes empty, so I feel safe in saying I have not managed to log my request with the controller.)

How can this happen? The most obvious way to set it up is to have the state indicators simply controlled from the central controller. Thus, if it comes on, the central controller does have the request, and if it doesn’t, it doesn’t (well, or the indicator is burned out, or there’s a wiring fault, or…oh, the heck with it; it doesn’t).

The evidence appears to suggest that this isn’t how it works, for whatever reason.

Okay, rampant speculation based on very little knowledge (said to be a dangerous thing; though actually that’s “learning”) coming up. It’s worth remarking that elevators are fairly old technology, that they’re safety-critical, and that they have been heavily regulated for most of the time they’ve existed. This can tend to limit implementation or design choices sometimes in bizarre ways.

One theory is that getting the request logged in the central controller and the response back to the state indicator is slow enough that people were reacting weirdly (they’d push the button, nothing would happen and then just as they tried again the state indicator would come on, for example). If this is seen (as it probably should be) as a user interface fault, maybe somebody had the bright idea of turning on the state indicator locally briefly, for long enough that the central command to turn it on would have arrived before the local command expired.

But that then raises the question of why the brief push is enough to trigger the local turn-on but not the central controller; surely it makes no sense for the two to have independent access to the exact details of the analog button-press and to make independent decisions about it based on different rules! The local module should decide if the button has been pressed or not, and then both take local action and communicate with the central controller, so they would never be in conflicting states.

It’s possible that, either in these particular elevators (which are fairly old), or in elevator designs by tradition, or perhaps by old regulatory fiat, this approach was adopted at a technological era when it was economically beneficial to put all the intelligence in one central place, and then do extremely simple things locally to work around it (I didn’t test carefully, the local turn-on of the state indicator may be as simple as “while the button is pressed”).

Or it could be weirder and much more interesting; we can always hope.

Speculation, as above, is cheap. Does anybody actually know anything about elevator control systems?

This particular behavior bugs me because the light coming on instantly tends to influence me to making shorter button pushes (I see confirmation!), which makes it more likely that I haven’t actually held the button down long enough to log my request properly.