./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

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

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

没有相关的开关的

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

反正，如果要考证的话，去看弹幕渲染相关的代码肯定可以确定原因的啦～