[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的四个坐标代入公式计算得出圆心坐标。

  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 国际许可协议进行许可。

wTodo Watch版微软Todo客户端

背景

我是一个很喜欢用电脑记录待办事项的人,感觉不通过待办事项我很容易就记不住事情。由于原来是在华为全家桶的用户,对跨平台有强需求(Windows+Android),因此顺理成章的选择了微软Todo作为我的待办事项记录平台。说实话,即使今天我已经开始转回Apple全家桶,但Todo的工作效率还是比Apple自家出品的”提醒事项”要好用很多。(Todo添加逻辑很自然,一打开界面就可以添加编辑待办事项,没那么多繁琐的设置)。

简介

wTodo是一款为Apple Watch适配的第三方Microsoft Todo应用, 通过该应用您可以在Watch端, 操作自己的待办清单。

系统需求

  1. iOS 15.0+
  2. watchOS 8.0+

商店链接

仅售1元

应用截图

使用指南

https://w-todo-guide.vercel.app/

[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】下载压缩包后,按照配置指南,一步一步的安装即可。

[小程序]PPG式心率测量模块

最近有空把之前想做的心率测量进行了开发和研究,最终选择了运动手环上面普遍采用的PPG式心率测量,载体则继续使用之前开发的”活力健身房”小程序。

什么是PPG式心率测量?

PPG是通过光电手段在活体组织中检测血液容积变化的一种无创检测方法。

测量的原理是啥?

原理:血液会吸收光纤,心跳时血液流量会规律性变化,进而产生规律性变化,进而产生规律性的光信号。

Demo视频

小程序码

使用方法

  1. 扫描小程序码
  2. 点击”我”
  3. 点击进入”心率测量”模块
  4. 阅读使用注意事项,点击下一步
  5. 开始测量,当剩余时间倒数至零时,即会生成测试结果

引用

  1. https://www.richtek.com/Design%20Support/Technical%20Document/AN057?sc_lang=zh-CN
  2. https://blog.csdn.net/QQ576494799/article/details/105024692/

[小程序] 活力健身房

简介

一款基于手机加速度传感器的跑步记录小程序。
用步伐丈量世界,在活力健身房记录你的跑步轨迹,助你更快达成你的跑步目标。
运动海报,记录每一天的变化,分享好友相互勉励,在活力健身房健身不再是孤独的坚持。

小程序码

截图

仓库地址

PS

这次开发的这个小程序其实就是Lebu的升级版本,算法上升级到了2.0,计算算法更加准确且高效。加入了轨迹图,逐公里的配速曲线以及逐公里的海拔曲线。还支持运动信息海报生成。终于是把在Lebu上没实现的功能都开发完成了,开心owo

PPS

第一次参加只能当个混子,拿个三等奖了。希望明年能够有更好的成绩吧!

[小程序] 大头菜估价

简介

一个简易的大头菜估价小程序,除了可以基于你的历史价格数据,给出接下来一段时间的价格,还能给出一些出手的建议,实属卖菜利器。

小程序码

截图

近况

上岛了这么久,其实我很少机会去卖菜,基本上都是在钓鱼ing,由于选在了南半球,所以快把图谱开完了,就一直没去买卖大头菜了。如果你想找我玩的话,欢迎通过邮箱联系我,交换SW码owo

[小程序] GCU课表+

简介

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

特性

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

小程序码

截图

服务支持

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

[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

[PHP]使用PHP拓展获取CPU占用率

导语

这两天了解了一下怎么用C++写PHP的拓展,今天整活了一下,才终于发现为啥那么少人给PHP写拓展了。PHP拓展真的是太难写了,入门门槛极其的高,贼复杂(指的是在Windows平台开发,贼复杂),做了这个就不搞了,溜了溜了。

如何使用

  1. 把php_getcm.dll复制到ext文件夹中
  2. 编辑php.ini,启用php_getcm.dll
  3. 在php代码中使用getcm_func(),即可获取CPU的占用率(int)

使用要求

之所以说难开发,还有一个方面,就是在windows平台上开发的时候,如果用了vc15编译了旧的版本,你就贼难测试,就不得不切换到新的PHP版本,然后继续踩坑,超级难受。
1. php:7.1.33
2. nts
3. vc15(这个没有官方版本,要你自己下载php来编译,贼麻烦,喜欢的可以折腾一下,没空看的就算了)
最近有空,会把一篇开发指南翻译一下,留给之后的dalao用吧。

下载链接

DLL库下载:php_getcm

[笔记]qduoj 前端 二次开发总结

前言

接了学校一个SRP项目,所以最近一个月都开始搞这个OJ的前端开发,现在分享一些这个OJ部署的一些坑点,帮助大家避坑,也Mark下给自己做笔记用.

启动前端组件

git clone https://github.com/QingdaoU/OnlineJudgeFE.git
npm install
npm run build:dll

配置Config/index.js
第一个target是后端的地址

npm run dev

FE即可成功编译

引入Component

  • 创建Conponent VUE文件
  • 配置route/route.js
  • 配置views/index.js
  • 参考iview语法设置导航栏入口
  • 修改i18n的双语文件即可

    通过上述步骤即可将自己的组件引入到FE之中

关于OJFE使用的CSS坑点

QDUOJ这个平台实际上时使用了两种UI框架
1. iView
2. ElementUI
其中iView是作为UI组件库使用,所以一开始Coding的时候会发现前端的语法与ElementUI对不上.而ElementUI的实际作用仅仅是给OJ提供了动画效果,所以为了让自己的组件也有弹出的效果,我们要使用Panel组件使得自定义的组件具有相同的弹出动画效果.
如果需要自定义动画效果的话,则需要我们自身使用transition标签来创建动画效果

结语

现在其实开刚刚起步,大致把前端摸了一下(后端也会摸,但我不是主要负责这块的),后续应该还有坑点.到时候也会分享出来给大家看的.
小声BB,QDU的文档真的不咋地.(可能是我菜才看不懂吧,若有冒犯请见谅:joy:)