The next After Hours Preview Party isn’t happening for another two months, but I have recently been doing some work on the Party People Photobooth. During the Picasso Preview Party, we experienced some trouble with the camera control system. Specifically, the camera, an older Canon 10D, would get into a frustrating state where it wouldn’t [...]
The next After Hours Preview Party isn’t happening for another two months, but I have recently been doing some work on the Party People Photobooth. During the Picasso Preview Party, we experienced some trouble with the camera control system. Specifically, the camera, an older Canon 10D, would get into a frustrating state where it wouldn’t talk to the computer, and the only cure was to cycle the power by physically disconnecting it from a power source, cycling the power switch wouldn’t do the trick. Add in that the CF card somehow corrupted itself, that the timing of the capture was always tenuous at best, and it was clear gphoto2 as the camera connection program wasn’t working.
Enter PSRemote. Having seen the software package Photoboof, I knew there had to be a better way. Indeed, looking at the requirements for Photoboof, it is noted that if you need to buy PSRemote if you wish to use a Canon PowerShot camera. Looking at PSRemote, we see that it “also includes a DLL and a sample program (complete with C++ source code) which allows other applications to release the camera’s shutter and adjust the shutter speed and aperture”. Sounds nifty, huh? The only (big) downside of PSRemote is that it runs on Windows only. Despite the pain this would this would inflict upon me, I decided that the benefits potentially outweighed the personal suffering and inevitable reinstall/reboot sequences I would endure.
Camera and Software
The Cameron Wittig in the Walker Photography Studio happened to have a Canon G7 that we could use, and it worked beautifully with PSRemote. The sample program that PSRemote provides for CLI access to snapping photos also works great, giving a reliable delay of about 1.5 seconds from hitting enter to the flash going off. Instead of using Photoboof, I used the Max/MSP + Jitter to control the preview and PSRemote. Under Windows, Jitter needs java installed from Sun, and the vdig component for quicktime so quicktime can talk to firewire devices. For the Camera, we added the AC adapter so it wouldn’t run off batteries, the lens adapter and macro ring adapter so that the ring flash would fit on the camera. It fits great and the camera stays powered up.
PSRemote, in it’s GUI form, can show a live video preview of what the camera sees, pulled over USB. The CLI sample program doesn’t provide this, though it is certainly possible for a person who knows c++ and the Windows development environment. Instead, I used the video output from the G7 connected to a firewire digitizer box and then pulled the digitized video back into Max/MSP this way. Certainly it is not the most elegant solution, but it is very reliable. PSRemote does turn off all the icons on the Camera display when you enable the video out preview. The added benefit of all this was that I no longer have to align an iSight and the actual capture camera so they see the same things. Now, the capture camera is also the preview camera. Our capture station isn’t very fast (an old AMD XP1700), so I am only able to run the preview (320×240) at 5fps, but as a preview, it works great. For the countdown text, displaying text in Jitter on windows is not so good. The jit.gl.text2d produces text that is not anti-aliased and just not great looking. It does, work, however.
Talking to PSRemote from Max proved to be a little tricky at first, mostly because I had forgotten how windows is put together. The DOSHack external under Windows provides similar functionality to the shell or aka.shell externals on OSX. The trick here is that you can only call built-in commands, or call upon programs located in c:\windows\system32\ (which is why you can launch notepad with the external). The solution is to simply place the PSRemote sample program and the DLL into the system32 directory, and then it magically works. Coming from OSX/Linux land, this doesn’t really strike me as an optimal solution, but it does work.
Proof is in the Pudding
As a test of this whole setup, I set up the photobooth for a private event a little over a week ago. Despite only having a week to put this together, everything worked with only one minor glitch. PSRemote saves the captured photos in sequentially numbered files (1.jpg, 2.jpg, etc..). My scripts that transfered the files around were erasing the captured files after copying them to the display computers. When this happened PSRemote would name the next file 1.jpg, and when it got transfered, it would replaced the existing file named 1.jpg. A quick rewrite of my transfer script fixed this and then it was in business. During the event, there were almost 100 photos captured and no crashes or other glitches.
The G7 has different white balance and levels than the 10D does, so the post processing script needs to be adjusted. I am planning on cutting Photoshop out of the mix, and instead post-processing the images with Imagemagick, since that can be easily installed on the projection computers. I also plan on enjoying the Frida Kahlo Preview Party a lot more since I won’t have to be baby-sitting the camera the whole time. It is my hope that this will make the Party People Photobooth a much more stable platform that won’t need to be revisited for testing every time we set it up.
Attached is also a revised clip of what the projection looks like. My original annoucement post featured a similar clip, but with test photos before we ever took real photos during an event. Here is a clip using some photos taken during the Picasso opening (but not with the picasso-ify filter).