A detector that scores 0.94 mAP in the lab and starts throwing false rejects on the conveyor is not one problem. It is a pipeline with five distinct stages, and each one fails differently. The team that can name which stage broke fixes it in hours; the team treating detection as a single box re-trains blind and hopes. That is the core of what goes wrong when “image processing” and “object detection” get collapsed into one phrase. On an inspection line, they are not the same thing, and the boundary between them is exactly where most diagnostic time gets lost. Understanding where localisation ends and defect classification begins is what lets you tell a lighting problem apart from a model problem when accuracy drops. How does image processing object detection work in practice? Feed frames in, get bounding boxes out — that is the mental model most teams start with. It is not wrong so much as it is incomplete, and the incompleteness is precisely what bites you in production. A working inspection system is a sequence of stages, and the frames that reach the neural network have already been through several transformations that determine whether detection can succeed at all. The useful frame is to treat the whole thing as a pipeline: acquisition, pre-processing, detection and localisation, classification, and decision logic. Each stage takes the output of the one before it and can degrade independently. A pre-trained YOLO checkpoint plus a confidence threshold covers exactly two of those five stages. The other three are where lab performance and line performance diverge. This is not an academic distinction. When a team can attribute a regression to a specific stage — the camera exposure drifted, the part-presence gate mis-fired, the classifier confused two defect classes — they skip the expensive default of re-labelling data and re-training a model that was never the problem. We see this pattern regularly: the model is fine, the frames it is being fed are not. The five stages of an object-detection pipeline for industrial inspection Here is the pipeline broken into the stages that fail independently, with what each one owns and how it degrades. Stage What it does Typical failure signature What you tune Acquisition Camera, lens, lighting, trigger capture the frame Motion blur, exposure drift, glare, missed triggers Shutter, lighting geometry, trigger timing Pre-processing Resize, normalise, colour-convert, ROI crop, contrast Wrong input scale, clipped highlights, ROI misalignment Resolution, normalisation stats, crop bounds Detection / localisation Find where objects/regions are; emit boxes Missed parts, duplicate boxes, poor box fit Model, anchors, NMS threshold, input size Classification Decide what each localised region is Class confusion, defect-vs-nominal mistakes Class balance, decision threshold, head fine-tune Decision logic Turn detections into accept/reject verdict Over-rejection, missed escapes, unstable gating Reject rules, aggregation, hysteresis The value of the table is not the rows themselves — it is that a symptom on the line maps to a stage. False rejects climbing overnight after nothing changed in the model points at acquisition (lighting cycled, a lens fogged) far more often than it points at the network. If your monitoring only reports “accuracy dropped,” you cannot make that call. The production-ai-monitoring harness exists to instrument each stage so a regression is attributable rather than a mystery. What is the difference between localisation, classification, and defect detection? These three get used interchangeably and they are not the same operation. Localisation answers where. It emits a bounding box (or a mask) around a region of interest without necessarily saying what it is. On an inspection line, this is often “find the part in the frame” — a prerequisite, not the inspection itself. Classification answers what. Given a localised region, it assigns a label: which part variant, or nominal-versus-defective. A detector like YOLO fuses localisation and classification into one forward pass, which is efficient but also means a failure in one can masquerade as a failure in the other. Defect detection is a task, not a stage. It is usually built on top of localisation and classification — sometimes as a fine-grained classifier over a localised part, sometimes as anomaly scoring against a nominal reference. The reason this matters: a detector can localise every part perfectly and still miss the scratch, because the scratch is a classification-scale problem, not a localisation-scale one. Teams that conflate the two try to fix a missed-defect problem by re-training the box regressor. It does not move the number. If you are choosing an architecture around this boundary, the trade-offs differ sharply between one-shot detectors and region-proposal families — we cover that split in how an image detection model works in industrial inspection, and the segmentation alternative in instance segmentation models for manufacturing inspection. Which pre-processing steps most affect detection accuracy on the line? Pre-processing is the stage teams underweight most, because in a notebook it is a one-liner. On a production line it is where lab-to-line drift concentrates. The steps that move accuracy the most, in rough order of impact we have observed across inspection engagements (an observed pattern across deployments, not a benchmarked ranking): Input resolution and resize policy. A detector trained at 640×640 and fed letterboxed 1280×1024 frames at inference will localise small defects worse than the lab numbers suggest. The defect that occupied 30 pixels in training now occupies 12. Normalisation statistics. If the mean/std used at inference does not match training, the network sees a distribution it was never optimised on. This degrades silently — no error, just quieter confidence scores. ROI cropping and part-presence gating. Cropping to the part before detection reduces background clutter and stabilises class scores. A misaligned crop, on the other hand, clips the defect-prone edge and manufactures false negatives. Illumination normalisation. Lighting on a conveyor is not constant. Contrast and white-balance correction in pre-processing absorbs some of that drift; skipping it pushes the variance onto the model, which is the harder place to absorb it. The general rule: every pixel the network sees has already been decided by pre-processing. When detection accuracy drops and the model weights have not changed, pre-processing and acquisition are the first two suspects, in that order. How do you tell an image-processing problem from a model problem? This is the question that separates a two-hour diagnosis from a two-week one. The instinct when precision or recall falls is to re-train. That is often the most expensive possible first move, because it assumes the model without checking the frames. A stage-isolation checklist we use before touching model weights: Freeze a sample of the exact frames the model saw at the failure. Not fresh captures — the actual pre-processed tensors. Most “model” regressions vanish here, because the frames are visibly wrong (blur, glare, wrong scale). Compare acquisition metadata against a known-good baseline. Exposure, gain, trigger latency. Acquisition drift is silent and common — a fogged lens or a lighting ballast cycling shows up here, not in the loss curve. Replay known-good frames through the current pipeline. If yesterday’s good frames now fail, the model or its runtime changed. If they still pass, the input distribution moved — an acquisition or pre-processing problem. Separate localisation error from classification error. Are parts being missed entirely (localisation) or found and mislabelled (classification)? These have different fixes and re-training the whole detector addresses neither cleanly. Only then consider the model. If frames are clean, baseline frames replay correctly, and the failure is genuinely class confusion on in-distribution parts, that is a model or data problem worth re-training for. Skipping to step 5 is the default mistake. The pipeline view is what makes steps 1 through 4 possible — you cannot isolate a failure to a stage you have not named. When defect detection is genuinely the weak link and fine-tuning is warranted, fine-tuning YOLO for line defect detection covers what that actually fixes and what it does not. How does inspection detection differ from generic object-detection benchmarks? A model that tops COCO is optimised for a task that barely resembles inspection. Generic benchmarks reward detecting many object classes across wildly varied scenes at moderate localisation precision. An inspection line is the opposite: a tiny number of classes, a fixed and controlled scene, and defects that are often small, low-contrast, and rare. The consequence is that benchmark leaderboard rank predicts inspection performance poorly. The computer vision practice we build around inspection optimises for the metrics the line actually cares about — recall on the specific defect classes that matter, and a false-reject rate that does not strangle throughput — not for average precision across 80 categories most lines will never see. There is also the real-time constraint. Generic benchmarks report accuracy offline; a line needs a verdict inside the part’s dwell time under the conveyor. How that constraint reshapes architecture and pre-processing choices is covered in real-time object detection on the production line. What metrics matter when false rejects gate throughput? mAP is the number everyone quotes and it is the wrong number to optimise alone for a production line. The operationally relevant measures are: Recall on the defect classes that matter — a missed defect is an escape, the expensive failure. False-reject rate — because every false reject pulls a good part off the line, and at volume this directly gates throughput and operator trust. Time-to-diagnose — how fast a regression can be attributed to a stage, which the pipeline view is designed to shorten. The tension between recall and false-reject rate is the real design axis, and it is not captured by a single aggregate score. What the aggregate metrics do and do not tell you is worth understanding in its own right — what mAP@50 means for defect detection unpacks the most commonly misread one. FAQ What should you know about image processing object detection in practice? It works as a pipeline, not a single black box: acquisition captures the frame, pre-processing conditions it, a detection stage localises regions, a classification stage labels them, and decision logic turns detections into an accept/reject verdict. In practice, “feed frames in, get boxes out” hides three of those five stages — and those three are where lab performance and line performance diverge. What are the distinct stages of an object-detection pipeline for industrial inspection? Five: acquisition (camera, lens, lighting, trigger), pre-processing (resize, normalise, crop), detection/localisation (find where regions are), classification (decide what each region is), and decision logic (turn detections into a verdict). Each stage takes the previous stage’s output and can degrade independently, which is why a symptom on the line maps to a specific stage. What is the difference between localisation, classification, and defect detection? Localisation answers where (it emits a box or mask around a region), classification answers what (it labels a localised region), and defect detection is a task built on top of both — often a fine-grained classifier or anomaly score over a localised part. A detector can localise every part perfectly and still miss a scratch, because the scratch is a classification-scale problem, not a localisation one. Which image pre-processing steps most affect detection accuracy on a production line? Input resolution and resize policy, normalisation statistics, ROI cropping and part-presence gating, and illumination normalisation, in roughly that order of observed impact. Every pixel the network sees is decided by pre-processing, so when accuracy drops and model weights have not changed, pre-processing and acquisition are the first two suspects. How do you tell whether a detection failure is an image-processing problem or a model problem? Freeze the exact frames the model saw at the failure and look at them; compare acquisition metadata to a known-good baseline; replay known-good frames through the current pipeline. If yesterday’s good frames now fail, the model or runtime changed; if they still pass, the input distribution moved. Only after clearing frames, acquisition, and pre-processing is re-training the right move. How does object detection for inspection differ from generic object detection benchmarks? Generic benchmarks reward detecting many classes across varied scenes at moderate precision; an inspection line has a few classes, a fixed controlled scene, and small, rare, low-contrast defects — plus a real-time dwell-time constraint benchmarks ignore. Leaderboard rank predicts inspection performance poorly, so you optimise for defect-class recall and false-reject rate, not average precision across categories the line will never see. What metrics matter for object detection when false rejects gate line throughput? Recall on the defect classes that matter (a miss is an escape), false-reject rate (every false reject pulls a good part off the line and gates throughput), and time-to-diagnose (how fast a regression is attributed to a stage). The tension between recall and false-reject rate is the real design axis, and no single aggregate score like mAP captures it. Where this leaves the evaluation If you take one thing from the pipeline view, make it this: the next time inspection accuracy drops on the line, resist the pull to re-train first. Name the stage. Was it a frame the camera should never have passed, a resize that shrank the defect below detectability, a localisation miss, or a genuine class confusion on clean in-distribution parts? Those are four different fixes, and only one of them is a model. The stage-by-stage view is exactly what a monitoring harness instruments so that each regression mode is attributable rather than a guess — and attribution, not raw accuracy, is what shortens the time between a defect escaping and someone knowing which stage let it through.
