[Discode] 生成 & 识别Discode

简介

书接上文,在上一章节中,我详细的分析了市场上已经落地应用的部分商用方案,也针对自己的实际需求进行了思考,设计了适合需求的编码规范和编码形式。在本章节中,我将会分享一下Discode的生成和识别过程和技术细节。

目录

  1. 生成Discode
  2. 识别Discode
  3. Github仓库
  4. 编后语
  5. 版权声明

生成Discode

如何生成图形编码?

在前面的设计原型中,Discode中包含四个定位点的设计。按照设计Discode的定位点类似于微信小程序码的定位点,基础元素是由一个圆环和一个圆点组成的图案。

定位点

之后会将其等距离的放置在图形编码的四个角上,用于图形的定位,如下图所示。

确定好定位点之后,我们就需要生成我们的图形编码了。图形编码包含两个部分:

一、用什么规则来代表数据?

参考条形码的设计,我决定通过点与线来分别代表0和1。之所以会有这样子的想法,是我认为在之后的学习研究识别过程中,点与线的识别应该会有更多现成的代码可以参考学习,不用自己再花大量时间来研究。

基于这种想法,通过简单的编程在canvas上生成了上图的DEMO图形,拥有五个定位点与按照一定规则环状点线的编码区所组成的Discode。(之所以在图形的中心也包含一个定位点,主要是当时想用来确认圆心是否能够被计算正确,所以增加的辅助图形,在技术验证后就被品牌Icon代替。)

二、存储数据量要设计多大?

在之前的原型设计中,我曾经分析过小程序拥有多种容量的设计,比如36线、72线、144线等设计。通过增加线密度来增加图形的数据承载量。因此我也对此进行了一些简单的实验。

上图是每隔五度绘制一位数据的72线版本的Discode,可以很容易的看到,在内圈的1-3层,由于图形之间的间隙过小,很容易产生图形与图形间粘连在一块的问题,特别是第二圈右下角的多线段连在一块很难辨别的问题。

题外话

那为啥微信小程序可以支持72线?

通过观察微信小程序的设计规范可以发现,之所以元信息区并不是从最内圈开始的原因:就是为了解决72线可能会导致图形绘制过于密集,导致编码图形难以被识别和处理。而选择了往外移了几圈,才开始进行实质性的编码。

微信小程序码编码设计

对比实际编码出来的图形,我们可以发现,为了美观考虑,小程序码在元信息区往圆心方向的编码区其实只有36线,即10度才记录一个编码,只有在元信息区才开始使用72线,即5度进行一个编码。

那问题就迎刃而解了,要么就是将实际数据编码区往外移,要么就是减少单圈编码密度。最终我还是选择了减少单圈编码密度作为我的解决方法,之所以选择这个方法就是图省事,简单快速的解决问题,不然将编码区外移又需要耗费一部分的时间来重新设计编码规范,我着实是不想这么干。

增大到10度一编码后,图形的视觉效果就好多了,另外也部分程度上的解决了图形粘黏的问题。解决了编码问题后,我们只要将定位点、编码区组装起来就是我们设计出来的Discode了。

其实到这一步Discode就已经生成完成了,只要在中间预留的空白处填上我们希望填充的Logo即可。

识别Discode

识别Discode主要有以下的几个步骤:

  1. 使用Hough Circle获取定位点的圆心坐标

通过Hough Circle Transform获得四个定位点的相对于图片的位置信息。

  1. 通过四个定位点计算编码区圆心位置

接下来连接对角点,形成两条线段(红线与蓝线),计算交点位置。

如上图顺序对应0-3的四个坐标代入公式计算得出圆心坐标。

\( y= \frac{(y_{0} – y_{1}) \times (y_{3} – y_{2}) \times x_{0} + (y_{3} – y_{2}) \times (x_{1} – x_{0}) \times y_{0} + (y_{1} – y_{0}) \times (y_{3} – y_{2}) \times x_{2} + (x_{2} – x_{3}) \times (y_{1} – y_{0}) \times y_{2}}{(x_{1} – x_{0}) \times (y_{3} – y_{2}) + (y_{0} – y_{1}) \times (x_{3} – x_{2})}\) \(x = x_{2} + \frac{(x_{3}-x_{2})\times(y_{cross} – y_{2})}{y_{3} – y_{2}}\)
  1. 设置ROI(Region of interest)识别指定区域

Discode的编码起点如下图所示:

Discode从上图的矩形框中开始生成第一位编码,然后在相同半径内沿着逆时针方向(红箭头),生成接下来的编码,当一圈编码完成后就自增半径,开始第二圈的编码直到编码五圈为止。

而识别其实就是逆向这个过程,如上图设置图像的ROI到图像的编码开始点,然后逆时针一个一个识别,一圈一圈识别,直到识别完成。

  1. 使用Canny edge detection获得识别区的轮廓

在上一步中,我们设置了图像的ROI,接下来我们要做的就是计算这个ROI内的图形到底代表的是0还是1。

识别的核心原理:计算ROI区域内的图形的面积。

之所以我们可以这么做,是因为我们已知ROI的面积信息,我们也知道长线段占用的面积理应大于短线段的常理,基于这两个信息,我们只要计算ROI内图形面积,并通过经验设定一个阈值来判定是长线段还是短线段。知道线段类型后,转换成0和1就水到渠成了。

这里我们引入了Canney边缘检测,通过边缘检测获得ROI内图形的轮廓数据。

  1. 通过contourArea函数计算轮廓面积

获得轮廓数据后,我们就可以计算出ROI中的闭合图形个数以及总面积信息,之所以有时候个数会大于1,是因为有时候ROI会重复识别到上一个图形的边缘,导致到污染了识别区。不过由于这种现象仅仅发生于长线段的交接处才会发生,且数据影响不大,因此我也没有做进一步的处理。如果要继续优化,可以继续精细化ROI区域,使得覆盖率提高。或者调整生成图形算法,加大线段之间的间隙,避免互相粘黏。

  1. 判定图形代表0或1

通过多次的实验可得,短线段的占用的面积必定小于10,大于10的必定是长线段。因此在这里使用10作为阈值,用于判定ROI内的图像是代表0或1。

  1. 分割 & 转换

将每个图像代表的二进制数值存入数组当中并将其按照6bit为一位通过编码字典,重新转换成可阅读的字符串。

  1. 输出结果

由于有时候编码的字符不一定会用完全部可用编码位,因此还会在有效编码后面加入一些随机数据作为填充,使得图形更加美观。

Github仓库

https://github.com/7gugu/Discode

仓库中包含了完整的生成和识别图形代码,可以自行运行学习一下。实测通过FireFox 100是可以正常运行的。

编后语

至此整个Discode系列就全部更新完成了。原来在这个部分我思考了很久,写了几个版本的内容,先是是过拆分成两个章节来慢慢讲解,也试过回溯历史结合QRCode来阐述为啥我要这么做,但效果都不尽如意,过于的繁琐冗余,最后还是秉着少即是多的原则,缩减成一章来讲解。五月中的时候恰好碰上了组内的技术分享,有幸向其他同事分享了我的这个想法,也得到很多宝贵的建议。之后由于毕业设计和工作上的琐事,使得进度很慢,对此向期待这篇技术分享的朋友说声抱歉。接下去我应该会专注于wasm和三维建模上,希望以后可以投入游戏产业,继续实现个人梦想。

版权声明

知识共享许可协议

本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。

独立 Watch App 真机调试无网络的问题

问题

现在我正在开发一个独立的 Watch App 应用,但是我发现在模拟器上调试时是可以正常连接网络的。但是当我上传到真机时,就会出现无网络连接的问题。具体的报错如下:

2021-11-20 21:42:27.156338+0800 wTodo WatchKit Extension[1068:2225475] PDTask <29C198EA-480A-459F-B5B9-421D9C26C7D8>.<3> finished with error [-1009] Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorFailingURLSessionTaskErrorKey=LocalDataPDTask <29C198EA-480A-459F-B5B9-421D9C26C7D8>.<3>, NSLocalizedDescription=The Internet connection appears to be offline., _kCFStreamErrorCodeKey=50, _NSURLErrorRelatedURLSessionTaskErrorKey=(
    "LocalDataPDTask <29C198EA-480A-459F-B5B9-421D9C26C7D8>.<3>",
    "LocalDataTask <29C198EA-480A-459F-B5B9-421D9C26C7D8>.<3>"
), NSErrorFailingURLStringKey=https://baidu.com, _kCFStreamErrorDomainKey=1, NSErrorFailingURLKey=https://baidu.com}

测试机型

Apple Watch S7

系统版本: 8.1

网络环境: WIFI

原因

在watchOS 8中,GPS版的Apple Watch是不能单独设置APP的网络的,他会镜像iOS侧的App网络设置,比如设置支付宝可以用Wi-Fi,则Watch侧的支付宝App也可以用Wi-Fi。现在陷入的一个僵局仅仅是存在于新推出的独立App,独立App顾名思义就是只存在于Watch侧,iOS侧是没有App的。因此也不存在镜像iOS侧App网络设置的可能。这导致了如果App默认被设置成了不能联网,就会导致用户没法更改App联网状态(因为iOS侧和Watch侧都不能更改App的网络设置)。

解决方案

  1. 彻底关闭手机
    该方法是为了让 Apple Watch 不去同步手机的网络设置(默认关闭网络),促使独立应用能够正常联网,但该方法仅适用于网络连接少或者无的独立应用,比如小说、阅读器等。
  2. 开发 iOS 配套应用
    如果 iOS 侧有配套应用,则用户就可以在 iOS 侧对应用的网络权限做控制,进而实现 Watch 侧应用联网,该方法适合对于网络请求较多的应用。

PS:这个 Bug 的出现真的是很无语,花了我一整天的时间才解决,心累啊😣。

[WP插件] WPComment2Bark

背景 🏞

最近大半年都在搞实习和雅思,其实没做多少实用的工具出来,有点手痒痒了。因此接着博客重建的契机,动手搞了一个评论信息推送的小插件。

思考 🤔

技术指标:

  1. 高触达率 🚀
  2. 开箱即用 📦
  3. 高度安全 🔐

解决方案:

1. 邮件推送

原来的推送方式就是通过Email的形式来推送,有可能会出现消息推送不及时或者被拒信,无法满足高触达率的技术要求,故摒弃这种推送方式。

2. Server酱

Server酱年初也因为各种外部原因,降级成了企业微信推送,其实不是特别方便,用户还得去装一个企业微信,然后配置Bot,再去配置APIKEY。对于我们做开发的用户来说,已经是挺繁琐的步骤了,对于普通用户而言简直就是噩梦。无法满足开箱即用的要求,故放弃。

3. Bark

最后我将目光投到了Bark身上,Bark是V站的一个dalao搞的一套利用Apple消息推送机制做的Web信息推送框架。Bark也同时满足我们三项技术要求:

1. 高触达率

借助Apple推送机制,我们甚至可以在息屏的情况下,都能正常收到推送消息。无视任何垃圾回收机制,绝对在线。

2. 开箱即用

用户只要下载Bark客户端,博客安装插件,配置插件,即可投入实际使用。

3. 高度安全

Bark提供免费服务器的同时,也提供了源代码供用户进行审查。如果是对于隐私比较敏感的用户,还能选择通过Docker部署自己的私有推送服务器。

综合上述优点,我选择了使用Bark作为消息推送的核心功能支持。

作用 🏄🏼‍♀️

每当有人评论你的文章时,可以推送到你的 Bark App。

配置指南 🧭

1. 从AppStore下载Bark客户端

2. 上传 & 安装插件

3. 配置推送链接

首先从客户端上复制出推送API和API密钥

第二步,切换到博客后台,依次点击【设置->讨论】,滚动到底部,找到【Bark推送设置】

至此就完成了全部配置工作,只要有新的评论被发出,就会调用API想您推送消息。

WordPress 插件市场

https://wordpress.org/plugins/wpcomment2bark/

插件仓库 ⛺️

https://github.com/7gugu/WPComment2Bark

点击【Code -> Download ZIP】下载压缩包后,按照配置指南,一步一步的安装即可。

[油猴脚本] V2EX 自动切换深色模式

起因

V 站从去年年中就好像开放深色模式了,但是切换样式一直都需要手动去切换,个人感觉有点麻烦。最近入手了 12,发现 iOS 的根据日出日落时间自动切换浅色深色模式的功能很好用,但是电脑端(Windows平台)不使用额外的软件不能实现自动切换样式,所以萌生了基于日出日落时间来自动切换 V 站样式模式的想法。

简介

目前脚本是基于定位获取当前设备的坐标,基于坐标计算出当地当日的日出日落时间,自动切换浅色与深色模式。 (日出后日落前就是一直保持浅色模式,日落后日出前就是一直保持深色模式)

脚本链接

https://greasyfork.org/zh-CN/scripts/421557-v2ex-autodarkmode

使用方法

第一次使用时,将会弹出询问❓是否允许获取定位📍,选择”允许”,并勾选✔”不再询问”即可完成初始设定。
之后的使用中,将默默运行在后台,没有任何的提示。

联系我

Email: gz7gugu@qq.com
Blog: https://www.7gugu.com
(由于把脚本放在了 GreasyFork,您也可以直接在 GreasyFork 上面私信我,看到就会回复)

Powered by 7gugu

[NodeJS]非抢占式多级反馈队列调度算法

前序

《操作系统》课程最近布置了一个大作业,要求我们每人实现一个非抢占式多级反馈队列调度算法的模拟程序,作为期末考核的一部分。(u1s1,真的是爽到,老师开心,我们也写的开心!)

实现代码

//Powered By 7gugu

//每一级队列的可运行时间
let timeSlice = [1, 2, 3];

//准备运行的队列
let preRunQueue = [];
//3级运行队列
let runQueue = [
  [],
  [],
  []
];

//准备运行的程序[开始时间, 运行时间]
let progs = [
  [0, 8],
  [1, 4],
  [5, 1],
  [3, 7],
  [4, 2]
];

for (let i = 0; i < progs.length; i++) {
  let prog = {};
  prog.id = "P" + i;
  prog.startTime = progs[i][0];
  prog.runTime = progs[i][1];
  prog.priority = 0; //设置最高优先级
  preRunQueue.push(prog); //把待运行的程序导入运行序列
}

//总运行时间
let totalTime = 0;

while (true) {
  //如果待运行队列中仍然有程序 & 程序已到达开始时间
  if (preRunQueue.length > 0) {
    let prog = preRunQueue[0];
    if (prog.startTime <= totalTime) {
      preRunQueue.shift(); //直接弹出队头的元素
      runQueue[0].push(prog); //把程序加入0级运行队列中
      console.log(prog.id + "开始运行,开始时间为:" + totalTime);
    }
  }

  for (let i = 0; i < runQueue.length; i++) {
    //如果各级队列还有程序的话,就继续运行
    if (runQueue[i].length > 0) {
      let prog = runQueue[i].shift(); //获取各级队列中第一个程序
      if (prog.runTime > timeSlice[i]) {
        //程序运行时间比时间片大
        totalTime = totalTime + timeSlice[i]; //总运行时间累加
        prog.runTime = prog.runTime - timeSlice[i]; //减去每一次运行的时间
        if (i != runQueue.length - 1) {
          //如果未处于最低优先级,则把程序放在下一个优先级队列中
          runQueue[i + 1].push(prog);
        } else {
          //如果处于最低优先级,则把程序放回最低优先级中运行
          runQueue[i].push(prog);
        }
      } else {
        //程序运行时间比时间片小
        totalTime = totalTime + prog.runTime;
        console.log(prog.id + "运行完成,目前时间为:" + totalTime);
      }
      break;
    }
  }
} 

运行结果

仓库地址

参考资料

计算机操作系统(第四版) 西安电子科技出版社

Vue import不识别 Unexpected Token (xx:xx)

Bug出现

最近在给工作室打工的时候,Vue做了个静态路由懒加载。

然后编译的时候死活不认这个import,截图如下,完全没有解决的思路。

解决思路

  1. 同事编译莫得问题,遂排除是代码问题
  2. 清除node_module,重新npm install,无效,排除是Node的问题
  3. 因为其他位置的import工作正常,遂排除babel未启用
  4. 最后通过下载安装”syntac-dynamic-import”,在配置后,问题解决

[小程序] GCU课表+

简介

一款专属于华广人的课表小程序。专注于课表信息查询,极简,优雅。不做论坛不做商城,节省流量保护隐私。

特性

  1. 支持教务系统导入课表
  2. 支持添加编辑课表
  3. 支持成绩查询
  4. 支持考试安排查询
  5. 支持深色模式
  6. 支持课表信息推送
  7. 公告信息
  8. 离线存储
  9. 弱网加载
  10. 自定义壁纸
  11. 无障碍访问
  12. 自带使用指南

小程序码

微信小程序码

截图

服务支持

现在后端已经完全迁移到了腾讯云的SCF上,每个月消耗的都是免费额度,如果未来使用人数不激增以及教务系统不升级,理论上是可以继续运行5年+的。另外目前打码已经接入Numpy等机器学习框架,自动识别,准确率高达98%,某种程度上,是不需要外部维护就能持续运行的。目前小程序的最长无维护记录是6个月,希望日后离校之后,可以实现4-5年无维护都能正常运行吧🤷‍♂️。

JavaScript OOP笔记[ES3]

简介

最近开始要学习ES6了,翻出JS看了看,发现OOP部分还没有掌握,所以就赶紧进行了补课。下面是这次学习的一些,个人认为重要的知识点。

对象

每次使用JavaScript的构造器时,都会创建一个对象。一个初始化的对象中将会含有一个属性集,称之为prototype(对象属性),还有一个constructor(构造器)。而属性集里面中则会默认存在一个属性_proto_(原型)。这个属性存储的是父类的prototype(可以理解为指向父类的一个指针)。

对象属性

访问对象属性

对象.prototype.属性名

创建对象属性

对象.prototype.属性名 = 值

继承

JavaScript中实现继承主要是通过修改对象的_proto_(原型)指向到父原型来实现的继承。一旦理解了就会很简单,但是这个设计真的不好,而且原型这个称谓真的太容易混淆了。

注意!

//错误的继承
student.prototype = person.prototype;

解释:因为如果是这么赋值的话,在后续的操作中,比如给student增加属性或者方法时,收student的本质还是person,这样子修改的话,本质上还是修改的person的对象属性。

//正确的继承
student.prototype = Object.create(person.prototype)
//此时就可以正确把student的_proto_正确的指向person.prototype了

(JavaScript在ES6中貌似已经引入了extend应该能改善当前这个反人类的设计了)

原型

原型就是对象上一个存储父类的属性,称之为_proto_。由于Object是顶层对象,所以它的原型就是NULL。

原型链

bosn的原型指向Student,Student的原型又会指向Person,Person的原型又会指向Object,则称这条联系为原型链。

InstanceOf

该方法用于判断方法右边的函数是否存在于左边对象的原型链中,返回一个Bool值。其原理还是通过遍历prototype来看看左边的原型链上面是否存在右边函数的prototype。

用途:判断对象是否存在该方法(函数)

尾言

说实话,平时对于JavaScript的应用还停留在普通的事件应用,函数闭包这种层面,第一次了解了关于JS的面对象过程,也是受益匪浅,希望可以帮助到后续的ES6的学习,如果你觉着这篇文章好的话,不妨点一个赞吧,如果我理解有错误,也欢迎在下方评论区中学习交流owo。

[BAS弹幕动画] Bad Apple

前序

其实这个BAS动画我一直很想写的了,只是一直咕咕咕,还有身边的琐事,一直没抽出空来写一下弹幕动画。这次终于抽出空来写了一个(AV88558525),欢迎来看看。这篇博文主要是会分享一下这个BAS弹幕动画是怎么做出来的,以及一些BAS的个人看法。

处理流程

  1. 使用ffmpeg把BadApple.mp4分割成图片
  2. 使用PHP*将图片转换成字符画
  3. 将字符画拼接成BAS字符串
  4. 计算每一组BAS的起始时间
  5. 在视频上发布
  6. 微调**

*:语言没啥所谓,重点一定是能处理图片,还有就是顺手,python虽然有很多库,语法很优雅,但我是一个phper,所以还是倾向用php整活(PHP天下第一)

**:音乐视频可以找鼓点来定位,如果你放的视频的节奏型不是特别强无对话的话,你就随缘调吧,反正最后还是会有偏差的。

代码仓库

代码解析

视频转换

视频转换,我使用的是这个dalao的代码。地址:https://blog.csdn.net/somehow1002/article/details/77600186

切割视频

切割视频的码率一定要设置成30帧一秒,不然会卡到爆炸。

txt转BAS

其实BAS转换非常简单,你可以看到我的代码也就是跑了两个循环就拼接好了。每个BAS弹幕的开口是def c{属性},然后是set c{content=””},再然后的就都是then set c{xxxxx}。

这个c是可以换的仅仅是一个函数名而已,你换成啥都行。这里主要是要控制多少个bas组成一组。这次的经验是:

  • 0.033s为一帧
  • 三个为一秒
  • 201/402为一组

目前测试单次弹幕为408KB,就是已知的B站容许POST的数据量。再大的话服务器那边会提示服务器错误(就是不允许你发这么大个的弹幕了),但如果本地测试的话,播放器单次怼1206个16×32的字符画也是OK的。

时间计算

这一步主要是要标定弹幕的开始时间,按照402个为一组的话,一段的时间是13266ms,那么第一段的时间就是0ms开始,第二段就是0+13266+1开始,偏移1ms让弹幕不要叠在一起。

还有就是要对鼓点,不然整个视频的节奏就会很有问题。除非你的视频没有啥节奏,不然就很有必要对多几次,这里有一些想吐槽的就放到最后再写。

成果

吐槽

语法缺失

其实最最大的缺点就是这个BAS语法没有加入一些for,if之类的语法定义,这个script甚至连Boolean都没有定义,可以玩的东西实在有限。最多只能写一些动画出来玩玩。

标准缺失

这个标准指的是弹幕数据的一些标准,虽然平常发弹幕实际能触顶的机会十分的少,但是对于BAS制作者来说,这些标准的指定可以大大减少我们的开发时间。之所以这么耗费功夫其中的一个原因就是总是要测试标准的上限在哪,客服一问三不知,也没法实质的解决,希望B站以后可以写出来。(已反馈到B站)

批量弹幕发送困难

对于技术宅来说可以用自动化测试套件/窗口捕获/模拟POST来实现批量提交弹幕,但这些基础脚本的编写也是要花费时间的,导致整个制作周期会拉长实在是非常讨厌,而这也就是我想说的另外一个耗费功夫的原因,实在是太麻烦了。就算是目前有多Tab,来发送还是繁复的不得了。其实解决方案应该是创建一个API中心,开发者/UP主可以针对单一视频通过API来提交弹幕。而且可以限制API单次使用时间,确保站点安全。

总结

上述的几个建议如果都能改进或者加入,相信BAS还有更多的空间发展,当初的代码弹幕的辉煌也会回来的。最近的互动视频的动作其实就不错,如果可以把BAS也加入其中,想必会给互动视频加入更多有意思的元素,B站黄油,B站FPS指日可待。

感谢你看到这里,希望你喜欢OWO