The short answer

Computer vision in print production should not be evaluated through an attractive model-accuracy score. The useful measures are defects actually caught before shipment, the cost of a missed defect, and inspection time. The Gràfiques Manlleu case from Spain demonstrates the right sequence: real samples, camera and lighting first, then the algorithm, offline validation, and only then an estimate for production-line integration.

According to the European Digital Innovation Hubs Network, the company worked with DIH4CAT and Eurecat on a prototype for detecting missing print areas, colour inconsistencies, misalignment, and finishing defects. The pilot used high-resolution images, controlled lighting, and computer-vision algorithms. It was conducted as a Test Before Invest project on real samples without rebuilding the production process.

The source reports a substantial potential effect and an estimated three-year payback period for deployment on two new machines. Yet the published indicators need reconciliation: different sections describe the reduction in detection time as more than 50% and approximately 40%, while the figures for defective deliveries use inconsistent descriptions and comparison bases. This is not a reason to dismiss the case; it is a reason to agree on definitions and recalculate the effect using the buyer’s own data before investing.

The business problem behind the pilot

Manual print inspection is slow and dependent on an individual operator. During a long run, people become tired, while a small registration error, missing element, or colour shift may not appear on every sheet. A defect found after finishing or by the customer is more expensive than an early rejection because it can add reprinting, material waste, repeat logistics, and damage to the customer relationship.

Gràfiques Manlleu wanted to strengthen inspection without replacing all existing equipment or retraining the entire workforce. The prototype therefore addressed a bounded task: capture an image of a real sample, compare it with the expected state, classify the defect type, and give the operator a reproducible signal.

The algorithm was only one part of the case. The source explicitly mentions high-resolution imaging, lighting setup, real production samples, and defect categorisation. These details are critical in printing. Glare on a laminate, a shadow at an edge, drift in colour temperature, or a slight camera displacement can look like a defect to the model or conceal a real one.

An architecture without premature autopilot

A modular design is appropriate for the first production-grade implementation.

1. **Image acquisition.** Camera, lens, distance, angle, and illumination are mechanically fixed. Exposure and white-balance settings are versioned with the line configuration.
2. **Job context.** The MES, ERP, or operator provides the job ID, reference artwork, material, finishing method, and tolerances. Without this context, the system cannot know which reference applies.
3. **Pre-processing.** Deterministic code aligns the image, detects registration marks, normalises geometry, and validates frame quality. A poor image should be rejected before inference.
4. **Detection.** A model, or a combination of rules and a model, looks for omissions, shifts, marks, and finishing changes. Classical vision can be cheaper and more explainable than a neural network for geometrically stable features.
5. **Threshold policy.** A score is converted into an operational action: pass, pause for review, or place the sample in an exception queue.
6. **Operator workspace.** A person sees the current sheet, reference, highlighted region, and neighbouring-frame history. The operator confirms the defect and assigns a reason.
7. **Learning loop.** Confirmed cases enter a versioned dataset. Retrained models and threshold revisions run in shadow mode before they are allowed to influence the line.

Local execution is often appropriate because high-resolution images can be large, decisions are needed close to the equipment, and an external network connection should not determine whether production can continue. “Local,” however, does not automatically mean a costly dedicated GPU for every machine. A pilot should compare CPU, integrated accelerator, shared GPU, and edge hardware using the real frame size, capture rate, and latency requirement.

Data that needs to be collected

A dataset containing only acceptable sheets is rarely sufficient. It needs several defect types and normal variations that must not be classified as defects.

For each sample, retain:

  • job ID and reference-artwork version;
  • material, coating, and finishing operation;
  • line, camera, lens, and lighting profile;
  • speed, shift, and stable process parameters;
  • defect type, size, and location;
  • operator decision and verified outcome;
  • scrap or correction cost where it can be measured.

Randomly splitting individual frames into training and validation sets is risky. Neighbouring sheets from the same run are nearly identical, so a model can appear excellent by memorising job conditions. A more honest evaluation separates entire runs, dates, materials, or machines and tests on a fresh series the model has never seen.

The grey zone must also be specified. A small colour deviation may be acceptable for one customer and critical for another. A similar scratch on protective film and on the finished surface has a different cost. These rules belong to the business process, not to the model.

Why the source metrics cannot simply be added together

The case page provides several useful reference points:

  • initial tests reportedly reduced error-detection time by more than 50%;
  • a table compares roughly four hours of manual inspection per shift with about 2.5 hours, or an approximate 40% reduction;
  • annual quality-control labour cost is shown as about €12,000 before the solution and a projected €6,000–7,000 afterwards;
  • reductions in defective output reaching customers and in scrap are also reported;
  • deployment on two new machines is given an estimated payback period of about three years.

These figures cannot be combined mechanically in one financial model. “Detection time,” “manual inspection time,” and “labour cost” have different denominators. The share of defective batches is not the same as the number of defective items, and a prevented delivery does not always equal avoided scrap because some output may be reprinted or repaired.

The source table also contains an explicit arithmetic ambiguity. A move from an estimated 40% of batches with defective output to less than 2% is described as an 80% reduction, although the change would be greater if the denominator were identical. Elsewhere, the text refers to a 40% reduction in defective output reaching customers. Without the underlying measurement protocol, it is impossible to know whether these figures cover different periods, different metrics, or simply require editorial correction.

The defensible conclusion is narrower: the pilot demonstrated enough potential to justify evaluating production deployment, but the published page is not an audited return-on-investment model.

Building a company-specific business case

First choose a single period, such as one month, and record the baseline:

  • manual inspection hours;
  • sheets and batches inspected;
  • defects found before the next operation;
  • defects found after finishing;
  • customer complaints and repeated runs;
  • material, machine-time, labour, and logistics costs;
  • downtime caused by false stops.

Then measure the cost of decisions rather than “accuracy.” Economic benefit for the period equals prevented reprints and claims plus released inspection time, minus hardware, integration, maintenance, and false-stop costs.

The two error types must be separated. A **missed defect** creates waste and customer risk. A **false alarm** stops the line and consumes operator time. The threshold should minimise the combined cost of these errors instead of maximising an abstract F1 score.

Latency and throughput must be measured on real frames when comparing hardware options. Tools such as OpenVINO Benchmark App can measure model performance on a specific device, but laboratory frames per second do not include image acquisition, transfer, pre-processing, evidence storage, and the operator interface.

A practical six-week pilot

In week one, select one machine, one material type, and two or three expensive defect classes. Fix the lighting and measure the baseline. In weeks two and three, capture real acceptable and defective samples, document the causes, and prepare reference images. In week four, build an offline prototype. In week five, run it in shadow mode beside the operator without permission to stop the line. In week six, recalculate errors and economics.

Define stop conditions in advance: too many false alarms, unstable illumination, too few examples of a critical defect, or an inability to associate a frame with a production job. A negative result is still useful because it shows that image acquisition, job identification, or the inspection process must be corrected before buying inference hardware.

The Gràfiques Manlleu case is valuable because of its sequence: a real process, non-invasive acquisition, defect classification, employee participation, and a gradual move from offline analysis toward possible real-time operation. Managers should borrow that sequence rather than the published payback percentage.