Sasquatch 70mm scanner

Research
1

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.

5 Likes
2

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!

3

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?

4

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: 5TK20GN-AW2U / 5GN9SA 20 W (1/38 HP) AC Torque Motor (9:1 Gear Ratio) (Single-Phase 110/115 VAC) – 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
Screen Shot 2020-01-03 at 05.37.45 PM2458×1558 178 KB

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
Screen Shot 2020-01-03 at 05.20.34 PM2890×1430 273 KB

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
5

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
6

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.

7

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
8

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?

9

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)

10

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.

11

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
12

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

13

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
14

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.

15

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).

16

Things have been really slow due to COVID and not being able to have people in the office simultaneously. I’ve had to send some parts out for manufacturing, rather than doing them in house, because of time constraints. I am, however, very happy with the results, and the bonus is that they’re done in a week and come back finished (we’re having everything anodized, some items in color.

We had to completely reengineer our camera/lens platform, and the new design is great. In the original Cintel configuration, the light source came from above, the image taken from below. This is problematic for a few reasons (gunk falling off the film and onto a mirror being the biggest, but also the fact that the mirror housing is hinged, leading to potential issues with the perpendicularity of the mirror to the camera. So we swapped the two, with the light source below and the camera above, using a fixed mirror to turn the image into the chassis. The new design has a large box that holds the camera and lens. it’s mounted directly to the frame of the scanner, the front plate sandwiched between the chassis and the deck plate.

Imgur
Imgur

The camera/lens sit on a sled, and each is on its own motorized platform:
Imgur

This slides into the box and is held down by a couple bolts at the rear.

On the front of the deck plate, we have the newly designed platter system. Since the scanner can handle 70mm and 35mm formats, you have to move the film farther from the deck plate for narrower gauges, so they’re centered in the gate. My solution to this was to mount a Delrin plate to the motor shaft:
Imgur

For 70mm, you mount a blue platter directly to this plate. Two screws hold it to the base plate, attaching to a pair of press-in nuts on the back of the Delrin piece. Note the spacing between platter and deck plate:
Imgur

For 35mm, you use an orange platter, which has a Delrin spacer mounted to the back, that interlocks with the base spacer. two longer screws go through the two Delrin pieces, using the same press-in nuts to hold them together.
Imgur
Imgur

This provides the correct spacing relative to the deck plate, centering the film in the gate. Hoping to start wiring up the motors by next week sometime.

2 Likes
17

You are a god among men.
(That is really clean, good-looking design.)

1 Like
18

Loving the interchangeable platter design. Really clever. Glad to see updates on this. I was wondering if the Sasquatch had gone back to his cave for the winter :slight_smile:

19

What kind of speeds do you get with the Sasquatch? Also what’s the benefit to using a mirror instead of mounting the camera in a column down the front?

20

The chassis we are using is an old Cintel Ursa, and that’s how it was designed. There wouldn’t be enough room to fit the optical assembly in this chassis and still close the door. So the idea is to not reinvent the wheel, though we are using it in a better way than the Cintel did, which could result in buildup on the mirror below, causing spots on the image. With our setup the light is below and it should be so bright in there that anything that might temporarily fall inside wouldn’t really matter.