duangsuse::Echo
718 subscribers
4.26K photos
130 videos
583 files
6.48K links
import this:
美而不丑、明而不暗、短而不凡、长而不乱,扁平不宽,读而后码,行之天下,勿托地上天国。
异常勿吞,难过勿过,叹一真理。效率是很重要,盲目最是低效。
简明是可靠的先验,不是可靠的祭品。
知其变,守其恒,为天下式;穷其变,知不穷,得地上势。知变守恒却穷变知新,我认真理,我不认真。

技术相干订阅~
另外有 throws 闲杂频道 @dsuset
转载频道 @dsusep
极小可能会有批评zf的消息 如有不适可退出
suse小站(面向运气编程): https://WOJS.org/#/
Download Telegram
Forwarded from 大 逗逼
还是要display视频
Forwarded from dnaugsuz
找不到了…… 是一个中文的字符画《晚安喵》视频
Forwarded from dnaugsuz
https://www.bilibili.com/video/av40029529
有点类似这种(不过不是…… 我之前看到那个质量很高,是中文字符组成而且不同时间有不同的字符组成)

貌似是 C# .NET 做的,据说绘制速度比较慢,彩色中文字符画。 可是 B 站搜不到 2019 年以前的结果了 而且只能搜到标题……

https://www.jijidown.com/video/av9725649
发现哔叽好像可以搜到很早以前的视频
Forwarded from dnaugsuz
草,原来绘制和矩阵处理天生不兼容 #CV #Python #visualize
反正我是熟悉 n m y x i j 那一套
可以把 for (i=0; i<n; i++) 套到 绘制程序里

我们只需要往 i, n 扩展一个 j, m 就可以处理项目和 y, x 不匹配的情况
然后矩阵处理又是另一种情况,没有 w,h 什么的
Forwarded from dnaugsuz
https://github.com/sibojia/cv-uni-text
https://github.com/jrosebr1/imutils #Python #CV
噢,原来 PIL 已经可以被 CV 完全替代了啊 🤔
以前看 PIL 有的 filter 工具、kernel 之类和 convolution 都是 numpy 弄的,现在加上 cv 和 matplotlib 好像的确没必要用 PIL 了
PIL 的颜色模式也很头疼…… RGB, ARGB 也就算了,还有 I, L 这种奇奇怪怪的模式…… 色彩通道也叫 bands 而不是 channels
extract-subtitles 现在支持默认 export 被请求 OCR 的 subtitle image (-debug-crop) 了
./vcat_subtitle_imgs.py a.png frames/subtitle_*.png
a.png << ['frames/subtitle_0.png', 'frames/subtitle_4.png', 'frames/subtitle_5.png', 'frames/subtitle_8.png', 'frames/subtitle_10.png']..['frames/subtitle_299.png', 'frames/subtitle_300.png', 'frames/subtitle_301.png', 'frames/subtitle_302.png', 'frames/subtitle_303.png'] (298)

结合这项特性,可以处理一些不打算提取时轴的硬骨头
再处理的时候,就可以利用许多成熟的工具,比如 GIMP 什么的进行后期处理再 OCR
a.png
3.7 MB
像这样,其实也可以直接在 OCR 的时候…不,是在拼接的时候直接存个 filename map 直接允许批量处理了再裁回来,再允许直接在这些帧文件上运行 OCR…… 还算简单,毕竟 ocrWithLocalMaxima 这个子程序被抽象为了一个方法,只需要弄一个把帧文件映射回 Frame 对象的程序即可 😂
#Python #CV #code 新程序已经支持,弄法非常简单,只需 dst src* | unpack dst 即可
duangsuse::Echo
a.png
已经支持 --only-images
做法很简单,削掉 peak estimation (postprocessDifferences 和 findPeaks 都赋一个没 self 的 lambda)
然后拿 image inputs 映射到 Frame(no, img, 0)
然后创建 reducer (ExtractSubtitle.DefaultOcrFold) 、 ocrWithLocalMaxima(frames, reducer)reducer.finishAll() 完事
Forwarded from Aelita Lyoko
如果我没猜错的话,这个是手机端渲染引擎的问题
Forwarded from Aelita Lyoko
视频图像是差分压缩差分渲染的,然而可能弹幕的渲染被放在图像变化区域渲染之前了,就导致变化区域的图像盖住了弹幕
Forwarded from Aelita Lyoko
(纯属猜测
Forwarded from dnaugsuz
我听人说是一个 feature,开了还会多消耗点CPU内存什么的 🤔
Forwarded from dnaugsuz
照道理如果是你说的那个情况,那我看其他运动激烈的视频会导致弹幕放不出
Forwarded from Aelita Lyoko
当然我也觉得可以当作是个feature
Forwarded from Aelita Lyoko
至于多消耗资源,这样子改了默认的渲染管线,的确会多消耗资源
Forwarded from dnaugsuz
v5.44.2 里我发现没有这个设置
Forwarded from dnaugsuz
真的是 bug 造出的 feature?!
Forwarded from Aelita Lyoko
好像有的时候是会有这个现象