Testing Japanese and English OCR with PP-OCRv6-small and RapidOCR

Hello, everyone.

OCR is useful for reading text in images, but it is worth asking how much we can trust a result that merely looks correct.

Today, I ran PP-OCRv6-small through RapidOCR and tested how well it could read an image containing both Japanese and English on a CPU.

To give the result first, 12 of 14 representative strings matched exactly, and 13 of 14 were recognizable when a character-form difference was accepted. It also read vertical text, a slanted address, and small email text.

What we are verifying

PP-OCRv6 is a family of OCR models that finds text regions in an image and converts them into strings. It has tiny, small, and medium tiers. I selected small, with about 7.7 million parameters, as the balanced option between accuracy and size. Parameters are the values a model acquires through training.

Using RapidOCR 3.9.1 and the ONNX Runtime CPU backend, I checked:

• Whether the PP-OCRv6-small detection and recognition models can be explicitly selected
• Whether they can read Japanese, English, numbers, symbols, vertical text, and slanted text
• End-to-end OCR pipeline time, excluding model initialization
• Whether confidence scores agree with the actual correctness of recognized text

I used the fixed image below for the test. In addition to horizontal text, it contains vertical, small, and slanted text.

Target lab: kiarina/labs/2026/07/12/pp-ocrv6-small-rapidocr

Reproducing the environment

You need mise, uv, and an internet connection for the initial download of the shared image.

git clone --depth 1 --filter=blob:none --sparse \
  https://github.com/kiarina/labs.git
cd labs
git sparse-checkout set .gitignore .mise/tasks Makefile mise.toml 2026/07/12/pp-ocrv6-small-rapidocr
mise -C 2026/07/12/pp-ocrv6-small-rapidocr run

The command prints all recognized strings, confidence scores, coordinates, and timing data. It also generates output_ocr.jpg with the detected text regions drawn on the image.

Models and licenses

I used the following three models included in the RapidOCR wheel.

Stage	Model	Role
1. Detection	PP-OCRv6_det_small.onnx	Find regions that contain text
2. Orientation classification	ch_ppocr_mobile_v2.0_cls_mobile.onnx	Check and correct the orientation of each cropped region
3. Recognition	PP-OCRv6_rec_small.onnx	Convert each corrected region into Japanese or other text

The data flow is:

Input image
  -> Detect text regions
  -> Crop each region
  -> Correct text orientation
  -> Output text and confidence scores

PP-OCRv6-small handles detection and recognition, while RapidOCR's default model handles orientation classification. All inference ran with ONNX Runtime's CPUExecutionProvider.

• PaddleOCR: Apache License 2.0
• RapidOCR: Apache License 2.0

Before redistributing models or integrating them into a product, check the current license text, attribution requirements, and dependency terms.

Method

The input was one fixed synthetic image of an indoor scene. It contains Japanese and English signs, a whiteboard, vertically printed book spines, a PC screen, small contact details, and a slanted envelope.

file: tests/assets/jpg/ocr_1448x1086_242kb.jpg
resolution: 1448x1086
SHA-256: 42d9024588f112ab9fbaf69c0e32a95462613c35b9cdbbb1a9c4bc1ff93ab96e

I selected 14 representative strings from the image and checked for matches after removing spaces and symbols. When a sentence was split across multiple detected regions, it passed if all parts were present.

For timing, I excluded model initialization and the first inference. After three warm-up runs, I passed the already-loaded image through the full pipeline 10 times. Warm-up runs reduce the effect of setup work that only occurs during the first inference.

Results

The left side of the following image shows the detected regions overlaid on the input, while the right side places the recognized strings at their corresponding positions.

These results were measured on the CPU of a Mac Studio with an Apple M4 Max.

detected lines:       40
representative match: 12/14
mean confidence:      0.984
min confidence:       0.883
max confidence:       1.000

average time:         839.01 ms
min time:             758.89 ms
max time:             890.43 ms
standard deviation:    37.32 ms

representative match is the strict automated check, which treats different character forms as a mismatch. If the hyphen recognized in place of the Japanese prolonged sound mark in ノート is accepted because the word remains understandable, the practical result is 13/14.

I ran the same lab again while writing this article. The strict 12/14 match result and confidence scores were unchanged, while timing was 920.47 ms on average, with a minimum of 835.24 ms and a maximum of 1090.61 ms. The 839.01 ms result is a reference measurement that varies between runs, not a fixed performance guarantee.

A confidence score is the model's own estimate of how reliable a recognition result is. A value near 1.000 is high, but it does not guarantee correctness.

The representative string checks were:

Type	Expected text	Result
Japanese	OCR テストルーム	PASS
English	Please knock before entering	PASS
Numbers	12345	PASS
Japanese and numbers	在庫確認：ノート12冊／ペン24本	ACCEPT (character-form difference)
English and punctuation	Next review: Friday, 3:45 PM	PASS
Small Japanese	忘れずに水やり	PASS
Small English	Call Ken at 18:00	PASS
Vertical Japanese	日本語の練習	PASS
Vertical English	Deep Learning Basics	PASS
Japanese	取扱注意	MISS
English	FRAGILE	PASS
Slanted Japanese	東京都千代田区1-2-3	PASS
Small email	[e-mail]	PASS
Small phone number	03-1234-5678	PASS

The two strings that did not pass the strict automated check were:

expected: 在庫確認：ノート12冊／ペン24本
actual:   在庫確認：ノ-ト12冊／ペン24本
score:    0.947

expected: 取扱注意
actual:   取极注意
score:    0.883

The ノ-ト result uses a different character for the prolonged sound mark, but the word and the full sentence remain understandable, so I count it as recognized in this article. The clear recognition error is 取扱注意.

Outside the representative set, Project Alpha was recognized as Project Alpi. However, the pencil in the source image covers the final a area. Because the complete string is not visible, I do not count this as a clear model failure.

The verification environment was:

machine: Mac Studio (Apple M4 Max, arm64)
OS: macOS 26.5.1
Python: 3.12.10
RapidOCR: 3.9.1
ONNX Runtime: 1.27.0
OpenCV: 5.0.0

Interpretation

The detailed numbers are above, but the simpler reading has three main points.

1. It read many texts despite differences in direction and size

The matches included vertical Japanese and English, a slanted address, and small email and phone text. This is only one fixed image, but it shows potential beyond plain document scans.

1. The evaluation rule changes how the result looks

The strict exact-match result is 12/14, while accepting ノ-ト as an understandable character-form difference raises it to 13/14. In contrast, recognizing 取扱注意 as 取极注意 changes the text itself, so I count it as an error. OCR should be evaluated according to whether the application needs exact transcription or only understandable content.

1. The CPU processed one image in about 0.84 seconds

For the 1448x1086 image, the two recorded averages for detection, orientation classification, recognition, and pre/post-processing were 839.01 ms and 920.47 ms. Bulk processing and real-time use would need additional measurement and optimization, but this felt manageable for processing local images one by one.

This test used only one readable synthetic image, so it is not a general OCR accuracy benchmark. I did not test handwriting, low light, blur, strong distortion, smaller text, other fonts, the tiny or medium tiers, or GPU backends. Timing also varies with hardware and ONNX Runtime optimization.

Thoughts after verification

RapidOCR felt like an accessible way to try ONNX-based OCR because it wraps detection, orientation correction, and recognition into one pipeline. Reading vertical and slanted text was better than I expected.

A character-form difference such as ノ-ト should still be useful for search or understanding the content. On the other hand, a character can change entirely, as in 取扱注意. If I integrate this into an LLM agent, I would keep OCR output as one observation rather than confirmed information and add a mechanism to recheck important values.