§01/License Plate Recognition
Applied AI · Platform
License Plate Recognition
The hard part was not one model. It was teaching motion, plate recognition and plate analysis to behave like one system.
A computer-vision prototype for continuous parking video: motion filtering, trained plate recognition, character analysis and alerts.
- Role
- Motion detection · model training & fine-tuning · plate analysis
- Span
- Nov 2024 — Jul 2025
- Status
- Completed team project
- Team
- Five-person university team
Completed university team project; source preserved in the upstream repository.
§02/The 60-second version
The 60-second version
- 01 / What was broken
- In continuous footage, the same plate changes with distance, angle, light and motion blur while every slow or inaccurate stage contaminates the next one.
- 02 / The move
- Treat data gathering, motion gating, plate recognition and plate analysis as one trainable pipeline, then decouple the expensive stages with queues.
- 03 / My contribution
- On a five-person team, I focused on motion detection and the plate-recognition and plate-analysis models: gathering and preparing data, training, evaluating, fine-tuning and integrating them into the pipeline.
- 04 / What exists as proof
- The upstream team repository preserves 69 commits and an inspectable multi-service Python architecture.
§03/The full story
The story
The summary above stands on its own. Open the decision trail below, one chapter at a time.
01/FrameThe model begins with the data
The model begins with the data
A clean, centered plate crop is an easy demonstration. Continuous footage is not: distance, angle, glare, darkness, occlusion and motion blur keep changing the input before a model gets to reason about it.
My work began with gathering and preparing project data, then training and fine-tuning the recognition and analysis models against the kinds of variation the pipeline had to handle. The project did not preserve a publishable dataset size or accuracy result, so this case describes the work rather than inventing a benchmark.
02/BuildSeveral models, one failure chain
Several models, one failure chain
I worked on the motion detector that gated the pipeline before the heavier models ran. Unchanged frames were rejected early; only relevant frames continued toward plate recognition and analysis. The repository does not contain a publishable measurement of how many frames the gate rejected.
The recognition and plate-analysis models were not isolated experiments. I trained, evaluated and fine-tuned them as connected stages, because a weak crop or localization result immediately becomes bad input for character analysis.
The team split the stages into services with queues to decouple their rates. In that design, a slow OCR pass can create backpressure instead of forcing every stage into one frame budget, and each component can be tuned or replaced independently. End-to-end throughput was not measured for this case study.
The project used a desktop operator client so alerts lived in a dedicated surface rather than a disposable browser tab.
03/ProveMeasure the models and the whole chain
Measure the models and the whole chain
Model evaluation is necessary because it shows whether new data and fine-tuning improved recognition under held-out conditions. It is still incomplete: end-to-end capture asks whether a vehicle entering the frame produces correct plate text in time to matter.
No publishable model or end-to-end measurement was preserved, so this case explains the evaluation method rather than claiming an accuracy result.
§04/The evidence underneath
System & architecture
- 4
- Stages
- Continuous input
- Mode
- Compose
- Deploy
Motion → detect → OCR → alert
Asynchronous stages
Containerised services
Technology
- Python
- Ultralytics YOLO
- PaddleOCR
- FastAPI
- Redis
- Docker
- PyQt5
Decisions & trade-offs
D-01
2025
Separate services with a queue, not a single process.
- Why
- The stages have very different costs and rates. Coupling them in one process means the slowest stage sets the frame rate for everything and there is no way to absorb a burst.
- Tradeoff
- Operational complexity, serialisation overhead between stages, and a much harder debugging story than a single script.
- Revisit if
- If deployed to a single edge device where the network hop costs more than the decoupling is worth.
D-02
2025
Motion gate before detection.
- Why
- A fixed parking camera shows an empty scene most of the time. Running detection on every frame spends the entire compute budget confirming nothing happened.
- Tradeoff
- A slow-moving or partially occluded vehicle can be missed at the gate, and that failure is invisible downstream — nothing logs a frame that was never considered.
- Revisit if
- If false negatives at the gate turn out to be a real source of missed vehicles rather than a theoretical one.
If I rebuilt it today
- 01
Version the dataset, training configuration and evaluation set together. Without that lineage, fine-tuning becomes a sequence of impressions rather than a reproducible experiment.
- 02
Instrument the motion gate's rejections. It is the one stage whose failures leave no trace, which makes it the least trustworthy part of the system.
- 03
Measure end-to-end capture rate from the beginning instead of component accuracy. It is the only number that describes whether the system works.