草，原来绘制和矩阵处理天生不兼容 #CV #Python #visualize
反正我是熟悉 n m y x i j 那一套
可以把 for (i=0; i<n; i++) 套到 绘制程序里

我们只需要往 i, n 扩展一个 j, m 就可以处理项目和 y, x 不匹配的情况
然后矩阵处理又是另一种情况，没有 w,h 什么的

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

像这样，其实也可以直接在 OCR 的时候…不，是在拼接的时候直接存个 filename map 直接允许批量处理了再裁回来，再允许直接在这些帧文件上运行 OCR…… 还算简单，毕竟 ocrWithLocalMaxima 这个子程序被抽象为了一个方法，只需要弄一个把帧文件映射回 Frame 对象的程序即可 😂

#Python #CV #code 新程序已经支持，弄法非常简单，只需 dst src* | unpack dst 即可

已经支持 --only-images
做法很简单，削掉 peak estimation (postprocessDifferences 和 findPeaks 都赋一个没 self 的 lambda)
然后拿 image inputs 映射到 Frame(no, img, 0)
然后创建 reducer (ExtractSubtitle.DefaultOcrFold) 、 ocrWithLocalMaxima(frames, reducer) 、 reducer.finishAll() 完事

关于这个，我来说一下后继 #Bilibili #drawing #CV

如果我没猜错的话，这个是手机端渲染引擎的问题

视频图像是差分压缩差分渲染的，然而可能弹幕的渲染被放在图像变化区域渲染之前了，就导致变化区域的图像盖住了弹幕

（纯属猜测

我听人说是一个 feature，开了还会多消耗点CPU内存什么的 🤔

照道理如果是你说的那个情况，那我看其他运动激烈的视频会导致弹幕放不出

当然我也觉得可以当作是个feature

至于多消耗资源，这样子改了默认的渲染管线，的确会多消耗资源

v5.44.2 里我发现没有这个设置

真的是 bug 造出的 feature？！

好像有的时候是会有这个现象

我觉得 it's a feature，未来版本这种 bug 应该可控（

没有相关的开关的

It's not bug, it's a feature .