用 MATLAB 来数 Ingress Portal Key

本咸鱼的特长就是乱放 key，且懒得打理，所以经常出现以下尴尬局面：

• 咦？link 不上？翻桶。卧槽，这桶里咋没有？！难道是下个桶？卧槽，怎么也没有？！

• 卧槽，我怎么囤了这么多这个坡的 key？！

• 这是最后一把，……了……吗？

一堆桶里扒拉着数 key 找 key 好痛苦。索性开个脑洞，交给电脑数去。不曾想，这不是脑洞是深坑啊。而且还忘记了马上就 Prime 了，哭丧脸。

把扒拉 key 的操作录屏，视频文件喂给 MATLAB，OCR 识别完输出坡名和数量。打完收工！

受限于技术水平，这活真不好干。憋了好久憋出个满是 bug 的脚本，索性凑合能用了。

文件说明

• CountIngressKeys_V1.m 数Key脚本；

• RectAspectRatio.m 输出每帧图像中最大矩形框的高宽比，并绘图的函数。

依赖

• 脚本只在 WIN 下测试过。其他系统按道理也可以。

• MATLAB Computer Vision System Toolbox：用来调用该工具箱的 ocr 命令，识别英文、数字。其实换下面这个 Tesseract OCR 做识别也成，并不必须，但现在脚本里还是有用ocr。
  

• Tesseract OCR：命令行式的 OCR，需另装，配置好简繁字库，用来识别简繁中文。装配过程可以放狗搜，很多教程。

录屏

Inventory 里的 key，如果只有 1 把的话，是不会显示数量的，即没有“x1”；桶里的则会显示，而且在桶里点 load，则会显示 Inventory 里的 key，而且有“x1”（上图）。所以推荐录屏时不直接录 Inventory 里翻 key 的过程，而是找个桶，点 load 再录。当然，录 Inventory 里的也可以，脚本也能处理。

翻 key 一定要从头翻到底，比如从左翻到右，或从右翻到左，翻快点都可以的（如上）。现在的脚本没考虑来回翻的情况，会数错。

一个桶翻完换另一个桶时的切换过程，没关系，要相信脚本能识别这个过程（看人品）。当然你也可以每个桶录一个，分别丢给脚本去数。

预设

有了 MP4，先在 MATLAB 里 implay(文件路径) 一下（上图）。红色矩形框里是控制按钮，右下角是当前第几帧和总帧数。有时候录屏会录进去一些开始录屏或终止录屏的菜单按钮(下图)，所以要掐头去尾。不用编辑视频，找到可供 OCR 识别的帧数范围就行，在脚本里填好。脚本也是逐帧做循环处理的。

每帧图像在 OCR 之前，先识别该帧图像里最大的矩形框。如果这帧图像是滑动key的视频里的一帧，这个最大矩形框就一定是可滚动的key图这部分（下图红色虚线）。

而且，该矩形框的高宽比浮动不大（下图），所以可根据这个矩形框的高宽比判断是不是 key 图。可以先运行一下 r=RectAspectRatio(文件路径);输出高宽比的序列来看一下 key 图对应的高宽比大致为多少，然后在脚本 CountIngressKeys_V1.m 参数区域里填入上限和下限。从下图可以看出，桶界面和翻桶时所识别出来的最大矩形高宽比和桶里 key 图的高宽比差很远，这也是为什么从一个桶翻key切换另一个桶的过程可以被排除。不过，问题来了，不同手机这个高宽比是不一样的。脚本里预设了 iPhone 6 和 Moto G 2nd Gen 的（我们没有钱.jpg）。欢迎补充。

下图即脚本 CountIngressKeys_V1.m 里的参数设置区域，改好运行脚本即可，人品好的话能一直 run 到底。

脚本执行时不用管，这里只简单说下逻辑：

• 裁切出key图后，再切出上部的数量区域和下部的坡名区域分别 OCR。

• Tesseract OCR 识别一次比较慢，外加一次读写。如果每帧都要 OCR 就太慢了，况且大部分时候前后相邻帧都是同一个画面。所以用前后相邻 key 图的坡名区域做互相关，互相关系数在 0.75 以上的认为是同一个坡名，不做 OCR，跳到下一循环。

• 坡key数量识别成功率有限，某些识别不出的场合，输出图像人肉判断后输入数字。

• 坡名的识别成功率就更低了，各种乱码。比如，经常把“院”识别成“脘”，无力吐槽。做了清理之后，停留在一眼能看出是哪个坡的水准。

• 如果循环处理完每一帧后，得到的坡名数组里相邻的两个坡名是一样的，就干掉一个，应该是在相关系数筛选那里漏网了。

• 最后查找坡名数组里同名的坡，把对应的key数相加得到该坡的合计key数量。比如桶里有2条这个坡的key，仓库里有1条，所以相加得到总共有3条。

结果写去 EXCEL 文件，方便根据 key 数量排序神马的。输出的前两列是根据 OCR 识别顺序也就是录屏视频的时间顺序排列的坡名和数量，后两列则是根据坡名文字排序的。有后两列的好处是，有识别差错的时候，可以一眼发现同一个坡被识别成了俩坡名：

• 每个城市里都有好多个“小象”、“石狮”这种同名坡，脚本会把他们全加起来。理论上可以把坡名识别区域扩大到坡名及其下面一行的地址识别，这样就多一个判据可以对同名坡加以区分，但我懒癌直犯。。直犯。。

• 翻key录屏不要来回往复翻。

• 玄学属性爆棚。

• 放出这个用吃奶的劲儿编出来的 0.2 成品就是期待能被技术大佬打脸。
  

• 神马？你说数得对不对？不管你信不信，我反正是信了！

• 其他脑洞：桶里的数一遍，Inventory 里的数一遍，两边一 match，看看有哪些 key 该从桶里搬出来 link 用了。嗯。这个。再说吧。