Shallow Thoughts : tags : photo

Akkana's Musings on Open Source Computing and Technology, Science, and Nature.

Wed, 16 Jul 2014

Time-lapse photography: a simple Arduino-driven camera intervalometer

[Arduino intervalometer] While testing my automated critter camera, I was getting lots of false positives caused by clouds gathering and growing and then evaporating away. False positives are annoying, but I discovered that it's fun watching the clouds grow and change in all those photos ... which got me thinking about time-lapse photography.

First, a disclaimer: it's easy and cheap to just buy an intervalometer. Search for timer remote control or intervalometer and you'll find plenty of options for around $20-30. In fact, I ordered one. But, hey, it's not here yet, and I'm impatient. And I've always wanted to try controlling a camera from an Arduino. This seemed like the perfect excuse.

Why an Arduino rather than a Raspberry Pi or BeagleBone? Just because it's simpler and cheaper, and this project doesn't need much compute power. But everything here should be applicable to any microcontroller.

My Canon Rebel Xsi has a fairly simple wired remote control plug: a standard 2.5mm stereo phone plug. I say "standard" as though you can just walk into Radio Shack and buy one, but in fact it turned out to be surprisingly difficult, even when I was in Silicon Valley, to find them. Fortunately, I had found some, several years ago, and had cables already wired up waiting for an experiment.

The outside connector ("sleeve") of the plug is ground. Connecting ground to the middle ("ring") conductor makes the camera focus, like pressing the shutter button halfway; connecting ground to the center ("tip") conductor makes it take a picture. I have a wired cable release that I use for astronomy and spent a few minutes with an ohmmeter verifying what did what, but if you don't happen to have a cable release and a multimeter there are plenty of Canon remote control pinout diagrams on the web.

Now we need a way for the controller to connect one pin of the remote to another on command. There are ways to simulate that with transistors -- my Arduino-controlled robotic shark project did that. However, the shark was about a $40 toy, while my DSLR cost quite a bit more than that. While I did find several people on the web saying they'd used transistors with a DSLR with no ill effects, I found a lot more who were nervous about trying it. I decided I was one of the nervous ones.

The alternative to transistors is to use something like a relay. In a relay, voltage applied across one pair of contacts -- the signal from the controller -- creates a magnetic field that closes a switch and joins another pair of contacts -- the wires going to the camera's remote.

But there's a problem with relays: that magnetic field, when it collapses, can send a pulse of current back up the wire to the controller, possibly damaging it.

There's another alternative, though. An opto-isolator works like a relay but without the magnetic pulse problem. Instead of a magnetic field, it uses an LED (internally, inside the chip where you can't see it) and a photo sensor. I bought some opto-isolators a while back and had been looking for an excuse to try one. Actually two: I needed one for the focus pin and one for the shutter pin.

How do you choose which opto-isolator to use out of the gazillion options available in a components catalog? I don't know, but when I bought a selection of them a few years ago, it included a 4N25, 4N26 and 4N27, which seem to be popular and well documented, as well as a few other models that are so unpopular I couldn't even find a datasheet for them. So I went with the 4N25.

Wiring an opto-isolator is easy. You do need a resistor across the inputs (presumably because it's an LED). 380Ω is apparently a good value for the 4N25, but it's not critical. I didn't have any 380Ω but I had a bunch of 330Ω so that's what I used. The inputs (the signals from the Arduino) go between pins 1 and 2, with a resistor; the outputs (the wires to the camera remote plug) go between pins 4 and 5, as shown in the diagram on this Arduino and Opto-isolators discussion, except that I didn't use any pull-up resistor on the output.

Then you just need a simple Arduino program to drive the inputs. Apparently the camera wants to see a focus half-press before it gets the input to trigger the shutter, so I put in a slight delay there, and another delay while I "hold the shutter button down" before releasing both of them.

Here's some Arduino code to shoot a photo every ten seconds:

int focusPin = 6;
int shutterPin = 7;

int focusDelay = 50;
int shutterOpen = 100;
int betweenPictures = 10000;

void setup()
{
    pinMode(focusPin, OUTPUT);
    pinMode(shutterPin, OUTPUT);
}

void snapPhoto()
{
    digitalWrite(focusPin, HIGH);
    delay(focusDelay);
    digitalWrite(shutterPin, HIGH);
    delay(shutterOpen);
    digitalWrite(shutterPin, LOW);
    digitalWrite(focusPin, LOW);
}

void loop()
{
    delay(betweenPictures);
    snapPhoto();
}

Naturally, since then we haven't had any dramatic clouds, and the lightning storms have all been late at night after I went to bed. (I don't want to leave my nice camera out unattended in a rainstorm.) But my intervalometer seemed to work fine in short tests. Eventually I'll make some actual time-lapse movies ... but that will be a separate article.

Tags: , , , ,
[ 18:31 Jul 16, 2014    More hardware | permalink to this entry | comments ]

Thu, 03 Jul 2014

Detecting wildlife with a PIR sensor (or not)

[PIR sensor] In my last crittercam installment, the NoIR night-vision crittercam, I was having trouble with false positives, where the camera would trigger repeatedly after dawn as leaves moved in the wind and the morning shadows marched across the camera's field of view. I wondered if a passive infra-red (PIR) sensor would be the answer.

I got one, and the answer is: no. It was very easy to hook up, and didn't cost much, so it was a worthwhile experiment; but it gets nearly as many false positives as camera-based motion detection. It isn't as sensitive to wind, but as the ground and the foliage heat up at dawn, the moving shadows are just as much a problem as they were with image-based motion detection.

Still, I might be able to combine the two, so I figure it's worth writing up.

Reading inputs from the HC-SR501 PIR sensor

[PIR sensor pins]

The PIR sensor I chose was the common HC-SR501 module. It has three pins -- Vcc, ground, and signal -- and two potentiometer adjustments.

It's easy to hook up to a Raspberry Pi because it can take 5 volts in on its Vcc pin, but its signal is 3.3v (a digital signal -- either motion is detected or it isn't), so you don't have to fool with voltage dividers or other means to get a 5v signal down to the 3v the Pi can handle. I used GPIO pin 7 for signal, because it's right on the corner of the Pi's GPIO header and easy to find.

There are two ways to track a digital signal like this. Either you can poll the pin in an infinfte loop:

import time
import RPi.GPIO as GPIO

pir_pin = 7
sleeptime = 1

GPIO.setmode(GPIO.BCM)
GPIO.setup(pir_pin, GPIO.IN)

while True:
    if GPIO.input(pir_pin):
        print "Motion detected!"
    time.sleep(sleeptime)

or you can use interrupts: tell the Pi to call a function whenever it sees a low-to-high transition on a pin:

import time
import RPi.GPIO as GPIO

pir_pin = 7
sleeptime = 300

def motion_detected(pir_pin):
    print "Motion Detected!"

GPIO.setmode(GPIO.BCM)
GPIO.setup(pir_pin, GPIO.IN)

GPIO.add_event_detect(pir_pin, GPIO.RISING, callback=motion_detected)

while True:
    print "Sleeping for %d sec" % sleeptime
    time.sleep(sleeptime)

Obviously the second method is more efficient. But I already had a loop set up checking the camera output and comparing it against previous output, so I tried that method first, adding support to my motion_detect.py script. I set up the camera pointing at the wall, and, as root, ran the script telling it to use a PIR sensor on pin 7, and the local and remote directories to store photos:

# python motion_detect.py -p 7 /tmp ~pi/shared/snapshots/
and whenever I walked in front of the camera, it triggered and took a photo. That was easy!

Reliability problems with add_event_detect

So easy that I decided to switch to the more efficient interrupt-driven model. Writing the code was easy, but I found it triggered more often: if I walked in front of the camera (and stayed the requisite 7 seconds or so that it takes raspistill to get around to taking a photo), when I walked back to my desk, I would find two photos, one showing my feet and the other showing nothing. It seemed like it was triggering when I got there, but also when I left the scene.

A bit of web searching indicates this is fairly common: that with RPi.GPIO a lot of people see triggers on both rising and falling edges -- e.g. when the PIR sensor starts seeing motion, and when it stops seeing motion and goes back to its neutral state -- when they've asked for just GPIO.RISING. Reports for this go back to 2011.

On the other hand, it's also possible that instead of seeing a GPIO falling edge, what was happening was that I was getting multiple calls to my function while I was standing there, even though the RPi hadn't finished processing the first image yet. To guard against that, I put a line at the beginning of my callback function that disabled further callbacks, then I re-enabled them at the end of the function after the Pi had finished copying the photo to the remote filesystem. That reduced the false triggers, but didn't eliminate them entirely.

Oh, well, The sun was getting low by this point, so I stopped fiddling with the code and put the camera out in the yard with a pile of birdseed and peanut suet nuggets in front of it. I powered on, sshed to the Pi and ran the motion_detect script, came back inside and ran a tail -f on the output file.

I had dinner and worked on other things, occasionally checking the output -- nothing! Finally I sshed to the Pi and ran ps aux and discovered the script was no longer running.

I started it again, this time keeping my connection to the Pi active so I could see when the script died. Then I went outside to check the hardware. Most of the peanut suet nuggets were gone -- animals had definitely been by. I waved my hands in front of the camera a few times to make sure it got some triggers.

Came back inside -- to discover that Python had gotten a segmentation fault. It turns out that nifty GPIO.add_event_detect() code isn't all that reliable, and can cause Python to crash and dump core. I ran it a few more times and sure enough, it crashed pretty quickly every time. Apparently GPIO.add_event_detect needs a bit more debugging, and isn't safe to use in a program that has to run unattended.

Back to polling

Bummer! Fortunately, I had saved the polling version of my program, so I hastily copied that back to the Pi and started things up again. I triggered it a few times with my hand, and everything worked fine. In fact, it ran all night and through the morning, with no problems except the excessive number of false positives, already mentioned.

[piñon mouse] False positives weren't a problem at all during the night. I'm fairly sure the problem happens when the sun starts hitting the ground. Then there's a hot spot that marches along the ground, changing position in a way that's all too obvious to the infra-red sensor.

I may try cross-checking between the PIR sensor and image changes from the camera. But I'm not optimistic about that working: they both get the most false positives at the same times, at dawn and dusk when the shadow angle is changing rapidly. I suspect I'll have to find a smarter solution, doing some image processing on the images as well as cross-checking with the PIR sensor.

I've been uploading photos from my various tests here: Tests of the Raspberry Pi Night Vision Crittercam. And as always, the code is on github: scripts/motioncam with some basic documentation on my site: motion-detect.py: a motion sensitive camera for Raspberry Pi or other Linux machines. (I can't use github for the documentation because I can't seem to find a way to get github to display html as anything other than source code.)

Tags: , , , ,
[ 20:13 Jul 03, 2014    More hardware | permalink to this entry | comments ]

Thu, 26 Jun 2014

A Raspberry Pi Night Vision Camera

[Mouse caught on IR camera]

When I built my http://shallowsky.com/blog/hardware/raspberry-pi-motion-camera.html (and part 2), I always had the NoIR camera in the back of my mind. The NoIR is a version of the Pi camera module with the infra-red blocking filter removed, so you can shoot IR photos at night without disturbing nocturnal wildlife (or alerting nocturnal burglars, if that's your target).

After I got the daylight version of the camera working, I ordered a NoIR camera module and plugged it in to my RPi. I snapped some daylight photos with raspstill and verified that it was connected and working; then I waited for nightfall.

In the dark, I set up the camera and put my cup of hot chocolate in front of it. Nothing. I hadn't realized that although CCD cameras are sensitive in the near IR, the wavelengths only slightly longer than visible light, they aren't sensitive anywhere near the IR wavelengths that hot objects emit. For that, you need a special thermal camera. For a near-IR CCD camera like the Pi NoIR, you need an IR light source.

Knowing nothing about IR light sources, I did a search and came up with something called a "Infrared IR 12 Led Illuminator Board Plate for CCTV Security CCD Camera" for about $5. It seemed similar to the light sources used on a few pages I'd found for home-made night vision cameras, so I ordered it. Then I waited, because I stupidly didn't notice until a week and a half later that it was coming from China and wouldn't arrive for three weeks. Always check the shipping time when ordering hardware!

When it finally arrived, it had a tiny 2-pin connector that I couldn't match locally. In the end I bought a package of female-female SchmartBoard jumpers at Radio Shack which were small enough to make decent contact on the light's tiny-gauge power and ground pins. I soldered up a connector that would let me use a a universal power supply, taking a guess that it wanted 12 volts (most of the cheap LED rings for CCD cameras seem to be 12V, though this one came with no documentation at all). I was ready to test.

Testing the IR light

[IR light and NoIR Pi camera]

One problem with buying a cheap IR light with no documentation: how do you tell if your power supply is working? Since the light is completely invisible.

The only way to find out was to check on the Pi. I didn't want to have to run back and forth between the dark room where the camera was set up and the desktop where I was viewing raspistill images. So I started a video stream on the RPi:

$ raspivid -o - -t 9999999 -w 800 -h 600 | cvlc -vvv stream:///dev/stdin --sout '#rtp{sdp=rtsp://:8554/}' :demux=h264

Then, on the desktop: I ran vlc, and opened the network stream:
rtsp://pi:8554/
(I have a "pi" entry in /etc/hosts, but using an IP address also works).

Now I could fiddle with hardware in the dark room while looking through the doorway at the video output on my monitor.

It took some fiddling to get a good connection on that tiny connector ... but eventually I got a black-and-white view of my darkened room, just as I'd expect under IR illumination. I poked some holes in the milk carton and used twist-ties to seccure the light source next to the NoIR camera.

Lights, camera, action

Next problem: mute all the blinkenlights, so my camera wouldn't look like a christmas tree and scare off the nocturnal critters.

The Pi itself has a relatively dim red run light, and it's inside the milk carton so I wasn't too worried about it. But the Pi camera has quite a bright red light that goes on whenever the camera is being used. Even through the thick milk carton bottom, it was glaring and obvious. Fortunately, you can disable the Pi camera light: edit /boot/config.txt and add this line

disable_camera_led=1

My USB wi-fi dongle has a blue light that flickers as it gets traffic. Not super bright, but attention-grabbing. I addressed that issue with a triple thickness of duct tape.

The IR LEDs -- remember those invisible, impossible-to-test LEDs? Well, it turns out that in darkness, they emit a faint but still easily visible glow. Obviously there's nothing I can do about that -- I can't cover the camera's only light source! But it's quite dim, so with any luck it's not spooking away too many animals.

Results, and problems

For most of my daytime testing I'd used a threshold of 30 -- meaning a pixel was considered to have changed if its value differed by more than 30 from the previous photo. That didn't work at all in IR: changes are much more subtle since we're seeing essentially a black-and-white image, and I had to divide by three and use a sensitivity of 10 or 11 if I wanted the camera to trigger at all.

With that change, I did capture some nocturnal visitors, and some early morning ones too. Note the funny colors on the daylight shots: that's why cameras generally have IR-blocking filters if they're not specifically intended for night shots.

[mouse] [rabbit] [rock squirrel] [house finch]

Here are more photos, and larger versions of those: Images from my night-vision camera tests.

But I'm not happy with the setup. For one thing, it has far too many false positives. Maybe one out of ten or fifteen images actually has an animal in it; the rest just triggered because the wind made the leaves blow, or because a shadow moved or the color of the light changed. A simple count of differing pixels is clearly not enough for this task.

Of course, the software could be smarter about things: it could try to identify large blobs that had changed, rather than small changes (blowing leaves) all over the image. I already know SimpleCV runs fine on the Raspberry Pi, and I could try using it to do object detection.

But there's another problem with detection purely through camera images: the Pi is incredibly slow to capture an image. It takes around 20 seconds per cycle; some of that is waiting for the network but I think most of it is the Pi talking to the camera. With quick-moving animals, the animal may well be gone by the time the system has noticed a change. I've caught several images of animal tails disappearing out of the frame, including a quail who visited yesterday morning. Adding smarts like SimpleCV will only make that problem worse.

So I'm going to try another solution: hooking up an infra-red motion detector. I'm already working on setting up tests for that, and should have a report soon. Meanwhile, pure image-based motion detection has been an interesting experiment.

Tags: , , , ,
[ 13:31 Jun 26, 2014    More hardware | permalink to this entry | comments ]

Sat, 24 May 2014

Raspberry Pi Motion Camera: Part 2, using gphoto2

I wrote recently about the hardware involved in my Raspberry Pi motion-detecting wildlife camera. Here are some more details.

The motion detection software

I started with the simple and clever motion-detection algorithm posted by "brainflakes" in a Raspberry Pi forum. It reads a camera image into a PIL (Python Imaging Library) Image object, then compares bytes inside that Image's buffer to see how many pixels have changed, and by how much. It allows for monitoring only a test region instead of the whole image, and can even create a debug image showing which pixels have changed. A perfect starting point.

Camera support

As part of the PiDoorbell project, I had already written a camera wrapper that could control either a USB webcam or the pi camera module, if it was installed. Initially that plugged right in.

But I was unhappy with the Pi camera's images -- it can't focus closer than five feet (though a commenter to my previous article pointed out that it's possible to break the seal on the lens and refocus it manually. Without refocusing, the wide-angle lens means that a bird five feet away is pretty small, and even when you get something in focus the images aren't very sharp. And a web search for USB webcams with good optical quality was unhelpful -- the few people who care about webcam image quality seem to care mostly about getting the widest-angle lens possible, the exact opposite of what I wanted for wildlife.

[Motion detector camera with external  high-res camera] Was there any way I could hook up a real camera, and drive it from the Pi over USB as though it were a webcam? The answer turned out to be gphoto2.

But only a small subset of cameras are controllable over USB with gphoto2. (I think that's because the cameras don't allow control, not because gphoto doesn't support them.) That set didn't include any of the point-and-shoot cameras we had in the house; and while my Rebel DSLR might be USB controllable, I'm not comfortable about leaving it out in the backyard day and night.

With gphoto2's camera compatibility list in one tab and ebay in another, I looked for a camera that was available, cheap (since I didn't know if this was going to work at all), and controllable. I ordered a used Canon A520.

As I waited for it to arrive, I fiddled with my USB-or-pi-camera to make a start at adding gphoto2 support. I ended up refactoring the code quite a bit to make it easy to add new types of cameras besides the three it supports now -- pi, USB webcam, and gphoto2. I called the module pycamera.

Using gphoto2

When the camera arrived, I spent quite a while fiddling with gphoto2 learning how to capture images. That turns out to be a bit tricky -- there's no documentation on the various options, apparently because the options may be different for every camera, so you have to run

$ gphoto2 --set-config capture=1 --list-config
to get a list of options the camera supports, and then, for each of those options, run
$ gphoto2 --get-config name [option]
to see what values that option can take.

Dual-camera option

Once I got everything working, the speed and shutter noise of capturing made me wonder if I should worry about the lifespan of the Canon if I used it to capture snapshots every 15 seconds or so, day and night.

Since I still had the Pi cam hooked up, I fiddled the code so that I could use the pi cam to take the test images used to detect motion, and save the real camera for the high-resolution photos when something actually changes. Saves wear on the more expensive camera, and it's certainly a lot quieter that way.

Uploading

To get the images off the Pi to where other computers can see them, I use sshfs to mount a filesystem from another machine on our local net.

Unfortunately, sshfs on the pi doesn't work quite right. Apparently it uses out-of-date libraries (and gives a warning to that effect). You have to be root to use it at all, unlike newer versions of sshfs, and then, regardless of the permissions of the remote filesystem or where you mount it locally, you can only access the mounted filesystem as root.

Fortunately I normally run the motion detector as root anyway, because the picamera Python module requires it, and I've just gotten in the habit of using it even when I'm not using python-picamera. But if you wanted to run as non-root, you'd probably have to use NFS or some other remote filesystem protocol. Or find a newer version of sshfs.

Testing the gphoto setup

[Rock squirrel using Raspberry Pi camera] For reference, here's an image using the previous version of the setup, with the Raspberry Pi camera module. Click on the image to see a crop of the full-resolution image in daylight -- basically the best the camera can do. Definitely not what I was hoping for.

So I eagerly set up the tripod and hooked up the setup with the Canon. I had a few glitches in trying to test it. First, no birds; then later I discovered Dave had stolen my extension cord, but I didn't discover that until after the camera's batteries needed recharging.

A new extension cord and an external power supply for the camera, and I was back in business the next day.

[Rock squirrel using Raspberry Pi camera] And the results were worth it. As you can see here, using a real camera does make a huge difference. I used a zoom setting of 6 (it goes to 12). Again, click on the image to see a crop of the full-resolution photo.

In the end, I probably will order one of the No-IR Raspberry pi cameras, just to have an easy way of seeing what sorts of critters visit us at night. But for daylight shots, an external camera is clearly the way to go.

The scripts

The current version of the script is motion_detect.py and of course it needs my pycamera module. And here's documentation for the motion detection camera.

Tags: , , ,
[ 20:09 May 24, 2014    More hardware | permalink to this entry | comments ]

Thu, 15 May 2014

A Raspberry Pi motion-detecting wildlife camera

I've been working on an automated wildlife camera, to catch birds at the feeder, and the coyotes, deer, rabbits and perhaps roadrunners (we haven't seen one yet, but they ought to be out there) that roam the juniper woodland.

This is a similar project to the PiDoorbell project presented at PyCon, and my much earlier proximity camera project that used an Arduino and a plug computer but for a wildlife camera I didn't want to use a sonar rangefinder. For one thing, it won't work with a bird feeder -- the feeder is always there, so the addition of a bird won't change anything as far as a sonar rangefinder is concerned. For another, the rangefinders aren't very accurate beyond about six feet.

Starting with a Raspberry Pi was fairly obvious. It's low power, cheap, it even has an optional integrated camera module that has reasonable resolution, and I could re-use a lot of the camera code I'd already written for PiDoorbell.

I patched together some software for testing. I'll write in more detail about the software in a separate article, but I started with the simple motion detection code posted by "brainflakes" in the Raspberry Pi forums. It's a slick little piece of code you'll find in various versions all over the net; it uses PIL, the Python Imaging Library, to compare a specified region from successive photos to see how much has changed.

One aside about the brainflakes code: most of the pages you'll find referencing it tell you to install python-imaging-tk. But there's nothing in the code that uses tk, and python-imaging is really all you need to install. I wrote a GUI wrapper for my motion detection code using gtk, so I had no real need to learn the Tk equivalent.

Once I had some software vaguely working, it was time for testing.

The hardware

One big problem I had to solve was the enclosure. I needed something I could put the Pi in that was moderately waterproof -- maybe not enough to handle a raging thunderstorm, but rain or snow can happen here at any time without much warning. I didn't want to have to spend a lot of time building and waterproofing it, because this is just a test run and I might change everything in the final version.

I looked around the house for plastic objects that could be repurposed into a camera enclosure. A cookie container from the local deli looked possible, but I wasn't quite happy with it. I was putting the last of the milk into my morning coffee when I realized I held in my hand a perfect first-draft camera enclosure.

[Milk carton camera enclosure] A milk carton must be at least somewhat waterproof, right? Even if it's theoretically made of paper.

[cut a hole to mount the Pi camera] I could use the flat bottom as a place to mount the Pi camera with its two tiny screw holes,

[Finished milk cartnn camera enclosure] and then cut a visor to protect the camera from rain.

[bird camera, installed] It didn't take long to whip it all together: a little work with an X-acto knife, a little duct tape. Then I put the Pi inside it, took it outside and bungeed it to the fence, pointing at the bird feeder.

A few issues I had to resolve:

Raspbian has rather complicated networking. I was using a USB wi-fi dongle, but I had trouble getting the Pi to boot configured properly to talk to our WPA router. In Raspbian networking is configured in about six different places, any one of which might do something like prioritize the not-connected eth0 over the wi-fi dongle, making it impossible to connect anywhere. I ended up uninstalling Network Manager and turning off ifplugd and everything else I could find so it would use my settings in /etc/network/interfaces, and in the end, even though ifconfig says it's still prioritizing eth0 over wlan0, I got it talking to the wi-fi.

I also had to run everything as root. The python-picamera module imports RPi.GPIO and needs access to /dev/mem, and even if you chmod /dev/mem to give yourself adequate permissions, it still won't work except as root. But if I used ssh -X to the Pi and then ran my GUI program with sudo, I couldn't display any windows because the ssh permission is for the "pi" user, not root.

Eventually I gave up on sudo, set a password for root, and used ssh -X root@pi to enable X.

The big issue: camera quality

But the real problem turned out to be camera quality.

The Raspberry Pi camera module has a resolution of 2592 x 1944, or 5 megapixels. That's terrific, far better than any USB webcam. Clearly it should be perfect for this tast.

[House finch with the bad Raspberry Pi camera module] Update: see below. It's not a good camera, but it turns out I had a lens problem and it's not this bad.

So, the Pi camera module might be okay if all I want is a record of what animals visit the house. This image is good enough, just barely, to tell that we're looking at a house finch (only if we already rule out similar birds like purple finch and Cassin's finch -- the photo could never give us enough information to distinguish among similar birds). But what good is that? I want decent photos that I can put on my web site.

I have a USB camera, but it's only one megapixel and gives lousy images, though at least they're roughly in focus so they're better than the Pi cam.

So now I'm working on a setup where I drive an external camera from the Pi using gphoto2. I have most of the components working, but the code was getting ugly handling three types of cameras instead of just two, so I'm refactoring it. With any luck I'll have something to write about in a week or two.

Meanwhile, the temporary code is in my github rpi directory -- but it will probably move from there soon.

I'm very sad that the Pi camera module turned out to be so bad. I was really looking forward to buying one of the No-IR versions and setting up a night wildlife camera. I've lost enthusiasm for that project after seeing how bad the images were. I may have to investigate how to remove the IR filter from a point-and-shoot camera, after I get the daylight version working.

[rock squirrel with cheeks full of sunflower seeds] Update, a few days later: It turns out I had some spooge on the lens. It's not quite as bad as I made it out to be. Here's a sample. It's still not a great camera, and it can't focus anywhere near as close as the 2 feet I've seen claimed -- 5 feet is about the closest mine can focus, which means I can't get very close to the wildlife, which was a lot of the point of building a wildlife camera. I've seen suggestions of putting reading glasses in front of the lens as a cheap macro adaptor.

Instead, I'm going ahead with the gphoto2 option, which is about ready to test -- but the noIR Pi camera module might be marginally acceptable for a night wildlife camera.


Tags: , , ,
[ 13:30 May 15, 2014    More hardware | permalink to this entry | comments ]

Wed, 16 Jan 2013

Bluebirds and phantom horses at Arastradero

[Western bluebird]

The weather was a bit warmer today than it has been, so I snuck off for an hour's hike at Arastradero, where I was amazed by all the western bluebirds out enjoying the sunny day. I counted three of them just on the path from the parking lot to the road crossing. Bold, too -- they let me get close enough to snap a shot with my pocket camera.

Farther up the trail, a white-shouldered kite was calling as it soared, and a large falcon flew by, too far away and too backlit for me to identify it for sure as a peregrine.

[Phantom stump horse] But then I spotted an even more unusual beast -- a phantom horse rearing out of the ground, ears pricked forward, eyes and mouth open and mane whipped by a wind we could not feel on this pleasant, windless day.

Dave always teases me about my arboronecrophotography inclinations (I like to take pictures of dead trees). But how could I resist trying to capture a creature like this?

Tags: , ,
[ 20:26 Jan 16, 2013    More nature | permalink to this entry | comments ]

Fri, 21 Sep 2012

Farewell, Space Shuttle Endeavour

[Space shuttle Endeavour flyby] This morning, the last space shuttle, Endeavour, made a piggyback fly-by of California cities prior to landing at LAX, where it will be trucked to its final resting place in Exposition Park. And what science and astronomy fan could resist a once in a lifetime chance to see the last shuttle in flight, piggyback on its 747 transporter?

Events kept me busy all morning, so I was late getting away. Fortunately I'd expected that and planned for it. While watching the flyby from Griffith Observatory sounded great, I suspected there would be huge crowds, no parking and there's no way I could get there in time. The Times suggested Universal City -- which I took to mean that there would be huge crowds and traffic there too. So I picked a place off the map, Blair Dr., that looked like it was easy to get to, reasonably high and located in between Griffith and Universal.

It turned out to be a good choice. There were plenty of people there, but I found a parking spot a few blocks away from where everybody was hanging out and walked back to the viewpoint where I'd seen the crowds.

[Universal Studios back lot] I looked down and the first thing I saw was a smashed jumbo jet among the wreckage of some houses. Um ... not the way I wanted to see the shuttle! But then I realized I was looking at the Universal Studios back lot. Right. Though binoculars I could even see the tram where the folks on the studio tour went right by the "plane crash". And I could look across to Universal City, where the crowds made me happy I'd decided against going there -- I bet they had some traffic jams too.

The crowd was friendly and everybody was sharing the latest rumors of the shuttle's location -- "It just flew over Santa Barbara!" "It's over West Hollywood -- get ready!" "Nope, now it's going west again, might be a while." That helped with the wait in the hot sun.

[Space shuttle Endeavour flyby] Finally, "It's coming!" And we could see it, passing south of the crowds at Universal City and coming this way ... and disappearing behind some trees. We all shifted around so we'd see it when it cleared the trees.

Only it didn't! We only got brief glimpses of it, between branches, as the shuttle flew off toward Griffith Observatory. Oh no! Were we in exactly the wrong location?

Then the word spread, from people farther down the road -- "It's turning -- get ready for another pass!" This time it came by south of us, giving us all a beautiful clear view as the 747 flew by with the shuttle and its two fighter-plane escorts.

We hung around for a few more minutes, hoping for another pass, but eventually we dispersed. The shuttle and its escorts flew on to LAX, where it will be unloaded and trucked to Exposition Park. I feel lucky to have gotten such a beautiful view of the last shuttle flight.

Photos: Space shuttle Endeavour flyover.

Tags: ,
[ 21:35 Sep 21, 2012    More science/astro | permalink to this entry | comments ]

Wed, 06 Jun 2012

There's a big black spot on the sun today ...

[Transit of Venus, June 5 2012] After a heart-stopping day of rain on Monday, Tuesday, the day of the Venus transit astronomers have been anticipating for decades, dawned mostly clear.

For the 3 pm ingress, Dave and I set up in the backyard -- a 4.5-inch Newtonian, a Takahashi FS102, and an 80mm f/6 refractor with an eyepiece projection camera mount. I'd disliked the distraction during the annular eclipse of switching between eyepiece and camera mount, and was looking forward to having a dedicated camera scope this time.

Venus is big! There wasn't any trouble seeing it once it started its transit. I was surprised at how slowly it moved -- so much slower than a Mercury transit, though it shouldn't have been a surprise, since I knew the event would take the rest of the evening, and wouldn't be finished until well past our local sunset.

The big challenge of the day was to see the aureole -- the arc of Venus' atmosphere standing out from the sun. With the severely windy weather and turbulent air (lots of cumulus clouds) I wasn't hopeful. But as Venus reached the point where only about 1/3 of its disk remained outside the sun, the aureole became visible as a faint arc. We couldn't see it in the 4.5-inch, and it definitely isn't visible in the poorly-focused photos from the 80mm, but in the FS102 it was definitely there.

About those poorly focused pictures: I hadn't used the 80mm, an Orion Express, for photography before. It turned out its 2-inch Crayford focuser, so nice for visual use, couldn't hold the weight of a camera. With the sun high overhead, as soon as I focused, the focuser tube would start to slide downward and I couldn't lock it. I got a few shots through the 80mm, but had better luck holding a point-and-shoot camera to the eyepiece of the FS102.

Time for experiments

[Binocular projection of Venus transit] Once the excitement of ingress was over, there was time to try some experiments. I'd written about binocular projection as a way anyone, without special equipment, could watch the transit; so I wanted to make sure that worked. I held my cheap binoc (purchased for $35 many years ago at Big 5) steady on top of a tripod -- I never have gotten around to making a tripod mount for it; though if I'd wanted a more permanent setup, duct tape would have worked.

I couldn't see much projecting against the ground, and it was too windy to put a piece of paper or cardboard down, but an old whiteboard made a perfect solar projection screen. There was n trouble at all seeing Venus and some of the larger sunspots projected onto the whiteboard.

As the transit went on, we settled down to a routine of popping outside the office every now and then to check on the transit. Very civilized. But the transit lasted until past sunset, and our western horizon is blocked by buildings. I wanted some sunset shots. So we took a break for dinner, then drove up into the hills to look for a place with a good ocean view.

The sunset expedition

Our first idea, a pullout off Highway 9, had looked promising in Google Earth but turned out to have trees and a hill (that somehow hadn't shown up in Google Earth) blocking the sunset. So back up highway 9 and over to Russian Ridge, where I remembered a trail entrance on the western side of the ridge that might serve. Sure enough, it gave us a great sunset view. There was only parking space for one car, but fortunately that's all we needed. And we weren't the only transit watchers there -- someone else had hiked in from the main parking lot carrying a solar filter, so we joined him on the hillside as we waited for sunset.

[Mak 90 with solar filter] I'd brought the 80mm refractor for visual observing and the 90 Mak for camerawork. I didn't have a filter for the Mak, but Dave had some Baader solar film, so earlier in the afternoon I'd whipped up a filter. A Baskin-Robbins ice cream container lid turned out to be the perfect size. Well, almost perfect -- it was just a trifle too large, but some pads cut from an old mouse pad and taped inside the lid made it fit perfectly. Dave used the Baader film, some foam and masking tape to make a couple of filters for his binocular.

The sun sank through a series of marine cloud layers. Through the scopes it looked more like Jupiter than the sun, with Jupiter's banding -- and Venus' silhouette even looked like the shadow of one of Jupiter's moons.

[off-axis aperture stops from ice cream containers] Finally the sun got so low, and so obscured by clouds, that it seemed safe to take the solar filter off the 90mm camera rig. (Of course, we kept the solar filters on the other scope and binocular for visual observing.) But even at the camera's fastest shutter speed, 1/4000, the sun came out vastly overexposed with 90mm of aperture feeding it at f/5.6.

I had suspected that might be a problem, so I'd prepared a couple of off-axis stops for the Mak, to cover most of the aperture leaving only a small hole open. Again, BR ice cream containers turned out to be perfect. I painted the insides flat black to eliminate reflections, then cut holes in the ends -- one about the size of a quarter, the other quite a bit larger. It turned out I didn't use the larger stop at all, and it would have been handy to have one smaller than the quarter-sized one -- even with that stop, the sun was overexposed at first even at 1/4000 and I had to go back to the solar filter for a while.

[Venus transit at sunset] [Venus transit at sunset] I was happy with the results, though -- I got a nice series of sunset photos complete with Venus silhouette.

More clouds rolled in as we packed up, providing a gorgeous blue-and-pink sunset sky backdrop for our short walk back to the car. What a lovely day for such a rare celestial event!

Photos here: Venus Transit, June 5 2012.

Tags: , ,
[ 12:48 Jun 06, 2012    More science/astro | permalink to this entry | comments ]

Wed, 21 Jul 2010

Writing scripts for your Canon camera with CHDK

On Linux Planet yesterday: an article on how to write scripts for chdk, the Canon Hack Development Kit -- Part 3 in my series on CHDK.

Time-Lapse Photography with your Inexpensive Canon Camera (CHDK p. 3)

I found that CHDK scripting wasn't quite as good as I'd hoped -- some of the functions, especially the aperture and shutter setting, were quite flaky on my A540 so it really didn't work to write a bracketing script. But it's fantastic for simple tasks like time-lapse photography, or taking a series of shots like the Grass Roots Mapping folk do.

If you're at OSCON and you like scripting and photos, check out my session on Thursday afternoon at 4:30: Writing GIMP Plug-ins and Scripts, in which I'll walk through several GIMP scripts in Python and Script-Fu and show some little-known tricks you can do with Python plug-ins.

Tags: , , , , , ,
[ 10:31 Jul 21, 2010    More photo | permalink to this entry | comments ]

Thu, 08 Jul 2010

Article: CHDK part 2

Part 2 of my series on hacking Canon point-and-shoot cameras with CHDK: Turn Your Compact Canon Camera Into a Super-Camera With CHDK, discusses some of CHDK's major features, like RAW image file support, "zebra mode" and on-screen histograms, and custom video modes (ever been annoyed that you can't zoom while shooting a video?)

Perhaps equally important, it discusses how to access these modes and CHDK's other special menus, how to load CHDK automatically whenever you power the camera on, and how to disable it temporarily.

Part 3, yet to come, will discuss how to write CHDK scripts.

Tags: ,
[ 17:27 Jul 08, 2010    More photo | permalink to this entry | comments ]

Wed, 30 Jun 2010

Tiny froglets at Picchetti Ranch

You read so much about the dire state of amphibians in today's world. They're delicate -- they can absorb toxins through their porous skins, making them prey to all the pollution the human world dumps at their doorstep, as well as being prey for a wide assortment of larger animals and prone to infection by parasites. I remember seeing lots of frogs around ponds in the woods when I was growing up, and these days it's rare to see a frog in the wild at all.

But sometimes you get lucky and get an indication that maybe the state of amphibians isn't as dire as all that. Mark Wagner gave me a tip (thanks, Mark!) that the pond at Picchetti Ranch was literally hopping with frogs. I thought he must be exaggerating -- but he wasn't.

[tiny frog at Picchetti Ranch] They're tiny, thumbtip-sized creatures and they're everywhere around the margin of the lake, hopping away as you approach. It's tough to get photos because they move so fast and like to hide under grass stems, but like anything else, take a lot of pictures and you'll get lucky on a few.

The scene is absolutely amazing. If you're at all a frog fan in the south bay area, get yourself to Picchetti and take a look -- but be very, very careful where you step, because they're everywhere and they're hard to spot between jumps.

I unfortunately lack a good amphibian field guide, and couldn't find much on the web either, but some people seem to think these Picchetti frogs are Sierran tree frogs -- which apparently are sometimes are green, sometimes brown and have a wide range of markings, so identifying them isn't straightforward.

Photos: Tiny frogs at Piccheti Ranch.

Tags: , , ,
[ 19:14 Jun 30, 2010    More nature | permalink to this entry | comments ]

Wed, 23 Jun 2010

Article: Customize or Hack your Canon camera with CHDK

My latest Linux Planet article came out a day early: RAW Support (and more) For Your Canon Camera With CHDK.

CHDK is a cool way you can load custom firmware onto a Canon camera. It lets you do all sorts of useful hacks, from saving in RAW format even in cameras that supposedly don't allow that, to getting more control over aperture, shutter speed and other parameters, to writing scripts to control the camera.

I didn't have space for all that in one article, so today's Part 1 simply covers how to install CHDK; Part 2, in two weeks, will discuss some of the great things you can do with CHDK.

Tags: ,
[ 20:02 Jun 23, 2010    More photo | permalink to this entry | comments ]

Wed, 04 Feb 2009

Tasmania Photos

I still haven't finished writing up a couple of blog entries from bumming around Tasmania after LCA2009, but I did get some photos uploaded: Tasmania photos. Way too many photos of cute Tassie devils and other animals at the Bonorong wildlife park, as well as the usual collection of scenics and silly travel photos.

Tags: , , , ,
[ 15:49 Feb 04, 2009    More travel/tasmania | permalink to this entry | comments ]

Sat, 15 Nov 2008

Using (or not) an Apple Cinema Display on a non-Apple

Dave and I recently acquired a lovely trinket from a Mac-using friend: an old 20-inch Apple Cinema Display.

I know what you're thinking (if you're not a Mac user): surely Akkana's not lustful of Apple's vastly overpriced monitors when brand-new monitors that size are selling for under $200!

Indeed, I thought that until fairly recently. But there actually is a reason the Apple Cinema displays cost so much more than seemingly equivalent monitors -- and it's not the color and shape of the bezel.

The difference is that Apple cinema displays are a technology called S-IPS, while normal consumer LCD monitors -- those ones you see at Fry's going for around $200 for a 22-inch 1680x1050 -- are a technology called TN. (There's a third technology in between the two called S-PVA, but it's rare.)

The main differences are color range and viewing angle. The TN monitors can't display full color: they're only 6 bits per channel. They simulate colors outside that range by cycling very rapidly between two similar colors (this is called "dithering" but it's not the usual use of the term). Modern TN monitors are astoundingly fast, so they can do this dithering faster than the eye can follow, but many people say they can still see the color difference. S-IPS monitors show a true 8 bits per color channel.

The viewing angle difference is much easier to see. The published numbers are similar, something like 160 degrees for TN monitors versus 180 degrees for S-IPS, but that doesn't begin to tell the story. Align yourself in front of a TN monitor, so the colors look right. Now stand up, if you're sitting down, or squat down if you're standing. See how the image suddenly goes all inverse-video, like a photographic negative only worse? Try that with an S-IPS monitor, and no matter where you stand, all that happens is that the image gets a little less bright.

(For those wanting more background, read TN Film, MVA, PVA and IPS – Which one's for you?, the articles on TFT Central, and the wikipedia article on LCD technology.)

Now, the comparison isn't entirely one-sided. TN monitors have their advantages too. They're outrageously inexpensive. They're blindingly fast -- gamers like them because they don't leave "ghosts" behind fast-moving images. And they're very power efficient (S-IPS monitors, are only a little better than a CRT). But clearly, if you spend a lot of time editing photos and an S-IPS monitor falls into your possession, it's worth at least trying out.

But how? The old Apple Cinema display has a nonstandard connector, called ADC, which provides video, power and USB1 all at once. It turns out the only adaptor from a PC video card with DVI output (forget about using an older card that supports only VGA) to an ADC monitor is the $99 adaptor from the Apple store. It comes with a power brick and USB plug.

Okay, that's a lot for an adaptor, but it's the only game in town, so off I went to the Apple store, and a very short time later I had the monitor plugged in to my machine and showing an image. (On Ubuntu Hardy, simply removing xorg.conf was all I needed, and X automatically detected the correct resolution. But eventually I put back one section from my old xorg.conf, the keyboard section that specifies "XkbOptions" to be "ctrl:nocaps".)

And oh, the image was beautiful. So sharp, clear, bright and colorful. And I got it working so easily!

Of course, things weren't as good as they seemed (they never are, with computers, are they?) Over the next few days I collected a list of things that weren't working quite right:

The brightness problem was the easiest. A little web searching led me to acdcontrol, a commandline program to control brightness on Apple monitors. It turns out that it works via the USB plug of the ADC connector, which I initially hadn't connected (having not much use for another USB 1.1 hub). Naturally, Ubuntu's udev/hal setup created the device in a nonstandard place and with permissions that only worked for root, so I had to figure out that I needed to edit /etc/udev/rules.d/20-names.rules and change the hiddev line to read:

KERNEL=="hiddev[0-9]*", NAME="usb/%k", GROUP="video", MODE="0660"
That did the trick, and after that acdcontrol worked beautifully.

On the second problem, I never did figure out why suspending with the Apple monitor always locked up the machine, either during suspend or resume. I guess I could live without suspend on a desktop, though I sure like having it.

The third problem was the killer. Big deal, who needs text consoles, right? Well, I use them for debugging, but what was more important, also broken were the grub screen (I could no longer choose kernels or boot options) and the BIOS screen (not something I need very often, but when you need it you really need it).

In fact, the text console itself wasn't a problem. It turns out the problem is that the Apple display won't take a 640x480 signal. I tried building a kernel with framebuffer enabled, and indeed, that gave me back my boot messages and text consoles (at 1280x1024), but still no grub or BIOS screens. It might be possible to hack a grub that could display at 1280x1024. But never being able to change BIOS parameters would be a drag.

The problems were mounting up. Some had solutions; some required further hacking; some didn't have solutions at all. Was this monitor worth the hassle? But the display was so beautiful ...

That was when Dave discovered TFT Central's search page -- and we learned that the Dell 2005FPW uses the exact same Philips tube as the Apple, and there are lots of them for sale used,. That sealed it -- Dave took the Apple monitor (he has a Mac, though he'll need a solution for his Linux box too) and I bought a Dell. Its image is just as beautiful as the Apple (and the bezel is nicer) and it works with DVI or VGA, works at resolutions down to 640x480 and even has a powered speaker bar attached.

Maybe it's possible to make an old Apple Cinema display work on a Mac. But it's way too much work. On a PC, the Dell is a much better bet.

Tags: , , , , , , , ,
[ 21:57 Nov 15, 2008    More tech | permalink to this entry | comments ]

Tue, 02 Sep 2008

DSLR Camera Foo

I thought it would never happen ... I've finally joined the Digital SLR world.

Why would it never happen? I enjoyed film SLRs for years ... from the Olympus OM-1 (great little manual camera) I had as a teenager to the Nikkormat EL and Nikon FG I used a decade ago. I only stopped because processing and scanning slides was such a hassle compared to the ease of uploading digital images. So why not a DSLR?

The problem was that when Nikon went digital, they orphaned all their old manual-focus lenses. They're still physically compatible (they'll screw on to the DSLR body), but peeved Nikon DSLR owners inform me (and camera store clerks agree) that the Nikon cameras won't meter with the old lens attached.

I don't mind doing my own focusing (manual focusing is one of the prime advantages of an SLR, not a disadvantage) but having to guess at the exposure setting too? "Oh, just carry a light meter," people say. On a camera that costs over $600? That bothers me.

So I was peeved at Nikon and not about to buy anything from them ... but meanwhile I had all these lenses, and hated to buy some other brand where the lenses wouldn't even screw on. So, no DSLR for me ...

Until I was pouring out my lens-mount frustrations during a camera discussion one night on #gimp and one of the regulars (thanks, Liam!) said "Well then, why don't you just get an adaptor that lets you use Nikon MF lenses on a Canon?"

A what? said I.

Sure enough, there are lots of them on Ebay ... search for canon nikon adaptor or look at Gadget Infinity's "lens adaptor" section. You can even (for a little more money) get a "confirm" lens that lights up the autofocus-confirm points in the viewfinder to tell you when the camera thinks you're in focus.

A few months passed (too busy to do camera research) but eventually I found the time and budget ... and now I have a 5-day-old Canon Rebel Xsi, which indeed takes excellent photos (correctly metered) through my old Nikon AI-mount Sigma 70-300 APO zoom macro. And the 18-55 kit lens (the equivalent of a 29-88 in a 35mm camera) isn't bad either -- a little slow (f/3.5 at the widest) but decently wide at the wide end (in the years of using pocket digicams I'd forgotten how much nicer it is to have a true wide-angle lens) and with a nice close focus for macros at the long end.

Even the autofocus isn't bad -- there are still plenty of times when I need manual, but the Rebel's autofocus is much faster and more accurate than any I'd seen on earlier cameras.

[The Canon says F00] It's such a great feeling to use an SLR again. The morning after the camera arrived, I looked up and saw goldfinches at the feeder just outside the window. I picked up the camera, switched it on, pointed, zoomed, focused and snapped. No worries about whether the camera might have decided to focus on the window, or the window frame, or the tree, or the bush -- just focus and shoot. What a pleasure!

And the best part: this must be a camera made by geeks, because when it has the Nikon lens attached ... it says F00!

Tags:
[ 20:59 Sep 02, 2008    More photo | permalink to this entry | comments ]

Thu, 25 Aug 2005

Dowitcher Photo Published!

I was contacted months ago regarding a photo on my web site asking whether it could be used along with an article on molting patterns in Dowitchers in Birding magazine.

Months went by (print magazines are slow) and I wondered if the plan had been dropped, but last week I heard from the author, Caleb Putnam, and the article is in the current (July/August) issue! Yesterday I received a copy of the magazine and a modest payment. Cool!

Even cooler, the photo is the frontispiece of the article. The author says he's received many comments about how great a shot it is for illustrating molt gaps. That's a pull quote if I ever heard one: "Great shot for illustrating molt gaps."

The article is interesting as well -- I didn't know that molt patterns could identify the two species of dowitcher. Telling long-billed and short-billed dowitchers apart has been beyond my modest birding skills, but perhaps I'll have better luck now. I'll be heading out to Baylands today at lunch to see what the dowitchers are doing ...

Tags:
[ 11:49 Aug 25, 2005    More photo | permalink to this entry | comments ]

Tue, 28 Jun 2005

Freeway Fire

Some jerk decided it would be funny to throw a lit firecracker into the dry brush beside the freeway a few blocks away from where I live, with predictable results.

Fortunately the fire department responded incredibly quickly (must have been less than five minutes from when I heard the bang to when the fire truck arrived) and they were able to put the fire out before it spread far.

I hope someone saw whoever threw the firecracker, and got a license plate.

Tags:
[ 23:12 Jun 28, 2005    More misc | permalink to this entry | comments ]

Sun, 04 Jul 2004

Musings on photo workshops and classes

Dan's party was last night, including an group which was giving an informal workshop on night photography.

The presentation was a little disappointing, just people showing slides of recent photographs. No discussion of techniques or interesting ideas for night photography, things to try out that night.

It was mildly fun for the couple of us who were Linux users to watch the Windows people fumble with their JASC slideshow program trying to get it to present photos at a reasonable size. Whenever I wonder why I bother to keep maintaining pho, I look at what Windows and Mac people have to go through to look at photos and am amazed all over again.

But strangely, before heading off to Marin yesterday, I did some searching for other linux image viewing programs, to see if they'd solved the window manager problems I've been wrestling with for pho. Amazingly, I couldn't find a single free program in Debian that did what pho does (namely, view a list of images serially, at full size or screen resolution). I had to search for xv source (not in Debian, probably licensing issues), which requires a couple of tweaks to get it to build on linux, and which has the same window management issues pho has. I guess I'll keep maintaining it after all!

After dark we trooped up the hill to photograph lights (Richmond and the Richmond-San Rafael bridge were visible, along with parts of Marin) and wait for moonrise. I took an SLR and the Minolta, and wish I'd taken the Olympus -- nearly everyone else had digital SLRs (Canon) and I wished for something with a decent zoom which would still give me exposure feedback. It's not as if bay area skies can support long star-trail exposures anyway. Moonrise was lovely, a sliver of moon emerging above a thick cloudbank centered over the San Rafael bridge, and growing into a full-sized moon. I hope some of the film photos (on old expired PJM multispeed film!) come out.

Most of the photographers there knew each other from previous classes (I wasn't clear how many are students versus instructors) and most of the group spent the hour before moonrise clustered together taking turns taking the same shot, a person silhouetted against the lights of Richmond while someone else fired a flash from behind the person, back toward the camera, giving an "aura" effect around the silhouette and lighting the nearby grass a bit. Not really knowing anyone, I hung back and instead worked on photos of the various photographers silhouetted against the sky (which may or may not come out; I was shooting from 10 sec to about 3 min, betting on the Marin sky being too bright for longer star trails, but we'll see. One of the other solo shooters was shooting 10 minute exposures and people kept walking into her frame.) Dave shot a few Canon digicam images before the sunset light was completely gone, then the wind got to him and he went back to the house and didn't wait for moonrise.

I'd wondered about maybe taking one of their regular workshops, but this outing was a bit like the couple of other photo workshops I've done: no real instruction or sharing of ideas, basically just a bunch of people wandering around taking photos. If you have specific questions or know the instructors already you might be able to get questions answered, but as a person new to the group, I felt like I'd probably do just as well just going somewhere on my own and taking a lot of photos.

It may be that their multi-day pay workshops involve more instruction, and more feedback the next day on images taken at the workshop. I'm curious about that; the few photo seminars and classes I've taken have also promised feedback afterward, but haven't had much, if any.

Sometimes I think that the ideal format for a photo workshop is an online class: give assignments, then people post their photos a few days or a week later, and everyone discusses them, then you go off to the next assignment with what you learned based on the feedback. The important parts are the discussion and the feedback, not being in the same physical place during the shooting (since not much instruction seems to take place then, for most participants, and if it does it seems to be of the type "everybody line up and take exactly the same photo"). It's hard to do feedback in a several-day workshop at a place like Death Valley when people are shooting film and you can't get it developed quickly enough; a digital camera might be a prerequisite to getting much out of that sort of workshop.

Tags:
[ 11:00 Jul 04, 2004    More photo | permalink to this entry | comments ]

Syndicated on:
LinuxChix Live
Ubuntu Women
Women in Free Software
Graphics Planet
DevChix
Ubuntu California
Planet Openbox
Devchix
Planet LCA2009

Friends' Blogs:
Morris "Mojo" Jones
Jane Houston Jones
Dan Heller
Long Live the Village Green
Ups & Downs
DailyBBG

Other Blogs of Interest:
DevChix
Scott Adams
Dave Barry
BoingBoing

Powered by PyBlosxom.