RetroScan UNIVERSAL

[carllooper]

Has anyone had any experience with the RetroScan Universal?

A colleague has recently acquired one and we're trying to troubleshoot a problem with it. Now I should say in advance that the unit has been modified, and so it is from the outset entirely conceivable that the modification is responsible for the issue we're attempting to troubleshoot. On the other hand it might make no difference at all. Either way we're trying to understand the problem and how to create a fix for it.

The issue we're seeing is that the take up motor is behaving a little erratically in terms of the rate at which it takes up the film. When the unit is turned on it will begin to take up the film at a rate one has otherwise selected, but then after a little while it can, of it's own accord (and inconsistently), increase the rate at which the film is taken up.

The modification.

The modification replaced the Retro's own camera with another camera: a Point Grey camera. This involved a modification of the cable between the unit and the camera. What I'm not yet able to understand is how this modification might be affecting the takeup motor on the reel.

Now an idea entertained by the owner of the Retro, in order to fix this takeup motor problem, was to bypass the Retro circuitry altogether and power the take up on a separate power line. But even if one knew what voltage/current to supply the motor one would have to vary the motor rate over the course of a capture. For if the motor were to otherwise turn at a constant rate, the rate at which film passes through the gate would actually increase in rate - as a function of the increase in radius of the takeup.

One solution to this is to simply test some upper and lower bound with respect to a corresponding takeup radius. A more elegant solution is to put a sensor on the film that can measure the actual rate at which film is being pulled through the gate and adjust the motor accordingly. For example: a perf sensor!

Now the Retro already has a perf sensor and it seems to me this could very well be performing just such a task, ie. in addition to it's role in triggering the camera. Indeed I don't know how the Retro could otherwise keep the takeup rate under control.

And if so then it's quite plausible that altering the relationship between sensor and camera might also alter the relationship between sensor and motor, interferring with any feedback system between sensor and motor. However, all of this is in the realm of speculation. I don't know if this is the case.

So one idea is to reverse the mod that was made - and see if that makes any difference. However the owner would very much like to keep using his camera, rather than the Retro's camera.

And so we may very well need to power the takeup independantly of the Retro, and simply use a second custom perf sensor on the film to keep the motor in check. However I don't have any info on what the takeup motor needs in order to turn. So I might just end up proposing putting a new motor on the takeup reel in addition to a second perf sensor. Or rather, just make a separate takeup arm altogether (leaving the Retro's one as is). So the separate arm just sits on the bench next to the Retro, pulling the film through the Retro - and leaving the Retro's own take up arm to do whatever it wants to do to it's hearts content.

C

[MovieStuff]

The Universal obviously has a perf sensor, otherwise it would not know when to trigger the camera. The sensor also provides a speed feedback reference to the motor control circuit to maintain a constant speed. Proper adjustment of the sensor knob is required so that the sensor is not fooled by clear edges or image contamination in the sprocket hole path. Improper sensor adjustment can result in the motor radically speeding up or down, depending on what the sensor encounters during film travel. Even under proper operation, there may be some clear edged film that will not run on the unit. Color neg, however, runs fine since its edge is amber and not clear.

I have been contacted by the customer previously. The customer should have followed the warranty requirements to test the unit upon arrival using the provided camera. Instead, the customer cut the camera trigger cable so it could be patched to a different camera. Installing a different camera is allowed and does not void the warranty nor customer support as long as the unit/camera is not damaged nor disabled in the process. This is made very clear in our warranty info on the order page of our website. To be clear, I allow and, indeed, encourage customers to try different cameras. That's the main reason for the design of the unit. But the original camera must be maintained for the purpose of diagnostics in situations exactly like this. Had the unit been tested immediately upon arrival with the provided camera, we would have a benchmark for performance and, had that camera been maintained for testing purposes in its original condition, then it would be easier to sort out whether the current problem is with the unit or user error.

It should be noted that the camera trigger cable is a standard telephone multi pin connector which was chosen to accommodate the use of other cameras as this cable is commonly available in most electronics and hardware stores. As such, it was economically unnecessary to hack the original camera cable. If the new camera is not integrated properly, it can impede proper operation of the unit, including proper film transport, because there is not a common ground throughout the electronics. So adding a different camera isn't just about hacking wires and splicing things together. Anyone attempting camera replacement should have a good understanding of electronics. While there could be something wrong with the unit, it is now impossible to determine if this damage was there upon arrival or introduced through improper implementation of the new camera.

Roger

[MovieStuff]

Carl, check your email.

Roger

[carllooper]

Hi Roger.

thanks for that. I've recommended to the customer that he follow your instructions and reverse the mod before proceeding with any additional work, which he'll be doing in due course.

He has been away in Malaysia for the last month, on a tour with a film group (touring films our group have made including one of mine) and has only just got back.

And I take your points raised in the pm.

Carl

[MovieStuff]

Thanks for your consideration. The only way I can help is if the unit is returned to "factory condition", so to speak. Once we know the unit is working correctly or, conversely, know what the problem with the unit might be, then a solution might be viable. Until then, we don't really have enough of a benchmark for comparison.

Roger

[carllooper]

Thanks Roger.

I'll have a good look at the system in the next few days and see what he's done. It probably is just a loose connection on a ground line or even a lack of a connection altogether. But in any case I'll ensure the original cable (ie. a new one) is put back in first, ie. to reverse the mod and check operation with the original camera. And if that solves the problem then we'll know it's the mod that is responsible (or if not can at least rule that out and troubleshoot the system further). Can then get a plug for that cable and make an extension cord for it (so to speak) to act as an interface for his other camera - allowing us to troubleshoot any issues that might arise as a consequence of that, ie. in the knowledge that it otherwise works perfectly fine with the original setup.

I'm quite keen he gets up and running with it as I have a film I want him to transfer on it. As do others. My own bespoke system I'm using for film to film transfers (optical printing) so don't really want to be doing digital transfers on it, other than for experimental purposes. My system is actually offline at the moment due to a belt disintegrating in the projector (it's a very old projector).

I should just say the Retro owner is a young filmmaker and makes some extraordinary work. Stunning in fact. My own work is a complete joke compared to his (but in my defence I'm a bit of a comedian so that tends to works in my favour). The transfer business is just a side line for him but if he can get it up and running it's some good pocket money for him.

cheers

C

[Tscan]

My machine will do this occasionally on certain spools of 16mm or reg 8mm where there can be a certain length of clear film at the head or tail. And one time I had some more sporadic changes toward the end of a 400ft spool. But in either case, the final capture came out fine. In the 1st case, the sensors can get tripped up by clear film and the second I believe the motor was just adjusting to maintain proper speed with the change in torque. If everything is threaded right for spool size, arms adjusted optimally, and sensor dialed in, you may still get some necessary speed changes but with a steady capture. The beginning of a spool always starts slower, then speeds up to the correct pace once you get past the leader and head. Run it for a little bit to dial in your settings, then backup and start your capture from the head and all will be fine.

[JeremyC]

It could be that the cable 'modification' is somehow dragging down the power supply rail confusing various bits of electronics, it may not be a constant thing but happen at various times during the scanning/film advance cycle so could eb hard to find. Roger's advice of removing it is a good idea.

[carllooper]

My machine will do this occasionally on certain spools of 16mm or reg 8mm where there can be a certain length of clear film at the head or tail. And one time I had some more sporadic changes toward the end of a 400ft spool. But in either case, the final capture came out fine. In the 1st case, the sensors can get tripped up by clear film and the second I believe the motor was just adjusting to maintain proper speed with the change in torque. If everything is threaded right for spool size, arms adjusted optimally, and sensor dialed in, you may still get some necessary speed changes but with a steady capture. The beginning of a spool always starts slower, then speeds up to the correct pace once you get past the leader and head. Run it for a little bit to dial in your settings, then backup and start your capture from the head and all will be fine.

Yes, he does understand that the perf sensor works best with reversal, and that it otherwise needs some experimentation with the sensor adjuster to work with negative. And he does work with negative. And when doing so the frames he gets can vary a little in terms of their registration, and sometimes drop a frame. He's actually winding the film by hand at the moment, and doing registration in post. Obviously you wouldn't want to be doing that for customers! But that's the way he's currently doing it for his own work. And yes that would or could play into the motor issue as well. Not sure if that's the entire source of the problem, or just a part of it. It could be. If the sensor misses a perf one can understand the internal logic saying to itself that the film is moving too slowly, and therefore choose to speed the motor up to compensate.

Anyway, the Retro is a pretty cool machine. I love the mechanics and the interchangeable gates. It's beautiful. I want to get one myself

C

[carllooper]

It could be that the cable 'modification' is somehow dragging down the power supply rail confusing various bits of electronics, it may not be a constant thing but happen at various times during the scanning/film advance cycle so could eb hard to find. Roger's advice of removing it is a good idea.

Yes, as I understand it the cable is just providing a GPIO trigger for the camera, ie. only two of the wires in the cable actually connect to Roger's camera. So without checking, it must mean Roger's camera's power must be on another cable altogther. And if Roger's camera is on the same ground line as the power supply for the rest of the Retro (as you'd imagine) could very well mean the new camera should be on the same ground line as well (if it's not already).

Anyway, that's down the track. The first thing is just to bring it back to it's default factory setting, with it's original camera, and give it a good test with some well exposed reversal film. Get a solid baseline. And then make some measurements with negative, both colour and B&W, to get a reference on that.

C

[carllooper]

So we've made some progress on troubleshooting the Retro.

The good news is that when we wired Roger's camera back in - it all worked perfectly fine. So we haven't damaged the Retro in any way - which is what I was worried about. And we can complete some commercial chores on it in the interim period - using Roger's camera.


The next step is to just work out why the new camera is producing interference with the Retro's normal operation. Looking at the GPIO port for both cameras I notice that the GPIO cable goes to a line on it's own camera that can be used for both input and output - where it's default state is input (triggering the camera). But on the new camera there is no equivalent line. On the new camera there is instead either an opto-isolated input line (camera trigger), or an opto-isolated output line. We use, of course, the input line (camera trigger). And being opto-isolated there's no way for the camera to interfere with the Retro.

The Retro must be interfering with itself (without it's own camera). So we have to give the Retro something equivalent. Something the new camera isn't yet providing.

Now there are two ground lines for the new camera - one ground line for the opto-isolated line (of course), and another for a serial data line. We use, of course, the ground for the opto-isolated lines. And we can't change that because the camera won't otherwise trigger.

But depending on how the Retro interoperates with it's own camera, it may be necessary to connect the Retro to both ground lines on the new camera. While this will defeat the purpose of opto-isolation, it may be that the Retro needs a little bit of extra ground, so to speak. One that finds it's way back to Earth via the USB power supply (on through the laptop, it's power supply and the national power grid, plugged into the Earth at large so to speak). The theory is that once grounded in this way the Retro will stop interfering with itself. Not that we have any moral issue with the Retro otherwise entertaining itself in this way

So that's what I'm going to try.

----

On a different tangent (my pet pre-occupation):

One thing I discovered (by the power of mathematics) is that using a higher resolution camera on the Retro won't increase the resolution of the captured image. This is because the speed at which the film travels through the gate is such that there is a maximum effective resolution due to motion blur.

Notes.

For any camera, to exploit the full resolution of the camera, the film should move no more than a distance of one pixel (in the sensor plane) during the shutter time.
But what distance is a pixel? Well that's up to the camera.

The Grasshopper has a vertical definition of 2192 px. This means one film frame height = 2192 sensor pixels.

So the ideal frame rate (for a 0.2 ms shutter time) would be:

1 frame per 2192 * 0.2 ms
= 1 frame per 438.4 ms
= (1000 / 438.4) frames per second
= 2.28 frames per second

The Chamelon has a vertical definition of 720 px.
So the ideal frame rate would be:

1 frame per 720 * 0.2 ms
= 1 frame per 144 ms
= (1000 / 144) frames per second
= 6.94 frames per second

So the formula becomes:

Code: Select all

FPS = 1000 / (sensorHeightPixels x shutterTimeMilliseconds)

Examples:

FPS = 1000 / (720 * 0.2) = 6.944 fps
FPS = 1000 / (2192 * 0.2) = 2.281 fps

Of course if you increase the amount of light by two, then you can half the shutter time and get:

FPS = 1000 / (720 * 0.1) = 13.88 fps
FPS = 1000 / (2192 * 0.1) = 4.563 fps

------

The other way to look at is, given a frame rate, such as 10 fps, what is the effective definition?

We've defined the definition as shutter time = 1 px (we could define it more loosely or more pedantically but this one strikes a sensible balance)

If we divide 1 second by 0.2 ms we get 5000 px. In other words we get 5000 px over 10 frames.

So over 1 frame we'd get 500 px. So running the film at 10 fps gives us a vertical definition of 500 px (per frame)

The formula becomes:

Code: Select all

vertical definition = 1000 / ( shutterTimeMilliseconds * fps)

Example:

fps = 5,
shutterTimeMilliseconds = 0.2
vertical definition = 1000 / ( 0.2 * 5 ) = 1000 px

C

[carllooper]

There's an error in my last post.

The Chameleon camera from Point Grey has a maximum resolution of 1296 x 964 where I mentioned it's vertical resolution was 720. This was due to second hand information and me not checking it's veracity. My thanks to Roger for correcting this.

https://www.ptgrey.com/chameleon-usb2-cameras

However it makes no difference to the mathematical discussion. The formulas remain correct. If one uses a 720 camera - (be it brand X or brand Y) the maximum FPS you'd want to use for such would remain the same as that mentioned in the discussion.

If we were to otherwise use a 964px camera (be it brand X or brand Y), the maximum frame rate for such a camera would be calculated in exactly the same way as we did for our fictional 720px camera. The only difference is that we'd plug the number 964 into the formula.

So by way of an example, here we'll calculate the maximum frame rate for a 964px camera, and a 0.1 ms shutter time.

This is the maximum rate we'd want to use if we wanted to use such a camera to it's full capability. Running the film at a faster rate will reduce the vertical definition of the source image to below that of which the camera is otherwise capable of encoding it. And running it at a slower rate, while it will produce an image with greater definition it will be greater than that of which the camera is capable of encoding it, ie. slowing down the time it takes to do a transfer for no additional benefit. So the calculated frame rate becomes an optimum rate at which to move the film, given the constraints, ie. it simultaneously satisfies a target definition (that of the camera) and the competing need to push a project through at the fastest rate.

Note that we use exactly the same formula:

FPS = 1000 / (sensorHeightPixels x shutterTimeMilliseconds)
FPS = 1000 / (964 x 0.1)
FPS = 10.4 FPS

What is important here are not the numbers used, but the formula. The numbers used will be specific to whatever specific camera and shutter one intends to use. The formula (such as it is) pertains to all cameras and all shutter times. Nobody can claim any ownership over such a formula. Its one that anyone could derive from consideration of the variables if they were so inclined.

Or to be blunt we're not actually talking about the Retro here. We're talking about any system in which the film moves continuously, and in the context of which, the Retro becomes but one example of such a system.

But this is a side note. The main discussion is about how we're attempting to use another camera on the Retro. Roger encourages this and we're looking into how to make this possible. It does not in any way reveal any proprietry information. All the information provided here is that which is visible to anyone willing to think about what they can publically see with their own eyes and brain, and otherwise speculate.

I come from a tradition of experimental filmmaking where we are interested in using technology in a way that isn't necessarily the way it was intended to be used. The goal is to get something different occuring - not something nominally 'better' or 'worse'. But in order to do that it can be of great assistance to understand the original intent of the technology.

Roger's machine is a fantastic machine, and I recommend it whole-heartedly. And it comes with a great camera, and you don't actually need anything more than such a camera on this great machine.

C

[MovieStuff]

Thanks, Carl. I will say that, while your formula is technically correct, the reality is sometimes surprisingly different. In other words, things that seem impossible on paper often work just fine in real life. When we were developing the unit, we of course captured a benchmark frame stationary and then compared all other frames to that as we played with shutter speeds and rate of travel. In theory, you would need a ridiculously high shutter speed to perfectly freeze a moving frame. But when you stop to realize there is no way to "perfectly" freeze anything that's moving, all math ultimately falls by the wayside since any formula that one might come up with still has to be imperically tested, visually, to see at what point "imperfection" degrades the image in a way that's detectable by the human eye. Without getting into specifics, let me just say that we were very surprised by just how low you could go on shutter duration and still have a viable image though we are well above that threshold.

The other thing that has to be accounted for is how the image will be displayed since the effect of movement on resolution is what's at play here. As you pointed out, the Chameleon we use has a resolution of 964, which is only 58 lines short top and bottom of being 1080. As a practical unit of measure, 58 lines is about the thickness of a regular 8 frame line, and the software perfectly interpolates the missing data when exporting to 1080. Based on our research, we found that the number one selling flat screen worldwide is currently a 42" diagonal. At that size and typical viewing distance, even 720p borders on overkill for most customer needs, especially since most of our equipment customers are still only outputting DVDs and not BluRay discs.

So the thing that I've found is that what's technically implausible often works fine in the real world and what's technically feasible is often not even in demand by the public. Yet. Of course, that's why the Universal is designed as it is, to accommodate the "yet" when the time comes. Super high res CCD cameras are so stupidly expensive now and virtually all equivalent CMOS cameras have rolling shutters, which makes them unusable for a continuous feed transport. I'm looking forward to a whole slew of low cost, high res CMOS cameras with global shutters that I know will be hitting the market in the next year or so.

I'm also waiting to see if there will be ANY kind of standardization on UHD formats. It's all well and fine to talk about scanning at 2K and 4K but, unless there are some standardized codecs to export for the average user, it's all kind of moot, IMHO. Most consumers can barely handle editing 1080 these days, in terms of storage and smooth file handling on their consumer edit systems, and there really is STILL no standardized codec for HD. Everyone uses something different. I remember over a decade ago when the planets aligned and the various industry players agreed on the DV codec. It was probably the single best thing that ever happened to SD video. But that isn't the case for HD and I fear UHD customers may face the same problems unless the industry can get it together again.

But, in terms of being able to produce UHD scans when the time comes, the Universal by design should accommodate most any high res camera. It should just be a matter of replacing the camera and updating the software to work with new camera drivers. Then you have a whole new unit without having to buy a whole new unit!

Roger

[RCBasher]

One thing I discovered (by the power of mathematics) is that using a higher resolution camera on the Retro won't increase the resolution of the captured image. This is because the speed at which the film travels through the gate is such that there is a maximum effective resolution due to motion blur.
.
.
.
.
For any camera, to exploit the full resolution of the camera, the film should move no more than a distance of one pixel (in the sensor plane) during the shutter time.
But what distance is a pixel? Well that's up to the camera.

The formula becomes:

Code: Select all

FPS = 1000 / (sensorHeightPixels x shutterTimeMilliseconds)

Thanks, Carl. I will say that, while your formula is technically correct, the reality is sometimes surprisingly different. In other words, things that seem impossible on paper often work just fine in real life. When we were developing the unit, we of course captured a benchmark frame stationary and then compared all other frames to that as we played with shutter speeds and rate of travel. In theory, you would need a ridiculously high shutter speed to perfectly freeze a moving frame. But when you stop to realize there is no way to "perfectly" freeze anything that's moving, all math ultimately falls by the wayside since any formula that one might come up with still has to be empirically tested, visually, to see at what point "imperfection" degrades the image in a way that's detectable by the human eye. Without getting into specifics, let me just say that we were very surprised by just how low you could go on shutter duration and still have a viable image though we are well above that threshold.

Hi Carl & Roger. A timely and interesting discussion for me, as I'm in the middle of writing a simple paper on just this very subject. I have been asked many times about using 2K and 4K cameras on a continuous transport systems (CTS) and with the expectation of maintaining 24fps and upwards scanning speeds. In practice Carl I have found 2 lines movement to be pretty much indistinguishable from 1 line, probably because I'm dealing with Bayer sensors anyway which of course have half the vertical resolution. I also agree with Roger that the reality is often different and many people seem to be pleased with a 24fps scan with an HD camera at 200us or 300us exposure. With my system, the exposure time varies to accommodate different film densities but I target to keep well below 100us to get within the "2 lines" factor with real time scanning speeds.

I think we do not see a practical difference with higher relative speeds because of the lack of real image definition on most films. All we are doing is better defining the film grain! This latter point is interesting because enthusiasts sometimes seem keener on the grain than the image! I will not argue the point but will say that as the grain looks like noise, it does not compress very well at all. If we take the case of a 4K 4:3 36bit image saved in a 16bit depth container then if my maths are correct, that's 72MB/frame. This equates to something like 6.22TBytes for a 1 hour 24fps film. Handling that kind of data at any speed is quite a challenge! Enter compression: Lossless may get us down to about 2/3rds, so it helps but not a game changer. Lossy compression it has to be. Why do we often think lossy compression is acceptable? Usually because we look at the image and at some given level decide it is ok. But to get lossy compression to work reasonably well the first thing we have to do is apply a noise filter - oops, there's goes the grain! Bottom line is I think 4K scanning is just an excuse to pixel brag rather than to obtain practical scans other than for very high end professional use, probably only for 35mm - and those scans will not be done on a CTS scanner but a frame locked one with many tens of thousands of £/$/Euros in computing muscle and fast storage required. Any resulting images would need a high resolution projector for viewing as even a large UHD TV will not look any different to a 720p one at 3m/10ft viewing distance, even with 20:20 vision!

Frank

[MovieStuff]

Hi Carl & Roger. A timely and interesting discussion for me, as I'm in the middle of writing a simple paper on just this very subject. I have been asked many times about using 2K and 4K cameras on a continuous transport systems (CTS) and with the expectation of maintaining 24fps and upwards scanning speeds. In practice Carl I have found 2 lines movement to be pretty much indistinguishable from 1 line, probably because I'm dealing with Bayer sensors anyway which of course have half the vertical resolution. I also agree with Roger that the reality is often different and many people seem to be pleased with a 24fps scan with an HD camera at 200us or 300us exposure. With my system, the exposure time varies to accommodate different film densities but I target to keep well below 100us to get within the "2 lines" factor with real time scanning speeds.

Agreed. I felt that scanning at 24fps wasn't really that necessary to be efficient and slowing the unit down makes a world of difference in terms of shutter speed head room. The Universal has a normal speed of 15fps and can be slowed to 10fps by way of a switch in the back. Ultimately, the frame rate is maintained by a speed control board inside the unit. The board firmware can be custom programmed to other speeds, as well. I have a customer that ordered a unit and paid to have a second board with speeds of 6 and 13fps because those were the safe top speeds of his two cameras. He can simply swap out the boards as needed in seconds.

Roger