Combatting Telecine Pulldown Blur


I successfully ran a few test captures with the syncmouse last night. The idea behind a frame-by-frame telecine is to take a single picture of each frame while it is being projected. The projector/telecine has a little claw that pulls the film down in order to advance it, and this happens at the frame rate. On a normal 8mm projector, this would be 18 frames per second, but this telecine has been modified to run at 6 8 fps instead, or 1/3 ~1/2 the usual rate. The pulldown itself happens quickly, I estimate within 25-30 degrees of the projection cycle which is a full 360 degrees. With this estimate, we can estimate the time required to pull the frame down. At 8 fps, each frame consumes 124.6 ms of projection time total. Some of that time is used for the pulldown sequence. With the 27.5 degree estimate, we can divide that by the 360 degree cycle to find that 7.6% of the time is used for the pulldown. Multiplying this by the 124.6 ms projection cycle time tells us the pulldown is present for ~9.5 ms. Some time must also be allowed for the film to stop moving. This is the window we must avoid.

Unfortunately, it appears to be difficult to set this window up correctly due to a number of factors that must be accounted for. In the Workprinter XP telecine, the “mouse click” time accounts for approximately 110 degrees of the projection cycle, or 38 ms, during which the frame must remain absolutely still. However, the frame must be still at the final capture destination rather than the source (the telecine itself); this is tricky due to a number of delays in the capture path. There is a slight delay between when the syncmouse is triggered and the computer receives and processes the action to capture the frame, there is a processing delay within the camera viewing the frame, there is a processing delay within the Avermedia C127 HDMI capture card, there is an OS delay to pass the information to CineCap, and there is the delay present within CineCap itself. All this must be accounted for in order to yield a predictable and desirable result. A quick google search yielded a youtube video that found a similar capture card to have a 67.27 ms delay. As can be seen from above, this delay is longer than the time it takes to click the mouse! However, if the mouse click starts exactly as the pulldown process stops, we should still capture a clear image of each frame should no other delays be present. The timeline will look like below:

|Pulldown – 10 ms | Mouse click – 38 ms | Capture delay – 67 ms | remaining time 10 ms|

|Pulldown ———–| Still frame ————————————————CAPTURE————–|

However, I am still capturing moving frames. This indicates that there is more than an additional 10 ms of delay present between the camera, OS, and capture program. This is solved by measuring the amount input delay present and advancing trigger wheel by the amount of delay present. For example, if we 67 ms for our input delay, we would divide that by the projection time of 124.6 ms to find that the delay is 53% of the projection sequence. We multiply 53% times 360 degrees to find the degrees of advance required to compensate for the delay, which is 194 degrees of advance. This signals the computer to capture the frame 194 degrees earlier so that by the time the delay has elapsed, a perfectly still frame will be present.

This poses yet another question – how do we measure the delay? The closest answer I’ve come up with is to display an accurate timer or clock on a monitor alongside the capture preview window, then capture the monitor. The difference in time between original timer and the timer as viewed in the capture window is the delay in the camera, capture card, OS, and capture previewSome delay will exist in actually displaying the information, but as it is present in both the original output and capture, it should cancel out. However, this does not account for signaling delay, which is hopefully minimal. As long as this signaling and capture delay is less than ~77 ms (125 ms projection time – [10 ms pulldown + 38 ms capture window]), the capture should be successful.


I measured the delay using the above method and came up with an astounding average delay of 256 ms over an average of five measurements! That’s more than TWICE the projection time which means I drop two frames every time the capture starts. Below are my exact results

Trial   Screen          Clock             Diff
1          21:59.941      22:00.208     249 ms
2         24:17.609      24:17.892      283 ms
3         25:04.009     25:04.259     250 ms
4         26:51.542      26.51.809      267 ms
5        28:20.859     28.21.090       231 ms
AVG                                               256 ms delay

256 milliseconds of delay is equal to (256 ms delay / 124.6ms projection time = 2.05457 frames) * 360 degrees = 739.65 degrees of advance required to correct for the delay. Because I can’t advance the timing disc by more than one full rotation, we get rid of any whole intervals of 360* to leave 19* as the answer to getting perfect results. Unfortunately, this assumes the timing remains perfect – and apparently it doesn’t because I STILL get pulldown blur :-( So the next fix either slowing down the projector to provide more timing leeway and/or increasing timing consistency.


An interesting note to these calculations is that the telecine is supposed to run at 6 fps (I believe). However, I felt it necessary to measure and verify the speed – and it’s a good thing I did because the calculation completely changed with the telecine running at 8 fps! I measured the speed using two different methods. The first method involved recording the running telecine with a microphone, then identifying the audio fingerprint of a new frame being projected. Once this was identified, I measure the time which I found to be ~.12832 seconds or 128.32 ms. This corresponds to 7.79 fps. The second method was performed by using an online stopwatch, positioning the mouse over the lap button, and letting the syncmouse rip. Over an average of 5 “laps,” I recorded a time of 124.6 ms which is almost exactly 8 fps.

*Side note: The shear volume of information captured is worth noting. At 1080p in high color, each frame generates a 4 megabyte bitmap. At eight frames per second, 32 MB/s continuous write speed is required to flush the information to disk. This makes fast drives an absolute requirement to avoid dropping frames. Worse, playback at 18 fps requires three times more bandwidth, or 72 MB/s, something my RAID 1 volume** is apparently incapable of, although my SSD handles it without a problem. Unfortunately, SSD space is expensive.

**Fixed that… maybe I’ll post about it later. I had a 5400 rpm & 7200 rpm running in the same RAID array due to an ordering error. I swapped out the 5400 rpm drive for another 7200 rpm drive and all is well.

MovieStuff Workprinter XP Syncmouse

The Workprinter is a rather rudimentary machine. As one of Roger’s earlier efforts, it is clearly handbuilt and what I would call “DIY” quality. One of the harder parts in constructing a frame-by-frame telecine is detecting when a frame is fully displayed and then being able to successfully signal the capture device to grab the frame; Roger accomplished this by making a lobed disc that triggers a mechanical switch during each frame. This switch then outputs to an RCA jack on the front of the unit which would have originally been attached to a device he dubbed the “syncmouse.” The syncmouse would simply “click” the left mouse each time the switch was triggered inside the projector/telecine, allowing the button inside CineCap to be pressed each time a new frame is displayed. Unfortunately, the syncmouse was long gone by the time I acquired this Workprinter and so I must construct a new one.


My syncmouse is simply an old Compaq branded Logitech PS/2 mouse. I pulled it apart and, with the aid of a multimeter, determined how the left mouse button was wired. I then soldered an RCA jack to the responsible pins so that the Workprinter can signal the mouse click. This is an exploring electronics (beginner) level project.



With the newly made syncmouse, the capture card, 5DmkIII as a suitable capture device, CineCap, a fast computer, and the Workprinter all in-hand, it is time to begin capturing footage!



MovieStuff Workprinter XP 8mm Telecine Test Run

I just graduated with my master’s degree and now have a little more time to work on the telecine project. This update is going to be a little different as it is using a different telecine/projector than before. I was browsing eBay to look for a good deal on a MovieStuff Retro-8 and ran across an old Workprinter XP – I believe one of the first made by Roger as this one is hand modified and still uses the halogen bulb with a transformer. It arrived without the “sync-mouse,” which is just a mouse that has the left mouse button wired to an RCA plug so that each time a frame advances in the telecine, it “clicks” the mouse the button, but was otherwise complete. I’ve noticed a few things already – I’m on the right track with the other projector, mechanical switches are not a reliability concern, and the Workprinter is surprisingly “DIY” quality. With the addition of my 5D3, I can now use that camera to output clean 1080P images to a capture card. This is how the Workprinter XP was intended to be used, albeit with a “normal” video camera and an older capture card. As a test, I decided to film some test 8mm film with the telecine running at 6 fps & the 5D3 running at 24 fps. I sped the film speed up by 300% in post. You will notice frame smearing and other artifacts in this video because it is not a proper frame-by-frame transfer. However, it does demonstrate a decent transfer can be accomplished with the Workprinter, 5D3, and a capture card. I am now debating the continuation of my telecine project or if I should just use the Workprinter – I may remove the optics to increase the transfer quality.

DIY 8mm Telecine – Progress Report 4

Finally – here is the much overdue update I promised a while back! Progress has been made on several fronts since the last post: the projector now has an appropriate backlight, I drilled a hole in the backplate I made to allow for projection, a new lens has joined the lineup, and an Arduino UNO has been thrown in the mix!


RGB_Backlight_OnThe backlight is a 3 watt, Red, Green, Blue (RGB) LED I purchased on eBay. The idea is that the red, green, and blue colors can be mixed independently to set the white balance and supposedly, an RGB LED will provide a fuller color spectrum as compared to a standard white LED. This is important for capturing all the different colors present in the original film.



The Arduino has been added mostly because I had eBay bucks to spend making the $12.79 Arduino essentially free.  While slower than the Propellor, the Arduino is easier to program (for me anyway). It supports hardware pulse width modulation (PWM) which I attempted to use to control the red, green, and blue channels of the LED (we’ll get to that…). As the Arduino is limited in how much output it can drive directly, I have the rather power LED powered through the transistors seen on the breadboard.

So why am I not using the Arduino’s hardware PWM controller to drive the LED channels? It turns out that the frequency the PWM controller operates at causes visual artifacts on the webcam. Cheap digital cameras scan their sensors sequentially – imagine the pixels on the sensor as being arranged into columns and rows. The sensor will start in the begin to scan the pixels in rows from top to bottom which takes a small amount of time. This is generally imperceptible, but when the image is changing quickly, it is possibly for the position of a picture element to change as the pixel rows are being scanned, leading to visual artifacts. This is easily seen when an iPhone takes pictures of an aircraft propellor. I think the same thing is happening to the webcam – the LED light is strobing as the image sensor is scanning rows of pixels. This is seen as visual stripes in the webcam output :-/

How is this solved? One way is to change the PWM implementation. The LED must remain lit short enough to strobe once every pixel row scan OR the LED can remain lit long enough that the entire image is scanned in one go. This latter solution works for still images – I’m not sure how it would hold up in video. Finally, the LED’s current could be controlled directly. This is the ideal solution that will allow the LED to remain constantly lit while being able to alter its brightness.



Projection hole

I drilled a hole through the back of the plate I made earlier to allow the film to be viewed. Due to space constraints, the backlight is mounted in the front of the projector where the lens was originally and the image is projected in reverse.




The lens is now mounted to the rear of the projector. At this stage, the mounting is temporary – as you can probably tell by the zipties. Instead of enlarging the image, the lens now serves as a macro lens providing approximately 1:1 magnification. I’m actually using the original lens for this demo, but I also purchased a new zoom lens from eBay.

Putting it all together

Telecine_BacklightTo the left is the current state of the backlight. There are four wires soldered to it – common, red, green, and blue. At full brightness with the resistors I had in my shop, the backlight casts a purple light; this was supposed to be remedied by the Arduino. Indeed, the Arduino is able to control the backlight color – but with visual artifacts, a new solution is needed.


Telecine_Webcam_Projection_CloseOn the right, you can see the lens barrel (far right silver object), the webcam board in the center with the blue power LED, and the projected image itself on the sensor in the center. Remember, this is the bare webcam without any lens at all! It’s all held in temporary place by a “third hand” soldering tool so it’s not in the best alignment.


Below is a wide view of the setup, with the white arrow pointing to the projected image. Here you can clearly see the zipties holding the projector lens in place. Additionally, note that the backlight now casts a warm white light – this is from the adjustment provided by the Aduino.


Finally, here’s a video of it in action.


DIY 8mm Telecine – Progress Report 3

DC Motor Mounted to Projector

Last night saw significant progress on the telecine project. I made a new back for the projector that replaces the original motor & lamp housing, then successfully tested the new DC motor.

Projector Plate

I began with what was once an ECU cover (or more accurately, a DME cover from a BMW). I made a cardboard template of the rear of the projector earlier, than transferred the outline to the cover. From there, I used a dremel to cut the outline out and drilled and tapped four 3mm x .50 holes for machine screws.

Cutting the gear up

With the plate taken care of, I turned  my attention towards the drive gear. The cassette player I sourced the gears from had two identical gears with both inner and outer teeth as pictured. My plans use one of the gears to replace the original drive pulley with the outer teeth being driven. The motor uses the inner teeth of the remaining gear to engage the outer teeth of the now replaced drive pulley, but the gear must be ground down to only the center for it to clear. I used a dremel and grinder to first cut up the gear, then grind the remaining metal down until only the center remained.

Finished ground gear

The newly ground gear was then mounted to the DC motor. A hole slightly large than the gear was drilled into the new back plate, then the motor was mounted to the back plate. A spacer had to be used for proper clearance, and the spacer also made it easier to mount the DC motor using very shallow screws. With everything mounted, I applied +12v  DC to the motor and watched the projector run!