# The Chinese plate detector documents four runtimes and no install step

> A YOLOv5 based detection and recognition project for Chinese vehicle plates, with twelve plate types claimed and demo commands for PyTorch, ONNX, OpenVINO and a video path. The readme is written in Chinese, states only a minimum Python version, and never says how to install the thing.

**we0091234/Chinese_license_plate_detection_recognition** — yolov5 车牌检测   车牌识别   中文车牌识别 检测 支持12种中文车牌 支持双层车牌

- Repository: https://github.com/we0091234/Chinese_license_plate_detection_recognition
- Stars: 1,883 · Forks: 297
- Language: Python
- License: GPL-3.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/we0091234-chinese-license-plate-detection-recognition

## The readme names a minimum Python version and never says how to install

The whole environment specification is one line, in Chinese: Python 3.6 or newer and PyTorch 1.7 or newer. There is no pip command, no virtual environment instruction, and no reference to the requirements file that sits in the tree. The demo section instead starts from the assumption that an interpreter with the right packages already exists, offering two ways in.

```bash
python detect_plate.py --detect_model weights/plate_detect.pt  --rec_model weights/plate_rec_color.pth --image_path imgs --output result
```

You can run the script directly, which the readme says is equivalent, or pass the two weight files and the folders explicitly. The detector weight and the recognition weight are separate arguments, which tells you the two stages are independent artifacts you can swap, and the detection and recognition halves are also trained separately, with the detection training notes inside this repository and the recognition training notes in a separate one. The page also carries a note that the models were trained on public datasets, and points readers who need higher accuracy, or who want a commercial engagement, to a contact.

## The OpenVINO example names a different recognition weight than the ONNX example

Four runtimes are documented and the two ONNX-family commands do not agree on a filename.

```bash
python onnx_infer.py --detect_model weights/plate_detect.onnx  --rec_model weights/plate_rec_color.onnx --image_path imgs --output result_onnx
```

```bash
python openvino_infer.py --detect_model weights/plate_detect.onnx --rec_model weights/plate_rec.onnx --image_path imgs --output result_openvino
```

The ONNX line expects the colour recognition file, the same name the PyTorch demo uses with a different extension, while the OpenVINO line drops the colour infix. One of the two has to be renamed or supplied separately, and the readme does not say which. The OpenVINO entry is also the only one with a version attached to it, 2022.2, which dates the conversion path even though the other paths carry no version at all. Both commands keep the same shape as the PyTorch one, with a separate output directory per runtime, so the pattern is that the inference scripts are parallel ports of a single interface rather than separate tools.

## The video demo ships as a netdisk link and the filename does not match the command

The video example is the only path with an external download, and it comes with an extraction code.

```bash
python detect_plate.py --detect_model weights/plate_detect.pt  --rec_model weights/plate_rec_color.pth --video 2.mp4
```

The sample is listed as 2.MP4 in capitals, while the command and the explanatory sentence both refer to 2.mp4 in lower case, and the output is written to result.mp4. On a case sensitive filesystem that is a rename waiting to happen, and it is the kind of detail that costs a newcomer an afternoon on a machine where the download lands with a capitalised extension. The image path is the sibling case, where the readme names an input folder and an output folder and leaves the contents to you. Both netdisk links in the page, the video and the ONNX weights, sit behind their own codes, so neither the sample nor the converted weights come from the repository itself.

## The tree still carries the face detection project it grew out of

The credits at the bottom name two upstream projects: a YOLOv5 face repository and a CRNN Chinese character recognition repository. Those two are where the detector and the recogniser come from, and the tree shows the merge rather than hiding it. There is a face dataset evaluation script and a matching evaluation directory still present, a hub configuration module, and a dataset conversion script named for a Chinese plate dataset. So the repository is a fork of two unrelated projects, combined, and the leftovers are still in the directory listing. That is not a criticism of the result, since a working combination of two proven pieces is a reasonable thing to publish, but it does mean the tree is larger than the readme describes and that a reader auditing the plate-specific code has to know which files came from where.

## The dependency list has no version pins and carries a notebook stack

The requirements file is a bare list of names with no version constraints on any line.

```text
asttokens
backcall
charset-normalizer
cycler
dataclasses
debugpy
decorator
executing
fonttools
idna
ipykernel
ipython
```

Two things stand out. The first is the absence of pins, so a fresh resolve picks up whatever is current, which for a project pinned to a 2022-era stack is a gamble. The second is the composition: the runtime list includes a full interactive environment with a kernel, a client, a server and a stack of prompt and completion packages, alongside the actual computer vision dependencies. Some entries are also backport packages for interpreters that predate the version which bundled them, and the readme's stated floor of Python 3.6 has no ceiling, so a modern interpreter is the untested case rather than the supported one. Verify the resolve before anything else on a current machine.

## Twelve plate types, presented as a checklist with everything ticked

The supported types are listed as twelve items, each with a ticked checkbox, which reads as a status list but functions as a claim. Single row blue, single row yellow, new energy plates, white police vehicle plates, driving school plates, armed police plates, then the harder group: double row yellow, double row white, embassy plates, the Hong Kong, Macau and Z plates, double row green, and civil aviation plates. Three of the twelve are double row, which is the case that breaks most single line crop assumptions, so the fact that they are in the list at all is the interesting part. The page does not give accuracy figures per type, only the project owner's note that higher accuracy models exist, so the checklist tells you what was attempted rather than how well each one works. No evaluation script or per-class result is published in the readme.

## The newest work lives in other repositories on a newer detector

The news section points away from this repository. The most recent entry, dated 2026-02-13, is a separate YOLO26 plate repository, the one before it from 2022-12-04 is a combined vehicle and plate system, and the page also links sibling repositories for a YOLOv8 and a YOLOv7 version. So this YOLOv5 implementation is one of at least four published attempts by the same author, and the current one has moved to a newer detector generation in a different project. The deployment section points outward the same way, with the Android NCNN path living in a repository owned by somebody else and the TensorRT path in a separate one, while only the ONNX and OpenVINO demos run from code in this tree. The licence is GPL-3.0, there are no published releases, and the last recorded commit on the main branch is dated 2026-06-05.

## Conclusion

This project fits someone who already has a YOLOv5 checkout and wants Chinese plate detection with the weights in the tree, rather than someone starting from a blank machine, because the readme assumes an existing PyTorch environment and the requirements file pins nothing. Three things to check first. There is no documented install step at all, so treat the dependency list as a starting point rather than a working recipe. The OpenVINO example names a different recognition weight file from the ONNX example, so decide which one your weights directory actually has before running either. And the project's own news section points at newer implementations in other repositories, so check whether the branch you want lives here before building on this one.

## FAQ

### Which Chinese licence plate types does this project claim to support?

Twelve, each listed with a ticked box: single row blue, single row yellow, new energy, white police vehicle, driving school, armed police, double row yellow, double row white, embassy, Hong Kong Macau and Z plates, double row green, and civil aviation. The readme gives no per type accuracy figures.

### How do I run the image demo?

Run detect_plate.py with the detector weight, the recognition weight, an input path and an output path, for example pointing at the bundled imgs folder and writing to result. The readme also says you can run the script directly with no arguments, and it is written in Chinese.

### Which weight files do the ONNX and OpenVINO demos expect?

The ONNX demo names weights/plate_detect.onnx together with weights/plate_rec_color.onnx, while the OpenVINO demo names the same detector but a recognition file called weights/plate_rec.onnx. The readme does not explain the difference, and the OpenVINO entry is the only one that names a tool version, 2022.2.

### Are the Android and TensorRT deployments in this repository?

No. The Android NCNN path points at a repository owned by a different account, and the TensorRT path points at a separate repository by the same author. Only the PyTorch, ONNX and OpenVINO demos run from code in this tree, and the sample video and the converted ONNX weights are linked from a file host rather than stored here.

### What does the requirements file for this plate project pin?

Nothing. Every line is a bare package name with no version constraint, and the list mixes the computer vision dependencies with a full notebook and kernel stack plus several interpreter backport packages. The readme states Python 3.6 and PyTorch 1.7 as minimums and gives no install command.

## Sources

- [Issues](https://github.com/we0091234/Chinese_license_plate_detection_recognition/issues)
- [License: GPL-3.0](https://github.com/we0091234/Chinese_license_plate_detection_recognition/blob/main/LICENSE)
- [README](https://github.com/we0091234/Chinese_license_plate_detection_recognition/blob/main/README.md)
- [we0091234/Chinese_license_plate_detection_recognition on GitHub](https://github.com/we0091234/Chinese_license_plate_detection_recognition)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/we0091234-chinese-license-plate-detection-recognition