FPS Targets and How to Derive Them From Line Rate

The required frames-per-second is not a sales-deck number. It is a derived calculation from line rate, captures-per-part, and timing margin.

required_fps = parts_per_minute / 60  *  captures_per_part  *  timing_margin

Example 1 — automotive component, 60 ppm, single capture per part, 1.5x margin:
  required_fps = 60/60 * 1 * 1.5 = 1.5 fps  (almost any camera works)

Example 2 — pharma blister pack, 400 ppm, 2 captures per part, 1.5x margin:
  required_fps = 400/60 * 2 * 1.5 = 20 fps

Example 3 — PCB SMT line, 80,000 components/hr, 1 capture per component, 1.5x margin:
  required_fps = 80000/3600 * 1 * 1.5 = 33 fps

Example 4 — continuous web inspection, 5 m/s line speed,
            10 mm capture height per frame, 1.5x margin:
  required_fps = (5000 mm/s / 10 mm) * 1.5 = 750 fps  (line scan, not area scan)

The 1.5x timing margin absorbs jitter from network, host scheduling, and occasional model-call slowdowns. Designs without margin run at the edge of capacity and miss frames during garbage-collection pauses or transient network slowdowns. Margins below 1.3x are dangerous; margins above 2x are wasteful but not harmful.

For continuous-web applications above ~50 fps area-scan limits, the answer is a line-scan camera at 50-100 kHz line rate, which converts the throughput problem to a different mathematical regime.

The False-Positive Problem

A model that calls 99% of defects correctly is a great spec-sheet number. A model that flags 5% of good parts as defective on a 60 ppm line is generating 180 false rejects per hour. Within a shift, the operator either disengages with the alerts, bypasses the reject station, or asks the engineering team to disable the model. False-positive tuning is therefore not a polish step. It is what determines whether the system stays running.

The four levers that move false-positive rate down without giving up recall:

1. Threshold calibration on the score distribution. Plot the model's confidence score for known-good and known-defect held-out images. Set the operating threshold at the intersection that hits the FNR target, not at the default 0.5. Mature deployments use a two-threshold system: a high-confidence "definite defect" threshold that triggers reject and a lower "review" threshold that flags for human override.
2. Per-class thresholding. Different defect classes have different score distributions. A single global threshold leaves accuracy on the table. Per-class thresholds tuned on validation data are standard practice in production AVI.
3. Hard-negative mining. Every operator override of a false-positive is a labelled training example. Pipe these back into the retraining set with explicit negative weighting so the next model version sees the same image and learns it is a good part. This single feedback loop drops FPR more than any other intervention.
4. Multi-frame voting. If the inspection geometry allows multiple captures of the same part (e.g. on a rotating fixture, or from multiple cameras), require N-of-M positive calls before triggering reject. Independent failure modes statistically multiply, dropping FPR by orders of magnitude with minimal recall cost.

A typical mature deployment runs at 0.5-2% false-positive rate at the chosen recall target. Below 0.5% you are usually leaving recall on the table; above 2% you are creating operator friction that erodes adoption.

Anomaly Detection Versus Classification for Real-Time AVI

The choice between anomaly detection (PaDiM, PatchCore, EfficientAD, FastFlow) and supervised classification matters for the false-positive profile.

• Supervised classification learns the visual signature of each labelled defect class. Requires meaningful labelled-defect volume per class. Tends to undergeneralise to defect types it has never seen.
• Anomaly detection learns only what good parts look like and flags anything that deviates. Requires very few defect examples. Tends to overgeneralise and fire on benign variation (lighting drift, dust on the lens, conveyor wear marks).

The pragmatic choice in 2026 is a hybrid: anomaly detection as the first-pass filter (high sensitivity, accept the wider FPR) followed by a supervised classifier on the regions flagged as anomalous. The classifier confirms or rejects the anomaly call, dropping the effective FPR while preserving the wide-class coverage of anomaly detection.

Operationalising the Real-Time Pipeline

A pilot that hits real-time on a clean lab bench is not the same as a system that holds real-time across a 12-month production run. The operational bar that separates pilots from production deployments:

• Watchdog and heartbeat — the inference host emits a heartbeat to the PLC; if it stops, the line stops or falls back to manual inspection. No silent failures.
• Per-station SLOs — uptime (target 99.5%+), p99 inference latency (under 50 ms), false-positive rate (within budget), and false-negative rate (validated weekly against a sampled audit).
• Automated retraining cadence — monthly retrain with the previous month's overrides and new defect examples. Validate on a frozen test set before production promotion.
• Canary deployment — new model versions run in shadow on a single station for 24-72 hours before full rollout. Rollback path is one config change.

How Opsio Helps

Opsio's MLOps and edge-engineering teams build real-time AVI systems that hold latency, accuracy, and false-positive budgets across production runs. We deploy on Jetson Orin and industrial GPU PCs, optimise with TensorRT and INT8 quantisation, and surround the inference host with the watchdog, heartbeat, and retraining infrastructure that keeps the system trustworthy long after the pilot phase. Customers planning vision-AI programmes typically engage through our cluster pillar at AI visual inspection services, with related capabilities in MLOps consulting for the retraining infrastructure and IoT predictive maintenance for the broader edge-AI estate that vision is one node in.