【GdOcrTool】即指即译，OCR取词工具

Vim · 2021 年12 月 5 日 14:07

请教：使用新版GdOcrTool.ahk后，为什么无法通过以下代码关闭它？有什么特别机制？

closeScript("GdOcrTool.ahk")
closeScript(Name) {
    DetectHiddenWindows On
    SetTitleMatchMode RegEx
    IfWinExist, i)%Name%.* ahk_class AutoHotkey
        {
        WinClose
        WinWaitClose, i)%Name%.* ahk_class AutoHotkey, , 2
        If ErrorLevel
            MsgBox, "Unable to close " . Name
            ; return "Unable to close " . Name
        else
            MsgBox, "Closed " . Name
            ; return "Closed " . Name
        }
    else
        return Name . " not found"
}

使用这个也不行：

closeApps("GdOcrTool.ahk")
closeApps(Name) {
    DetectHiddenWindows On
    SetTitleMatchMode RegEx
    process, exist, %Name%
    pid = %ErrorLevel%
    Process, Close, %pid%
}

medp7060 · 2021 年12 月 5 日 20:25

@Johnny_Van 非常感谢！

特别喜欢“区域取词修改鼠标指针为十字，冻结屏幕”功能，这便于对pdf文件区域取词。

现在， [GoldenDict 官方版 OCR 功能]已经相当完善了！今后的任何改进都是锦上添花了！

请教一下：之前的鼠标冻结是哪里有问题？我想长点见识。

Johnny_Van · 2021 年12 月 6 日 01:26

用链接里这个试试：

Johnny_Van · 2021 年12 月 6 日 01:31

上一版本区域取词等待剪贴板返回之前会一直占用鼠标，新版本画框结束左键抬起时立即释放鼠标。

yaviscz · 2021 年12 月 6 日 15:03

你的这个打包简单好用，楼主更新了，自己不会配置，期待你的打包也更新一下。谢谢。

medp7060 · 2021 年12 月 6 日 20:52

楼主 @Johnny_Van 已经全部自动化了，“不需要手动配置了，与文件路径相关的配置均由对话框进行”。我的包仍然可用，但是需要如下改动：
1）下载更新了的GdOcrTool.exe和Capture2Text.ini，置于Capture2Text.exe 文件所在的目录。
2）把我的包里的 GoldenDict.exe 改名为GoldenDict.exe.old (或者直接删了)，再把我的包里的 GoldenDictOCR.exe 改名为GoldenDict.exe。(不改名也可以，只是在用对话框找“GoldenDict.exe”时，直接选择“GoldenDictOCR.exe”就可以了)
3）启动GdOcrTool.exe，用对话框完成路径相关的配置。

如果嫌麻烦，下载GoldenDict_OCR-All-in-1_update 20211205.rar (x32 and x64通用)，覆盖旧的文件，这样使用方法不变 (即直接启动GoldenDict.exe)。
GoldenDict_OCR-All-in-1_update 20211205.rar (351.2 KB)

2021/12/30更新 ：楼主更新了（2021/12/15），如果要用更新了的版本，下载GoldenDict_OCR-All-in-1_update 20211215.rar (x32 and x64通用)，覆盖旧的文件，这样使用方法不变 (即直接启动GoldenDict.exe)。
GoldenDict_OCR-All-in-1_update 20211215.rar (352.4 KB)

medp7060 · 2021 年12 月 6 日 23:12

知道了，谢谢。

My testing: The new version handles the apostrophe ( ’ ) very well except when it is followed by another word. e.g.

I placed the cursor on y, r, o of “memory”, I got the following results: (sometimes, but not always)

New version: 2021/12/05

y - mputer
r - omputer
o - computer

Previous version:

y - mputerW
r - omputerW
o - (failed)

It was correctly recognized by all versions when clicked on m-e-m

m - memory
e - memory
m - memory

It looked like the results were affected by the image’s view size and the Capture2Text settings.

Johnny_Van · 2021 年12 月 7 日 01:29

单点取词依赖于从 Capture2Text 获取的两次 OCR 的结果，Text Line Capture 和 Forward Text Line Capture，然后从中推测鼠标下的单词。受限于该取词原理，某些条件无法得到正确结果。

在 GdOcrTool.ini 中修改 EnableDebugInfo 可查看两步 OCR 识别到的所有字符。

从你的结果上看，在你电脑上显示的字体应该很大。在我这边分辨率下识别上图的 computer 和 memory 没有出现你说的情况。

Johnny_Van · 2021 年12 月 7 日 02:48

假设原始文本为 “the place where a piece of information is stored in a computer’s memory”，
鼠标位于 “piece” 中间的 “e” 处。

Text Line Capture 和 Forward Text Line Capture 会依据 Capture2Text 设置页 OCR 2 分别画出两个框，假设识别到的字符串分别为，
Text Line Capture ①：“he place where a piece of informati”，
Forward Text Line Capture ②：“ece of mforma”，

前一个版本 GdOcrTool 会直接判定识别失败，因为两次识别有歧义，无法判断哪个更准确。

而新版本中采用了两种提取方式一、二，其中方式一会逐个剔除②末尾的字符直至消除歧义，即②变成 “ece of”，可在①中准确定位。

如果②识别到的字符串为：“lece of information is”，这时方式一会失效，切换到方式二：按标点及空格将②截断成 “lece”，且将①拆分成 “the”，“place”，“where”，…，“piece”，… 这时将②的 “lece” 从最末字符起逐个与①拆分出的单词候选比较，找出匹配最多的一个。

鉴于画框中央识别的字符相比于边缘更准确，即使有歧义，也取 Text Line Capture 的识别结果为准。

当然这两种提取方式仅是折衷方案，受限于 Capture2Text 所能提供的结果。

又假设原始文本为 “the place where a piece”，且右边没有任何文字，而鼠标置于 “piece” 的最末尾 “e”。若 OCR 识别到的字符串完全正确，
Text Line Capture ①：“lace where a piece”，
Forward Text Line Capture ②：“e”，
这时候从原理上无法判断这个 “e” 是属于 “lace”，“where” 还是 “piece”。

medp7060 · 2021 年12 月 7 日 03:43

懂了，谢谢您的详细解释。OCR本身无法100%准确。目前的单点取词成功率已经相当高了，个别单词可用框选解决。

再次谢谢您给大家带来了这个方便，实用，高效率的学习工具，辛苦了！

Vim · 2021 年12 月 8 日 01:01

每天开机启动AHK，没遇到类似问题。

Johnny_Van · 2021 年12 月 8 日 03:03

出现乱码的是什么软件？

Johnny_Van · 2021 年12 月 8 日 03:12

在什么条件下发生的，鼠标变十字的时候？我在屏幕上覆盖了一层透明窗口，不知跟这有没有关系。

Johnny_Van · 2021 年12 月 8 日 03:30

不清楚你的操作步骤，难以界定问题出在何处。

abs · 2021 年12 月 14 日 05:14

系统默认分辨率是200%，偶尔有词条识别不到（必须得放词条正中才行），现在改成150%就都能识别到了，有遇到的同学可以改下这个系统设置看看。感谢楼主作品！

Johnny_Van · 2021 年12 月 15 日 12:25

@abs
2021/12/15更新：修正 Capture2Text.ini 路径；增加适应较大字号的 Capture2Text.ini 配置文件（识别速度慢一丢丢），不用去改系统分辨率了。

dyasbd · 2021 年12 月 16 日 03:02

单点取词ctrl+右键没反应区域取词没问题，请问这种情况怎么办呢？

medp7060 · 2021 年12 月 16 日 03:27

多半是你的设置没有弄好。先下载我打的包试一试：

Johnny_Van · 2021 年12 月 16 日 08:19

检查一下 Capture2Text 的设置与顶楼图片是否一致。

sff34 · 2021 年12 月 18 日 13:28

新版本很完善了，不过还是有点小问题：

1、放大镜在框选取词异常退出时是怎么处理的？超时退出我没等到，但按esc退出取词时放大镜没随动退出。

2、微软放大镜Magnify.exe的配置参数存储位置能否找到？如能找到并可读写，那就不需要手动设置放大镜了。

3、单点取词的效果始终比框选取词差甚远，甚至比欧路的屏幕取词（OCR）差甚远。这就奇怪了，欧路WordCaptureX用的ocr内核似乎也是tesseract？怎么效果差这么多？当前成功率下，单点取词只能是一种尝鲜功能，而不是实用功能。

如果情况无法解决，要想把单点取词实用化，我出个主意，单点取词还是调用欧路或其它词典的屏幕取词功能好了。技术上应该没什么问题，必应、有道、欧路都可以把mini窗口整体复制，欧路甚至mini窗口整体复制和所选词的复制两种功能都有。就是不知法律和技术伦理上有没有问题，不过，应该也没什么。