围绕着OCR构建的截图软件，本地运行，UIUX经过打磨
按下 Alt+Q（可自定义），框选区域即可截图并复制到剪贴板，右下角弹出缩略图：
简体中文 / 繁体中文 / 英文 / 日文（界面 + 识别，效果良好，中日文支持竖排识别）；其他语言效果不保证。
GPL-3.0，github.com/tcita/HushSnap
Microsoft Store（或商店搜索 hushsnap）
【HushSnap,一款把 OCR 当作一等公民的截图工具。V1.5.0 更新:缩略图角花】
两个问题 第一个纯本地运行是如何保证ocr识别的准确率的呢
第二个问题 我记得钉钉企业微信应该带的截图都支持ocr了吧 你这个产品比他们的优势在哪里呢
Q: 纯本地运行如何保证 OCR 识别准确率？
A: 底层引擎是 PP-OCRv6 small + RapidOCR，具体指标可查阅 PPOCR 官方文档。本地小模型不等于精度必然打折——我除了调库外额外的做工作, 比如预处理策略、fallback 逻辑、DB 检测框稳定性处理、排版聚合算法、中日文横竖排判断等调参和实验细节，都在我的 GitHub 仓库里，欢迎交流。
Q: 相对于微信自带 OCR 的优势？
A: 抱歉可能没说清楚——这里对标的其实不是聊天软件
自带截图，而是 Snipping Tool / ShareX 这类无需联网、无需注册、纯本地运行的截图工具。不过你提到微信也确实是个现实场景：开机自启、常驻后台，很多人（包括我在内）图省事就顺手用了它自带的截图 OCR。但这背后有两层问题：一是需要联网登录，隐私不够透明，且截图 OCR 依附于整个微信客户端运行，资源占用不小；二是具体交互体验上也有打磨空间——比如截图后要先点一个会抢焦点的工具栏（很多专门的截图软件已经换成不打扰人的通知栏缩略图了），还得在工具栏里找到 OCR 按钮再点一下；识别出的文字也不支持直接编辑、没有排版容易挤成一团、也没法单独调整识别窗口的文字大小等等优化空间。这些正是 HushSnap 想做好的地方。"围绕着 OCR 构建"具体是什么体验，欢迎下载感受一下。
可惜了，只能通过微软商店下载。。
没有有处理过多屏多缩放比例环境下的截图问题 
，比如有两个屏幕，一个缩放是100%，另一个缩放是150%
有做多屏适配,我自己有用双屏,主屏幕缩放是150%,副屏是175%,分辨率都是2560 × 1600,表现正常
假如有遇到其他多屏适配问题欢迎反馈,谢谢 
此软件是否付费？如果不付费的话，可否提供更多的下载途径？主要是微软商店真的一言难尽，下载不下来。
既然是OCR优先，能否考虑右下角显示时间增加“不显示”的选项。截图完成后增加“直接弹出文本框”选项？如有需要再打开编辑图片功能。
既然用ai写了，为什么要选择python呢，运行效率太差，复杂界面容易卡顿，建议趁早找ai翻译成其他语言。
没必要这样吧，友好讨论，我仅仅是表达在ai时代，编程语言的选择可以非常自由。
因为不全只支持ocr一个功能,如果是只能ocr的话,其实可以设计为砍掉缩略图,直接在光标处弹出文本弹窗比较好
但是我也希望在我个人的使用中,在不与离线,本地冲突,极简的uiux冲突的前提下,能够尽量覆盖大多数场景,所以赋予了缩略图工具栏的功能,比如截图后编辑,钉图,存图什么的,尽量一套快捷键能够覆盖多一点,而不是ocr专门一个软件,其他的用prtsc系统截图;
所以我的设计是最短时长还是加上了5s,因为就像手机截图,或者系统通知,5s我个人觉得已经不打扰人了
不过你的观点我理解,如果做以后决策的时候可能会考虑一下 谢谢你的想法
免费软件,暂时没有收费的想法
用微软商店有几个理由
如果没有msix的沙盒层,我无法判定exe的兼容性,我现在推到微软商店后就用虚拟机从商店下载,几乎能保证其他人的电脑和虚拟机绝大多数情况是一样的; 而且在裸exe的时候,有被杀毒软件连着扫描导致超长的开启时间(>20s),或者直接被SmartScreen拦住的情况(这个我无法复现,只能说有时候有) ,会不会被windows其他机制拦住我也不清楚,而用msix就消失了,购买签名暂时不考虑,除非达到一定规模;
再者两个渠道意味着两套用户反馈、两套版本对齐问题(万一 Store 审核卡住导致两边版本不一致,反而制造混乱),而且 GitHub release 的下载数字基本没有实际意义(爬虫、CI、镜像都会拉高计数),Partner Center 的数据至少是真实设备的安装转化,我维护也稍微困难;
我也知道有个问题,既然主打离线,那么有的电脑可能连微软商店都上不去,又或者像您,不喜欢用微软商店;只走微软商店可能是暂时的权衡,谢谢你的意见
这个我也想过,但是这个和架构有关系
真正的计算密集路径是 OCR 推理（ONNX Runtime，C++）和 图像处理（OpenCV，C++）。Python在这里只是胶水层——把截图喂给 ONNX，把结果传给 Qt 渲染。换成 Rust/C++ 对 OCR 延迟几乎没有提升，并且比如,实测移植到rust+tauri很不跟跟手,用webview产生的几百毫秒的延迟对于截图软件其实影响挺大的 ,PySide6 的 QPixmap、QScreen::grabWindow 底层都是 C++ 原生调用，Python只是在上面做事件布线。实际体验中 UI 响应延迟感知不到语言差异。
即使代码的落地ai可以代劳,但是Python 的写-跑-调周期远快于
Rust（编译+链接），对于频繁调整 UI 行为、文本后处理规则、打包配置的场景，这是实打实的时间节省,而且pyqt很方便,很成熟,能很好的给我想要的功能;
PyInstaller → MSIX 的流水线已经在跑，Rust 要达成同样的 Windows Store
分发，得自己处理 WinRT 绑定、MSIX 打包、代码签名链，工具链成熟度远不如 PyInstaller。
而且上游的ppocr,rapidocr都是python语言,多引入一个语言就代表多一个语言要额外处理,甚至可能导致需要自己维护c++版本的rapidocr之类的过度成本
此外还有其他的理由,比如我相对熟悉python,在做review的时候能更清楚在写什么,省去额外语言理解成本,总而言之,换语言是很大的活,而且直接带来的好处可能集中在软件安装后的大小会更小上,性能提升有限,所以暂且搁置;
谢谢你的想法
感谢回复。
之所以提这个建议，是因为我之前也写过类似的东西，截图框选时总要在python里实时响应吧，框选这个动作在python里总觉得慢半拍。
另外既然选择了msix、winrt，或许C#更适合呢，C#里通过pythonnet调用python也非常方便，可以轻松接入python生态，gui使用C#实现，pythonnet作为胶水层连接ocr。
的确c#我也考虑过,假如哪天有瓶颈,需要重构的时候会想起你的建议的,总之谢谢你的分享
想试试，可惜我是debian
有个工具可以获取应用商店安装包：https://store.rg-adguard.net/
排版这个功能挺好
挺巧,我也是使用 PP-OCRv5和v6,不过我是mac应用
我直接用原生 ONNX Runtime 在 macOS 上跑
