RapidOCR 默认参数与PaddleOCR默认参数对齐探究 - RapidOCR 文档

[giscus[bot]]

RapidOCR 默认参数与PaddleOCR默认参数对齐探究 - RapidOCR 文档

RapidOCR 是支持离线部署的开源 OCR 工具，面向 Python、C++、Java、C# 等生态，支持 ONNX Runtime、OpenVINO、Paddle、PyTorch、MNN、TensorRT 等推理引擎。

https://rapidai.github.io/RapidOCRDocs/latest/blog/2026/07/19/rapidocr-paddleocr-param-align-plan/

[tcita]

最后的总结可能有笔误 ,"要想和 PaddleOCR 参数基本等价，需要按照下面的配置来设置："后应该是
engine = RapidOCR(
params={
"Det.ocr_version": OCRVersion.PPOCRV6,
"Det.std": [0.229, 0.224, 0.225],
"Det.mean": [0.485, 0.456, 0.406],
"Det.limit_side_len": 64,
"Det.use_dilation": False,
},
)
"Det.std": [0.5, 0.5, 0.5], # 这其实是 RapidOCR 的默认值，不是 PaddleOCR 的
"Det.mean": [0.5, 0.5, 0.5], # 同上

[SWHL]

感谢指出，的确笔误了

…

---- 回复的原邮件 ---- | 发件人 | ***@***.***> | | 发送日期 | 2026年07月24日 03:26 | | 收件人 | RapidAI/RapidOCR ***@***.***> | | 抄送人 | Subscribed ***@***.***> | | 主题 | Re: [RapidAI/RapidOCR] RapidOCR 默认参数与PaddleOCR默认参数对齐探究 - RapidOCR 文档 (Discussion #715) | 最后的总结可能有笔误 ,"要想和 PaddleOCR 参数基本等价，需要按照下面的配置来设置："后应该是 engine = RapidOCR( params={ "Det.ocr_version": OCRVersion.PPOCRV6, "Det.std": [0.229, 0.224, 0.225], "Det.mean": [0.485, 0.456, 0.406], "Det.limit_side_len": 64, "Det.use_dilation": False, }, ) "Det.std": [0.5, 0.5, 0.5], # 这其实是 RapidOCR 的默认值，不是 PaddleOCR 的 "Det.mean": [0.5, 0.5, 0.5], # 同上 — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tcita]

对于参数 limit_side_len 我有一些拙见:

大多数场景正如作者写的,limit_side_len=736 质量更好,就是慢一点(Elapse 0.165 / 0.235 ≈ 0.70),但是我想提醒大家格外注意"又小又清晰"的图片出现的频率。

736(limit_type=min)会把短边不到 736 的图放大到短边 736 再给 det。而 736px 的短边对桌面截图这类图片来说偏大 -- 随手截的视频字幕、软件 UI 文字、漫画对白等,短边常常达不到 736px。这类又小又清晰的图本来就不需要放大,强行拉大反而会降低边缘锐度、引入双线性插值伪色,极端情况(短边很小、放大十几倍)甚至可能让 DB 找不到框。

而且经过我的测试,在极端情况比如桌面的单行文字识别(图小且清晰、短边 <<736、文字量少),rec 耗时短,det 因为被 736 拉伸而产生的额外耗时就格外明显,我猜测是 det 的 CNN 推理在更大的张量上随像素线性增长所致。

如果您真的验证了不放大也可以准确识别,那么对足够清晰的小图,可以不放大,只把边长凑整到最近的 32 倍数,省掉额外的开销。比如 limit_side_len=32时,只有短边特别小(<32px)的图才相对温和的放大兜一下,不会像 736 那样把每张小图都拉到 736 去算。

[SWHL]

嗯呢，的确是你这样说的。如果确定自己的场景是那种足够清晰的小图，这个参数设置为更小，的确会更合适。

但是需要注意的是如果进入检测模型图中的文本都接近一行了，就可以尝试直接走识别了。这种过检测模型反而会增加出错率和耗时。