8mm film telecine project using picamera

[jasonl]

I'd like to present my Raspberry Pi based 8mm film telecine project. It uses the Pi and camera, some Makerbeam extrusion, a couple of stepper motors, a couple of hacked servos, LED lighting and some 3d printed parts to handle the film. Glued together using some electronics and Python code. Pulled together and refined over the last few months.

It's still all a bit Heath Robinson – there are definitely areas for refinement/improvement. But it appears to work pretty reliably, and I'm quite pleased with the results despite the primitive optics. The lens is a £4 smartphone 'macro' lens positioned in front of the Pi camera lens which is unscrewed as much as possible.

The machine uses the Pi camera to take a high resolution image (or multiple images) of each frame of a reel of 8mm film. These are saved as a sequence non-lossy compressed PNG files on the SD card. These are then copied to a PC for further processing and assembling as video. Silent of course - sound has to be added later.

The aim is to make good archival copies of some precious home movies, a lot I inherited, and some I took myself. These films date from the 60s to the 80s. I also recently bought a job-lot of commercial home movies from ebay, to help with testing the telecine – the less the precious films are handled the better.

Here's a video I threw together showing it in action: http://youtu.be/xm3jTsKSOtE

I uploaded some of the test films, too. Basically these show the results straight from the telecine with no additional processing other than using mencoder to make a video resized to 1024x768, and uploaded to Youtube. The sprocket holes are shown to demonstrate the Pi based registration/cropping. Instability in the films is in the original prints, if the sprocket holes are steady.

https://www.youtube.com/playlist?list=P ... tuXlku2PGd

Code, some documentation and designs are on Github here: https://github.com/jas8mm/rpitelecine

It's all a bit rough and ready, as this project has evolved from the primordial soup somewhat rather than being designed – and there are probably better ways of doing some things, and my Python coding is very non-optimal, but hey, it's working at the moment!

Some background: A number of years ago I started by attempting to hack my old Eumig Mark 500 projector – adding LED light, DC motor, Point Grey industrial camera. Controlled via an Arduino from a PC. It was slow and cumbersome and my old projector very tired and worn and had a habit of not pulling the film through and damaging the sprocket holes. Things got very complex, and the project stalled...

Since then the Pi arrived, then its camera, but I was put off a bit using it because the camera only operated in auto exposure mode, and it wasn't possible to fix the white balance. Now solved. Also Dave Hughes' excellent Python camera API makes it easy to interface the camera, and OpenCV/Numpy allows easy handling of the resulting images.

Also last year's announcement of the Kinograph project got me rethinking the film transport, and perhaps using 3d printed parts to handle the film, instead of using a hacked projector. And this project was born...

[AndyD]

That is awesome!

[waveform80]

What a fantastic project (and with superb results)! Incidentally, do you think it would be worth adding a FAQ to the docs regarding settings that permit two sequential captures to appear reasonably similar? Obviously it's necessary with your project (looking at https://github.com/jas8mm/rpitelecine/b ... era.py#L70) and another user has asked for similar advice in #96 (https://github.com/waveform80/picamera/issues/96), not to mention it seems a relatively popular topic on this forum.


Dave.

[jasonl]

Thanks for the comments. Sorry for the delay in replying.
I'm quite pleased with the results so far, and hope to improve the code and tweak the hardware and optics.
As regards getting a consistent exposure for the capture, the camera is basically set to a fixed ISO, the auto white balance switched off and a fixed white balance is set. The camera is in stills mode at maximum detail and dynamic range. I aim for an exposure that doesn't clip pixel values in the image area (http://en.wikipedia.org/wiki/Exposing_to_the_right). It'll be interesting to see if the new DRC mode will help extract a bit more dynamic range from the shadows without resorting to bracketing...

For the set up and capture the basic camera setup is this:

Code: Select all

cam =  picamera.PiCamera()
cam.resolution = cam.MAX_IMAGE_RESOLUTION
cam.ISO=100
cam.exposuremode = 'fixedfps'
cam.framerate = 10
cam.awb_gains=awb_gains
cam.awb_mode='off'
cam.shutter_speed=shutter
cam.preview_fullscreen = True

The ISO is set to the lowest setting - as the lighting is bright and I wish to reduce image noise.
'shutter' is an integer variable with a fixed shutter speed - with my LED setup this is around 2000 (microseconds),
'awb_gains' is a tuple of floats that fixes the red and blue white balance gains.
'awb_mode' is set to off in order to fix the white balance.
I seem to recall that the fixedfps exposuremode and reducing the framerate is neccessary. May experiment without these. I can't remember if the preview setting is needed or not, either.

To get an initial value for the shutter speed and white balance I use this bit of code in https://github.com/jas8mm/rpitelecine/b ... nce.py#L55 - it's a hack, as it appears impossible (at present) to obtain the current shutter and white balance values in the camera except by taking a jpeg image and parsing the header....

Code: Select all

def get_awb_shutter( f ):
    f.seek(256)
    s = f.read(512) # Only part of the header needed
    r_pos = s.find('gain_r=')
    b_pos = s.find('gain_b=')
    s_pos = s.find(' exp=')
    gain_r = eval(s[r_pos+7:r_pos+12].split()[0]) if r_pos > -1 else 0
    gain_b = eval(s[b_pos+7:b_pos+12].split()[0]) if b_pos > -1 else 0
    shutter = eval(s[s_pos+5:s_pos+12].split()[0]) if s_pos > -1 else 0
    return (gain_r,gain_b,shutter)

stream = io.BytesIO()
with picamera.PiCamera() as camera:
    camera.shutter_speed = 0
    camera.exposure_mode = 'auto'
    camera.awb_mode = 'flash'
    camera.resolution = (2592,1944)
    camera.crop = (0.25,0.25,0.25,0.25) # use a small part of the centre of the image
    camera.ISO = 100
    camera.vflip = True
    camera.start_preview()
    camera.preview_fullscreen=True
    # Camera warm-up time - and allow time for WB to settle
    time.sleep(10)
    camera.capture(stream, 'jpeg')
stream.seek(0)
gain_r,gain_b,shutter_speed = get_awb_shutter(stream)
print("Gain_r:{:.3f} Gain_b:{:.3f} Shutter:{}".format(gain_r,gain_b,shutter_speed ))

I found the flash AWB setting got better results for me in setting a base exposure. This base exposure can then be adjusted manually in my setup script.

In the setup and capture routines a picture is taken simply with the function:

Code: Select all

def take_picture():
    with picamera.array.PiRGBArray(cam) as output:
        cam.capture(output, format='bgr')
   return output.array

This returns a numpy array that is then processed, and saved as a png using openCV (hence the bgr format).
I'm not sure if all of this is optimal - but it seems to work. Images seem to be pretty consistent across a capture.

Images are captured in about a second - so it's not fast. I understand this is a limitation of using stills mode - there's a switch between preview mode and stills mode that takes much of this time. Is it possible to disable the (hidden) preview in Picamera? This would perhaps allow almost instantaneous captures?

Anyway, the main bottleneck is saving the PNG files to the SD card, which times at around 1 - 1.5 seconds each. The saving is done in a separate thread, so the picture-taking/cropping is done in parallel with saving the pictures. My Pi is overclocked to High setting - which improves the speed by about a 1/4 to 1/3 over the default. I found Turbo mode would lock the camera after several hundred frames.

Thanks Dave for the picamera library - 1.5's array module really simplifies getting a numpy array from an image, knocking about a quarter of a second off taking each image. Means a lot when 50 foot of film is about 3500 images...

Jason

[6by9]

Seeing as you're setting manual AWB and exposure values, at the MMAL level you should be able to set the MMAL_PARAMETER_CAMERA_BURST_CAPTURE parameter to stop the switching back and forth to preview. How that would plumb through PiCamera is a different question.

At the IL level there is a parameter that does provide exposure time and a few other values. I'm not sure whether the AWB gains are in there. I don't think it is plumbed through MMAL at the moment though, but would be easy to do. Things are a little busy, but I'll try to check it out tomorrow.

[jasonl]

Thanks for the info! It'll be interesting to see if the MMAL_PARAMETER_CAMERA_BURST_CAPTURE parameter can be made available in the picamera library. It'll probably be useful in other circumstances like timelapse photography or scientific imaging.

Being able to access the current shutter and awb would be be really useful, and save the hassle of having to take a jpeg to get the info. There's a query in the picamera github issue tracker with another use case:
https://github.com/waveform80/picamera/issues/98

[waveform80]

Thanks for the comments. Sorry for the delay in replying.
I'm quite pleased with the results so far, and hope to improve the code and tweak the hardware and optics.
As regards getting a consistent exposure for the capture, the camera is basically set to a fixed ISO, the auto white balance switched off and a fixed white balance is set. The camera is in stills mode at maximum detail and dynamic range. I aim for an exposure that doesn't clip pixel values in the image area (http://en.wikipedia.org/wiki/Exposing_to_the_right). It'll be interesting to see if the new DRC mode will help extract a bit more dynamic range from the shadows without resorting to bracketing...

For the set up and capture the basic camera setup is this:

Code: Select all

cam =  picamera.PiCamera()
cam.resolution = cam.MAX_IMAGE_RESOLUTION
cam.ISO=100
cam.exposuremode = 'fixedfps'
cam.framerate = 10
cam.awb_gains=awb_gains
cam.awb_mode='off'
cam.shutter_speed=shutter
cam.preview_fullscreen = True

The ISO is set to the lowest setting - as the lighting is bright and I wish to reduce image noise.
'shutter' is an integer variable with a fixed shutter speed - with my LED setup this is around 2000 (microseconds),
'awb_gains' is a tuple of floats that fixes the red and blue white balance gains.
'awb_mode' is set to off in order to fix the white balance.
I seem to recall that the fixedfps exposuremode and reducing the framerate is neccessary. May experiment without these. I can't remember if the preview setting is needed or not, either.

Interesting information - I'll definitely use this in the FAQ entry. I'm pretty confident the preview setting should make no difference at all (because it's just a display setting). The reduction in framerate would be required if the shutter_speed setting exceeded the maximum allowed by the current framerate (so, if framerate is 30, then shutter_speed cannot be larger than 1,000,000/30 or 33,333µs), but I don't think it should be necessary if you're going all the way down to 2,000µs.

To get an initial value for the shutter speed and white balance I use this bit of code in https://github.com/jas8mm/rpitelecine/b ... nce.py#L55 - it's a hack, as it appears impossible (at present) to obtain the current shutter and white balance values in the camera except by taking a jpeg image and parsing the header....

Code: Select all

def get_awb_shutter( f ):
    f.seek(256)
    s = f.read(512) # Only part of the header needed
    r_pos = s.find('gain_r=')
    b_pos = s.find('gain_b=')
    s_pos = s.find(' exp=')
    gain_r = eval(s[r_pos+7:r_pos+12].split()[0]) if r_pos > -1 else 0
    gain_b = eval(s[b_pos+7:b_pos+12].split()[0]) if b_pos > -1 else 0
    shutter = eval(s[s_pos+5:s_pos+12].split()[0]) if s_pos > -1 else 0
    return (gain_r,gain_b,shutter)

stream = io.BytesIO()
with picamera.PiCamera() as camera:
    camera.shutter_speed = 0
    camera.exposure_mode = 'auto'
    camera.awb_mode = 'flash'
    camera.resolution = (2592,1944)
    camera.crop = (0.25,0.25,0.25,0.25) # use a small part of the centre of the image
    camera.ISO = 100
    camera.vflip = True
    camera.start_preview()
    camera.preview_fullscreen=True
    # Camera warm-up time - and allow time for WB to settle
    time.sleep(10)
    camera.capture(stream, 'jpeg')
stream.seek(0)
gain_r,gain_b,shutter_speed = get_awb_shutter(stream)
print("Gain_r:{:.3f} Gain_b:{:.3f} Shutter:{}".format(gain_r,gain_b,shutter_speed ))

I found the flash AWB setting got better results for me in setting a base exposure. This base exposure can then be adjusted manually in my setup script.

Yeah, unfortunately when AWB gain setting got added to the MMAL layer it was for setting only (I vaguely recall asking one of the engineers about this in a forum post, and he confirmed it couldn't currently be read back but that such functionality was on a wishlist). It'd certainly be nice to have though, as it's a bit weird having contrast, brightness, et al. as regular r/w properties on PiCamera, and awb_gains as a "write only" property :)

In the setup and capture routines a picture is taken simply with the function:

Code: Select all

def take_picture():
    with picamera.array.PiRGBArray(cam) as output:
        cam.capture(output, format='bgr')
   return output.array

This returns a numpy array that is then processed, and saved as a png using openCV (hence the bgr format).
I'm not sure if all of this is optimal - but it seems to work. Images seem to be pretty consistent across a capture.

Images are captured in about a second - so it's not fast. I understand this is a limitation of using stills mode - there's a switch between preview mode and stills mode that takes much of this time. Is it possible to disable the (hidden) preview in Picamera? This would perhaps allow almost instantaneous captures?

I was about to write that there'd be no point disabling the built-in hidden preview; the reason it was introduced was to fix issue #22. However, it occurs to me that that was way back at the start of picamera when we couldn't set shutter speed and AWB gains manually either ... perhaps the auto-exposure algorithm (which is what the hidden preview causes to run) isn't needed under such circumstances? I'll have to have a play and find out (not quite sure what API I'd introduce to completely kill the preview though - I'd definitely like to keep the hidden one by default to keep the more general use cases simple).

Anyway, I can confirm that not running a preview at all does speed up still captures (if I recall correctly, when I fixed #22 my capture_continuous tests dropped from 3-4fps to 1fps) - but obviously the fade-to-black issue made it a bit pointless! :)

Anyway, the main bottleneck is saving the PNG files to the SD card, which times at around 1 - 1.5 seconds each. The saving is done in a separate thread, so the picture-taking/cropping is done in parallel with saving the pictures. My Pi is overclocked to High setting - which improves the speed by about a 1/4 to 1/3 over the default. I found Turbo mode would lock the camera after several hundred frames.

Thanks Dave for the picamera library - 1.5's array module really simplifies getting a numpy array from an image, knocking about a quarter of a second off taking each image. Means a lot when 50 foot of film is about 3500 images... :-)

Jason

Yeah - I've found Turbo to be a bit flaky with camera stuff too, so High is what I run on my main development Pi (I've also got a model A which runs absolutely stock NOOBS Raspbian with no overclocking as a testing platform, but I only fire that one up for final release testing).

When it comes to the speed-up in 1.5, I suspect that wasn't the new array module but rather issue #103. I did some profiling on the unencoded RGB/BGR code and discovered my (quickly hacked together) alpha-byte stripping code was *awful*. So, I spent an hour or so playing with various ways of stripping alpha bytes and discovered a trivial sliced-del operation was several hundred times faster than my original attempt (not to mention a lot simpler). Still, the new array module certainly makes it easier to develop code that works on the unencoded output :)

Anyway, glad you're enjoying the library - I love seeing the projects people come up with, using it!


Dave.

[waveform80]

Seeing as you're setting manual AWB and exposure values, at the MMAL level you should be able to set the MMAL_PARAMETER_CAMERA_BURST_CAPTURE parameter to stop the switching back and forth to preview. How that would plumb through PiCamera is a different question.

At the IL level there is a parameter that does provide exposure time and a few other values. I'm not sure whether the AWB gains are in there. I don't think it is plumbed through MMAL at the moment though, but would be easy to do. Things are a little busy, but I'll try to check it out tomorrow.

That's an interesting parameter! Right, there's another ticket to investigate :)

[jasonl]

Hi Dave,

Thanks for your comments. I'll experiment and pare down the fixed exposure settings.

It'd be nice to kill the preview as the extra time freed up could allow additional captures to be made or processing to be done on the Pi. My pre-Pi telecine project took two exposures of each frame - one optimised for the perforation to aid frame extraction, and another optimised for the image area. Each second added per frame equates to about an extra hour per 50ft reel! At present picturetaking/processing and saving are about equal for single images, but the picture taking predominates when bracketing exposures.

The speedup with capturing in 1.5 to is also due to the fact it is no longer writing 5mp of data to a stream, which was then read back and then converted to a numpy array. I did a before and after comparison after upgrading to 1.5. Cf the original capture code at https://github.com/jas8mm/rpitelecine/b ... era.py#L91 The new way is much more efficient! Thanks!

[6by9]

Seeing as you're setting manual AWB and exposure values, at the MMAL level you should be able to set the MMAL_PARAMETER_CAMERA_BURST_CAPTURE parameter to stop the switching back and forth to preview. How that would plumb through PiCamera is a different question.

At the IL level there is a parameter that does provide exposure time and a few other values. I'm not sure whether the AWB gains are in there. I don't think it is plumbed through MMAL at the moment though, but would be easy to do. Things are a little busy, but I'll try to check it out tomorrow.

That's an interesting parameter! Right, there's another ticket to investigate

Doh, forgot about the fading to black issue Sorry for getting your hopes up,but you'll probably get the same issue with MMAL_PARAMETER_CAMERA_BURST_CAPTURE. It was mainly there as a way of being able to leave viewfinder all set up and enabled, but knowing that you wanted to do multiple stills then it stops the automatic switch back to viewfinder immediately after the capture. Not running preview would have the same effect.

[6by9]

(Sorry for the slight thread hijack, but it looks like it may be useful to you)

At the IL level there is a parameter that does provide exposure time and a few other values. I'm not sure whether the AWB gains are in there. I don't think it is plumbed through MMAL at the moment though, but would be easy to do. Things are a little busy, but I'll try to check it out tomorrow.

I've not had much time, but I do now have reporting of exposure, analog gain, digital gain, and AWB r & b gains back up to raspistill as they change. Most of the work was done already.
It gives the option of either polling for the data as required (with mmal_port_parameter_get), or you can request an event message to be sent every time the values change (expect lots of changes, often with every frame!). I've set Raspistill to do the latter as it saves having to sort out when to poll, and demonstrates how to get the callbacks.

I'll push the firmware change internally, but it's then up to Dom to release. If I get a chance, I'll sling a test firmware image on my github account, along with the updated headers and hacked raspistill.c.
Currently the request for callbacks has to be done against the control port, and you'll then get updates as preview runs. You can poll for the settings on the stills port, but can't get updates. When life is a little calmer I'll try to add that too.

[jasonl]

Wow - this looks really useful!

A lot of it's over my head as I'm just naively using python-picamera - but I'm sure they'll get added to the API in due course.

Are the analog/digital gains relevant in stills mode? Or are they just another representation of ISO? For my project dialling back any gain in the system to keep noise at at minimum, and to maximise dynamic range, is a good idea. But there's no mention in the python-picamera or raspistill docs about setting analogue or digital gain that I can find.... maybe just setting ISO/WB/Exposure time is enough?

Polling for the values of the WB/Exposure, possibly averaging over a period would work in a telecine setup context - using the result to fix the exposure for the capture, or to allow manual tweaking for correcting colour casts in the film...

Re the fade-to-black issue - would this affect taking consecutive stills, even having set ISO/WB/Exposure? If so, what's happening? I would expect the exposure to be consistent, as the various photographic variables have been fixed....

Thanks again for your work!

[6by9]

Sorry, not managed to push my changes to github at the today, and it looks like I just missed Dom doing an official release.
The Picamera Python library is up to waveform80, but he seems fairly on the ball for adding new functionality.

If you think back to analog photography, ISO is the gain of the film. This translates to the combination of analog and digital gain in digital photography. Analog gain is normally preferred as it introduces less noise (or at least a nicer form of noise). ISO 100 normally equates to analog gain x1.0 and digital gain 1.0.

Polling for values as the automatic algorithms run, and then fix the values for the captures would be the best bet. As you say, you can always tweak the numbers that you get.

Fade to black still hasn't been investigated fully. Part of the issue is that the AGC and AWB algorithms aren't running during consecutive stills, and so people were complaining as the scene changed. In your case everything is fixed, but I'm not sure there isn't a rounding error issue that slowly ends up reducing the gain and resulting in black images.

[6by9]

Changes pushed.
My GPU firmware made Dom's second release last night (https://github.com/Hexxeh/rpi-firmware/ ... 25242271d7), and that includes my MMAL header updates.

https://github.com/6by9/userland/commit ... eca64d7798 has my RaspiStill update. You should then be able to add --settings (or -set) to the command line and it will print to the console whenever the GPU notifies a change in the capture parameters. Expect a lot of these changes unless you have fixed everything (I've just slung in "--settings -ss 5000 -ISO 100 -awb off -awbg 1.0,1.0 -ex night" and I still get analog and digital gain changes for some reason. That wasn't expected).

I'm not in the office for the next week, but will check the forums for anything interesting, so do report back.

[totoharibo]

Changes pushed.

I'm not in the office for the next week, but will check the forums for anything interesting, so do report back.

Quite a long time ago.
I'm trying too numerize argentic films but it is 9.5mm ones.

I use the original projector with a 1.2W LED and a picam. The focus is ajusted roughly to the image.

A motor makes the advance on the "mechanic's" for each image. I use bash and raspistill to do the job.
On BW :
raspistill -roi 0.250,0.257,0.461,0.565 -q 85 -ex verylong -ISO 640 -ss 125000 -w 1200 -h 800 -o /mnt/$nom
On colour :
raspistill -roi 0.250,0.257,0.461,0.565 -ex verylong -ISO 320 -ss 30000 -cfx 128:128 -w 1200 -h 800 -o /mnt/$nom

Images are stored to an USB stick, and then copied to a PC.

The roll is cut in sequences (directory containing images).
I modify each image in each sequence with a script using convert (from Imagemagick) and for color a script named autowhite
Developed by Fred Weinhaus 10/13/2008 .......... revised 11/26/2011.

In the video on youtube, I don't see the way to advance precisely from one image to the other. Could you show (or explain) the hardware you use.

Thanks a lot for what I've already seen.

[jasonl]

[

Quite a long time ago.
I'm trying too numerize argentic films but it is 9.5mm ones.

I use the original projector with a 1.2W LED and a picam. The focus is ajusted roughly to the image.

A motor makes the advance on the "mechanic's" for each image. I use bash and raspistill to do the job.
On BW :
raspistill -roi 0.250,0.257,0.461,0.565 -q 85 -ex verylong -ISO 640 -ss 125000 -w 1200 -h 800 -o /mnt/$nom
On colour :
raspistill -roi 0.250,0.257,0.461,0.565 -ex verylong -ISO 320 -ss 30000 -cfx 128:128 -w 1200 -h 800 -o /mnt/$nom

Images are stored to an USB stick, and then copied to a PC.

The roll is cut in sequences (directory containing images).
I modify each image in each sequence with a script using convert (from Imagemagick) and for color a script named autowhite
Developed by Fred Weinhaus 10/13/2008 .......... revised 11/26/2011.

In the video on youtube, I don't see the way to advance precisely from one image to the other. Could you show (or explain) the hardware you use.

Thanks a lot for what I've already seen.

Hi, you possibly mean my project? I've had a break away from it, and just resuming. It's got a better lens, an RPi B+, and I am in the process of updating the capture script for the latest version of python-picamera. There's some information and code for the previous version on my Github: https://github.com/jas8mm/rpitelecine

Basically I am using a pair of stepper motors to pull and push the film through the gate. Registration is done in software - my Python code examines the frame to locate the edges of the sprocket hole. This position is used to crop the image before saving, and also to adjust the number of steps the motors need to move the film to the next frame. For standard8 film, there are about 278 steps per frame, but slippage and imprecision in the system means this varies from frame to frame; the stepper motors are used in microstepping mode, which gives pretty good precision.

My perforation detection code is designed specifically for sprocket holes on the edge of a frame - but it should be possible to adjust it for 9.5mm film - a matter of changing the ROI. It's not perfect and can be confused by damaged film, but so far seems to work quite well on the films I have thrown at it. The Picamera is used to take a full 5 megapixel image, with the film frame taking the centre 1/3 - where the image is sharpest, but also allowing a generous border for cropping. A standard8 film frame crops to about a 1000 pixels. It ran at about 1.5seconds per frame - but for some reason it's slowed down when I updated everything and got it running again today - so today's tests are about 2.5seconds per frame. Need to investigate that.

Anyway, I will be updating the github with revised code and docs, and hope to upload some new examples to youtube in the next week or two, work permitting...

[totoharibo]

I'm surprised of the extra good quality of the light of your films. I'm far from your results.
You mechanic is very clean and I have no 3D printer

As i know you use the electronic way to moove the film.
I use the mechanic of the projector controlled by a "salvaged" printer motor and opto captors.

Advance is mechanically perfect. It takes 10 sec to moove to next picture (motor is slow : 5V powered and it is a 36V model...).
I have problems to take correct pictures. My 1.2W LED does not light very much and it takes 5 seconds for image to stabilize.
So 20sec for one image

I'm studying a new version using quicker mechanical advance of the film and use your system for capture with a RPi of course.

I'll have a look on your .py scripts to see your parameters of exposure.

thanks for the informations I steal you.

see you soon ...

[gcraig102]

Hi. I've been doing a similar thing with a cine projector and a new lens on the pi camera. You can take the lens mount off the camera board and replace it with a standard bigger one. You can then fit a range of cheap standard screw in lenses. I found a 8mm focal length one suited well. I'll look out the details and take a picture.
I do like this design as a cine projector is not ideal. A dual gauge one like mine jams up easily if there is any damage to the film sprockets. It is also difficult to fit the camera and align it in the limited space. I think I'll do something like this as I've now built a 3D printer. I found with the pi that I could get much faster, more reliable control of the projector by moving from Python to C.

[dave1167]

Fantastic project, one thing I am missing which I thik is me being dim , but why do you need 2 servo motors and 2 stepper motors? I would have thought the stepper motors would have been enough to pull the film through on a frame by frame basis.

[jasonl]

Fantastic project, one thing I am missing which I thik is me being dim , but why do you need 2 servo motors and 2 stepper motors? I would have thought the stepper motors would have been enough to pull the film through on a frame by frame basis.

Thanks! I've neglected this project somewhat - but I've now got it up and running with a Model B v2 now that picamera (or rather the GPIO library) is now working correctly with the new model.

Anyway to answer your question, the servos are to pull the film onto the take-up spools. The steppers do indeed pull (and push) the film past the gate.

My first attempt tried to use just the steppers, using a belt from the stepper to turn the film spool - but couldn't get it to work reliably. Anyway the servos have been hacked to remove the electronics, so they're basically dumb geared motors with a handy spline fitting enabling the spool tables to be screwed on securely. The film spools are a loose friction fit, so slip when needed, meaning that there's no need to be precise when advancing the film - the take up spool motor is simply pulsed once every frame.

The Pi 2 makes a lot of difference to this project - it's averaging about 1 second per frame, meaning a 50 foot reel of film can be captured in an hour or so.

Although it is still reliant on the camera speed and speed of writing files to the SD card, it's now able to run the capture script from within LXDE without slowing down. Doing a capture at the moment, and the processor's at 30%.

There's scope for doing more image processing during capture improving the sprocket hole detection. And for making a proper GUI for it, combining the setup and capture into one application.

My next job is to revisit the camera code and see if it's possible to reduce the 0.8 secs required to take a 5MP image during capture...

[jarleigel]

This looks really cool.
Have been looking for all sorts of ways to digitize my Super8 films.
And already having a Pi, camera, Arduino + some of the cables - that is a good start.

But ordering the PCB looked a bit difficult.
Have been on the http://smart-prototyping.com/PCB-Prototyping.html site.
But there is a lot of questions that is difficult for me to answer. Like: Layers, PCB Thickness, Copper Thickness, Surface Finish, and so on..

Is it as easy as uploading the Gerber files, and choose the standard on all of the questions?
Will they solder the componentes excepts the Mosfets?

Anywya, if anyone has ordered more than one, I would be happy to buy from you.

Kind regards,
Jarle

[jasonl]

This looks really cool.
Have been looking for all sorts of ways to digitize my Super8 films.
And already having a Pi, camera, Arduino + some of the cables - that is a good start.

But ordering the PCB looked a bit difficult.
Have been on the http://smart-prototyping.com/PCB-Prototyping.html site.
But there is a lot of questions that is difficult for me to answer. Like: Layers, PCB Thickness, Copper Thickness, Surface Finish, and so on..

Is it as easy as uploading the Gerber files, and choose the standard on all of the questions?
Will they solder the componentes excepts the Mosfets?

Hi you will only get PCBs with no components. I just chose the basic service. Colour and finish is up to you, but the basics are double-sided 10x10cm. You get 10 nice identical PCBs in a couple of weeks. Other services are available like Itead, Seeed or OSH Park...

Anyway I have some spare PCBs from the batch of 10 I got - send a PM and we can work something out if you want one. I've some spares of the MOSFETs too. I make no claims as to suitability of purpose or quality of design - it's an amateur hobby project after all. However, mine has been working well since building it last year and it's now plugged into a Raspberry Pi 2.

[TheCase]

Thanks for posting this project. I've been struggling along with opencv and frame strip scans from a flatbed, but this single-frame approach seems much more straight forward. I've got a 3D printer, so I'm going to start cranking out the parts for this.

I'm interested in more details about the LED lights and heat sinks you used. I tried to send a PM, but cannot, since my account is new. If you have any spare boards still available, I'd be interested in purchasing one (as well as any other spare parts you no longer need).

[matthewepler]

This is awesome! What lens are you using? Can't wait to dive into the code and build plans. Exciting stuff.

I'm going to be posting some stuff soon on Kinograph 8mm work too - just getting started. Would love any input you have to offer.

Matt Epler
(Kinograph)

[williatf]

This project is awesome! I successfully built the machine over the holidays, and was able to digitize several old 8mm home movies from the 1960's that have been sitting in my closet for decades, and I'm still going.

This project has all the elements of a totally fun project: custom PCB and circuit board design, 3D CAD design, software design, soldering, optics, motor control, etc.!!! And it works great!

I wasn't able to find the recommended macro lens (they're out of stock at the time I wrote this), so I just unscrewed the standard pi-camera lens to get the most macro effect I could and it works pretty well.

Thanks for sharing!