参数介绍 - RapidOCR 文档

[giscus[bot]]

参数介绍 - RapidOCR 文档

Awesome OCR multiple programing languages toolkits based on ONNXRuntime, OpenVION and PaddlePaddle.

https://rapidai.github.io/RapidOCRDocs/main/install_usage/rapidocr/parameters/

[longdexin]

在rapidocr 2.1.0版本中，(return_word_box) support word box of English and number text。这个改动，返回的是若干个字符的整体坐标，使得我代码中之前基于单个字符进行定位的判断逻辑直接崩溃了。我的问题如下：

1. 这个改动是否合理和必要？我问过paddleocr官方人员，能否支持单个字符返回坐标，他们说支持不好，没这个功能，所以我才用的rapidocr，速度更快，还能返回单个字符。
2. 如果必要，是否能给个别的参数，比如return_single_word_box来兼容之前返回单个字符的逻辑？我的程序非常需要单个字符的位置信息，我不想一直停留在rapidocr 2.0.7版本。
3. PP-OCRv5的识别精度提升真的很客观，rapidocr赶紧支持一下哈。我也会一直支持你们的^_^，你们这个库用起来比paddleocr舒服很多。

[SWHL]

这个改动是否合理和必要？我问过paddleocr官方人员，能否支持单个字符返回坐标，他们说支持不好，没这个功能，所以我才用的rapidocr，速度更快，还能返回单个字符。

这个改动主要是针对纯英文场景下，请问你那里是需要纯英文场景下，返回单个字母的坐标？

中文和 中英文混合场景，仍然是返回单个字符的坐标的。

想听听你的想法

[longdexin]

我这边有一些实验图片要识别，需要知道每个泳道编号数字的具体位置，然后确定泳道位置，确实是纯英文场景，因为编号挨的近，一般会识别为一串数字。我觉得，无论中文、英文或者混合场景，都应该只返回单个字符的坐标。有单个坐标，计算整体坐标是很容易的，但只有整体坐标，计算单个字符却不现实，一方面，每个字符的大小不一致，再就是，中间往往有一些未知长度的空白区域。只要涉及到合并，就会丢失位置信息。我看了一下，2.1.0版本中的word_box结果，其实并不太理想，也很难做到理想。当然了，单个字符的坐标，在rapidocr中，到底怎么得到的，我不太清楚哈，有可能也是通过整体坐标计算出来的。

[longdexin]

在rapidocr这块，改善算法，把单个字符位置进一步计算精确，是一个好方向。至于如何合并这些字符，不同场景需求不一样，这应该是用户自己要考虑的问题。

[SWHL]

晓得了，现在单个坐标的确是估算出来的呢。我后面看看兼容一下两者吧。

…

---- 回复的原邮件 ---- | 发件人 | ***@***.***> | | 发送日期 | 2025年05月23日 12:07 | | 收件人 | RapidAI/RapidOCR ***@***.***> | | 抄送人 | SWHL ***@***.***>, Comment ***@***.***> | | 主题 | Re: [RapidAI/RapidOCR] 参数介绍 - RapidOCR 文档 (Discussion #433) | 我这边有一些实验图片要识别，需要知道每个泳道编号数字的具体位置，然后确定泳道位置，确实是纯英文场景，因为编号挨的近，一般会识别为一串数字。我觉得，无论中文、英文或者混合场景，都应该只返回单个字符的坐标。有单个坐标，计算整体坐标是很容易的，但只有整体坐标，计算单个字符却不现实，一方面，每个字符的大小不一致，再就是，中间往往有一些未知长度的空白区域。只要涉及到合并，就会丢失位置信息。我看了一下，2.1.0版本中的word_box结果，其实并不太理想，也很难做到理想。当然了，单个字符的坐标，在rapidocr中，到底怎么得到的，我不太清楚哈，有可能也是通过整体坐标计算出来的。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[longdexin]

好的，非常感谢。

[iskyshop]

请教一下如何使用RapidOCR来检测图片上的文字方向是否正向，返回结果中的angleIndex正向为0，其他方向都是1，是否有方案判断旋转了多少度

[SWHL]

内置一个文本行分类模型，分类类别为0,180。
没看到过判断旋转多少度的模型。不过可以通过文本框的坐标来近似计算一下旋转角度

[ApocalypticDoctor]

请问一下对于小图来说 rapidocr比paddleocr的速度慢了3倍 这个情况是正常的吗

[SWHL]

不正常哈。建议给出具体复现代码，我这里排查一下。一般会有些默认超参设置不同导致的。

[ApocalypticDoctor]

感谢回复 刚刚重新测试了一下 开启use_det=True后耗时会增加 如果单纯只是识别文字是很快的 加上位置就会很久了 有没有什么办法可以加快这个速度

[SWHL]

用gpu

[timmykkk]

我用onnxruntime_cann在npu上进行推理，但是报错，参数是按上面写的默认参数来的，rapidocr版本是3.2.0，onnxruntime版本是1.22.0，cann版本是8.1，卡是910b2c，具体报错是：2025-06-30 10:00:30.923194257 [E:onnxruntime:Default, cann_call.cc:139 CannCall] CANNGRAPH failure -1: GRAPH_FAILED ; NPU=0 ; hostname=paddle-server-npu-5db7557d77-dsx8v ; expr=ge::aclgrphBuildModel(graph, options, model);
Traceback (most recent call last):
File "/usr/local/python3.10.17/lib/python3.10/site-packages/rapidocr/inference_engine/onnxruntime/main.py", line 90, in call
return self.session.run(self.get_output_names(), input_dict)[0]
File "/usr/local/python3.10.17/lib/python3.10/site-packages/onnxruntime/capi/onnxruntime_inference_collection.py", line 273, in run
return self._sess.run(output_names, input_feed, run_options)
onnxruntime.capi.onnxruntime_pybind11_state.Fail: [ONNXRuntimeError] : 1 : FAIL : Non-zero status code returned while running Model from PaddlePaddle._18197367658083689701_0 node. Name:'CANNExecutionProvider_Model from PaddlePaddle._18197367658083689701_0_0' Status Message: CANN Graph error executing ge::aclgrphBuildModel(graph, options, model)，请问有解决思路吗

[timmykkk]

报错中还看到了paddlepaddle，可我根本连rapid_paddle都没装

[timmykkk]

我把内存调大不报错了，但是性能特别差，因为我看每次对新的图片进行ocr时都会重新生成一个CANNExecutionProvider_Model from PaddlePaddle._18197367658083689701_0_0.om 类似这种文件名的模型，有没有办法让rapidocr使用生成过的.om模型而不重复生成呢

[SWHL]

这个可以去查一下cann的参数了，我这里并没有这个设备，所以也没具体调试

…

---- 回复的原邮件 ---- | 发件人 | ***@***.***> | | 发送日期 | 2025年07月02日 11:02 | | 收件人 | RapidAI/RapidOCR ***@***.***> | | 抄送人 | SWHL ***@***.***>, Comment ***@***.***> | | 主题 | Re: [RapidAI/RapidOCR] 参数介绍 - RapidOCR 文档 (Discussion #433) | 我把内存调大不报错了，但是性能特别差，因为我看每次对新的图片进行ocr时都会重新生成一个CANNExecutionProvider_Model from PaddlePaddle._18197367658083689701_0_0.om 类似这种文件名的模型，有没有办法让rapidocr使用生成过的.om模型而不重复生成呢 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[xiaoxinismygod]

Python3.8.10环境下，使用engine = RapidOCR(config_path=config_path)调用，设置了font_path (str)字体路径，但是result.vis("vis_result.jpg")还是使用.\Lib\site-packages\rapidocr\models中默认下载的FZYTK.TTF字体，请问下怎么解决？

[SWHL]

我新建了一个issue来跟踪这个问题。issue #498 ，请移步到那里讨论吧

[DamianRice]

请教一下，之前RapidOCR针对C++版本Onnx的库是停止更新了么？我有使用场景需要在CPU桌面程序中运行，之前C++版本的效率及编译大小的非常适合。想咨询一下未来是否会有计划重启？万分感谢。

[SWHL]

不是停止更新了，是有心无力了。欢迎加入维护哈。

[DamianRice]

感谢回复！我先学习一下目前的项目实现，希望有机会可以贡献维护

[lilizee]

在线demo里设置Return word box为true，能将两个挨的比较近的数字分出来——如“123”、“456”。导出yaml文件并本地运行后，图片的结果与demo一致，但print('result')却显示是的“123 456”。请问是什么原因，该怎么才能分开这种相较较近的数字？

[lilizee]

result.txts里显示'06020603 0604'，result.word_results里显示(('0602', 0.99962, [[995, 907], [1085, 906], [1085, 956], [995, 957]]), ('0603', 0.99994, [[1127, 906], [1225, 905], [1225, 954], [1127, 955]]), ('0604', 0.99975, [[1267, 904], [1365, 903], [1365, 953], [1267, 954]])), 确实是分开了

[SWHL]

那我理解使用返回word_results的功能，是不是就可以了？

[lilizee]

是的，感谢作者