Computer vision in production: lessons from ALPR

A computer vision demo is quick to build: take a pre-trained model, point it at a few sample images, and it finds what you are looking for. Taking the same idea into production, where it runs day and night on real cameras and people rely on its alerts, is a different job.

We learned this building an ALPR system (automatic licence plate recognition) for the parking module of Smart DigiBuild, the smart building platform we develop for Four Corners Technology. This article shares the lessons that apply to almost any computer vision project, whether it is reading plates, checking products on a line or counting people.

1. The model is the smallest part

In the finished system, the model that finds plates is one component among many: camera integration, image pre-processing, character recognition, post-processing, business rules, alerts, storage, an API, monitoring and a user interface. Most of the engineering effort goes into everything around the model. Plan and budget accordingly.

2. Your data is not the benchmark data

Pre-trained models are trained on public datasets. Your cameras are mounted at your angles, in your light, with your weather, and they see your local plate formats or your products. Collect real images from the actual cameras early, including the difficult ones: night, rain, glare, dirt, motion blur, partial occlusion. These images decide whether the system works, and they become your test set.

3. Camera placement matters as much as the algorithm

Many recognition problems are really camera problems. Angle, distance, resolution, shutter speed and infrared lighting at night often have more impact on accuracy than switching to a bigger model. Involve the people who install cameras, and test placements before the hardware is fixed.

4. Two stages are easier to improve than one

For ALPR we use a two-stage pipeline: one model (YOLOv8) detects the plate, then OCR reads the characters from the cropped image. Separating the steps makes problems visible: is the plate not found, or found but misread? Each stage can be measured and improved on its own.

5. Post-processing turns raw output into reliable results

OCR output is noisy. Simple rules make a large difference: normalise characters that are often confused, check the result against valid plate formats, and combine several frames of the same vehicle instead of trusting a single image. Domain knowledge encoded in rules is often cheaper and more robust than a larger model.

6. Decide where the model runs: edge or cloud

• Edge (a small computer next to the camera): low latency, works when the connection fails, and less image data leaves the site, which helps with privacy.
• Cloud: easier to update and scale, more computing power, central monitoring.

We packaged the service as a Docker container so the same code runs on an edge box or in AWS. Many systems end up hybrid: recognition at the edge, events and storage in the cloud.

7. Measure with your own test set

Accuracy figures from papers or vendors say little about your site. Build a labelled test set from your cameras and measure what matters for the business: how many vehicles are detected, how many plates are read correctly, how many false alarms security receives per day. Re-run the test after every change to the model, the rules or the cameras.

8. Keep a human in the loop

No system is perfect. Design for that: store each event with its image, let staff confirm or correct uncertain reads, and use the confidence of the model to decide when to alert automatically and when to ask a person. Corrections also become new training data.

9. Monitor the system, not just the server

A camera that is knocked out of position, a lens covered in dust or a new type of plate can silently reduce quality while every server metric looks green. Monitor business signals too: detections per hour per camera, average confidence and the share of unreadable plates. A sudden change usually means something in the real world changed.

10. Privacy is part of the design

Licence plates, faces and people in images are personal data under the GDPR. Build privacy in from the start: a clear purpose, only the images you need, short retention with automatic deletion (in our case S3 lifecycle rules), role-based access to images, and documentation for the data protection officer and, where relevant, the works council. Under the EU AI Act, some uses of biometric recognition are restricted, so check your use case early.

Conclusion

Successful computer vision in production is less about the newest model and more about good data, sensible camera setups, robust post-processing, honest evaluation, monitoring and privacy by design. That is how we approach every vision project. If you are considering one, start with a short feasibility test on your own images. See our AI development page or our article on how plate recognition works.

Discuss your computer vision idea