Happy weekend, everyone!
I was looking for perforation detection solutions using fiber optic amplifiers and came across this photoelectric sensor specifically designed for transparent label films (FUWEI FGU07)
I have tested infrared sensors before, but I know they can present some inconsistencies with highly transparent films. I got curious and bought it to test out since it was quite cheap. Has anyone used a similar sensor?
Cheers!
@Eldi found this:
I just found this on AliExpress: https://a.aliexpress.com/_ExmdZEE
I just found this on AliExpress: https://a.aliexpress.com/_Exy9bS2
Personally, I prefer laser pinpoint sensors to; they work with all types of film—white, black, color, or transparent—and ensure perfect detection. Best of all, they don’t require a reflector.
You just need to add a small lens to the end of the fiber optic cable to focus the laser and produce a 0.3mm beam.
Hi @Roland,
Thanks to you and @Eldi for sharing these links! I will definitely order these and test (the price is very good too).
I’ll share the results here. Thanks again!
One thing I’d point out with these detectors is that they can work well for a single gauge, but if your scanner supports different gauges, like 8mm and 16mm, they won’t line up without some mechanism to move them (and then you may have issues with alignment). Personally I prefer perf detection in the image, which is cheap and easy these days with machine vision software.
That is partly wrong and not entirely accurate. An alignment system is indeed needed, but extreme precision is not required. However, @friolator, could you give us some concrete details about the affordable machine vision system you are referring to, ? It is very interesting.
OpenCV - it’s free. The way we do it in sasquatch is to move the film a fixed number of steps to where it should more or less be, take an image, determine the perf position. If it’s dead on then great. if it’s off, then the next frame advance we compensate a little by adding or subtracting steps to get it to where it should be. That’s for intermittent motion.
For constant motion, if you’re using a Raspberry Pi camera, the built in libraries can do this. My only experience with it was building a Microfilm scanner. I wanted to see if Claude Code could build it all (it did, with a lot of testing on my end and many revisions). It was mostly a proof of concept, but it works fine - it detects the images and tracks them across the frame. there’s no reason the same can’t be done with a perf, which is probably easier since it’s in a consistent area of the film.
There are other ways, I’m sure. But object detection is nothing new and that’s all this is.
I can support this. My scanner does monitor the location of the sprocket hole during capture and adjusts the next step forward accordingly. Easily done with opencv - I published a (very simple) working algorithm years ago. Runs in realtime on a RP4.
Also Perry (@friolator) is right: Claude will probably give you a much better algorithm if you ask.
Even with the limited processing power of a Raspberry 4, and the limited frame rate of the HQ (maximum 10 fps at full resolution), I am using the image to determine the position of the sprocket and the film edge in the Tingopix project.
Due to the processing power limitations, I did not use OpenCV. It is all done with numpy arrays to find the hole and film edge in an area of interest slice. It is the measurement used to move the film (stop-motion).
In general, film is less translucid in UV, so the position is detected by using only the blue channel, at a cost of resolution.
mod_detector and mod_sprocket do the work from a raw capture.
@friolator, I understand the appeal of camera-based perforation detection. However, describing it as “easy and inexpensive” needs some context.
Felipe initially asked for feedback on a sensor. We don’t know enough about his requirements to conclude that image processing would be the simplest solution for him.
In Sasquatch, you describe an intermittent transport with a motorized capstan. The film advances, an image is captured, and the perforation position is then used to adjust the next advance. That approach suits this architecture. But for someone using continuous transport without a capstan, switching to that arrangement would require a substantial change.
OpenCV obviously requires neither a capstan nor intermittent motion. However, the detailed example you provide relies on those elements, which also contribute to the complexity and cost of the overall system.
For continuous motion, you mention your Raspberry Pi microfilm prototype and the possibility of adapting it to detect perforations. That is a credible idea, but in this discussion it remains a potential adaptation. You say yourself that getting the prototype working involved extensive testing and revisions. That work does not disappear because the library is free.
Thanks to cpixip and PM490 for sharing their code and examples. There are indeed concrete implementations. cpixip’s script demonstrates detection and image registration. Tingopix includes control of an intermittent transport. These examples show that the method works in those configurations.
I also see the advantage of using vision to change film gauges without moving a detector. A dedicated sensor, meanwhile, can provide a perforation-passage signal without adding image processing to the triggering chain.
In my view, these solutions therefore need to be compared in terms of the transport, camera, required scanning speed, and integration work. OpenCV is free. A complete solution still needs to be built around it. That distinction seems to be missing when the approach is summed up as “easy and inexpensive.”
I would argue the opposite. Doing it in software may involve a bit more development time, but it’s overall a less complex system because you’re not adding additional hardware, and that fact alone makes it more flexible, assuming your camera is getting a good image of the perfs. You can always go back and adjust, but if a sensor isn’t working for a given application, that’s a sensor sitting on the shelf.
It took extensive back and forth to get the scanner working. As in, having Claude do the whole thing. Getting it to recognize oddly positioned page of varying size and rotation took about 2 hours of back and forth. Perforations would probably take an hour with good prompting.
Good evening, everyone!
I’m really curious to see @cpixip algorithm, thanks for sharing!
It’s great that you touched on the subject of software detection because that’s my main issue right now (a fundamental one, I’d say). The initial design for my scanner was a 35mm continuous transport (though I always had the desire to make it all-format). From the beginning, I used OpenCV for detection (C++ for perforation detection and Python for image processing/scanner operation). I’ve heavily used LLM agents (currently using Gemini with Antigravity, haven’t tested Claude Code yet). I must confess, I’ve been constantly amazed by the ability to develop software with these tools.
It turns out I’m redesigning the scanner completely from scratch. I went back to Onshape and I’m working on the CADs right now (racking my brain over the gate at the moment). That’s when I thought: what if I try designing this gate with hardware detection, already factoring in the gauge adjustments (35mm, 16mm, 9.5mm, and 8mm)?
My main issue with perforation detection right now is this: I’m using a XIMEA MQ042MG-CM camera. I set an ROI over the perforation area, but I have to force the camera to run at high resolutions at a considerable frame rate (around 40fps) just to get a capture speed of about 3 to 6 fps. Faster than that, and the resulting capture is very unstable. The data throughput also gets massive (even running in RAW8 and doing the demosaicing via OpenCV). Inevitably, dropped frames happen, which somewhat ruins the perforation detection.
So I figured that using hardware for detection would ease the data processing load a bit (there is also the possibility that my algorithm is just trash lol). Having said that, I’ve always been a staunch defender of software-based perforation detection, but since I’m getting my hands dirty with the design again, I thought… why not? And maybe I could evaluate, as @Roland mentioned, which option is best. Who knows, maybe even use both together? Would there be a reason for that? Probably just a whim, lol.
The repo for the scanner’s algorithm (also known as miniola):
I’ll make a post soon to introduce and share the scanner parts here. 
Have a good night!
Oi Felipe, tudo bom?
While Tingopix is stop-motion capture (using the HQ module which has rolling shutter), there are some areas that translate to your project, particularly the orchestration, capture handling, and AOI slicing.
Orchestration is the key…
Tingopix is running simultaneously on a 4GB Rpi4 with a window refresh of about 7 fps (HQ maximum is 10fps):
But with stop motion… so saving the captures is not done in real time.
Hope it helps!
Yes, and in the specific case of an raspberry Pi camera, you can also run concurrent streams. In my Microfilm scanner, it’s running a low res greyscale video stream for the object detection. Then it does high res captures only when necessary. It’s able to run at a reasonable pace (capturing to a multi-page 4k TIF file).
At this stage of development, choosing the right system is crucial. It will determine how much time must be devoted to the project, its cost, its technical feasibility and, of course, the final image quality. With ChatGPT’s assistance in wording the text and designing the table, I have prepared a short comparison of the two possible systems.
| Criterion | Hardware laser detection | Software detection using an ROI |
|---|---|---|
| Current maximum speed | Up to approximately 20 fps | Approximately 6 fps |
| Detector positioning | Manual laser adjustment | Manual ROI adjustment |
| Film transport | Tolerates moderate speed variations, as each perforation triggers a capture | Requires a capstan to maintain sufficiently consistent film positioning |
| Mechanical complexity | Adjustable laser and receiver assembly | Capstan, motor, pressure system and speed control |
| Detection method | Direct and predictable | Dependent on the video stream and software processing |
| Image centring | Small deviations can be corrected through post-production stabilisation | Can be measured by the software and also corrected through stabilisation |
| Damaged perforations | Potentially less tolerant | Software can perform a more detailed analysis |
Advantages:
Can realistically reach the scanner’s maximum speed of 20 fps.
Each perforation directly triggers a capture.
The detection signal generates no image data stream.
Computing requirements are very low.
Synchronisation is stable and predictable.
Moderate variations in transport speed are acceptable.
Once the laser has been positioned, its mechanical adjustment is no longer restrictive.
Small image-centring errors can be corrected through post-production stabilisation.
Disadvantages:
Requires the initial design and adjustment of the laser system.
Provides no information about the complete shape and condition of each perforation.
Severely damaged, obstructed or deformed perforations may result in missed or incorrect triggers.
Advantages:
Only a small region of interest around the perforation needs to be analysed, limiting the data rate required for detection.
Provides more information about the shape, position and condition of each perforation.
May be more tolerant of partial or damaged perforations.
Detection thresholds and algorithms can be modified without changing the hardware.
In theory, the camera appears fast enough to support a higher scanning rate after substantial software optimisation.
Disadvantages:
The current implementation produces only approximately six final captures per second.
Detection is affected by camera readout time, buffering and processing latency.
Coordinating the detection ROI with full-resolution capture is complex.
The ROI must also be positioned manually.
A capstan is required to maintain accurate film positioning.
The capstan adds a motor, rollers, pressure adjustment and speed regulation.
Film slippage on the capstan can cause positioning errors.
Contact with the capstan introduces a small risk of scratching the film.
Reaching 20 fps remains theoretically possible but has not yet been demonstrated with the complete software pipeline.
The software solution is therefore not mechanically simple. In addition to positioning the detection ROI, it requires a capstan system to regulate film movement.
The capstan can improve transport stability and make the passage of the perforations more predictable. However, it also introduces additional mechanical design, motor control, pressure and tension adjustments, a risk of slippage, increased maintenance and additional contact with the film.
The laser system also requires an initial mechanical adjustment, but it directly detects the actual passage of each perforation. It is therefore less dependent on perfectly constant transport speed.
At the current stage of development:
The laser system can reach up to 20 fps and provides direct, predictable triggering, with relatively simple operation once adjusted.
The current software system reaches approximately 6 fps and requires both capstan-regulated transport and a more complex processing pipeline.
Software detection provides more information about each perforation and may handle damaged film more intelligently.
Post-production stabilisation reduces the significance of the software system’s theoretical advantage in image centring.
At this stage, hardware laser detection appears to be the faster, simpler and more robust solution. Software detection remains more flexible and potentially more informative, but reaching the same speed would require substantial further development and has not yet been demonstrated.
A couple things I’d point out on the cons for image-based perf sensing.
It doesn’t require a capstan. It just requires consistent tension. My microfilm scanner is just a feed and takeup reel, two spring-loaded dancer arms for tension (a magnetic rotation sensor on the shafts of the arms to measure position), and some rollers to line the film up with the gate. No capstan, just a feed motor and a takeup motor. works fine. The rotation sensors cost about $8 each, by the way, and work great as feedback for the motors to maintain consistent tension.
Speed is an issue only if you have a slow camera. For the Raspberry Pi cam, those numbers look about right, but other cameras would potentially give you much more speed along with higher quality.
I don’t understand why you’d need manual ROI adjustment. Again, object detection is a well understood problem. The perf is an object, the edges of the film are an object, the frame with the picture is an object. detecting those is done well even on a rolling shutter camera moving at a reasonable pace. There’s no need to do anything manual beyond the initial setup.
I get that you don’t like the idea, but all the professional scanners at this point do it this way, and that’s for a reason. It really works well, and it doesn’t require different lasers for different gauges, or manually repositioning the laser when you change gauges. It’s fewer mechanical and electronic parts to manage, because for most systems it’s just built into the camera and/or frame grabber driver.
Thank you for these clarifications.
I note that your microfilm scanner has no capstan.
The object-recognition approach appeals to me. I’ve actually already used OpenCV in two of my own applications. But designing a scanner built on image recognition requires considerably harder skills to acquire, and the software tuning is more delicate — all the more so on a multiformat device.
Nor is it a matter of saving on components: where you have two servo-controlled arms, I have a single laser detector.
What would happen if your scanner became multiformat ? Would you use the same image frame for Super 8 as for 35 mm? and for 9.5mm ?
That, it seems to me, is where you’re generalizing a bit too quickly.
Positioning the laser takes five seconds, even if you’re clumsy about it. And it’s just as inaccurate to claim you’d need several lasers depending on the format: one is enough.
Not really. Again, try Claude Code. design and build the hardware frame the way you want it. Take good pictures, or provide CAD drawings in an image format it can read. Provide the specific model numbers of the sensors you’re using and make sure they’re working correctly with the Pi. Same with the motors/drivers. Make sure you’re clear about what is supposed to happen and let Claude have at it. Honestly, I had the microfilm scanner up and running in a week using the free version, and that included making design decisions and changes on the fly and iterating the code many times. And that was almost a year ago. The quality of the code it produces now is significantly better. And if you’re working in something like Python, it can even sandbox its own testing and simulations before presenting code to you, so you’re more likely to get something that just works early on, as long as you’re succinct in your prompts and you keep it focused.
They’re not servo controlled arms. The feed and takeup spools each have a motor behind them, yes. But the tension arms are just a shaft on bearings, a spring, and a metal arm that extends off one end of the shaft. That arm has a roller on it that the film goes around. On the other side of the shaft is a 3D printed frame that holds a cheap magnetic rotation sensor. On the end of the shaft itself is a 3D printed sleeve to hold the tiny magnet the sensor uses. When the arm is pulled in one direction or another, the rotation is picked up by the sensor and sent back to a raspberry pi via i2c. It’s actually quite a simple setup. The feed and takeup motors just have their speeds adjusted based on the tension arm positions. The goal is to keep the arms vertically down, If they pull inwards towards the center, there’s too much tension so you slow the takeup motor to allow it to center. If it’s too far to the outside, there’s not enough tension, so you do the opposite.
You need to teach it where the correct locations are, but claude built a shell script to do that, prompting you to hold the arm in the “normal,” “too taut,” and “too loose” positions, while recording what those positions are. it generated a config file with that, which the motor control software uses. These are machine specific settings, but really only need to be set up once.
You set up configurations for each gauge. When you tell it you’ve loaded 16mm the software would load the appropriate config file, which enumerates approximately where the perfs are expected to be found. Or if you used machine learning to “teach” the perfs to the machine, you’d have to do that for each film guage. but that’s a thing you do once, not every time you use the machine.
How so? As far as I’m aware, the following scanners all use machine vision:
That’s pretty much the whole list of high end scanners currently being manufactured.
I wasn’t saying you’d need multiple scanners. I was saying that two ways to do it would be to move the sensor depending on the gauge, or to have fixed sensors in position for different gauges, and only enable the one you’re currently using.
Unfortunately, once again you are generalising a bit too quickly. I asked Claude to draw up a list of how the scanners on the market work. You made some mistakes in your list, but that doesn’t matter, you may also find a few mistakes in the one Claude produced.
Let’s each stick to our own position: yours, which favours “object” recognition, simple and easy to implement, and mine, which favours laser recognition, simple and easy to implement.
| Brand | Model | Position detection |
|---|---|---|
| Lasergraphics | Archivist | Main imaging camera (perforations in overscan) |
| Lasergraphics | ScanStation | Main imaging camera (perforations in overscan) |
| Lasergraphics | Director | Main imaging camera (perforations in overscan) |
| Blackmagic Design | Cintel G3 HDR+ | Mechanical (servo encoder, capstan or sprocket wheel), software correction afterwards |
| DFT | Scanity HDR | Mixed: dedicated perforation camera + tacho wheel |
| DFT | Polar HQ | Optical perforation sensor, separate from imaging camera |
| ARRI | Arriscan XT | Mixed: mechanical pin, or main imaging camera in pinless mode |
| DCS | Xena | Main imaging camera (Dynamic Perf), pin option |
| Reflex Technologies | Reflex scanner | Laser perforation sensor |
| Digital Vision | Golden Eye 4 | Separate “technical” camera |
| Filmfabriek | HDS+ | Optical perforation sensor (LED cell) |
| Filmfabriek | Pictor / Pictor Pro | Mechanical (toothed idler wheel) |
| Kinetta | Archival Scanner | Non-contact optical perforation sensor |
| MWA Nova | Spinner S2 | Optical light barrier + shaft encoder |
| MWA Nova | flashscan Nova | Optical light barrier + shaft encoder |
| MWA | flashscan HD / Choice / Vario | Optical light barrier + capstan encoder |
| CUImaging | Axion | Optical fibre scatter-light sensor (non-laser) |
| FilmLight | Northlight | Mechanical (sprockets + registration pins) |
I don’t really want to get in an argument about this, but that summary is full of mistakes.
