parkpow/deep-license-plate-recognition: a client toolkit for the Plate Recognizer API, not an ALPR engine

What this repository actually is, and who it is for

The name is misleading in a way that matters for procurement. The README opens by saying the repository contains example clients, integrations and operational utilities for Plate Recognizer Snapshot, Stream, Blur and ParkPow, and then states directly that it does not contain the recognition models themselves. So the C++ entry in the language field is not the story here. This is a Python-first collection of scripts, with C++, C#, Java and mobile examples sitting alongside it, and the intelligence lives behind an HTTP endpoint.

The audience is narrow and concrete. You are already using Plate Recognizer, either through an API token or a running self-hosted Snapshot SDK, and you need the glue: a script that reads a JPEG, a watcher that moves processed files into an archive, a processor that pulls images off an FTP or SFTP server, a redactor, webhook consumers, a gate relay controller. If you are evaluating ALPR engines on accuracy per frame, this repository gives you nothing to evaluate. If you have already picked the engine and want the plumbing, it gives you a lot of it in one place.

The data flow: local file in, JSON with boxes and scores out

Every utility follows the same shape. A local file or a remote folder is read, the image is sent to either the cloud API or a self-hosted SDK over HTTP, and the response comes back as JSON. The README shows the response schema for the image client: a list containing an object with version, results and filename, where each result carries a box with xmin, ymin, ymax and xmax, a plate string, a score and a dscore.

That schema is the contract you build on. The box coordinates let you crop or annotate; score and dscore are two separate confidence values, and the README does not explain how they differ, so treat that distinction as something to confirm against the Snapshot API reference rather than guess. The two engine options are selected by flag: --api-key MY_API_KEY sends the image to the hosted service, --sdk-url http://localhost:8080 sends it to a Snapshot SDK you run yourself. Same script, same output shape, different backend.

The repository is organised as a map rather than a library. plate_recognition.py handles images, number_plate_redaction.py handles redaction, ftp_and_sftp_processor.py handles remote folders, transfer.py watches a directory and archives what it processes, and stream/, webhooks/, parkpow/, blur/, video-editor/, docker/, benchmark/ and gate-controller/ each carry their own README. The root pyproject.toml is described as a shared Python development environment managed with uv, and the README warns that the root is a collection of scripts rather than an installable package. That warning is the most useful sentence in the document: do not expect to pip install this as a dependency.

Getting the image client running: two dependencies and one flag

The quickstart is short. Clone the repository, create a virtual environment, and install two packages:

python -m pip install requests pillow

Then run recognition against the cloud API with python plate_recognition.py --api-key MY_API_KEY /path/to/vehicle.jpg, or against a local SDK with python plate_recognition.py --sdk-url http://localhost:8080 /path/to/vehicle.jpg. The README asks you to replace the token locally and not commit it.

Region filtering is repeatable, so --regions fr --regions it restricts recognition to France and Italy. Multiple files and shell globs work in the same call, which the README demonstrates with a trucks wildcard. The full option set, covering output, annotation, cropping and engine selection, is behind --help.

Other tools have their own dependency lines, and the README is explicit that each subproject has its own dependencies and that the image-client installation does not cover the whole repository. The FTP processor needs requests, pillow and paramiko. The transfer watcher needs requests, watchdog and jsonlines. For development on the repository itself, uv sync --locked builds the root environment from uv.lock, and uv run pre-commit run --all-files runs the configured hooks. Note the phrasing: the first pre-commit command installs Git hooks, the second runs every configured hook.

Redaction is the one utility with its own cost model

number_plate_redaction.py is the most interesting script in the set because it exposes a trade-off rather than hiding it. It detects plates, including small or barely readable ones according to the README, and can write a blurred copy with --save-blurred.

The --split-image option is the part worth reading twice. For high-resolution images it splits the frame, and the README states this uses three API lookups instead of one. If you are billed per lookup, redacting a batch of 4K stills costs three times what you might assume from the single-image example. That is a real budget consideration and the repository is honest about it.

Two filters shape what gets redacted. --ignore-regexp REGEX leaves matching plates unblurred and can be repeated to supply more than one expression. --ignore-no-bb ignores results that come back without a vehicle bounding box. The second option implies that some detections arrive without a vehicle box, and the README does not say why or how often. If your workflow depends on vehicle context, that gap is worth testing against your own footage before you rely on it.

Where this toolkit stops being the right tool

The hard boundary is stated by the project itself: no models. You cannot fine-tune, quantise, inspect or self-host the detector from this repository. Every recognition call leaves your machine unless you have separately obtained and deployed a Snapshot SDK, and the README treats that SDK as a prerequisite you already have, not something this repository provides. The docker/ directory is described as on-premise tools for installing or managing an SDK, which is closer to the engine, but the README does not describe model files or training there either.

There is a second boundary around privacy and connectivity. The default path sends vehicle images to a third-party endpoint. The self-hosted path removes that, but it requires an SDK deployment the README does not walk you through at the level of detail it gives the Python client.

The third boundary is architectural. Because the root is a set of scripts and each subproject carries its own dependencies, there is no single versioned artifact to pin across an organisation. You get a git checkout plus per-tool requirements. For a two-person integration that is fine. For a platform team that needs reproducible builds across a fleet of edge devices, the per-subproject dependency model is friction you will feel at every upgrade.

What to compare it against: an embedded detector

The obvious alternative is an embedded ALPR library that ships weights with the code and runs inference locally, such as an OpenCV-based plate detector combined with a text recognition model. The difference is not accuracy, which this material cannot speak to. The difference is where the model lives and who maintains it.

With an embedded stack, your build contains the model, your inference costs are hardware rather than per-call, and there is no network dependency at recognition time. You also own the accuracy problem: region-specific plate formats, night footage, motion blur and skewed plates become your training data and your tuning work. With this repository, that work is delegated to Plate Recognizer, and the --regions flag is the visible surface of it. You trade control and offline capability for not maintaining a model pipeline.

A second alternative is writing the HTTP client yourself. The Snapshot API reference is linked from the README, and the request the scripts make is not exotic. If you only need the image path, a few dozen lines against the documented endpoint may be less to maintain than a checkout with a dozen subprojects. The value here is breadth: FTP and SFTP processing, directory watching with an archive step, webhook consumers, a gate relay controller, and examples in C++, C#, Java and Android. That breadth is what you would otherwise rebuild piece by piece.

Maintenance, licensing and what to check first

The repository is MIT licensed and is not archived. MIT covers the code in the repository. It does not cover the Snapshot, Stream, Blur or ParkPow services, the API token, or any self-hosted SDK you obtain separately; those are governed by Plate Recognizer's own terms and pricing, which the README links to but does not summarise. Do not read the MIT header as permission to run the hosted service without an account.

Upgrade cost has two components. The client side is light: two dependencies for the image path, three for the FTP processor, three for the transfer watcher, and a uv-managed root environment for development. The service side is the one that moves. The README pins the response schema at version 1 in its example, and the complete schema lives in an external API reference. When that reference changes, your parsing code changes, and nothing in this repository's versioning tells you that a remote contract shifted.

What to verify before adopting: whether your deployment can reach the cloud endpoint or needs the SDK URL path, what a --split-image redaction pass costs under your plan, whether --ignore-no-bb behaviour matches your footage, and which of the subproject READMEs you actually need, since the root install covers none of them. Start with python plate_recognition.py --help against a single test image and read the JSON before wiring anything into a pipeline.

Editorial conclusion

Adopt this repository if you have already decided to use Plate Recognizer cloud or a self-hosted Snapshot SDK and want ready-made clients for images, FTP/SFTP folders, redaction, webhooks and gate relays. Do not adopt it if you need an offline model you can train, fine-tune or audit, because the README states the recognition models are not in the repository. Before committing, verify the current Snapshot API response schema and pricing against docs.platerecognizer.com, and confirm whether your deployment target is the cloud endpoint or a Snapshot SDK container, since the two are selected by different flags (--api-key versus --sdk-url).

Official sources

1. Issues
2. License: MIT
3. parkpow/deep-license-plate-recognition on GitHub
4. Project website
5. README