Type “printing inspection” into a search bar and the mental picture that comes back is usually the same: a camera pointed at a moving web, comparing each impression against a golden reference and flagging anything that doesn’t match. That picture is not wrong so much as incomplete. It hides the part that actually decides whether a system works — the fact that print inspection is a pipeline, not a comparison, and every stage of that pipeline is tuned to the specific ways print varies. The gap matters because the naive model quietly assumes one accuracy number covers every job, every substrate, and every defect. In practice, a print inspection system has a different detection sensitivity for a hairline streak than it does for missing text, and a different false-positive behaviour on glossy stock than on uncoated kraft. A demo that catches gross misprints against a clean reference can still flood operators with false rejects — or miss subtle colour drift — the moment real substrates and real run speeds hit the line. Understanding the pipeline is what lets a team scope which print defects are genuinely detectable before committing to a pilot. What should you know about printing inspection in practice? At its core, a print inspection system captures an image of each printed impression, processes it, and produces a keep-or-reject decision. The comparison-to-reference idea lives inside that flow, but it is one step among several, and it is rarely a naive pixel diff. Print has its own physics. On a web press, the substrate is moving — often at several hundred metres per minute — and the image the camera captures is subject to registration drift (colour planes shifting relative to each other), ink density variation across a run, substrate texture that changes how light scatters, and vibration that blurs fine detail. A pipeline built for print treats these as first-class variables. It does not treat the reference image as ground truth and everything else as noise; it models the expected variation and only flags deviations that fall outside it. This is the same reframing that applies across industrial vision generally. As we explain in our walkthrough of how an image detection model works in industrial inspection, the model is only ever as good as the imaging and the variance envelope you build around it. Print is a sharp case of that principle because its variance envelope is unusually wide and unusually job-specific. For teams building the vision engineering behind it, our computer vision work centres on exactly this: matching the pipeline to the physical process it inspects rather than to an idealised reference. What are the stages of a print inspection pipeline? It helps to see the flow as discrete stages, each of which can pass or fail independently. A weak link anywhere upstream caps the accuracy of everything downstream — the model cannot recover detail the camera never captured. Stage What it does Where it commonly breaks Imaging Line-scan or area-scan capture synced to web speed and encoder position Motion blur at speed; insufficient resolution for fine defects; lighting glare on coated stock Registration / alignment Aligns each captured impression to the reference frame despite web drift Alignment error mistaken for a defect, inflating false positives Normalisation Corrects for exposure, ink-density drift, and substrate colour Over-correction hides real colour deviation; under-correction flags it everywhere Detection Flags candidate defects — comparison-based, model-based, or both Sensitivity set for one defect class misses another Classification Sorts candidates into defect types and severity Confusing a hickey with a substrate speck; no severity threshold Reject decision Applies rules — defect class, size, count, position — to keep or divert Binary keep/reject with no tolerance for cosmetically irrelevant defects The detection stage is where most of the attention goes, but in our experience it is rarely the stage that decides whether a pilot succeeds. Imaging and registration set the ceiling; the reject-decision logic sets how many false alarms an operator tolerates before they mute the system. Both sit outside the model. Which print defects are easy versus hard to detect? Not all defects are equal, and treating them as one catalogue with one accuracy number is the single most common scoping error we see. A print defect catalogue directly shapes what the system can and cannot flag reliably, because each class has a different signal-to-noise ratio against the substrate. Missing text or missing elements — relatively easy. A whole block of copy that failed to print is a large, high-contrast deviation that survives most normalisation and web-speed blur. Streaks and doctor-blade lines — moderate. Detectable when they exceed substrate texture contrast, but fine streaks on textured stock blur into the noise floor. Hickeys (small spots from debris on the plate or blanket) — moderate to hard. Small, and easily confused with harmless substrate specks unless classification is trained to tell them apart. Registration drift — moderate. Measurable directly if you track colour-plane offset, but a shift that is cosmetically acceptable on one job is a reject on another. Colour deviation — hard, and the most misleading. Subtle ΔE-scale drift across a long run is exactly what a golden-reference demo under fixed studio lighting will not reveal, because the demo lighting and single reference frame don’t reproduce the drift that accumulates at production scale. That last point is the crux. The defect that is hardest to detect is often the one a demo makes look easy, because the demo removes the variance that makes it hard. This is an observed pattern across the print and packaging inspection work we’ve scoped — not a benchmarked rate — but it recurs consistently enough to plan around. Why do lighting, substrate, and web speed matter as much as the model? Because they change the input the model ever sees. A detection model — whether it is a classical comparison engine or a fine-tuned network like the ones we cover in fine-tuning YOLO for manufacturing-line defect detection — can only reason about pixels the camera actually captured cleanly. Web speed sets the exposure window. At 300 metres per minute, a line-scan camera has microseconds per line; too little light and fine detail smears into motion blur, and the streak you needed to catch is gone before the model runs. Lighting geometry decides whether a glossy coated stock throws specular glare that masks defects or reveals them. Substrate texture sets the noise floor: a hickey that stands out crisply on smooth label stock disappears into the grain of uncoated board. None of these are model problems, and none of them can be fixed by a better model. They are captured — or lost — before inference begins. Deployed at web speed, these systems also face drift over time: substrates change, defect distributions shift with plate wear, and a pipeline validated once can quietly degrade. That is why a print-inspection system that runs continuously needs the same reliability discipline as any other production model — monitoring, revalidation, and drift detection — the kind of engineering rigour our services team scopes alongside the vision pipeline itself, so the accuracy number you validated at launch is the one you still have six months in. What does an accuracy number mean at real web speed? A single “99% accuracy” figure is close to meaningless for print inspection unless you know three things: which defect class it refers to, what the false-positive rate was at that sensitivity, and whether it was measured at production web speed or in a static demo. The operationally relevant metrics are defect detection rate per defect class, false-positive rate at web speed, and cost versus manual sheet sampling. The reason per-class matters is the same reason detection metrics like the ones we unpack in what mAP@50 means for defect detection are read per-category: an aggregate number can be dragged up by the easy classes while the class you actually care about sits well below it. The false-positive dimension is where demos mislead most. A system tuned hot enough to catch every subtle defect will also flag benign substrate variation, and once operators are diverting good product or clearing false alarms every few seconds, they stop trusting the system. In our experience, a print inspection pilot fails more often from an unworkable false-reject rate at speed than from missing defects — an observed pattern across the feasibility work we’ve done, not a published benchmark, but a consistent one. The right question is never “how accurate is it?” It is “at the sensitivity that catches the defects we care about, how many good impressions does it wrongly reject at our run speed?” FAQ What does working with printing inspection involve in practice? A print inspection system images each printed impression, aligns and normalises it, detects and classifies candidate defects, and applies rules to keep or reject. In practice it is a pipeline tuned to print’s specific variance — registration drift, ink density, substrate texture, web speed — not a single template match against a golden reference. What are the stages of a print inspection pipeline, from imaging to reject decision? Imaging captures the impression synced to web speed; registration aligns it to the reference despite drift; normalisation corrects exposure and ink density; detection flags candidate defects; classification sorts them by type and severity; and the reject decision applies rules to keep or divert. Each stage can fail independently, and a weak upstream stage caps everything downstream. Which print defects are easy versus hard for a CV system to detect? Missing text is relatively easy because it is a large, high-contrast deviation. Streaks, hickeys, and registration drift are moderate and depend on substrate contrast. Subtle colour deviation is the hardest — and the most misleading, because a fixed-lighting golden-reference demo removes exactly the run-scale drift that makes it hard. Why do lighting, substrate texture, and web speed matter as much as the inspection model itself? They determine the input the model ever sees. Web speed sets the exposure window and controls motion blur, lighting geometry decides whether glare masks or reveals defects, and substrate texture sets the noise floor. Detail lost at capture cannot be recovered by any model downstream. What does an inspection accuracy number mean at real web speed, and why can a golden-reference demo mislead? A single accuracy figure is meaningless without knowing the defect class, the false-positive rate at that sensitivity, and whether it was measured at production speed. A golden-reference demo under fixed lighting hides the ink drift, registration variance, and web-speed blur that decide real performance, so it can make hard defects look easy. What questions should a print or packaging team answer before assuming an off-the-shelf inspection system will hold up on their line? Which defect classes actually matter, and what detection sensitivity does each require? What false-positive rate can operators tolerate at your real web speed? Were the vendor’s numbers measured on your substrates at your run speed, or in a static demo? And how will accuracy be maintained as substrates and defect distributions drift over time? If you take one thing from the pipeline view, let it be this: the accuracy that matters is the one your operators still trust at run speed after the false rejects have had a chance to annoy them. Scope the defect catalogue and the web-speed false-positive rate first, before any model is chosen — that framing decides whether a print inspection pilot survives contact with a real line, or joins the pile of systems that demoed well and got muted in week two.
