Design Feedback and New Ideas

Machine Design
1

Hello, all. I had the pleasure of meeting Ed Nisely recently. He’s an experienced engineer and was kind enough to take a look at the v2 Kinograph designs and offer his ideas. I’ve tried to capture them below along with my thoughts. Let me know what you think!

1. Drive system (motors, etc)
In a nutshell: get rid of the tension hubs and replace the direct drive design with a friction drive.

I will admit, I did not see this coming. I have been quite confident in the motor design thus far, but once he pointed it out, Ed awakened a small voice in me that has been saying since the beginning: “This PID feedback loop isn’t quite right and it’s a pain to tune.”

Ed’s point is that simpler is better. His reference is a reel-to-reel tape machine, which often used a friction drive to achieve the very same things Kinograph is trying to achieve.

Also, because PIDs loops have to be “tuned” to be good at what they do, that means that every owner of a Kinograph would (at some point, maybe) have to tune their machine’s PID loops, which is intimidating for anyone without an interest in tinkering with machinery and code. We could write some kind of auto-tuning routine, but as Ed said to that idea, “There lies madness.”

By removing the PID we reduce the complexity (physically and mathematically) of the system while achieving the same results.

I think the idea is interesting enough to merit a test to try it out. What do you think?

2. Getting constant linear speed at the capstan drive
In a nutshell: use a flywheel

Again, Ed reached for simplicity in this solve. By adding a flywheel, we smooth out the torque of the motor and, in Ed’s words, “make it expensive to change our speed.”

I think it’s a great idea and won’t cost much to implement.

3. Frame detection (or, when to take a picture)
In a nutshell: use a simple sensor and you have all the data you need

If the flywheel is giving us steady linear speed, then we can make some calculations based on when we sense perforations. For the sake of argument, let’s just say we have a sensor set up that works and accurately tells us when it see’s a perforation. If we know the circumference of the capstan’s PTR roller, and we know how frequently we are seeing perforation holes, then we should be able to calculate the distance of film we have traveled at any given time.

Let me put it another way. We know the circumference of the PTR roller. We know the length of 1 frame of film (depending on your gauge, aspect ratio, etc - which the user can input into software), and we know the distance between perforations. Of course, the film may have shrunk or warped, so we start with the assumption that it is perfect and all lengths are standard. Then, as we begin scanning, we measure the actual distance between perforations (# of perfs over time on a known circumference length) and then make adjustments in our calculations as needed. More perfs/second than we anticipated? Film must be shrunken! Shorten the time between captures!

As for missing or damaged perfs, we can try out different averaging algorithms that allow these to be ignored.

Lastly, in order to know how far the PTR has rotated, we will need to install an encoder.

I like this idea a lot and it gets rid of any computationally expensive CV during the scan and would greatly reduce the amount of CV required at the end if we were to go with my latest idea.

2

Random thoughts on the way home …

I was thinking of a friction clutch, rather than a variable drive. Think of a felt disk squashed between plates, with the felt providing enough friction to let one plate drive the other, but not enough friction to lock them together. Adjusting the pressure on the felt adjusts the amount of friction. Obviously, this doesn’t work for high-power transmissions, but I think it’ll suffice for film tensioning.

On the takeup side, a little DC motor running fast enough (through a reduction belt drive) to keep up with the smallest reel hub diameter will do; the friction disk handles the speed “adjustment” from empty to full. You may not need a motor back-driving the supply reel, because the friction disk ought to apply enough torque.

Which means you should cook up a dedicated film rewinder, rather than run film through the scanner again. It’ll be faster and save wear & tear on the gate.

The capstan speed need not be entirely constant, because the encoder tells you what it actually is. Sync the camera shutter to the encoder / hole detector and take a picture whenever the proper moment comes around on the guitar.

After you digitize the first & crappiest reel of film, you have an essentially unlimited supply of leader stock for all the other reels. Splice a few yards onto the next reel to give the Kinograph plenty of spin-up time, as needed.

You can optically sample / digitize / record the audio track with timing information from the capstan encoder. Convert the encoder’s LSB into a sine(-ish) wave, digitize that, and record it along with the sampled audio as a stereo signal. A 1000 pulse/rev encoder gives you a (nominal) 1 kHz tone, so you can re-tune the audio based on the tone’s frequency.

Long ago, in a project far away, I worked with a group doing video compression. They discovered, somewhat the hard way, that frame-by-frame compression produced lethally ugly inter-frame artifacts, particularly in low-contrast skies and high-density grass. If you’re not doing aggressive JPEG (whatever) compression, it probably won’t matter, but should you notice weird crawly artifacts across skies and fields, now you know what happened.

The FLIR camera specs suggest 2040×1536 at 12 bits tops out around 40(-ish) fps, which seems perilously close to 24 fps for a first cut. I don’t know enough about the storage chain, but a low-compression 2K image might be 2 MB, so the processing stack + hardware must handle two continuous 48 MB/s streams (in and out) without burping.

I still need convincing about sufficient light. Back of the envelope says 24 fps → 18 inch/s → 56 µs/mil, so the exposure must be around 25 µs to maintain 1 mil blur. The lens will (probably) run around f/11 for enough depth of field, which (in the old days) means you need outdoor-full-sun-intensity illumination for ISO 40000 film. ISO 40k seems aggressive for a 25 µs exposure, but I haven’t digested the camera specs.

Definitely a three-pipe problem!

3

@ednisley thank you for the post and welcome to the forums!

I’m intrigued by your audio idea. Do you have any experience with capturing optical audio tracks? At one point we had discussed capturing sound from the film with hardware. How hard of an electronics problem do you think that would be to solve?

If I understand your suggestion, it would mean we capture the audio as a digital file (in what format, I’m not sure) and then apply a time-mapped adjustment to that file based on the recorded variance of speed during the scan. Is that right?

4

The electronics will be less daunting than the mechanics & optics.

At 18 inch/s, a 10 kHz signal has a 1.8 mil wavelength, so the light must be under 1 mil = 0.45 mm along the audio track and maybe 2.5 mm across. Some poking around suggests 10 kHz is a bit over the actual bandwidth, but it’s a reasonable starting point.

The illuminator must produce a sheet of light collimated well enough to account for film bendiness / wobbulation in the gate. Basically, you want a rectangle of light passing vertically through the film.

On the other side of the film, a magnifier images the (now modulated) light on a photodiode detector or, for stereo, two detectors. The photodiodes need enough illumination (more bright light!) to produce a good SNR and a current-to-voltage amplifier to extract it. After that, it’s a reasonably low bandwidth audio preamp.

I’d start with photo-etched slit masks on both sides of the film and cylindrical lenses for collimation, although I think the right way has real lenses imaging aperture slits on the film to maintain enough clearance. I don’t know enough optics to have a real opinion.

The audio signal will vary with the (nearly constant) film speed, as will the encoder signal from the capstan drive. Given that the encoder signal should be a constant frequency, some DSP magic can determine the frequency error and the adjustment required to correct it, then apply the same tweak to the audio track signal.

All of which is easier in theory than in practice … [grin]

1 Like
5

Your point is really good, we’re definitely balancing traditional photographic math here. I know I’m going to be unpopular in suggesting intermittent motion, but it does solve a LOT of exposure woes especially as frame size and resolution increase. I’m only half serious :wink:

6

With the new proposed setup here, we could probably figure out a way to implement an “intermittent” mode. It would not likely be in the first beta of v2 but would make for a great community project thereafter! I like that idea.

7

Designing a cheap / simple / reliable intermittent drive seems like a major effort, so a slowed-down continuous drive may be easier. Smooth motion definitely simplifies audio capture and frequency-shifting / -correcting the sound up to normal ought to be straightforward (compared to the video chain, anyhow).

8

I did it with a loop of code, a stepper and sprocket sensor - but I can see how it appears complicated next to continuous motion. I had some lighting and optical considerations that routed me to an intermittent design.

My office has a lot of motion picture film cameras around and it just occurred to me that maybe a hybrid setup could work well - the film reels would have significant mass (considering 35mm film) and could keep spinning if there were loops on either side of the gate, and the slack in the loops could give an intermittent movement through the gate “time” to stop and go.

9

We’re also using intermittent motion on the scanner we’re building. Tension is with AC torque motors, which hold the film in place (There are some sensors in case of unthreading, to shut them down). All rollers are PTRs, and the drive is a closed loop stepper-motor PTR capstan with a built-in encoder so we know how far we’ve gone. Frame registration with OpenCV. Our design requires intermittent motion.

Speed isn’t a consideration, and it’s possible we’ll switch to a rolling shutter camera soon, which would require the film stays still.

I did all this a few years ago on a rebuilt Imagica scanner and it wasn’t much code, to be honest.

2 Likes