【Linux移植倡议】

[hiroi-sora]

各位开发者，大家好！我是PaddleOCR-json的作者。

PaddleOCR-json刚刚更新了v1.3测试版本，重构了部分代码，让任务流程更清晰，功能分类明确，更适合二次开发工作。对多平台兼容专门做了优化，绑定平台的代码都分离出来单独封装。理论上，移植其他平台，只需要重写少数几个跟进程交互及文件读取有关的函数即可。

另外，考虑到管道交互的潜在的限制性（缓冲区有限，及无纠错机制），v1.3新增了通过TCP交互的方式，在不同平台上也许能提供更稳定和可靠的服务。不过考虑到本项目的初衷是纯本地的应用，而且我的后端开发经验也不足，所以暂未考虑HTTP服务器等更高层的网络交互机制。

现在诚邀有Linux开发经验的人员参与本项目，负责移植Linux的工作。过程中，有任何跟项目流程及功能有关的疑问，都可以在这个issue下提出，我会尽力帮助你。

v1.3中，我重写了全部项目文档，希望这些文档会对你有帮助：

• 移植指南
• 主页README
• 详细使用指南
• 项目构建指南

[Gavin1937]

请问PaddleOCR-json 在linux上应该强制要求 AVX 吗？PaddleOCR 官方有推出无 AVX 的预测库（manylinux_cpu_noavx_openblas_gcc8.2）。我在无 AVX 的虚拟机里面测试的时候也可以成功编译 PaddleOCR-json。当然，跑不起来，报错 Illegal instruction

user@debian:~/PaddleOCR-json/cpp$ cmake -S . -B build/ -DPADDLE_LIB=$PADDLE_LIB -DWITH_MKL=OFF
cmake cxx flags  -std=c++11
default cmake for auto_log, no need to compile
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/PaddleOCR-json/cpp/build
user@debian:~/PaddleOCR-json/cpp$ cmake --build build/
[100%] Built target ppocr
user@debian:~/PaddleOCR-json/cpp$ cd .source/
user@debian:~/PaddleOCR-json/cpp/.source$ LD_LIBRARY_PATH=$LIBS ../build/ppocr -config_path=models/config_chinese.txt -image_path='data/img1.png' -enable_mkldnn=false
PaddleOCR-json v1.3.1 dev
Load config from [models/config_chinese.txt] : det_model_dir set to models/ch_PP-OCRv3_det_infercls_model_dir set to models/ch_ppocr_mobile_v2.0_cls_inferrec_model_dir set to models/ch_PP-OCRv3_rec_inferrec_char_dict_path set to models/dict_chinese.txt.
OCR single image mode. Path: data/img1.png
OCR init completed.
pathU8: data/img1.png
Illegal instruction
user@debian:~/PaddleOCR-json/cpp/.source$ lscpu | grep Flags | grep avx
user@debian:~/PaddleOCR-json/cpp/.source$

[hiroi-sora]

请问PaddleOCR-json 在linux上应该强制要求 AVX 吗？PaddleOCR 官方有推出无 AVX 的预测库

我觉得 Paddle 官方C++推理库的优势是性能好速度快。如果要兼容性或者精简的话，我觉得隔壁 RapidOCR-json 更合适，它本身不依赖AVX，甚至（在win7上）连VC运行库都不需要，外部依赖性非常小。

[Gavin1937]

请问PaddleOCR-json 在linux上应该强制要求 AVX 吗？PaddleOCR 官方有推出无 AVX 的预测库

我觉得 Paddle 官方C++推理库的优势是性能好速度快。如果要兼容性或者精简的话，我觉得隔壁 RapidOCR-json 更合适，它本身不依赖AVX，甚至（在win7上）连VC运行库都不需要，外部依赖性非常小。

也是，那就强制要求要支持 AVX 才能用 PaddleOCR-json 了。

[hiroi-sora]

Umi-OCR 初步的 Linux 运行环境：

https://github.com/hiroi-sora/Umi-OCR_runtime_linux

如果 PaddleOCR-json 这边已经基本完成了 Linux 兼容工作，那么下一步可以尝试进行 Umi 的移植了。

继续欢迎你的PR~

[Gavin1937]

辛苦了。其实PaddleOCR-json这边我还想加几个小功能：

1. 更新CMakeLists，直接用 cmake --install 来安装PaddleOCR-json到系统（或者指定一个安装文件夹）。这样子既可以实现安装也方便之后打包
2. 更新参数，可以直接输入models文件夹的路径来加载推理库，这样就不用让PaddleOCR-json强制与models文件夹在同一目录下了
3. 加一个Dockerfile，方便docker部署
4. 顺手再写一个rest服务器，方便其他软件集成。毕竟PaddleOCR-json在跨进程数据传输时用的都是json，只需要把现有的socket服务器换成http的就行了。直接用cpp-httplib，很省事的一个header only library。其他issue也提到过这个需求 提供restfull接口调用方式 #42
5. 当然，PaddleOCR-json的api也要跟着更新

这些功能主要是方便PaddleOCR-json的安装和部署，之后可以很方便的把它放到一个服务器上当OCR后端。这算是我自己的需求，更符合我的环境。

我自己的环境是：用着一台Windows主力机 + 一台Ubuntu的服务器，两台机子内网连接，平常一些耗时的活我都丢给服务器来做。

[hiroi-sora]

好！感谢贡献~

Docker是好文明，环境变量定义一下端口和外部models路径，用起来就方便了。

但是有两个难点：

• 目前的引擎结构，一个进程只能载入一组语言模型库。也就是不能热切换语言，必须停止旧进程，开启新进程并传入新的语言库，才能切换不同语言。
• 我们目前用的 Paddle 2.6 mkldnn 是Paddle系速度最快的推理库，但有内存管理的缺陷，长期使用内存会越占越多。这是mkldnn加速库本身的问题，很难改正。

只靠C++代码较难解决上述问题，因此 Umi-OCR 的 PPOCR插件 靠 Python 来管理内存和切换进程。

如果要做成Docker，可能也要考虑用 Python 等控制手段来负责这些工作。

---

另外聊聊：OCR引擎是很多的，有 Paddle，Rapid，TesseractOCR…… 等一堆。我的想法是引擎本身就负责好OCR的本职工作，而服务器模式等附加功能，就交给 Umi 等上级组件来实现。就像 one-api 协调多种大模型、对外提供一个统一的接口一样，我希望未来也能实现一个协调多种OCR引擎的系统，对外提供统一的接口。

[Gavin1937]

不能热切换语言

内存管理的缺陷

也许可以把下面这些个 detector_、classifier_、和recognizer_给重新创造一遍？或者直接把整个PPOCR对象给重建一遍。因为这整个项目只在这里加载models。说不定也能解决(绕过)内存溢出的问题。之后我去试试看。

PaddleOCR-json/cpp/src/paddleocr.cpp

Lines 23 to 50 in e23de04

	PPOCR::PPOCR()
	{
	if (FLAGS_det)
	{
	this->detector_ = new DBDetector(
	FLAGS_det_model_dir, FLAGS_use_gpu, FLAGS_gpu_id, FLAGS_gpu_mem,
	FLAGS_cpu_threads, FLAGS_enable_mkldnn, FLAGS_limit_type,
	FLAGS_limit_side_len, FLAGS_det_db_thresh, FLAGS_det_db_box_thresh,
	FLAGS_det_db_unclip_ratio, FLAGS_det_db_score_mode, FLAGS_use_dilation,
	FLAGS_use_tensorrt, FLAGS_precision);
	}
	if (FLAGS_cls && FLAGS_use_angle_cls)
	{
	this->classifier_ = new Classifier(
	FLAGS_cls_model_dir, FLAGS_use_gpu, FLAGS_gpu_id, FLAGS_gpu_mem,
	FLAGS_cpu_threads, FLAGS_enable_mkldnn, FLAGS_cls_thresh,
	FLAGS_use_tensorrt, FLAGS_precision, FLAGS_cls_batch_num);
	}
	if (FLAGS_rec)
	{
	this->recognizer_ = new CRNNRecognizer(
	FLAGS_rec_model_dir, FLAGS_use_gpu, FLAGS_gpu_id, FLAGS_gpu_mem,
	FLAGS_cpu_threads, FLAGS_enable_mkldnn, FLAGS_rec_char_dict_path,
	FLAGS_use_tensorrt, FLAGS_precision, FLAGS_rec_batch_num,
	FLAGS_rec_img_h, FLAGS_rec_img_w);
	}
	};

---

我的想法是引擎本身就负责好OCR的本职工作

我感觉这个项目的定位有点奇怪？真正的OCR引擎是PaddleOCR，这个项目作为一个wrapper降低了引擎的使用门槛，但是它又提供了更多的功能。比如说直接通过tcp远程连接调用OCR。在我的理解中，这个项目是一个基于PaddleOCR引擎的OCR后端。

对外提供一个统一的接口

不过确实，有一个统一的接口会更干净，而且管理起来也方便。确实应该由一个统一的http服务器来专门负责提供接口 + 与引擎通讯。

[hiroi-sora]

感觉这个项目的定位有点奇怪？这个项目作为一个wrapper降低了引擎的使用门槛，但是它又提供了更多的功能。比如说直接通过tcp远程连接调用OCR

嘛，算是项目前期考虑得比较多，添加了一些 基础以外的功能。而现在， Umi-OCR v2 实际上只需要调用两种基础功能：

• 输入路径，进行OCR
• 输入base64，进行OCR

其余功能都由外部控制模块来负责。

现在先保留多余的功能吧，本项目之后要升级重构、跟进 PaddleOCR v2.7+ ，那时候考虑一下精简。

把下面这些个 detector_、classifier_、和recognizer_给重新创造一遍？或者直接把整个PPOCR对象给重建一遍。因为这整个项目只在这里加载models。说不定也能解决(绕过)内存溢出的问题。

新的 PaddleOCR v2.7 版本换了后端推理库，砍掉了 mkldnn ，所以也顺带解决了内存泄露的问题。代价是速度似乎下降了一点。（解决不了问题就解决提出问题的模块😂）

至于切换语言，除了 Paddle ，其实很多（大多数？）OCR引擎都是不支持热切换语言的，都要外部控制模块重新创建进程/对象来切换。所以这部分工作都交给外部吧。

因此，我觉得暂时无需在C++端开发相关功能。

[Gavin1937]

本项目之后要升级重构、跟进 PaddleOCR v2.7+ ，那时候考虑一下精简

确实需要精简。现在整个项目的架构还是有些混乱的，我们自己的代码和PaddleOCR官方的纠缠在一起。直接把他们的C++部署项目当成一个library调用会更好。一来我们用不到所有的功能，二来也方便之后的引擎更新。这样就能把我们自己的代码放到一个单独的文件夹下管理。

OCR引擎都是不支持热切换语言的，都要外部控制模块重新创建进程/对象来切换。所以这部分工作都交给外部吧。

我觉得这个功能还是在C++里写会更好，毕竟直接用C++重建一个PaddleOCR的对象会比重启进程更快更稳定。当然，就算要写也要等重构完之后再写。