Open Takenforgranted opened 4 months ago
hiroi-sora
commented
4 months ago 感谢建议~~
希望能够实现对于数学公式OCR识别结果的渲染
我之前也有研究过这个方面，技术上是可以实现的。不过，工程上，需要先对现有插件机制后端进行一次重构升级，才能做前端的适配。
当前，P2T的公式识别，在后端是复用普通文字识别的业务流程。未来我想为公式识别、表格识别等不同任务种类，分配不同的后端业务流程，这样前端才好切换不同UI来显示结果。
不过我最近也忙，连着出差😂只能等有空了
自动版本检查/升级机制也一样，我希望重构了插件后端之后加入它，这样每个版本升级可能仅需下载几KB的纯代码文件，无需重新下载占空间大头的OCR引擎插件。
就像老婆饼里面的老婆一样找不到
（笑
Takenforgranted
commented
4 months ago 那我就慢慢等待期待着更新了，你的GitHub活动挺频繁的倒不担心断更。
Takenforgranted
commented
4 months ago 自动版本检查/升级机制也一样，我希望重构了插件后端之后加入它，这样每个版本升级可能仅需下载几KB的纯代码文件，无需重新下载占空间大头的OCR引擎插件。
每次的更新还分为插件版本的更新和软件版本的更新，不同版本之间可能存在冲突或不兼容，如果都可视化的话，可能需要用到git来实现灵活管理。 任重而道远，慢慢来了。
希望能够实现对于数学公式OCR识别结果的渲染，而不只是显示latex代码。在这里我以对高斯公式的识别为例子：
うみOCR的识别结果如下，我觉得单纯的显示latex代码有点一言难尽……
而我在另一个识别软件里面得到的结果是latex代码和公式渲染后的结果如下：
我感觉如果能改为后者会更好看，这并不是对于识别结果精确度的需求，而是对于latex公式识别结果的显示的建议。而且关于公式识别还有很多地方是值得改进添加的功能，比如这个copy的latex代码格式的设置：
对于软件整体评价挺好，而且你们确实也是每一个版本都有进步——想当初umi-OCR启动响应时间可是有足足20s+，现在最新的差不多应该是5s内。很多非盈利的游戏爱好者团队在对游戏解包后制作剧情相关的wiki时都可能会用到你们的软件。 God bless your future version！
Appendix： 运行环境，About里面有，挺有创意的： { "cpu": "Intel64 Family 6 Model 154 Stepping 3, GenuineIntel | 14C20T", "home": "E:\some tools\ToolBox\Umi-OCR_Paddle_v2.1.0", "path": "E:\some tools\ToolBox\Umi-OCR_Paddle_v2.1.0\Umi-OCR.exe", "platform": "Windows-10-10.0.22631", "python": "3.8.10", "ram": "15.7 GB" } （你们的名字うみ应该是海，但是这个元素在你们的软件里面就像老婆饼里面的老婆一样找不到啊。）