Line crossing object counting: how crossing detection works

A line-crossing counter tallies each object once, at the moment its tracked centre crosses a line you draw in the image. Detect, track, test the line: that three-stage pipeline sits behind conveyor out-feed tallies, door and aisle traffic counts, vehicle counts and reject confirmation, and it runs on a vision sensor with no PC attached. This guide explains the part that decides whether the number is trustworthy: the signed-distance test, its hysteresis band and the one-shot latch behind it. It also works the sizing arithmetic — pixels per object, pixels per frame, exposure — and lists the failure modes behind double and missed counts.

What a crossing counter counts

A single-frame count answers a different question: how many objects are in the image right now. You segment one frame and count the blobs, as in counting rod-shaped objects in a single frame. That method breaks on flow: a part present across several frames is counted once when it should be many, or once per frame it appears in. Throughput questions need time, not a snapshot.

A crossing counter tracks every object and counts an event instead. Each object carries a track ID from first detection to exit; the counter increments when that track's centroid passes the line, exactly once per ID. What the object does afterwards — slow down, pause, shuffle — changes nothing, because the latch has already fired.

Counters are partitioned per line and per class, so one camera can watch a main line and a reject line and file boxes and rejects into separate tallies. Typical uses: out-feed counts on conveyors, parcels confirmed into a chute, people through a doorway, vehicles in a lane, parts past a diverter.

Detect, track, then test the line

Everything hangs off three stages, and the middle one is where counters usually go wrong.

1. Detect. Every frame returns objects: boxes from a trained detector or blobs from thresholding, each with a class and a centroid. Getting stable centroids from contours is its own small craft — see OpenCV contour coordinates to x and y arrays.
2. Track. Associate detections across frames so each object keeps one ID. Nearest-centroid matching holds while objects move less than about half their own pixel width per frame; dense scenes need an assignment step that weighs all pairs, not just the nearest neighbour. The output is a stream of ID, centroid and class per frame — segmentation and tracking from a machine-vision cell shows what that stream looks like in practice.
3. Test. For each track and each line, compute the signed distance from centroid to line and run the state machine in the next section.

One gate sits before the test: a track must be seen in 3 consecutive frames before it may arm. Detector flicker throws one-frame phantoms; without the gate, glare and vibration write phantom counts all shift long.

The crossing test: signed distance and hysteresis

Draw the line, fix the travel direction, and the geometry reduces to one number per track per frame: the signed distance from centroid to line, in pixels.

Each track walks four states per line: new, confirmed after 3 detections, armed once its centroid sits more than h pixels on the origin side, fired when it reaches more than h pixels on the far side. The increment lives in the fired transition only.

The band h exists because a centroid jitters 1-2 px between frames from segmentation noise. A bare sign test at s = 0 toggles with that noise, and an object pausing on the line is counted by every toggle. A band of 3 px on each side covers the jitter for a cleanly lit 20 px object; move to 5 px when silhouettes flicker — shiny parts, thin edges, distant targets. The band only has to beat the jitter, so it tracks your segmentation quality, not the object size.

The count is an edge event, not a level. It is the same discipline as a rising-edge counter written in structured text on a PLC: increment on the transition, never while the condition holds.

Test the centroid, not the bounding-box edge. The box re-fits every frame and can wash back and forth across the line; the centroid of a passing object advances monotonically. When objects can legitimately recross — a person stepping back through a doorway — re-arm only after the centroid returns past the far band, and keep an IN and an OUT counter rather than one net number. And because a centroid that lands inside one pixel sits on either side of your line in arithmetic terms, the half-pixel convention in blob centroid coordinates decides that edge case: pick one convention and keep it.

Sizing the camera: pixels per object, pixels per frame, exposure

Three pixel requirements size the station, and all three hang off one scale factor: p, the millimetres per pixel at the line.

Size for 15-20 px across the smallest object: below that, detectors stop holding stable IDs and jitter approaches the object's own width. Keep travel under about a third of the object width per frame, so the tracker sees it at least 3 times before the line. Cap exposure at p / v so blur stays inside one pixel and the centroid stays honest.

That 480 mm field comes from focal length and working distance in the usual way:

Check your own pixel budget before shortlisting hardware:

Placing the line and aiming the camera

Put the line in the middle third of the field of view. The track needs history before it can arm: confirmation costs 3 frames × 6.7 px ≈ 20 px ≈ 50 mm of travel at the belt example. A centred line leaves about 96 px — roughly 14 frames at 30 fps — of confirmed track before the crossing, so even a late first detection counts.

Aim square to the travel direction and shoot from above where you can. Overhead views stop objects occluding each other at the line and keep scale uniform across it. A tilted camera makes mm per pixel vary with depth: your p, and with it the frame-rate and exposure numbers, is then exact at one distance only.

Calibrate p against something known in the scene — a ruler laid across the belt, a part of known width. The inverse problem, reading a distance from a known pixel width, is worked in camera distance from a tape line's pixel width; same geometry, solved backwards.

Keep lines out of the outer few percent of the frame, where lens distortion moves centroids most.

Where counts go wrong, and the fix

Nearly every miscount is one of six failures:

Shutter type is the last hardware-level cause. A rolling shutter reads rows in sequence, so a fast object leans within its frame; the skew stays inside the band for slow traffic but, at tens of pixels per frame, distorts the detection itself. Fast lines get a global shutter; slow lines run either type.

Hardware for a counting station

A single line and one or two classes need no PC. The MV-SCB007EC-12S-WBN combines a 1/2.9" global-shutter sensor, a fixed 12 mm lens and Fast Ethernet: the hardware list is one cable.

When classes separate by colour rather than shape, or you want several lines and the lighting built in, use a smart camera with a global shutter. The MV-SC6050C-08M-XBN pairs a 5 MP colour global-shutter sensor with an integrated multi-colour light source on GigE.

Multi-camera tallies, footage retention and heavier models belong on a PC. The area scan cameras category covers the sensor side — the MV-CU020-90GC brings a 2.5 MP colour global-shutter sensor in 1/1.7" format to a C-mount on GigE — while the vision controllers category covers the compute side. The MV-VC2140-128G40-1T contributes an Intel N-series processor, 8 GB memory, a 128 GB SSD plus 1 TB HDD, three to four LAN ports and four built-in light channels.

For the algorithm-in-camera route, browse smart cameras; to run counting alongside locating and code reading in one controller, start at the camera step of the system configurator.

Checks before you trust the number

• Record the worst five minutes — fastest belt, densest spacing, worst light — and replay them through the counter against a manual tally. They must agree exactly; every disagreement is a bug with an address.
• Repeat the replay per product and per light level, and score it per condition: per-condition generalisation checks for detection models show which condition breaks before production does.
• Watch the last-crossing timestamps, not just the total: strictly increasing, one timestamp per increment, and an interval distribution that matches your part flow.
• Reset counters at batch and shift boundaries — the per-batch counter reset pattern keeps every total attributable to a window — and log each reset.
• After any change of lens, zoom or camera height, re-derive p, exposure and pixels per frame; the line position is the only part of the set-up you may carry over unchanged.

From here it is four lines of arithmetic: belt speed and smallest part give p, f and t_exp, and the camera finder turns them into a shortlist. The applications topic hub collects the neighbouring set-ups — conveyors, tracking, sizing — when counting is one station among several.