We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
目前的离线ocr使用PaddleOCR的c++部署和python部署(mac下)编译而成。 这样的方式有几个缺点
综上,新的离线OCR需要主要使用js语言、与nodejs耦合度较高、跨平台更快捷、同时性能不会损失太大
幸好onnx让这一设想成为可能 设想使用onnxruntime,保证执行模型时的性能 会在周末时间开发,预计3周,可能其他功能的开发会推后 目前已实现:
The text was updated successfully, but these errors were encountered:
非常强大,大佬,演示视频中的Dock栏是Windows软件吗?叫什么?😀
Sorry, something went wrong.
非常强大,大佬,演示视频中的Dock栏是Windows软件吗?叫什么?grinning
是kde plasma的面板,kde主要提供linux桌面,不知windows有没有
大佬,可以增加跨屏截图吗? 绘制截图区域的时候,canvas 绘制4个阴影区和1个透明区,在快速拖4条边或者4个角,会出现绘制卡顿问题;
跨屏截图太难了,现在没精力搞😔 卡顿是怎么样的,是整个软件卡还是拖动不跟手,屏幕分辨率是怎样的,能创建个新issue描述一下吗
No branches or pull requests
目前的离线ocr使用PaddleOCR的c++部署和python部署(mac下)编译而成。
这样的方式有几个缺点
我个人的能力不行衍生出不可把握的问题:原先使用离线ocr的逻辑是:保存框选区域到临时文件夹,使用编译好的二进制文件识别,输出结果并返回到eSearch,此过程耦合性较小,还会有许多奇怪的错误(比如 OCR报错 #6 中的路径配置错误)。
综上,新的离线OCR需要主要使用js语言、与nodejs耦合度较高、跨平台更快捷、同时性能不会损失太大
幸好onnx让这一设想成为可能
设想使用onnxruntime,保证执行模型时的性能
会在周末时间开发,预计3周,可能其他功能的开发会推后
目前已实现:
The text was updated successfully, but these errors were encountered: