Arabic recognition cannot be paired with the multilingual detector — "Unsupported configuration"

[al-ashalash]

Summary

default_models.yaml ships multilingual detection models (multi_PP-OCRv3_det_mobile, multi_PP-OCRv6_det_{tiny,small,medium}) and Arabic recognition models (arabic_PP-OCRv4_rec_mobile, arabic_PP-OCRv5_rec_mobile), but I could not find a combination that lets me use a multilingual detector with the Arabic recognizer — every pairing I tried is rejected by config validation.

Text detection is script-agnostic in principle, but in practice the default detector appears tuned for Chinese/English line shapes, and on Arabic pages it misses a substantial share of the text. Since the multilingual detector exists in the catalog, being unable to select it costs real coverage.

Environment

• rapidocr 3.9.2, onnxruntime 1.28.0, python-bidi installed
• Python 3.12.10, Windows 10 x64, CPU only

Reproduction

from rapidocr import RapidOCR, LangRec, LangDet, OCRVersion, ModelType

# 1) multilingual detector + Arabic v5 recogniser
RapidOCR(params={
    "Det.lang_type": LangDet.MULTI,
    "Rec.lang_type": LangRec.ARABIC,
    "Rec.ocr_version": OCRVersion.PPOCRV5,
    "Rec.model_type": ModelType.MOBILE,
})
# ValueError: Unsupported det.lang_type='multi' for PP-OCRv6 small model.

# 2) pin the detector version to v4 as well
RapidOCR(params={
    "Det.lang_type": LangDet.MULTI,
    "Det.ocr_version": OCRVersion.PPOCRV4,
    "Rec.lang_type": LangRec.ARABIC,
    "Rec.ocr_version": OCRVersion.PPOCRV4,
    "Rec.model_type": ModelType.MOBILE,
})
# [ERROR] base.py:158: Unsupported configuration:
# ValueError: Invalid OCR configuration.

Also worth noting: Rec.lang_type=ARABIC with OCRVersion.PPOCRV5 fails unless Rec.model_type=MOBILE is given explicitly, because only a mobile Arabic model exists. The error there is the generic ValueError: Invalid OCR configuration., which does not say which of the three settings is the problem. A message naming the unsupported field would save users a lot of guessing — that applies to all of the failures above.

Measured impact

Same scanned Arabic page (a business letter, 2381 px wide, rendered from PDF at 300 dpi), same machine:

configuration	lines	words	time
Arabic rec v5 + default detector	33	222	14.7 s
Arabic rec v4 + default detector	38	293	20.7 s
Windows OCR engine, same image, for reference	—	345	2.8 s

Where RapidOCR does detect a line, its recognition is clearly better than the reference engine — it read a stylised letterhead and mixed Arabic/English lines correctly where the other engine produced garbage. The gap in the table is coverage, not recognition quality, which is why the detector matters here.

I could not verify that the multilingual detector would close that gap, precisely because I cannot select it. That is the request: make the combination selectable so it can be measured.

Suggested fix

1. Allow Det.lang_type=MULTI to pair with non-CJK recognisers, at least for the versions where a multi detector exists in default_models.yaml.
2. If some pairings are genuinely invalid, make the error name the offending field and list the supported values, instead of Invalid OCR configuration.
3. Document the supported (det, rec, version, model_type) matrix — even a generated table from default_models.yaml would help.

Happy to test any combination you enable and report line/word counts on real Arabic scans.

(Edited: corrected the OS version — Windows 10, not 11.)

[al-ashalash]

Thanks for picking this up. If you enable the pairing on a branch, I can measure line and word coverage on real Arabic scans and report the numbers here — that comparison is the part I can contribute.

[SWHL]

@al-ashalash Feel free to open a new branch for this fix. Unfortunately I'm tied up with other work right now and won't have bandwidth for this. Much appreciated.