Sasquatch 70mm scanner

At Gamma Ray Digital, we’re building a 70mm scanner. Actually, it’ll do more than 70mm, since it’s based in part on things we’ve learned from our Lasergraphics scanner and from rebuilding an old Imagica scanner several years ago.

I’ve set up a flickr album here where I’m putting the photos as we go.

The scanner started as a Cintel Ursa Diamond telecine. We picked up the chassis for free after the parts were removed by someone who bought it and didn’t want to deal with the heavy stuff. In order to make this work as a 70mm scanner, the whole transport was simplified, the mirror housings enlarged, and all the remaining electronics were stripped from it. The chassis is nice in that the lower section and the bridge above it are all standard 19" equipment racks, so we have a place to put the host computer, shelves, and all the motion control hardware.

The goal is to make a scanner capable of scanning 35mm 4-8perf and 70mm 5-15perf. We’re building it specifically to handle weird formats that most scanners can’t - things like 10perf 70mm, a largely scientific format.

The current camera is a Vieworks VN-16MC, which is a pixelshift CCD imager that can produce a 14.5k image. We will likely swap this out for something running a Sony IMX 411, which is about 14k as well, but is a more modern sensor with excellent S/N and better low light capabilities.

Motion control is being done with off the shelf PLCs from Velocio. LED lighting is all custom, with two banks of separate RGB LED COBs. Each bank is tuned differently - one for neg and one for print. These are controlled by custom built drivers.

The transport is very simple: all PTR rollers including the drive capstan. Tension is held using AC torque motors, just as the Imagica scanners used. This is a very simple way to maintain tension on the film, and can be fine-tuned fairly easily with the use of external torque motor controllers (we’re using Oriental Motor controllers and motors).

Drive is handled with a closed-loop stepper motor that has a built-in encoder so you can accurately track position. We’ll be doing frame registration in OpenCV using the perfs as references, and the scanner is intermittent motion. It will not be fast. With the current camera, 1FPS is probably the best we can expect. if we upgrade to the Sony sensor, maybe 3-5fps.

In terms of capabilities, it will do sequential R-G-B scans, and will also do 2 and 3 flash HDR scanning.

The capture software is also custom built, written in the Xojo programming language. We’re starting on this part now.

Feel free to ask any questions you might have. I’ll be adding to that album over the coming weeks as the freshly powder-coated pieces get installed, the motors are installed and hooked up, and we start assembling the lamp house.

Oh, and about the name: The Imagica 70mm scanner at Fotokem has long been nicknamed Bigfoot. Since we borrowed so much from that design, and it’s one of the only other high resolution 70mm scanners out there, it only seemed fitting to call ours Sasquatch.

3 Likes

HOLY DANG. I have so many questions. This is incredible! Thanks so much for sharing. We are stoked to have you.

Here are some questions that come immediately to mind:

1 - What led to your decision to use the Velocio PLCs? Is there an advantage over Arduino?
2 - Would you be willing to share the technical specs of your lighting setup (both neg and print)?
3 - Do you have a link to the kind of motors you’re talking about? I’d love to simplify the current motor feedback system I have for Kinograph and yours sounds interesting but I’m not 100% sure I understand how the tension is maintained in your setup.
4 - Since you’re using a stepper and intermittent motion, I suspect you are not worried about film shrinkage. True?

I haven’t read your other posts yet so forgive me if you’ve answered any of these elsewhere already.

Really cool project!

I’d also love to hear how you thought about your film path - where to put rollers, sensors, etc. and why. When I first looked at the photos I thought you inherited the path from the old machine you repurposed but then realized (!!) you built it from scratch!

Also, what does your gate look like? Did you go for a curved/flat hybrid or a more traditional pressure gate with rails?

No programming, really. It’s just faster. PLCs are meant for programming repeatable actions, so we will be setting these things up to do simple tasks like “go to X frame” or “advance one frame” – stuff like that. The Velocio PLCs are unique in that they don’t require you to use ladder logic, which is incredibly weird unless you’ve been using it forever. They basically provide a simple flowchart interface to build state machines, and the various controllers (which are tiny little pucks) can be networked together. So we can have one for just the steppers and torque motors and one for the motors that operate the camera/lens platform. Communication is over serial with modbus, so it’s easy to integrate into a desktop application

It could be done in the Arduino, and that was the original plan, but time constraints got the best of us, and this was a simple way out that didn’t cost that much.

I’d have to talk to the engineer who built these. The LEDs were selected based on the frequency response of the camera, but they’re a fairly generic COB form factor, so changing them out if there’s a new camera that requires different lamps. We will be using filters as well to really fine-tune it. We’re doing sequential RGB with a monochrome camera, and we’re reusing the cintel lamp house enclosure (which is very roomy - about 18" square by 6" deep), so we have lots of room to play in.

The Torque motors are these: https://catalog.orientalmotor.com/item/single-phase-tk-series-torque-motors/20w-tk-series-torque-gear-motors/5tk20gn-aw2u-5gn9sa – the way they work is that they’re not meant to spin freely for a long time. They’re designed to hold something in place. Imagine two torque motors each with a reel on it. There’s film going from feed to takeup. The motors are pulling against each other, holding the film in place. If you move the film to the right (with very little effort), it holds there. If you move it to left, it holds there. They’re not meant to transport the film, just hold it in place. The capstan, which is just a stepper with a built in encoder and a matching driver, is what pushes and pulls the film through.

I was skeptical of this setup myself when I did the imagica, but it’s so simple I don’t understand why more scanners don’t do this. Of course, you do need to have basic sensors in place to shut the motors down, say if the film breaks or something, otherwise they’ll both start spinning at high speed. but that was super cheap - I just got some simple proximity sensors, which are designed to work with transparencies. they didn’t cost much.

We may have to bolt on some kind of additional tension sensor at some point, but it may not be necessary once we get the tensions dialed in.

Not sure what you mean - The scanner will handle shunken film in a way similar to what you outlined in another post: The gate is oversized to allow for slop (whether that’s slippage – which shouldn’t happen – or shrinkage). We know how many rotations the capstan motor needs to go for a given frame, so we can count that to get in the right position. Then we’ll use OpenCV to determine the perf position within the captured frame. Once that frame is being processed, that information can be used to determine shrinkage and how far we need to go for the next frame. lather, rinse, repeat. Since shrinkage can vary over a given reel or across reels, it has to be constantly adjusted for anyway.

Here’s the model: Screen Shot 2020-01-03 at 05.37.45 PM

Film travels from left to right, and can be A or B wind. It goes around the bottom left roller first, over the top left roller, across the gate, down through the three rollers (the bottom is the capstan), around the bottom right, and up onto the takeup reel. The thread/unthread sensors are right to the left of the gate and just to the left of the bottom right roller. All the rollers are 70mm PTRs, including the capstan.

It’s curved slightly on the edges but flat in the middle. This may still require some tweaking, which we can do easily once we get the new CNC router set up. The gate is held onto the deck with the same pins the Cintel scanner used. They’re 1/2" stainless registration pins that stick out about 3" from the deck surface. They enter into the back of this gate, and then screws in the front go into tapped holes on the registration pins. Once tightened, the back edge of the gate is pulled flush to the deck and is perfectly perpendicular to it. We left a little room above the gate so we could potentially put in a pressure plate system in the future if necessary.

Screen Shot 2020-01-03 at 05.20.34 PM

The PTRs on either side of the gate should provide enough tension to keep the film taut. This is very similar to how our Lasergraphics scanner does it.

1 Like

Thank you for the generous response. I really appreciate the time it took!

I like how your design is driven by simplicity. It’s easy to understand and makes a lot of sense.

Re: the motors, I’m very intrigued by this approach. Would this list be an accurate accounting of what happens in the system for each frame?

  • the capstan moves forward by X, where X is determined either by the default or the position of the previous frame (assuming CV is NOT used in this step)
  • a frame is captured by the camera, saving it to the hard drive of a connected PC
  • CV is used to detect frame within the saved image. If not in the position you expected, then the difference between where you expected the frame and where it actually appears is “saved” and the capstan will take this into account in the next frame advancement

What I cannot figure out is how the torque motors know when to turn and by how much. Can you help me understand that part?

Also, is there only one motor on the take-up side? Or are you providing some “pull” on the film with another motor on the feed side rotating in the opposite direction?

Using CV as feedback to the capstan (if I understood it correctly) is a cool approach. In our case, we want a bit more speed and I’m not sure we can do that. Our goals are the same, however: create a feedback loop that tells the capstan how much to move the film before a frame is captured.

In my case, I’m going to try using a rotary encoder on the captstan to measure linear travel of film and reflective sensors to measure the length of a frame (averaged over many perfs to account for any missing/damaged perfs).

I hadn’t realized it until now but because we have the same end result, we could possibly use intermittent motion on Kinograph too. It would require the motors to “hold” in the way that you describe, however and might have to run at lower speeds. @johnarthurkelly you could get your wish! That would open the door for multi-exposures.

Thank you @friolator for sharing all your hard work. We all really appreciate it. It helps us all make better machines and save more films from The Darkness :slight_smile:

1 Like

amendment to the above, we could still use CV and get speed. It would require either a good amount of GPU or a machine learning camera like this Flir model.

Essentially, yes. We’ll be using OpenCV to do several things to the image before it’s writing to disk, including frame registration. So as part of that process, we’ll already know the position of the reference points (whether those are perfs, frame edges or both. If there’s an offset from where we expect to be, as far as the positioning of the frame in the gate, then we let the PLC know to move X distance more or less next time to get it back where we expect it.

Based on the info gathered from OpenCV, we should be able to generate a report as to how shrunken the film is at the end, which is potentially useful for archives as well.

Both the feed and takeup side platters will have torque motors. they pull in opposite directions, and with the use of a motor controller (which you can control via standard GPIO signaling), you can control the direction and the tenstion. tension is controlled by the amount of voltage getting to the motor. So the idea is that if the two motors are “balanced” – that is, one doesn’t have more pull than the other – then they simply hold the film in place indefinitely. They’re motors that aren’t designed to spin, they’re designed to hold. In fact, if you used one of these motors to try to wind something without any opposing force, it would rapidly overheat and go into a protective mode to prevent damage. They’re designed to work in a “stalled” state and to hold there until made to do otherwise by some opposing force.

So when you move the film (in this case with a capstan), you’re pulling slightly from the feed side and the takeup side immediately takes up the slack, keeping the tension on the film.

Of course, it’s possible to do multiple exposures while the film is in motion, but it’s a lot more complex. The Lasergraphics Scanstation does this by varying the exposure time slightly. There are limits of course, because too long an exposure and you introduce motion blur. But it absolutely works and we see a significant difference in dynamic range with 2-flash encodes vs 1-flash, on very dense film. It’s a lot easier to do this with intermittent motion as well.

I would imagine the Lasergraphics Director (the newer sprocketless models) are using servos for feed and takeup, instead of torque motors. The earlier directors used sprockets and mechanical registration pins, so they had a projector-like mechanism with loops on either side of the gate. I don’t think they have loops anymore but it’s still intermittent.

I think GPU is the way to go - They’re just getting faster and faster, and many of the algorithms needed to do this are already CUDA accelerated. And you probably don’t need that much to pull it off, to be honest - I mean the ScanStation uses dual GTX1070 cards, which are pretty cheap. They ping-pong frames between them to maintain speed while scanning. I don’t know for sure, but I’d imagine they’re doing all their color processing on the GPU, and probably the perf detection and alignment too. The computer they ship with is pretty middle of the road as workstations go.

2 Likes

Great thanks for the answers @friolator.

So the motors don’t need any input to know how much to turn? No swing arm or swiveling hub like I’m using?

Does the voltage you’re sending it need to be adjusted over time or is it a “set it and forget it” thing? Sorry for my ignorance. This is new to me.

Also, how does this affect rewind? Could you still do a quick-ish rewind that was tight enough?

Correct. Don’t think of them as “correcting” tension - they’re just keeping tension on the film.

I believe there would need to be some adjustment, which we’ll dial in as soon as we get the transport completed in the next couple of weeks. Each motor has its own controller, so they can be adjusted separately. Right now we have nothing in the middle to measure the tension, but we could probably use a load cell with a roller on it to do that. The idea though, is to dial in the settings for each kind of film, and then we wouldn’t need to do realtime adjustments. The Imagica simply has the two motors and the drive stepper as well, with no springs or tension arms or any of that.

We likely wouldn’t use it for rewind, but the way you’d do that is to bias the voltage towards one motor or the other. That is, the one that has more voltage is the takeup and the other is just providing resistance to keep the tension. It would be possible to do rewinding this way. I’d probably do it like the Cintel did, where instead of rewinding through the full transport, you would rethread through a roller in the middle of the feed and takeup reels, and just hit rewind or fast forward to move it from one reel to another.

The controller we’re using is the Oriental Motors TMP-1, which is designed for their motors, but you can get an idea of what you can do with it from the datasheet (uploaded). The brochure also talks a little about how torque motors work in general. It shows you how much time you can run some of their motors continuously before they power down to prevent damage. All the torque motors are designed to have a locked rotor (holding the film in place) for a constant duty cycle. But they can run as normal motors for a fixed period before shutdown. 5 minutes is more than enough time to rewind a 2000’ reel of film, for sure. So to rewind, you’d drop the voltage on the feed motor so it’s lower than the takeup motor. The feed motor acts as a break, keeping the tension. The tightness of the wind is based on the differential in voltage between the two. So the bigger the difference, the more tension on the film.

TMP-1-Brochure.pdf (1.4 MB)

Thank you so much for the explanation @friolator. This gives me enough to look into this option more on my own. It’s probably more than I can commit to in this first round of prototyping but something I’d definitely want to try in a subsequent phase later this year.

Our first gate should be here late in the week. As soon as we get the rollers installed and the torque motors installed, I’ll see if I can shoot some video of how they work. Probably wont’ be until next week at the earliest though

1 Like

Great project. Curious… what throughput frame rate you are targeting? thinking in terms of massive source data.

We’ve made a decision to get a new camera that uses the Sony IMX411 sensor, and this is faster than the camera we’ve been testing with. So if we’re doing monochrome film we should be able to max it out at just under 3fps, the top speed of that camera at 16bit. It could go faster at 12 bit, so that’s an option as well, but we’re building it for quality, so 16bit is our default. Because color film requires three flashes (one for each color channel), it’s more like 1fps for color.

Now, that’s at full resolution, roughly 14k x 10k – for some gauges it’ll be faster because we’ll be using an ROI inside that large sensor, and there won’t be as much data to move around. There’s about a month lead time on the camera, so we won’t know for sure until probably March sometime, how fast we can make it go.

That said, speed isn’t our priority with this scanner.

3 Likes

Another update on the scanner - working on the feed and takeup platters today and hopefully getting all the rollers in place by the end of the day today so we can begin performance and tension testing with the transport next week.

We made a decision last week to ditch the stepper motor we were using. The one we bought wasn’t working properly, and we weren’t getting any response from the manufacturer on what to do (Stepperonline.com) – so instead I splurged and got one of these cool servos from Teknic. It’s completely self contained, and it can be plugged directly into our PLC. It has incredibly fine control over speed and torque, so we can make on the fly adjustments.

Though it would be a fairly big expense, we’re also considering changing the feed and takeup torque motors for a pair of these, because they can provide built in torque feedback, which would allow us to precisely control the tension right in the motor. Not cheap, but a lot easier and more reliable than relying on sensors to detect lost tension. We’re moving ahead with the original design on that though, and will evaluate using these motors once we get everything up and running.

Thanks for the update @friolator. I’ll def be checking out those motors. Looking forward to seeing the Sasquatch in motion (hopefully not as blurry as most of the other Sasquatches in motion I’ve seen).