hiroi-sora

感谢你的测试！使我找到了长期困扰这个项目的神秘Bug的产生原因。 结论： `0xc0000142` 代码报错是由于CPU缺乏AVX指令集引起。  PaddleOCR-json识别引擎依赖的Opencv图像处理库，默认启用了AVX指令集加速。PaddleOCR C++ 本身也需要AVX支持。因此在CPU无avx的机器上，引擎无法加载dll完成初始化。 关于解决方案： 我在未来可能提供一个 no_avx 版本的软件以供这些cpu使用。遗憾的是Opencv和Paddle官方似乎未提供 no_avx 版动态库，我可能需要改写源码并编译它们；这对我来说是个未知的工程。所以，短时间内这台机器确实是没办法使用本软件了

启动参数填 `--cls=1 --use_angle_cls=1`  为了加快速度，OCR引擎默认不开启方向分类器。可以填以上参数手动开启它，增强对大角度偏转文字的识别效果。 点击软件面板上的灰字可以查看更多参数，或者看看 [README](https://github.com/hiroi-sora/Umi-OCR#%E8%AF%86%E5%88%AB%E5%99%A8%E8%AE%BE%E7%BD%AE) Update：1.3.0版本在设置页勾选“启用方向分类器”就行了。

建议收到 √ 这实际上是两个问题：第一，ocr引擎使用恰当的模型，输出正确的竖排文本段。第二，umi对得到的文段进行整理排序，以正确的顺序输出为纯文本或其他格式。 对于问题一，我不擅长训练模型，得看看paddle有没有相关模型或等相关领域的大佬提供帮助。另外，umi-ocr的界面、后处理模块，和引擎模块是完全独立的。通过更换本地引擎（甚至在线ocr服务）来适配这种场景也是可行的。 对于问题二，如 [issue #12](https://github.com/hiroi-sora/Umi-OCR/issues/12) 这类关于文段排序的问题。我正在开发一套“文段后处理器”框架，它不仅包含我写的忽略水印区域之类的后处理模块，还可以比较方便的拓展，让别的开发者按自己的需求来开发后处理模块。像日文漫画，可能按常规竖排的逻辑来排版 效果很差，那么就可以再写一套专门针对漫画文段的后处理类。**但精力有限，我可能短期内不会着手这类小众模块的具体实现。** Update：`v1.3.0`已实现后处理器框架。

没有太理解，可以说详细点么？😂

请在启动参数填 `--limit_side_len=压缩阈值` ，其中压缩阈值是图片长边的一半（仍不准确的话再加大）。实测高7000像素的长图可以正常识别。  抱歉，这个版本需要填写[启动参数 ](https://github.com/hiroi-sora/Umi-OCR#%E5%90%AF%E5%8A%A8%E5%8F%82%E6%95%B0%E8%AF%B4%E6%98%8E)来配置引擎策略确实比较麻烦。以后会优化UI，用更直观的控件来修改各项参数。

`v1.3.0` 已更新 更直观的设置页。

感谢你的提议，目前还没有这个功能。竖排繁体识别在这个版本刚加入项目中，使用与横排一样的后处理方式，没有考虑周到。更佳的排版方式及自定义排版方向将在以后推出。 如果你急用，且你的识图结果是准确的从左向右。那么可以fork本仓库，在 `release/1.2.6` `main.py` 的第772行（即 analyzeText() 函数中）加一句： ``` oget = reversed(oget) ``` 这将使所有文段逆序输出，即从右向左。

`v1.3.0` 已更新 实用的竖排文本后处理。支持识别从左向右 / 从右向左的竖排文本，严格按顺序输出。

> 经过测试，检测 PrintScreen 键是可行的。这个功能将在 v0.10 提供，谢谢建议！ 感谢你的开发。非常期待新功能~

简单测了一下 PPOCR C++ `cpu_avx_mkl` 版本 系统：win10 硬件：r5 4600u，TDP只有15w的低压u 参数：启用enable_mkldnn，未启用cls，其它默认 已忽略初始化和热身耗时 | 图片编号 | 1 | 2 | 3 | 对照1 | 对照2 | | ------------------- | ------ | ------ |...