# PaddleOCR-json
**Repository Path**: spklee/PaddleOCR-json
## Basic Information
- **Project Name**: PaddleOCR-json
- **Description**: 转自:https://github.com/hiroi-sora/PaddleOCR-json;
umi-OCR的引擎,可以单独起服务供CLI使用。还提供了各语言的API。
- **Primary Language**: Unknown
- **License**: Apache-2.0
- **Default Branch**: autoclean
- **Homepage**: None
- **GVP Project**: No
## Statistics
- **Stars**: 1
- **Forks**: 0
- **Created**: 2024-09-13
- **Last Updated**: 2024-11-26
## Categories & Tags
**Categories**: Uncategorized
**Tags**: 代码
## README
#### 离线OCR组件 系列项目:
- **PaddleOCR-json**
- [RapidOCR-json](https://github.com/hiroi-sora/RapidOCR-json)
| | PaddleOCR-json | RapidOCR-json |
| ---------------- | ----------------------------------------------- | -------------------- |
| CPU要求 | CPU必须具有AVX指令集。不支持以下CPU: | 无特殊要求 👍 |
| | 凌动Atom,安腾Itanium,赛扬Celeron,奔腾Pentium | |
| 推理加速库 | mkldnn 👍 | 无 |
| 识别速度 | 快(启用mkldnn加速)👍 | 中等 |
| | 极慢(不启用mkldnn) | |
| 初始化耗时 | 约2s,慢 | 0.1s内,快 👍 |
| 组件体积(压缩) | 52MB | 15MB 👍 |
| 组件体积(部署) | 250MB | 30MB 👍 |
| CPU占用 | 高,榨干硬件性能 | 较低,对低配机器友好 |
| 内存占用峰值 | >2000MB(启用mkldnn) | ~500MB 👍 |
| | ~600MB(不启用mkldnn) | |
---
# PaddleOCR-json
> 支持: **Win7 x64**、**Linux x64**、[Docker](cpp/README-docker.md)
这是一个基于 [PaddleOCR v2.6 C++](https://github.com/PaddlePaddle/PaddleOCR/tree/release/2.6) 的离线图片OCR文字识别程序,可快速让你的程序拥有OCR能力。它可以作为一个子进程被上层程序调用,也可以作为一个单独的进程通过TCP调用。本项目提供了Python等语言的API,你可以无视技术细节,通过两行代码使用它。
本项目旨在提供一个封装好的OCR引擎组件,使得没有C++编程基础的开发者也可以用别的语言来简单地调用OCR,享受到更快的运行效率、更便捷的打包&部署手段。
- **方便** :部署方便,解压即用,无需安装和配置环境,无需联网。发布方便,可嵌入程序包也可作为外挂组件。
- **高速** :基于 PPOCR C++ 版引擎,识别效率显著高于Python版本PPOCR及其他一些由Python编写的OCR引擎。
- **精准** :附带PPOCR-v3识别库,对非常规字形(手写、艺术字、小字、杂乱背景等)也具有不错的识别率。
- **灵活** :可以以多种方式指定OCR任务,支持识别本地图片路径、剪贴板图片、Base64编码的图片。
**应用:[Umi-OCR 批量图片转文字工具](https://github.com/hiroi-sora/Umi-OCR)**
## 兼容性
- 系统支持 Win7 x64 及以上。Linux的支持正在筹备。
- 若 Win7 报错`计算机中丢失 VCOMP140.DLL` ,请安装 [VC运行库](https://aka.ms/vs/17/release/vc_redist.x64.exe) 。
- CPU必须具有AVX指令集。常见的家用CPU一般都满足该条件。
| AVX | 支持的产品系列 | 不支持 |
| ----- | ------------------------------------------------------ | ----------------------------------------------- |
| Intel | 酷睿Core,至强Xeon | 凌动Atom,安腾Itanium,赛扬Celeron,奔腾Pentium |
| AMD | 推土机架构及之后的产品,如锐龙Ryzen、速龙Athlon、FX 等 | K10架构及之前的产品 |
- 如果需求在无AVX的CPU上使用OCR,可看看隔壁 [RapidOCR-json](https://github.com/hiroi-sora/RapidOCR-json) 。
## 准备工作
下载可执行文件包:
- Windows: [Release](https://github.com/hiroi-sora/PaddleOCR-json/releases/latest)
- Linux: [Gavin1937/Release](https://github.com/Gavin1937/PaddleOCR-json/releases/tag/v1.4.0-alpha.2)
### 简单试用
`PaddleOCR-json.exe -image_path="test.jpg"`
## 通过API调用
调用流程大体分为如下几步。不同API的具体接口可能有细微差别。
- 启动:启动并初始化引擎子进程。
- 工作:调用识图接口,获取返回值。目前支持识别 **本地图片文件** 、 **剪贴板中的图片** 、 **Base64编码的图片** 。
- 关闭:结束引擎进程,释放内存资源。
## API列表
`资源目录`下有更详细的使用说明及demo。
### 1. Python API
[资源目录](api/python)
使用示例
```python
from PPOCR_api import GetOcrApi
# 初始化识别器对象,传入 PaddleOCR_json.exe 的路径
ocr = GetOcrApi("……\PaddleOCR-json.exe")
# 识别图片,传入图片路径
getObj = ocr.run(r'………\测试.png')
print(f'图片识别完毕,状态码:{getObj["code"]} 结果:\n{getObj["data"]}\n')
```
Python API 有丰富的附加模块:便于开发者调试观察的可视化模块;和[Umi-OCR](https://github.com/hiroi-sora/Umi-OCR)带来的文本块后处理(段落合并)技术。详细使用方法见 [资源目录](api/python)
### 2. Node.js API
[资源目录](api/node.js)
使用示例
```
npm install paddleocrjson
```
```js
const OCR = require('paddleocrjson');
// const OCR = require('paddleocrjson/es5'); // ES5
const ocr = new OCR('PaddleOCR-json.exe', [/* '-port=9985', '-addr=loopback' */], {
cwd: './PaddleOCR-json',
}, false);
ocr.flush({ image_path: 'path/to/test/img' })
.then((data) => console.log(data));
.then(() => ocr.terminate());
```
### 3. PowerShell API
[资源目录](api/PowerShell)
### 4. Java API
[资源目录](https://github.com/jerrylususu/PaddleOCR-json-java-api)
### 5. .NET API
[资源目录](https://github.com/aki-0929/PaddleOCRJson.NET)
### 6. Rust API
[资源目录](https://github.com/OverflowCat/paddleocr)
### 7. Go API
[资源目录](https://github.com/doraemonkeys/paddleocr)
### 更多语言API
欢迎补充!请参考 [详细使用指南](docs/详细使用指南.md) 。
## 常用配置参数说明
| 键名称 | 默认值 | 值说明 |
| -------------- | ------ | ----------------------------------------------------------------------------------- |
| config_path | "" | 可以指定不同语言的配置文件路径,识别多国语言。[详情见下节](#语言库与切换识别语言)。 |
| models_path | "" | 可以指定语言库 `models` 文件夹的路径。[详情见下节](#语言库与切换识别语言)。 |
| cls | false | 启用cls方向分类,识别方向不是正朝上的图片。 |
| use_angle_cls | false | 启用方向分类,必须与cls值相同。 |
| enable_mkldnn | true | 启用CPU推理加速,关掉可以减少内存占用,但会降低速度。 |
| limit_side_len | 960 | 对图像边长进行限制,降低分辨率,加快速度。 |
| | | 如果对大图/长图的识别率低,可增大 limit_side_len 的值。 |
| | | 建议为 32 & 48 的公倍数,如 960, 2880, 4320 |
| auto_memory_cleanup | 1800 | 设置无OCR工作时自动清理内存来减少占用。 |
| | | 值 <= 0 时禁用功能。 |
| | | 值 > 0 时将值作为时间(秒),每当无OCR工作一段时间后就清理一次内存。 |
| | | 默认值 1800 秒(30分钟)。 |
更多参数详见 [args.cpp](/cpp/src/args.cpp) 。(不支持其中GPU相关、表格识别相关的参数。-)
### 语言库与切换识别语言:
`v1.3`版本的Release压缩包中,默认附带了 `简中,繁中,英,日,韩,俄,德,法` 的语言库与配置文件,在 `models` 目录下。
`models` 目录中,每一个 `config_xxx.txt` 是一组语言配置文件(如英文是`congfig_en.txt`)。只需将这个文件的路径传入 `config_path` 参数,即可切换为对应的语言。以 Python API 为例:
```python
enginePath = "D:/Test/PaddleOCR_json.exe" # 引擎路径
argument = {"config_path": "models/config_en.txt"} # 指定使用英文库
ocr = GetOcrApi(enginePath, argument)
```
如果 config_path 留空,则 PaddleOCR-json 默认加载并使用简体中文识别库。
但是,当使用默认路径或单独设置 `config_path` 时,PaddleOCR-json可执行文件必须与语言库在同一目录下。比如:
```
.
├─ PaddleOCR-json.exe
└─ models
├─ ...
```
如果语言库在另外一个文件夹下,PaddleOCR-json就无法找到语言库。
在这种情况下,你可以使用 `models_path` 参数来设置语言库的位置。PaddleOCR-json会使用用户设置的语言库位置为基准来加载其他文件。
这样一来,即使 PaddleOCR-json 与语言库不在同一目录下也能正常使用。以 Python API 为例:
```python
enginePath = "D:/Test/PaddleOCR_json.exe" # 引擎路径
modelsPath = "D:/Hello/models" # 语言库路径路径
# 这里的参数顺序不影响结果
argument = {
# 指定语言库位置
"models_path": "D:/Hello/models",
# 指定使用英文库
"config_path": "D:/Hello/models/config_en.txt",
}
ocr = GetOcrApi(enginePath, argument)
```
#### 删除语言库:
若你希望删除吃灰的语言库文件以便减少软件体积,可以删除 `models` 目录中含有对应语言前缀和 **rec_infer** 后缀的文件夹。比如你希望删除日语`japan`相关的库,只需删除该文件夹:
`japan_PP-OCRv3_rec_infer`
一组语言的rec库大约占用10MB空间(未压缩)。若删除到仅剩1组语言,可以节省约60MB空间。
请不要删除cls_infer及det_infer后缀的文件夹,这是所有语言公用的检测/方向分类库。
## 返回值说明
通过API调用一次OCR,无论成功与否,都会返回一个字典。
字典中,根含两个元素:状态码`code`和内容`data`。
状态码`code`为整数,每种状态码对应一种情况:
##### `100` 识别到文字
- data内容为数组。数组每一项为字典,含三个元素:
- `text` :文本内容,字符串。
- `box` :文本包围盒,长度为4的数组,分别为左上角、右上角、右下角、左下角的`[x,y]`。整数。
- `score` :识别置信度,浮点数。
- 例:
```
{'code':100,'data':[{'box':[[13,5],[161,5],[161,27],[13,27]],'score':0.9996442794799805,'text':'飞舞的因果交流'}]}
```
##### `101` 未识别到文字
- data为字符串:`No text found in image. Path:"图片路径"`
- 例:```{'code':101,'data':'No text found in image. Path: "D:\\空白.png"'}```
- 这是正常现象,识别没有文字的空白图片时会出现这种结果。
##### `200` 图片路径不存在
- data:`Image path dose not exist. Path:"图片路径".`
- 例:`{'code':200,'data':'Image path dose not exist. Path: "D:\\不存在.png"'}`
- 注意,在系统未开启utf-8支持(`使用 Unicode UTF-8 提供全球语言支持"`)时,不能读入含emoji等特殊字符的路径(如`😀.png`)。但一般的中文及其他 Unicode 字符路径是没问题的,不受系统区域及默认编码影响。
##### `201` 图片路径string无法转换到wstring
- data:`Image path failed to convert to utf-16 wstring. Path: "图片路径".`
- 使用API时,理论上不会报这个错。
- 开发API时,若传入字符串的编码不合法,有可能报这个错。
##### `202` 图片路径存在,但无法打开文件
- data:`Image open failed. Path: "图片路径".`
- 可能由系统权限等原因引起。
##### `203` 图片打开成功,但读取到的内容无法被opencv解码
- data:`Image decode failed. Path: "图片路径".`
- 注意,引擎不以文件后缀来区分各种图片,而是对存在的路径,均读入字节尝试解码。若传入的文件路径不是图片,或图片已损坏,则会报这个错。
- 反之,将正常图片的后缀改为别的(如`.png`改成`.jpg或.exe`),也可以被正常识别。
剪贴板相关接口已弃用,不建议使用
##### `210` 剪贴板打开失败
- data:`Clipboard open failed.`
- 可能由别的程序正在占用剪贴板等原因引起。
##### `211` 剪贴板为空
- data:`Clipboard is empty.`
##### `212` 剪贴板的格式不支持
- data:`Clipboard format is not valid.`
- 引擎只能识别剪贴板中的位图或文件。若不是这两种格式(如复制了一段文本),则会报这个错。
##### `213` 剪贴板获取内容句柄失败
- data:`Getting clipboard data handle failed.`
- 可能由别的程序正在占用剪贴板等原因引起。
##### `214` 剪贴板查询到的文件的数量不为1
- data:`Clipboard number of query files is not valid. Number: 文件数量`
- 只允许一次复制一个文件。一次复制多个文件再调用OCR会得到此报错。
##### `215` 剪贴板检索图形对象信息失败
- data:`Clipboard get bitmap object failed.`
- 剪贴板中是位图,但获取位图信息失败。可能由别的程序正在占用剪贴板等原因引起。
##### `216` 剪贴板获取位图数据失败
- data:`Getting clipboard bitmap bits failed.`
- 剪贴板中是位图,获取位图信息成功,但读入缓冲区失败。可能由别的程序正在占用剪贴板等原因引起。
##### `217` 剪贴板中位图的通道数不支持
- data:`Clipboard number of image channels is not valid. Number: 通道数`
- 引擎只允许读入通道为1(黑白)、3(RGB)、4(RGBA)的图片。位图通道数不是1、3或4,会报这个错。
##### `300` base64字符串解析为string失败
- data:`Base64 decode failed.`
- 传入非法Base64字符串引起。(注意,传入Base64信息不应带有`data:image/jpg;base64,`前缀。)
##### `301` base64字符串解析成功,但读取到的内容无法被opencv解码
- data:`Base64 data imdecode failed.`
##### `400` json对象 转字符串失败
- data:`Json dump failed.CODE_ERR_JSON_DUMP`
- 输入异常:传入非法json字符串,或者字符串含非utf-8编码字符导致无法解析引起。
##### `401` json字符串 转对象失败
- data:`Json dump failed.CODE_ERR_JSON_DUMP`
- 输出异常:输出时OCR结果无法被编码为json字符串。
##### `402` json对象 解析某个键时失败
- data:`Json parse key 键名 failed.`
- 比错误码`400`更精准的提示。如果发生异常,程序优先报`402`,无法处理才报`400`。
##### `403` 未发现有效任务
- data:`No valid tasks.`
- 本次传入的指令中不含有效任务。
### [详细使用指南](docs/详细使用指南.md)
👆当你需要修改或开发新API时欢迎参考。
### 项目构建指南
- [Windows 平台](cpp/README.md)
- [Linux 平台](cpp/README-linux.md)
- [Docker 部署](cpp/README-docker.md)
- [移植指南](cpp/docs/移植指南.md) (需要移植项目到不同平台时可供参考)
### 感谢
本项目中使用了 [ReneNyffenegger/cpp-base64](https://github.com/ReneNyffenegger/cpp-base64) :
> “base64 encoding and decoding with c++”
本项目中使用了 [nlohmann/json](https://github.com/nlohmann/json) :
> “JSON for Modern C++”
感谢 [PaddlePaddle/PaddleOCR](https://github.com/PaddlePaddle/PaddleOCR) ,没有它就没有本项目:
> “Awesome multilingual OCR toolkits based on PaddlePaddle”
感谢各位为本项目开发API及贡献代码的朋友!
## 更新日志
版本号链接可前往对应备份分支。
#### v1.3.1 `2023.10.10`
- 兼容 Win7 x64 。
#### [v1.3.0](https://github.com/hiroi-sora/PaddleOCR-json/tree/release/1.3.0) `2023.6.19`
- 修复了一些BUG。
#### v1.3.0 Alpha `2023.5.26`
- 重构代码,条理更清晰,易于移植。
- 新功能:Base64传图片。
- 新功能:套接字服务器模式。
#### [v1.2.1](https://github.com/hiroi-sora/PaddleOCR-json/tree/backups/1.2.1/new_builds) `2022.9.28`
- 修复了一些BUG。
- 解决非中文windows难以读取中文路径的问题,拥抱utf-8,彻底摆脱对gbk等区域性编码的依赖。
- 新功能:直接读取并识别剪贴板内存中的图片。
- 错误代码和提示更详细。
#### [v1.2.0](https://github.com/hiroi-sora/PaddleOCR-json/tree/release/1.2.0) `2022.8.29`
- 修复了一些BUG。
- 增强了面对不合法编码时的健壮性。
- 默认开启mkldnn加速。
- 新功能:json输入及热更新。
#### v1.2.0 Beta `2022.8.26`
- 重构整个工程,核心代码同步PaddleOCR 2.6。
- 对v3版识别库的支持更好。
- 新功能:启动参数。
- 新功能:ascii转义。(感谢 @AutumnSun1996 的提议 [issue #4](https://github.com/hiroi-sora/PaddleOCR-json/issues/4) )
#### [v1.1.1](https://github.com/hiroi-sora/PaddleOCR-json/tree/release/1.1.1) `2022.4.16`
- 修正了漏洞:当`文本检测`识别到区域但`文本识别`未在区域中检测到文字时,可能输出不相符的包围盒。
#### v1.1.0 `2022.4.2`
- 修改了json输出格式,改为状态码+内容,便于调用方判断。
#### v1.0 `2022.3.28`