Background and Inspiration

##The inspiration When my grandfather died more than 40 years ago, he left behind 8 grown kids, who now have grandchildren - and even a few great-grandchildren - of their own. He also left hundreds of reels of 8mm, Super8, and 16mm films that he shot from the late 1930s up until the early '70s. Those films sat in storage for years, until a cousin projected them directly onto the sensor of a DSLR to capture them digitally, and showed them at a family reunion for the first time in decades.

Some of these films looked beautiful, but others were quite dirty and suffered badly from 'crazing' of the emulsion; a fine network of cracks throughout each frame. This and other dirt is impossible to remove unless the film can be captured one frame at a time. So we set out attempting to do that.

##Why frame-by-frame? With a projector, and a digital SLR, and the proper lenses it is fairly straightforward to directly project the film into the camera at speed. This approach has some significant drawbacks, however: Home movie film is shot at 16, 18, or 24 frames per second, and cameras generally capture at 24 or 30, so often the appropriate speed for the film will not match that of the camera being used for capture. So most frames in our captured videos were a blending of two different film frames.

Moreover, even it both camera and projector ARE running at 24fps, it is extremely difficult to precisely control the speed of most projectors, so as the projector speed 'drifts' slightly during the course of a reel, it will introduce video frames that are partial combinations of frames.

These blended frames don't look bad when watching the film at speed: But they make such a movie almost impossible to improve with post-processing. For one, changing the speed in an editing program will accentuate the 'blended' frames. Also, many digital dust/dirt-removal tools require a frame-by-frame capture in order to recognize and digitally remove dirt and the aforementioned cracks.

##Why use an old projector? We already knew (from the initial capture to DSLR) that although the films were in poor condition, their sprocket holes were undamaged and would feed well through a projector. I happened to have a raspberry pi and an old Super 8 projector that was missing a bulb, and I was skeptical of my abilities to create a film gate, advance mechanism, and takeup reel that would work reliably.

If your film's sprocket holes are damaged or your film is in extremely poor condition, this is not an approach you should use! It will likely damage your film further. A project like rpitelecine or kinograph will likely present fewer problems.

##Why the Pi Camera? The pi camera is very easily controllable, affordable, and well-documented. Its 5( now 8) MP resolution is sufficient more than adequate for capturing 8mm films. Its biggest drawbacks are speed -due to being connected to the pi, small sensor size, and dynamic range. Much of this project's design is motivated by an attempt to deal with these limitations.

##Why blend frames? When first setting out on this project, I underestimated the importance of film's high dynamic range: I found many films for which no setting could adequately capture both highlights and shadows in a single shot. For an early deign, I captured multiple images of each frame and blended them into a single image using 'enfuse'. This produced excellent, consistent results, but it meant that I now needed to capture at least two images per frame to a local usb drive, transfer them from the pi to another computer, and run a shell script on the folder to create a new folder of blended images. Moreover, writing images to an SD card was painfully slow.

##Why client-server? Writing images to a network stream turns out to be much faster than writing them to an SD card, so I wrote a pair of command-line programs that could capture and save images directly to the computer where I'd be processing them. This sped things up, but it was cumbersome; it required two entire keyboard/monitor setups to be able to set up a capture and even then, I couldn't easily monitor the results during the capture. I also discovered that it was a rare reel of film that I could set up and run straight through; often one shot would be overexposed, or another underexposed, so that I'd need to stop, rewind the film, adjust capture settings and resume. This got to be tedious, especially when I couldn't monitor my results in realtime. So I set about writing a gui in pyQt that would allow me to adjust the camera and capture a reel of film via the a single interface.

In doing so, I learned that the most recent version of OpenCV supports several functions which perform the equivalent of enfuse within python, merging multiple exposures into a single image with higher dynamic range. This functionality is now built into the rpi-film-capture client so that bracketing and blending exposures happens automatically.

The program is still not without bugs, but I think it's now managing the tradeoff between speed, quality and usability about as well as I see possible given the hardware.

Nearly every aspect of this project is something that I've done for the first time: My first experience using multithreading, first time using sockets, programming for the pi camera, using a stepper motor, building a GUI in Qt. And also my first github project. So please be liberal - but gentle - with your feedback.