/ / technical blog

ANPR System Design

This project is a real-time Automatic Number Plate Recognition system designed for lane-based monitoring, camera stream ingestion, OCR-powered plate reading, and database-backed event logging. It combines YOLO-based vehicle detection, OCR inference, FastAPI serving, and configurable lane pipelines.

Focus Computer Vision • OCR • Real-time systems
Stack YOLO • TrOCR • FastAPI • MySQL • MSSQL
Outcome Lane-aware real-time recognition with duplicate suppression and structured event logging

From live camera feeds to recognized plate text

The ANPR workflow starts with an RTSP stream or configured camera input and ends with a recognized plate number, a saved crop, and a structured database event. The important part is that the system is not just performing OCR in isolation — it also handles lane configuration, duplicate suppression, image annotation, and persistence.

That makes it useful for traffic monitoring, toll operations, access control, and real-time vehicle tracking workflows.

End-to-end processing pipeline

  • Load lane configuration from YAML and validate stream parameters
  • Start a long-running worker to collect frames from the RTSP input
  • Run YOLO object detection to identify the vehicle and estimate plate area
  • Crop the plate region and pass it through TrOCR for text recognition
  • Suppress duplicates with similarity checks and save annotated outputs
  • Persist related metadata to MySQL/MSSQL data stores

Key code structure

The project separates the recognition logic from the API server and stream orchestration, which makes the design easier to reason about and extend.

# Recognizer is initialized with configured media paths,
# model references, and validation settings.
recognizer = initialize_recognition_service(
    media_root=CONFIGURED_MEDIA_PATH,
    detection_model=SELECTED_MODEL,
    lifecycle_settings=VALIDATION_RULES
)

This initialization is performed in the service layer, while the underlying OCR and detection logic remains internal to the project.

YOLO + TrOCR

The recognition pipeline uses YOLO for the location stage and a TrOCR-based model for text extraction. The code loads the OCR model with the Hugging Face checkpoint and runs the OCR pipeline over the cropped plate image.

# Model loading is handled internally for the production deployment.
# Only a high-level process is shown here.
load_detection_model()
convert_if_needed_for_runtime()
prepare_ocr_pipeline()

# Detection → crop → recognition → post-processing
recognize_plate_from_frame(frame)

Making recognition stable in live feeds

In a live camera setup, the same vehicle can appear across multiple frames. The system avoids noisy duplicates by comparing the previous frame with the current frame and by checking plate similarity across a short time window.

# Duplicate suppression works by comparing recent detections
# within a short time window and rejecting near-identical repeats.
recent_match = compare_with_recent_events(current_plate)

if recent_match and within_time_threshold():
    skip_duplicate_event()
else:
    process_event()

This is a practical engineering choice: it reduces duplicate writes while preserving real events for different vehicles.

FastAPI service structure

The FastAPI app is responsible for dashboard rendering, configuration APIs, and starting per-lane camera workers. It also serves static assets and exposes endpoints for lane configuration updates and RTSP stream launch.

# Production endpoints manage lifecycle, stream setup,
# and configuration updates for each lane.
start_lane_session(config)
validate_source_parameters()
run_background_worker()
update_runtime_state()

Database integration and media output

The system writes the recognized result to a structured image path, stores metadata, and integrates with database backends for tracking. In the captured codebase, both MySQL and MSSQL managers are present, allowing deployment across different environments.

Production considerations

From a deployment standpoint, the project includes license validation, threaded worker management, YAML-driven lane configuration, and persistent logging. It is designed around the reality that production camera systems need lifecycle control, safe configuration updates, and operational visibility.

  • Real-time stream lifecycle management with clean shutdown paths
  • Structured logs for troubleshooting and auditability
  • Media directories for saved plate crops and annotated frames
  • Config-driven lane setup for different toll plazas or camera layouts
Open GitHub Profile Back to projects