Speed up vision acquisition time by cutting processing load

A snapshot that takes two seconds when the robot budget allows 300 ms gets blamed on the camera first, then on the detection threshold taught last month. Neither is the lever. This guide is for integrators and line engineers wiring a vision sensor or smart camera to a robot, a conveyor or a fixture. It separates the three stages behind trigger-to-result time, puts arithmetic on each, and works through the four levers that shorten a vision cycle — background, parts per frame, light stability and pixel count — with a decision for each case.

What sets the time from trigger to result?

Three stages add up — exposure, transfer and processing — and with 1-10 ms of exposure and 15-45 ms of transfer at GigE speeds, nine tenths or more of a slow snapshot is the processing stage.

Exposure you set from motion or from light. A still part under a bright or strobed light needs single-digit milliseconds. A moving part sets its own ceiling: keep blur inside a third of a pixel and the belt speed hands you the exposure.

At 100 mm/s belt speed and 0.21 mm pixels — a 1.6 MP camera over a 300 mm field — that allows 1000 × 0.21 / 300 ≈ 0.7 ms. The moving-part case, worked end to end, is in exposure time vs shutter speed for moving-part inspection.

Transfer is bytes over the link. An 8-bit mono frame costs one byte per pixel, so a 1.6 MP frame is 1.6 MB and a 5 MP frame is 5 MB. Practical GigE throughput sits near 110 MB/s, which puts those two frames at about 15 ms and 45 ms of pure transfer.

Processing is everything between frame received and result returned: preprocessing, candidate search, verification, pose sorting. That is the stage the four levers act on. What counts as fast enough on an on-device camera is its own worked question in smart camera image processing time: what is fast enough, and the same gap watched as frame rate instead of single-shot time is what acquisition faster than processing: fix the frame rate gap diagnoses.

Does raising the detection threshold speed up acquisition?

No. The score threshold is a filter applied after the search, and the search cost is already spent: the coarse pass still visits every position it flagged, so a higher threshold removes false accepts while the milliseconds stay put.

Most matchers run coarse to fine. The coarse pass sweeps the search region and flags every position whose feature signature resembles the template; the fine pass verifies each flag and scores it. The threshold you set during teaching acts on that score — it decides what counts as found, not how much got searched. Where scores come from and where to set them is covered in pattern match score threshold: the coarse search gates the result.

So leave the threshold at the level that holds your false accepts, and attack the flag count instead. The next two sections are the two sources of flags.

How much processing time does the background add?

Every edge, hole and printed mark inside the search region becomes a flag the coarse pass must test, so a feature-rich background can hold ten times the candidates of the part itself — and coarse-search work grows with that count.

The arithmetic is proportional, and you can measure it on your own station. Point at the strongest feature clusters in a live image: if nine of the ten strongest sit on the background, the background holds about nine tenths of the coarse tests, and replacing it removes about nine tenths of that stage's work. The ratio is an illustrative model rather than a vendor figure; the direction is not in dispute, and it is why a mat outperforms any threshold tweak.

The fixes are physical. Mount a matte, uniform mat. Keep ribs, grids, perforations and printed scale out of the field. Then shrink the region itself to the drop zone: pattern matching low fps: shrink the search to speed the update rate works that lever, and 2D vs 3D camera ROI: where to set it and which one wins covers the placement decision.

Why do more parts in the frame slow the snapshot down?

Each extra part brings its own candidates, its own verification and its own pose to sort, so a frame holding 8 loose parts can cost close to 8 times the matching work of the same part presented alone.

When cycle time matters, hold one to three targets per snapshot. Past that, staging beats one wide shot: two or three short shots on a staged mat return poses the robot can already act on, while one cluttered wide frame makes every pick wait for every part. Sort time grows too, because N matches means N poses to rank against your pick logic.

A bin of loose parts is the exception that proves the budget: the cost is real, so either stage the bin in layers or move the task to an approach built for clutter — 3D bin picking for flat parts: choosing a vision approach lays out the choices.

Does unstable ambient light really change processing time?

Yes. Flickering overheads and shifting daylight change the image from frame to frame, so contrast normalisation and edge maps move under the matcher and the search burns retries before it settles; stable light returns near-identical frames, and a near-identical frame converges in one pass.

Three fixes hold the image constant. Shield the station: a hood around the cell beats any software gain. Fix the exposure instead of letting auto exposure hunt — when the auto-exposure window overlaps your part, the feedback loop drags the whole image up and down, which is the failure auto exposure ROI instability dissects. And strobe: a flash of fixed energy at a fixed exposure swamps the ambient and freezes motion in the same shot. The driver side of that wiring is in integrated strobe drivers in machine vision lights: what they change, and the machine vision lights finder filters for strobe-ready models.

Where some variation survives, switch the matcher to edges: edge-based matching holds its result across contrast shifts far better than grayscale correlation, as edge based pattern matching for stable results when lighting changes shows. Pick-and-place cells get the fuller treatment in ambient light variation in pick and place vision: control it.

How many pixels does the inspection actually need?

The smallest feature sets the count: keep 3-5 pixels across it for detection, so a 1 mm feature over a 300 mm field needs about 5 px/mm — a 1.6 MP sensor just meets that, and a 5 MP sensor buys 3.1 times the pixels to transfer and filter.

Work the numbers for a 300 mm wide field and a 1 mm feature to catch:

A 1.6 MP frame spans about 1440 pixels: 1440 / 300 = 4.8 px/mm, so a 1 mm feature holds 4.8 pixels — inside the 3-5 pixel detection rule. A 5 MP frame spans about 2448: 2448 / 300 = 8.2 px/mm, which is 8 pixels across the same feature and 3.1 times the data — 5 MB instead of 1.6 MB per mono frame, roughly 45 ms instead of 15 ms of transfer at 110 MB/s, and 3.1 times the per-pixel filtering on every image. For measurement rather than detection the rule tightens to 10 or more pixels per feature, which is when those extra megapixels pay.

Check your own feature and field against the calculator:

The coarser end pays the same way. A 640 × 480 frame over a 240 mm field gives 640 / 240 = 2.7 px/mm, which places 8 pixels across a 3 mm feature — comfortably inside detection. For that job the sensor needs no headroom at all. The MV-SCA002M-03S-WBN-SR pairs a 3 mm lens with a 0.3 MP sensor and holds focus at 240 mm.

For the 1 mm job, the 1.6 MP class is the match: it holds the 5-pixel rule and keeps transfer near 15 ms. Both sensors below carry 1.6 MP with a global shutter over Fast Ethernet — the HK-TD032-12-WBN reads mono, while the MV-SCB007EC-12S-WBN adds a 12 mm manual-focus lens and color.

A 0.4 mm feature in the same 300 mm field is where 5 MP earns its data cost: 8.2 px/mm × 0.4 mm gives 3.3 pixels across the feature, which the 1.6 MP frame cannot hold. The MV-SC3050XC-16M-ATN-H covers that bar with a 5 MP color sensor, a global shutter and an M12 mount over Fast Ethernet.

When should you move processing off the camera?

Move up to a vision controller when the cleaned scene still misses the cycle: genuine multi-part scenes, mixed trays and multi-camera cells need compute and memory an on-device sensor does not carry, and a controller also drives the lights and merges several cameras into one result.

What the box changes: processor class and memory for matching and classification, several camera ports so two or four cameras feed one controller, built-in light channels so strobing needs no separate driver, and PoE variants that power cameras over the data cable. What it does not change: the scene. No controller rescues a feature-rich background or a drifting exposure — apply the four rules first, then size the hardware.

A typical single-station load is two GigE cameras plus strobed lights. The MV-VC3301H-128G66 carries that on an Intel Core i3 with 8 GB of memory, 5+ LAN ports and 4 built-in light channels, with the runtime license included.

Keep the link budget in the same calculation: a 6 MP mono frame is 6 MB, about 55 ms of transfer at 110 MB/s, per camera per cycle. The MV-SC5060XM-08M-WBN is a 6 MP mono smart camera with an 8 mm lens on an M12 mount, made for a stationary presentation where shape is the feature and every pixel works.

What do you check before re-teaching the scene?

Re-time with a three-timestamp log — trigger sent, frame received, result returned — and change one lever at a time, because a background swap that moves the second gap but not the first is doing exactly its job.

Run the checks in order; each removes a named cost.

• Swap the backdrop for a matte, uniform mat. Every background feature cluster removed is coarse-search work removed at the source.
• Mask the region down to the drop zone. The coarse pass then sweeps only area the robot can use.
• Count the targets per frame. Above three, stage them — candidate count grows with every part in view.
• Fix the exposure and strobe or shield. Identical frames converge in one pass and stop motion from costing pixels.
• Recompute the pixel budget: smallest feature × 5 pixels against field width. No larger sensor than the math calls for.
• Log trigger, frame and result timestamps before and after each change. The two gaps tell you which lever moved.

The decisions, per case. A stationary part, 1 mm feature, 300 mm field: 1.6 MP mono, mat, masked region, fixed exposure — one part per frame lands well under a second end to end. A part moving at 100 mm/s: the same scene plus a strobe at about 0.7 ms exposure. A bin or mixed tray: clean what you can, stage in layers, then move the remainder onto a controller sized to the camera count — and when the pose needs depth, the 3D guides above cover the hand-off.

Camera-side parts for these cases sit in the smart cameras range and controller-side parts in vision controllers; the camera finder filters by resolution, shutter and interface directly. More diagnosis guides on the systems side are gathered on the systems topic page, and if a scene resists all four levers, bring the layout to us through the contact page.