PlateRecognition: an open source licence plate pipeline that runs on edge chips

The pipeline is three stages, and the repository is split along them

The algorithm section describes the work as plate detection, plate rectification, plate recognition, and a combined detection plus recognition path. The repository layout makes that structure concrete, with separate directories for the YOLOv5 plate detector, the YOLOv7 plate detector, a combined PlateDetectionRecognition directory, and three recogniser implementations, PlateRecognitionOCRV5, PlateRecognitionOCRV6 and PlateRecognition_LPRNet, alongside common code and headers. A table in the algorithm section tracks the state of each piece, marking the YOLOv5 detector and the YOLOv7 detector as done, the YOLOv8 detector as still in progress, the recogniser as done, and the combined detection-to-recognition path as done. The directory names also hint at the history, since the recogniser alternatives are named after the OCR architecture they replace or complement, which is a common pattern in this kind of pipeline where accuracy and latency are traded against each other.

Eleven Chinese plate categories, and the international coverage claim

The PlateAlgorithm section states that the algorithm supports eleven kinds of Chinese plate, and lists them: the single-row blue plate, the single-row yellow plate, the new energy vehicle plate, the white police plate, the driving school plate, the armed police plate, the double-row yellow plate, the double-row armed police plate, the embassy plate, the Hong Kong and Macao plate, and the double-row agricultural vehicle plate. The country coverage section is longer still, spanning most of Asia including China, Hong Kong, Macao, Taiwan, Korea, Japan, Singapore, Thailand, Malaysia, Indonesia, Vietnam, Turkey, Israel and several Gulf states, a long European list, North America, South America and Oceania. The results section then shows sample images grouped by region, with separate sections for United States plates, European plates, Korean plates, Taiwan plates, Hong Kong and Macao plates and Mainland China plates, plus a section showing lane line, vehicle distance and plate recognition together.

The accuracy table is the number to read carefully

The recognition accuracy figures are given for a test set of 72,000 images, with the model name, the input size, the accuracy, the speed and the platform. The small model reaches 92.40 percent at 452.480 microseconds on an RTX 3090, the small variant with a different name reaches 98.90 percent at 452.597 microseconds, the medium model reaches 99.35 percent at 463.316 microseconds, and the large model reaches 99.56 percent at 507.082 microseconds. The pattern is the useful part. Accuracy rises with model size and so does latency, and all four run in roughly half a millisecond on a 3090. The colour variant is the outlier at 92.40 percent, which suggests plate colour classification is a separate and harder problem than reading the characters. These are the author's own numbers on their own test set, and the README describes that set as 7.2 wan images, so the figures tell you what the model does on the data it was measured against rather than what it will do on your camera feed.

TensorRT engines are built per graphics card, and that is a deployment trap

The implementation notes explain the mechanics, and one item deserves attention before you plan a deployment. All the models use C++ and TensorRT for accelerated inference, and the pre and post processing for the YOLOv7 plate detector is accelerated with CUDA, with the README noting that the same approach can be applied to optimise the other models. The third note is the operational one: the engine corresponding to your graphics card is generated automatically, and if the folder already contains an engine built for a different card you have to delete it before the one for your card is regenerated. A TensorRT engine is a compiled artefact for a specific architecture and software stack, so a folder that arrives with someone else's engine in it will either fail to load or, worse, load and behave unexpectedly. On an embedded board with a fixed SoC this is manageable, but it is the kind of detail that turns into a support ticket.

Edge deployment is the point, and the device table shows the range

The feature list claims support for CPU and GPU deployment on Linux, Windows, CentOS, Ubuntu, the UOS distribution and the Kylin distribution, and that calls can be made from C and C++, Python, C# and Java, plus deployment on Android, iOS and HarmonyOS. The first device table covers phone and tablet chips, listing a Redmi K30 Pro with a Snapdragon 865 at around 70 milliseconds on four CPU cores and 40 on the GPU, a Redmi K60 with the Snapdragon 8 Gen 1 at around 50 milliseconds on CPU and 30 on GPU and 18 on the NPU, a Redmi K90 Max with a Dimensity 9500 at around 40 on CPU and 15 on the NPU, a Huawei Mate 80 with the Kirin 9020 at around 40 milliseconds on CPU and 20 on the NPU, an iPhone 13 with the A15 at around 50 on CPU and 13 on the NPU, an iPad Air 3 with the A12 at around 100 on CPU and 35 on the NPU, and a Unisoc 7885 board. Every entry is at 99 percent or above, and the interfaces listed are Kotlin and Java for the Android parts, ArkTS for the HarmonyOS part, and Swift with Objective-C for the iOS parts, all at 1920 by 1080 input.

Rockchip and HiSilicon boards, and the commercial demo route

The remaining tables cover the boards that matter for embedded work. Rockchip devices include the rk3588 at around 25 milliseconds, the rk3576 at around 25, the rk3568 at around 70, the rv1126B at around 25, the rv1126 at around 62 and the rv1106 at around 150, with C and C++ or C and C++ with Python interfaces across Ubuntu, Buildroot, Debian and Android, apart from the rv1106 which is listed for Buildroot only. The HiSilicon entries cover the SS928 and Hi3403 at around 40 milliseconds, the Hi3519DV500 at around 50 and the Hi3516CV610 at around 150, all with C and C++ interfaces on Ubuntu and BusyBox. The README also lists support for the Sophgo BM1684 series and for the Axera series, and it describes a commercial test demo that can be obtained through a WeChat ID given in the acknowledgements, alongside a paid set of open and private plate detection and recognition datasets. That last point is the one to keep in mind when reading the MIT licence on the code: the code is open, the datasets and the packaged demo are not.

An online demo, a WeChat contact and a homepage outside the repository

The project is reachable in three ways, and none of them is a package manager. There is a web test at the vision.zhoujiayao.com address for trying plate recognition online, and the README describes it as the online experience for plate recognition. There is the acknowledgements section, which gives a WeChat ID, cbp931126, and an email address, and says the WeChat contact can share organised open and private plate detection and recognition datasets for a fee of 30 yuan, and invites people into a discussion group. The repository itself carries the code, with readme files in Simplified Chinese, Traditional Chinese, English and Korean, and the home page for the project is the vision.zhoujiayao.com site. The licence on the repository is MIT, the repository is not archived, and the last push was on 2026-09-02, with no GitHub releases, so there is no version history to track and you are working from the default branch.

Editorial conclusion

PlateRecognition fits an embedded vision developer who needs plate recognition to run on a specific device, whether that is a phone SoC, a Rockchip or HiSilicon board, and who wants the detection and recognition stages as separate C++ components rather than a hosted API. It does not fit a team that needs a production system with a support contract, since the accuracy figures are the author's own test-set numbers and the commercial demo path runs through a WeChat contact. Verify first that the plate types you need are among the eleven Chinese categories the algorithm section lists, that your device has a supported accelerator path, and read the engine regeneration note, because a TensorRT engine built for one graphics card will not run on another.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pcb9382/PlateRecognition on GitHub
4. Project website
5. README