hiroi-sora

先搜一下已有Issues嘛。暂时没有原生 MacOS 和 Linux 版本。可以通过[第三方docker](https://github.com/iszmxw/ocr-docker)尝试部署在Linux上。

嗯，当前版本HTTP接口暂不支持文档识别，待后续版本补充。

> pdf指定页码指定位置（矩形坐标） 理论上，指定页码是可以支持的，但指定坐标有点麻烦。 不过，预计接口的返回值里会包含坐标，调用方可以自己根据坐标过滤一下结果。

> 当前最新的2.1.1的版本支持HTTP接口了吗？ 抱歉，还没，我最近比较忙。此外，这项工作的优先级不高，还有一些排在前面的开发计划等待处理。

是的，远期有这个计划。 短期内暂时没有空闲进行这个大型功能的开发。

20231105版 跟后续所用的，是两款不同的二维码识别库，识别准度会有所差异。可能在某些情境下，旧库的准确率更好，而对另一些图片时新库更好。 新库在功能上有一些优势，并且能应对大多数情景，我认为是适合采用的。

软件本体（纯前端）适配Linux的难度应该不大，qt本身支持跨平台，我的代码里也预留了跨平台API的接口。 难在OCR引擎插件。PaddleOCR 和 RapidOCR 插件可能都要重新调整通信方式、调试编译C++代码，有点头大。 我打算下个版本（v2.1.1）加入在线OCR API模块。使得Umi就算无法使用离线OCR插件，也能调用在线服务。然后开始软件本体的Linux适配工作。 至于Linux平台的离线OCR插件，我可以先搞一些不依赖C++代码的插件（[Tesseract](https://github.com/qwedc001/tesseractOCR_umi_plugin)之类），然后再慢慢适配 Paddle 和 Rapid 。 总之，预计可能最早在 v2.1.2 版本，能提供初步的 Linux 平台原生部署支持。（不保证，看实际情况） 目前，可以用这个第三方的方案， [在Docker中跑Umi-OCR](https://github.com/iszmxw/ocr-docker) 。

目前只有很少的OCR引擎采用单字模型结构，即以**单个字符**为单位进行识别。单字模型能原生支持输出字符坐标。 更多的主流OCR引擎，使用的是 `编码器+解码器` 的模型结构。它们以**行/文本块/序列向量**为单位进行识别。  `编码器+解码器` 结构原生不一定支持输出单个字符的坐标，或者需要一定的转换步骤才能提取到。 Umi-OCR 为了兼容不同结构的引擎插件，选择了最通用的接口格式，即以**行/文本块**为最小单位。因此，暂时无法支持输出单字坐标。

据我所知，似乎没有开源/离线组件支持单字分割。 以下两个在线商业服务支持： [阿里云OCR](https://ai.aliyun.com/ocr/general) [腾讯云OCR](https://cloud.tencent.com/document/product/866/33527)

技术上不难，一直懒得写而已😂 我之后会写一写，预计添加到下个版本。