Gavin1937

Hey guys, I have the same needs of running ENCryptor in linux, and I actually rewrote ENCryptor's core library in C. I replaced all the CommonCrypto stuff with OpenSSL3 and...

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

> > 请问PaddleOCR-json 在linux上应该强制要求 AVX 吗？PaddleOCR 官方有推出无 AVX 的预测库 > > 我觉得 Paddle 官方C++推理库的优势是性能好速度快。如果要兼容性或者精简的话，我觉得隔壁 [RapidOCR-json](https://github.com/hiroi-sora/RapidOCR-json) 更合适，它本身不依赖AVX，甚至（在win7上）连VC运行库都不需要，外部依赖性非常小。 也是，那就强制要求要支持 AVX 才能用 PaddleOCR-json 了。

辛苦了。其实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](https://github.com/yhirose/cpp-httplib)，很省事的一个header only library。其他issue也提到过这个需求 #42 5. 当然，PaddleOCR-json的api也要跟着更新 这些功能主要是方便PaddleOCR-json的安装和部署，之后可以很方便的把它放到一个服务器上当OCR后端。这算是我自己的需求，更符合我的环境。 我自己的环境是：用着一台Windows主力机 + 一台Ubuntu的服务器，两台机子内网连接，平常一些耗时的活我都丢给服务器来做。

> 不能热切换语言 > 内存管理的缺陷 也许可以把下面这些个 `detector_`、`classifier_`、和`recognizer_`给重新创造一遍？或者直接把整个PPOCR对象给重建一遍。因为这整个项目只在这里加载models。说不定也能解决(绕过)内存溢出的问题。之后我去试试看。 https://github.com/hiroi-sora/PaddleOCR-json/blob/e23de048577b0e4e3616d11e6231f12e8643a770/cpp/src/paddleocr.cpp#L23-L50 --- > 我的想法是引擎本身就负责好OCR的本职工作 我感觉这个项目的定位有点奇怪？真正的OCR引擎是PaddleOCR，这个项目作为一个wrapper降低了引擎的使用门槛，但是它又提供了更多的功能。比如说直接通过tcp远程连接调用OCR。在我的理解中，这个项目是一个基于PaddleOCR引擎的OCR后端。 > 对外提供一个统一的接口 不过确实，有一个统一的接口会更干净，而且管理起来也方便。确实应该由一个统一的http服务器来专门负责提供接口 + 与引擎通讯。

> 本项目之后要升级重构、跟进 PaddleOCR v2.7+ ，那时候考虑一下精简 确实需要精简。现在整个项目的架构还是有些混乱的，我们自己的代码和PaddleOCR官方的纠缠在一起。直接把他们的[C++部署项目](https://github.com/PaddlePaddle/PaddleOCR/tree/release/2.7.1/deploy/cpp_infer)当成一个library调用会更好。一来我们用不到所有的功能，二来也方便之后的引擎更新。这样就能把我们自己的代码放到一个单独的文件夹下管理。 > OCR引擎都是不支持热切换语言的，都要外部控制模块重新创建进程/对象来切换。所以这部分工作都交给外部吧。 我觉得这个功能还是在C++里写会更好，毕竟直接用C++重建一个PaddleOCR的对象会比重启进程更快更稳定。当然，就算要写也要等重构完之后再写。

是的，本项目底层的其中一个OCR引擎是PaddleOCR v2.7，[仓库在这](https://github.com/hiroi-sora/PaddleOCR-json)

可以检查一下`UmiOCR根目录\UmiOcR-data\runtime\python3.dll`z这个文件在不在。 如果找不到该文件的话就说明您的安装出错了，请重新安装umi ocr 如果找到了该文件，请确保您的umi ocr安装路径是全英文的，然后再尝试一遍 如果文件存在并且安装路径全英文还是报错，那可能是您的系统缺少python3.dll的依赖库，请安装最新的[VC运行库](https://aka.ms/vs/17/release/vc_redist.x64.exe)

@zjcdtc000 升级的主要难点在如何本地部署paddle_inference v3然后能跑起来ppocr v5和其他模型。umi用的是一个基于paddle_inference cpp部署demo修改出来的引擎，[PaddleOCR-json](https://github.com/hiroi-sora/PaddleOCR-json)。我之前尝试更新它的时候卡在了最后一步，编译完没法加载模型。直接编译paddle官方的demo也遇到了同样的问题。您有兴趣的话可以看看[我的这个issue](https://github.com/hiroi-sora/PaddleOCR-json/issues/185)

无头模式的话可以修改`UmiOCR根目录/UmiOCR-data/.settings`文件，里面有几个带有`paddleocr`的设置，可以修改最大线程数、内存大小限制等等。ui里的全局设置也有对应的选项，没找到的话可以在Linux桌面端打开umiocr ui修改一下全局设置然后再参考生成出来的.settings文件