如何看待何同学最新视频《我用 36 万行备忘录做了个动画》?

画画的,专画可爱的东西

2130 👍 / 110 💬

问题描述

何同学被指盗用开源项目,本人致歉称文案不够严谨

何同学回应:我们看到了大家在评论中关于字符画转制程序的讨论。我们视频中使用的字符转制程序确实是由开源项目ASCII-generator改动而来,改动的内容主要是优化字符生成比例、图片裁切方式和传参方式。视频中55秒的旁白“所以我们专门写了一个软件,可以把预览动画里的色块转换成字符”确实不严谨,非常抱歉在视频里没有指出这一点。之所以会出现这种情况,是因为我在写视频的文案时不够严谨,没有和相关同事做好沟通,并没有意识到这个程序是从开源程序改动而来,也没有尽到审稿义务,实在抱歉。我们已经对视频进行换源,修改了相关描述并增加引用来源,同时进行内部检讨,反思流程和审稿上的问题。衷心感谢大家的监督。


如果非要我评价:

第一是视频做的确实不错。

第二才是开源项目说是自己做的不太厚道。

第三是恰饭麻不寒碜。

但如果这里我们不讨论技术实现之外别的东西,这个项目的技术实现本身还是有点意思的,当然有意思归有意思,难度来说确实挺简单的,当然口说无凭,为此不才特意牺牲了一个中午的午睡时间,来重现这个技术栈,确实只需要一点点时间。

在PainterEngine组件市场有组件市场,当中有支持视频解码的ffmpeg组件,这部分直接下载下来就行了

关于解码和音频对接的一堆破事儿我已经处理好了,所以这里直接就可以播放出结果了

那么如何将图像数据转换为字符画呢,非常简单,我们用一个8x16的卷积核对图像进行均值滤波即可,所以做出来的图像会类似这样

当然,这样看上去没啥意思,均值颜色我们将它绘制成字符的0就可以了

px_void PX_Object_RenderFilter(PX_Object_FFmpeg* pFFmpeg)
{
    px_int xcount = pFFmpeg->filtersurface.width / 8;
    px_int ycount = pFFmpeg->filtersurface.width / 16;
    px_int i, j;
    PX_SurfaceClearAll(&pFFmpeg->rendersurface, PX_COLOR(255, 0, 0, 0));
    for (j = 0; j < ycount; j++)
    {
        for (i = 0; i < xcount; i++)
        {
            px_int x, y;
            px_int r=0, g=0, b=0;
            for ( y = 0; y < 16; y++)
            {
                for (x = 0; x < 8; x++)
                {
                    px_color clr=PX_TextureGetPixel(&pFFmpeg->filtersurface, (i * 8 + x), (j * 16 + y));
                    r += clr._argb.r;
                    g += clr._argb.g;
                    b += clr._argb.b;
                }
            }
            r /= 128;
            g /= 128;
            b /= 128;
           
            PX_FontModuleDrawText(&pFFmpeg->rendersurface, 0, i * 8, j * 16,  PX_ALIGN_LEFTTOP, "0", PX_COLOR(255, (px_uchar)r, (px_uchar)g, (px_uchar)b));
            //PX_GeoDrawRect(&pFFmpeg->rendersurface, i * 8, j * 16, i * 8 + 8, j * 16 + 16, PX_COLOR(255,(px_uchar)r, (px_uchar)g, (px_uchar)b));
        }
    }
    
}

但目前为止,我们的实现还很粗糙,比如在何同学这里,有这样的大小变换甚至是字符渐变效果

这块我们先来处理字符渐变,这块其实也简单,使用蒙版渲染即可

这个大小密度渲染就有点意思了,对于视频来说如何决定其密度大小呢,这里其实我先试过了包括Sobel算子在内的边缘检测和DCT变换在内的信息密度,不过试来试去还是直接用灰度能量这种简单直白的算法效果最好

应该说还有很多有意思的效果优化空间的

最后我们来处理一下多屏协同问题,说实话,这部分还是有点意思的。这部分功能在PainterEngine也有,我管它叫VisualOS,简单来说服务端负责渲染,并使用差分压缩传输和一个视频优化压缩算法进行界面同步,就能完成多屏协同。

如果将软件运行在手机上,那么,就可以实现多屏协同了。但必须承认一个中午搓的效果肯定不如何同学的视频效果好,他的视频剪辑,配乐,视角,构图U1S1确实是很优秀的。

当然我也有优点,比如现在技术实现我已经给了还做出来了,除了ffmpeg视频解码部分,其它从渲染同步协议都是我自己搓的,没有用别人的开源库哈。

但问题来了,我还差一个带我恰饭的甲方爸爸。