像这样，其实也可以直接在 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 .

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

关于绘制提速…… 一般最大的想法就是 OpenCV-Python only (no PIL) 或者干脆 C++ 重写好了
参数也就 font(size), scale, spacing / calc_draw_color(key_color, key_res)

之前想了一种按行而非字符绘制文本的思路，可是发现根本不可行——排除 horizontal 间距没法自定义不提，不同字符不同颜色没法做到！
缓存什么的，估计 pillow 或者 freetype 什么的也是有做的（当然，freetype 只是一个栅格化库而已啦）