# mica-ppocr: PP-OCRv6 OCR in pure Java with ONNX Runtime, no PaddlePaddle

> mica-ppocr ports PP-OCRv6 text detection and recognition to Java using ONNX Runtime and OpenCV, with optional document orientation correction and structured parsers for Chinese ID documents. It targets Java 8+ projects that need offline OCR without a Python service.

**lets-mica/mica-ppocr** — PP-OCRv6 offline, pure-Java image text recognition!

- Repository: https://github.com/lets-mica/mica-ppocr
- Website: https://www.dreamlu.net
- Stars: 111 · Forks: 20
- Language: Java
- License: Apache-2.0
- Published: 2026-08-27 · Updated: 2026-08-27 · Language: en
- Canonical page: https://hysenlabs.com/projects/lets-mica-mica-ppocr

## What it solves and who it is for

The project is not a general OCR engine for all languages. The character dictionaries are sized for Chinese, with the tiny and small tiers covering roughly 2855 characters and the medium tier about 7180. If your input is mostly English or other scripts, this may still work but the coverage is not the selling point. The structured parsers are specifically for Chinese documents, and the example output in the README shows a Chinese vehicle license with fields like plate number and VIN. So the intended audience is teams working with Chinese administrative or commercial documents in a Java environment.

## How the pipeline is wired

The optional document orientation classifier runs before detection. It is a PP-LCNet model that classifies the whole image into 0, 90, 180, or 270 degrees, so a rotated photo can be corrected first. The README gives a cost estimate: about 3 milliseconds extra on CPU and about 30 MB more memory because it loads a third ONNX session. This is a clear trade-off: you pay a small latency and memory cost to make the OCR robust to rotated input, which is a common failure mode for mobile-captured documents.

## Getting it running: dependencies and model files

The models themselves are not bundled in the repository. You must download the PP-OCRv6 official ONNX models and place them under models/ppocr-v6/{tier}/. There are three tiers: tiny (1.7 MB det, 4.3 MB rec), small (9.4 MB det, 20.2 MB rec), and medium (59.2 MB det, 73.0 MB rec). The medium models come as .onnx.zip files that need unpacking. The doc_ori model is optional and can be fetched from ModelScope as model.onnx. This manual model provisioning is a real operational step; it means your build process must either download these files or you must document their location for each environment.

## Structured parsers: from boxes to typed results

The parsers rely on a shared LabelMatcher that does label location, position matching, regex fallback, and layout fallback. This is a heuristic approach, not a neural model. So the accuracy of structured extraction depends on the document layout being consistent with what the parser expects. If a vehicle license has an unusual format or a smudged label, the parser may fall back to regex and get it wrong. The README marks only vehicle license and ID card as production-verified; the other eight parsers have no such mark. That is a caution sign: adopt the unverified parsers only after running them on your own samples.

## The real limitation: model accuracy and deployment weight

The bit-exact claim applies to the default CPU single-thread mode. If you enable GPU acceleration or change thread counts, the output may not be bit-exact. The README does not detail what changes with GPU, so you should not assume identical results across configurations. Also, the doc_ori model is optional and off by default; if you turn it on, you must provide the model path and a threshold. The threshold affects when the classifier decides to rotate, and the README does not specify a default value, so you will need to tune it for your image set.

## A real alternative: the Python reference implementation

Another alternative is to use a different OCR engine like Tesseract, but that is a different approach entirely. Tesseract is a general OCR engine with its own models and does not provide the PP-OCRv6 detection and recognition pipeline. It may be simpler for English text but is not designed for the structured Chinese document parsing this project offers. So the comparison is not apples to apples.

## Maintenance, license, and upgrade cost

Upgrade cost is moderate. Because the core API is small (run, detect, runMat, etc.), upgrading the core version is likely a drop-in replacement if you use the high-level methods. The structured parsers are more coupled to the result types, so a new parser or a change to fieldBoxes could affect your code. The README shows the fieldBoxes map is only fully populated for vehicle license, so if you rely on that feature for other documents, an upgrade might not improve it. You should pin the version and test against your document samples after each upgrade.

## Conclusion

Adopt mica-ppocr if you run Java 8+ and need offline OCR with no Python or PaddlePaddle dependency, especially for structured Chinese documents like vehicle licenses and ID cards. Do not use it if you need full PP-OCRv6 feature parity beyond the documented models, or if your deployment cannot handle the native OpenCV and ONNX Runtime libraries. Verify first that the model files you download match the expected tiers and that the medium tier's zipped ONNX files are unpacked. Also check the license of the models themselves, since the code is Apache-2.0 but model terms are separate. The project's recent releases show active maintenance, but only the vehicle license and ID card parsers are marked as production-verified, so test others before relying on them.

## FAQ

### What is mica-ppocr and does it need PaddlePaddle?

It is a Java implementation of PP-OCRv6 text detection and recognition that runs on ONNX Runtime alone, with no PaddlePaddle dependency. Preprocessing and postprocessing are reproduced in full, including DB postprocessing, CTC decoding and a polygon unclip equivalent to pyclipper, and the port is kept bit-exact with the single-file Python reference it was ported from under the default single-threaded CPU configuration.

### Which mica-ppocr model tier should I download?

Three tiers are described. Tiny is 1.7 MB for detection and 4.3 MB for recognition with about 2855 characters, small is 9.4 MB and 20.2 MB with the same character set and is the recommended default, and medium is 59.2 MB and 73.0 MB with roughly 7180 characters, distributed as .onnx.zip archives that must be extracted first.

### How do I run mica-ppocr OCR from Java code?

The core API is PPOcrV6Engine, which implements Closeable and is meant for try-with-resources. Its public methods accept only String, File, Path or byte array arguments and handle OpenCV Mat decoding and release internally, with a full run covering detect, sort, crop and recognise, and a detect-only call returning boxes and scores.

### Which document types can mica-ppocr parse into fields?

Ten parsers ship: vehicle licence, identity card with automatic front and back detection, bank card, driver licence, business licence, VAT invoice, train ticket, taxi receipt, household register, and an eight-digit invite code parser. Only the vehicle licence and identity card parsers are marked as production verified.

## Sources

- [Official documentation](https://www.dreamlu.net)
- [Official README](https://github.com/lets-mica/mica-ppocr#readme)
- [Project repository](https://github.com/lets-mica/mica-ppocr)
- [Release notes](https://github.com/lets-mica/mica-ppocr/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lets-mica-mica-ppocr
