最近在家用投影仪给孩子放一部八十年代末的老动画孩子盯着屏幕问了一句为什么公主的脸是糊的我突然意识到我们这代人习以为常的经典老番对新一代孩子来说画质门槛已经高到劝退的程度。480p的解析度在4K大屏上被放大六倍线条全部发虚色块边缘全是锯齿和色斑观感确实很糟糕。那周我动手做了个视频超分工具用 C# WinForms 做界面APISR 的模型做超分推理Vulkan 做GPU执行后端最终把一个拖进去的老旧动画文件变成分辨率翻倍、线条干净、色带减轻的修复版。这篇文章就是把整个复盘写下来为什么这么选型、模型如何落地到桌面应用、中间踩了哪些坑、最终的参数和效果对照。目标读者是手里有老片源、想在家里自己修收藏的朋友以及想学习深度学习模型如何跑到桌面客户端这条路线的人。1. 老番为什么糊先搞清楚画质差在哪再谈修复在看任何超分方案之前必须先明白老动画画质差到底差在哪。如果只是分辨率低那用播放器的插值算法就能解决完全不需要深度学习。1.1 老动画画质损伤的四类源头第一类是最直观的源分辨率低。老动画从胶片转数字或者早期DVD母带标准就是480p甚至更低。放到1080p屏幕上等于每四个像素猜一个放大必然糊。第二类是压缩损伤。DVD时代普遍是MPEG-2编码码率又不高色度抽样4:2:0导致颜色过渡区域出现块状感边缘出现振铃和蚊噪。这和我们看低码率在线视频的感觉类似。第三类是来源劣化。很多老番根本没有干净的原始数字母带市面上流传的版本是多年前从录像带转的或者经过多次转压。这类片源自带噪声、扫描线、亮度抖动甚至还有隔行扫描残留。第四类是动画特有的线条与色块的退化。动画画面不是自然场景而是大面积平涂色块、锐利线条、网点纹理。低分辨率下线条变成锯齿渐变背景变成色带网点变成一团灰。普通的自然影像超分模型面对这些内容会手足无措因为它没见过明明是平的画面却必须保持边缘锐利这种组合。1.2 为什么普通锐化/插值救不了老番播放器自带的Lanczos、Bicubic插值本质是数学插值。它能增加像素数量但不能增加信息量。你看到的边缘清晰其实只是把原有锯齿放大得更锐利同时把色块边缘衬出一圈白边。锐化滤镜则是另一条路它会把每个边缘都加一条高对比过渡带客观上看起来清楚了但代价是物体边缘出现光晕halo噪点也被放大。老动画本来就有压缩噪声锐化一次等于噪声翻倍。这两类方法都解决不了图像中间缺少信息的问题它们只是让缺失信息的方式变得不那么扎眼。1.3 深度学习超分与传统方案的差异超分模型做的事情本质是猜测它学习了几百万张高清动画图片知道一个动漫人物的线稿边缘在4倍分辨率下应该长什么样所以当它看到一幅低分辨率、模糊、带压缩痕迹的画面时它能基于先验知识把缺失的高频细节补回去。这和插值有本质区别。插值是按数学规则填空模型是按视觉记忆再创作。所以超分能把色块边缘修平整、能把锯齿修成光滑弧线、能消除部分色带这些是任何传统算法做不到的。自然这种再创作也会带来副作用比如细节过度平滑、涂抹感、或者偶尔出现奇怪纹理。所以后文会讨论模型选型和放大倍率控制这是把工具用好最关键的一步。2. 技术选型复盘为什么是 APISR Vulkan WinForms把技术栈拆开说这三块各自解决了什么问题以及替代方案为什么被我否掉。2.1 APISR 在动漫超分里比 Real-ESRGAN 赢在哪Real-ESRGAN 是很强的通用图像修复模型但对动漫场景它有一个先天短板它的退化模型主要模拟自然图像的真实退化对动漫的线稿、色块、网点纹理理解不够深。用 Real-ESRGAN 放大老动画线条容易糊成一坨色块交界处容易出现不均匀的过渡。APISR 是专门为动漫设计的开源超分工具箱它的核心改进在两点训练数据覆盖了大量真实动画退化场景包括压缩伪影、降采样、噪声训练目标里有明确的恢复线与色块的约束。实际效果上APISR 对线条边缘的保持、对色带的抑制都明显比通用模型更适合老动画尤其是 2x 放大档主观观感非常自然。2.2 Vulkan 后端为什么不直接用 CUDA超分模型最常见的推理框架是 PyTorch CUDA。但问题很现实你想让普通亲戚朋友用上这个工具不可能让他先装 Python、再装几 GB 的 CUDA 和 PyTorch还得有一块 N 卡。用 Vulkan 做推理后端意味着任何现代显卡都可以参与计算N 卡、A 卡、核显都行。Vulkan 是图形驱动自带的不需要额外安装运算框架不需要用户配置环境。对个人工具来说这是能不能传给朋友用的关键。我在对比 ONNX Runtime 的多个执行提供程序时发现Vulkan EP 的算子覆盖度和性能已经足够跑 APISR 这种以卷积为主的模型而且它通过 C# 的 NuGet 包就能直接集成不需要写任何底层代码非常适合桌面工具场景。2.3 WinForms 在现在的桌面工具开发里仍是最务实的选择有人会问为什么不用 WPF、Avalonia 或者直接做个网页界面WinForms 的逻辑很简单它是 Windows 下最成熟、依赖最少、打包体积最小的 UI 方案。这个工具的核心逻辑是文件选择、参数配置、进度显示、日志输出不需要复杂的动画和布局。WinForms 在这类场景下开发速度极快发布时单文件发布加几个 DLL 就能跑对最终用户完全透明。种过地的朋友都知道锄头好不好使关键是省力、顺手、不挑地WinForms 就是这个角色的锄头。3. 从模型到界面一个可运行的桌面超分工具全流程下面就是整个项目的主干流程。按这条路线走你可以从零拼出一个能用的工具。3.1 第一步在Python环境里导出一个 ONNX 模型APISR 的模型是 PyTorch 格式桌面端不能用 PyTorch 直接跑所以先导成 ONNX。这一步需要一个临时 Python 环境但日常使用工具的人不需要这个环境这点后面会解释。导出过程大致如下加载 APISR 模型权重构造一个示例输入用torch.onnx.export导出指定 opset 版本。这里有两个经验值opset 建议用 16 或 17。太高可能遇到 ONNX Runtime 各 EP 支持滞后太低有些算子导出不了。输入尺寸尽量用固定 H/W。Vulkan EP 对动态尺寸支持比较弱固定 960x540 或者 640x360可以避免很多运行时问题。 如果是整段视频需要提前用 ffprobe 读取视频宽高再对宽高做对齐。为了避免尺寸不满足模型输入倍数要求把输入尺寸向上取到最近的 16 的倍数。导出后用onnxsim做一次图精简可以去掉一些冗余算子这能明显降低在 Vulkan EP 上出问题的概率。我实际遇到的 PixelShuffle 算子兼容问题就是在简化之后解决的。3.2 第二步在 C# 里接 ONNX Runtime 的 Vulkan 执行提供程序C# 侧核心是Microsoft.ML.OnnxRuntime这个 NuGet 包。它自带一个Vulkan执行提供程序选项需要还额外引用Microsoft.ML.OnnxRuntime.Vulkan运行时包。初始化会话的代码骨架大致如下using Microsoft.ML.OnnxRuntime; var options new SessionOptions(); options.AppendExecutionProvider_Vulkan(deviceId: 0); options.GraphOptimizationLevel GraphOptimizationLevel.ORT_ENABLE_ALL; options.EnableMemoryPattern false; using var session new InferenceSession(apisr_2x.onnx, options);值得注意的是EnableMemoryPattern false。默认开启内存模式时Vulkan EP 在部分动态尺寸输入上会出现内存分配异常。这个参数是我调试时偶然发现的关键开关不关掉的话第二次推理就会报错。推理时输入是 NCHW 的 float 张量值域是 0-1通道顺序是 RGB。每个像素由 Bitmap 转成浮点数组填充张量调用session.Run再把输出张量转回 Bitmap。核心代码using Microsoft.ML.OnnxRuntime.Tensors; var input new DenseTensorfloat(new[] { 1, 3, inputHeight, inputWidth }); // 将每个像素的RGB值归一化后填入input using var inputs new ListOnnxValue { OnnxValue.CreateFromTensor(input) }; using var outputs session.Run(inputs); var output outputs[0].AsTensorfloat(); // 将output转为Bitmap肉眼可见的问题是这个循环很朴素逐帧分配张量会有不少 GC 压力。但实测下来普通 720p 输入、2x 输出每帧推理时间在 N 卡主流型号上大约 30-60 毫秒GC 压力可以接受。如果以后要处理 4K 输出就得换 IOBinding 复用内存我在第 4 节再细说。3.3 第三步用 FFmpeg 抽帧与封装拼出完整视频处理管线视频处理不能直接喂给模型需要先抽帧。我的方案是用 FFmpeg 把视频拆成 PNG 序列逐帧处理最后再拿 FFmpeg 封装回视频。抽帧ffmpeg -i input.mkv -vsync 0 frame_%06d.png这个命令会按原视频的时间戳抽取每一帧而不是按默认的 25fps 去重采样。很多人在抽帧时没加-vsync 0导致动画这种 24/23.976fps 的片源抽出来的帧数不对最后视频时长会变。音频单独抽取ffmpeg -i input.mkv -map 0:a? -c:a copy audio.mka处理完所有帧后再合成ffmpeg -framerate 23.976 -i frame_%06d.png -i audio.mka -c:v libx265 -crf 18 -preset slow -pix_fmt yuv420p10le -c:a copy output.mkv这里额外建议用 10bit 的 x265 输出。动画是色带重灾区8bit 输出时即使超分模型修掉了大部分色带编码环节也可能重新压出色带。10bit 的改善非常直观现代设备播放 10bit HEVC 几乎没有兼容性问题。-framerate必须和原视频帧率一致做法是先用 ffprobe 读取r_frame_rate字段比如24000/1001直接传给 FFmpeg。3.4 第四步WinForms 界面与批量任务设计界面我没有做得很复杂一个主窗口包含视频文件拖放区域模型文件选择下拉框2x 修复、2x 均衡、4x 等等输出目录选择进度条和日志框开始/取消按钮用BackgroundWorker或者Task.Run跑后台任务UI 线程只做进度更新。事实证明这种异步架构对长视频很重要我最早图省事直接在 UI 线程里跑循环结果一集动画处理到一半窗口就假死只能在任务管理器里结束。后来改成后台线程加CancellationTokenSource做取消用户随时可以停止任务。批量处理也不难用户拖入多个文件任务队列按顺序执行每个文件独立抽帧、独立清理临时目录。WinForms 的ListBox配上任务状态枚举就能做出一个足够好用的调度界面。如果想把工具交给完全不懂技术的家人建议做成单文件发布把 ONNX 模型放到程序目录的 models 子文件夹用户只需要选视频、点开始。但凡要用户自己配路径、装依赖工具就会被打入冷宫。4. 调通之后才真正开始的坑Vulkan 推理的九个小教训这个工具最折磨人的阶段不是写界面而是把模型用 Vulkan 跑通。表面上看 ONNX Runtime 封装得很好实际运行中踩了不少坑我把最典型的几条排查链路完整记录下来。4.1 第一次跑通是运气绿屏与黑屏的排查链路第一个典型问题是输出全绿或全黑。具体现象第一帧输出正常第二帧开始输出变成一团绿色或者偶尔整帧黑屏。排查过程是这样的。先怀疑张量初始化有误打印输入 Tensor 的均值方差正常。再怀疑模型输出有问题换成 CPU EP 跑同一帧输出正常。这时候问题就锁定了 Vulkan EP 与 CPU EP 的行为差异。继续追发现session.Run每次都会创建一个新的输出张量而 Vulkan EP 内部对这个张量的内存复用策略有问题。解决方式有两个使用IOBinding绑定固定的输入输出缓冲区由我们自己管理内存复用或者更简单每次都走Run但每次Run之后要把输出张量立即Dispose并且把inputs列表也Dispose。我一开始用的就是第二种因为没有在一个循环里正确释放OnnxValue导致显存里的缓冲区被反复覆盖。把using的作用域严格限制在每次迭代内之后绿屏问题消失。还有一个黑屏问题与颜色通道顺序有关。ONNX 模型的输入通道是 RGB但我从 System.Drawing.Bitmap 读像素时拿到的是 BGR。这个错位会让画面变成一块诡异的灰蓝色或者暗红色。排查时我打印了第一帧的 RGB 均值和输出均值发现输出通道顺序异常才意识到是通道顺序的问题。4.2 显存与性能调优复用、限流与缓存第二个大坑是显存增长。跑完一集动画后任务管理器看到显存占用不降。这说明每一帧创建的 GPU 缓冲区没有被释放干净。解决方式是用IOBinding手动管理 I/O。绑定输入输出到固定的OrtValue后每次推理都在同一块显存区域里执行不再反复分配var ioBinding session.CreateIoBinding(); // 绑定输入张量 ioBinding.BindInput(input, inputOrtValue); // 绑定输出张量指定到设备 ioBinding.BindOutput(output, device); session.Run(ioBinding); var output ioBinding.GetOutputValues()[0];这样显存占用就稳定在一个固定值。注意BindOutput时如果不指定设备输出会落在 CPU 上反而引入一次不必要的拷贝。指定到 GPU 后用GetOutputValues拿结果再手动Dispose整体性能更好。性能上还有一个容易忽略的点Vulkan EP 第一次推理会做 shader 编译耗时可能达到几十秒甚至分钟级。这是正常的不是卡死。如果想让第二次启动变快可以开启SessionOptions缓存。具体做法是把session配置成SetOptimizationLevel并保存缓存目录。但 ONNX Runtime 的 Vulkan 缓存机制在不同版本间不太稳定我最终没有依赖它而是在程序启动时先跑一次 1 帧的预热推理让用户知道这个启动等待是正常的。至于要不要开多线程并行处理帧我建议不要。Vulkan 推理已经占满 GPUCPU 侧并行反而会因为张量拷贝和同步导致整体变慢。用串行循环加每 10 帧打印一次进度日志已经足够稳定。4.3 不同模型档位在动画上的玄学差异APISR 提供了不同侧重的模型有的更强调细节保留有的更强调去伪影。这个选择直接影响观感。我做的对比测试里对于 DVD 画质的老动画细节保留型模型在 2x 档效果最好线条干净、背景纹理自然、人物肤色过渡均匀。如果上 4x虽然分辨率提升明显但画面会出现一种过度锐化的油亮感尤其是人物的头发边缘像是被描了一遍黑边。对于本身噪声很大的录像带转数码片源分子先做一次轻度的去噪会比直接超分更好。我后来在管线里加了可选的预处理先用一个轻量去噪模型跑一遍再超分。虽然耗时多一倍但最终效果平静很多人物的皮肤不再是噪点肌肉。我的结论是超分不是放大倍数越大越好而是修复到目标分辨率的合适档位最好。家用 1080p 或 2K 显示设备480p - 2x 完全够用只有面向 4K 投影仪才需要 4x。4.4 配套的音画处理细节处理老番时还有一个容易翻车的点是封装参数。很多人只处理了视频流忽略了原视频可能包含软字幕、多条音轨、章节信息。用-map 0保留所有流再额外指定视频流替换可以避免丢字幕丢音轨。我实际用的是ffmpeg -i frame_%06d.png -i input.mkv -map 1 -map 0:v -c:v libx265 -crf 18 -preset slow -pix_fmt yuv420p10le -c:a copy -c:s copy output.mkv这样所有原封装的音频轨、字幕轨、章节信息都保留只替换视频流。这个细节对收藏老番很重要因为好多老番的外挂字幕和原声轨找不到替代品。另一个细节是帧率。动画片源经常是 23.976 或 24 帧如果抽帧时用了默认 25fps最终视频会整体加速 4%。从 ffprobe 直接拿r_frame_rate作为输入参数是最可靠的。5. 写给新手的实测参数与主观效果对照工具写完我拿了几类典型片源做了对比这里给出主观效果评估和参数建议。5.1 分片源的主观效果对照片源类型推荐倍数效果评价干净DVD480p2x线条锐利色带减少明显效果非常自然压缩严重网络片源2x 去噪块状感减轻边缘仍有轻微振铃但整体可看录像带转制2x慎用4x噪点大量保留建议先降噪否则放大后噪点更密720p较新动画2x提升有限但不产生副作用适合投大屏主观评分上对动漫观众最在意的线条边缘和色带控制APISR 在 2x 档都得 9/10 左右4x 档线条得 8 分但自然度只有 6 分。所以我推荐大部分人对老番只用 2x。5.2 家庭场景下的推荐处理参数我自己最终固定的参数组合抽帧-vsync 0输出 PNG预处理不启用通用锐化超分2x输入尺寸对齐到 16 的倍数编码x265 10bitCRF 18preset slow这个组合在保持画质和压缩率之间最平衡。如果你对体积不敏感CRF 16 也可以但通常 CRF 18 已经肉眼看不出差异。用 x265 preset slow 处理一集 24 分钟动画在主流 CPU 上大约需要一到两小时这完全可接受毕竟不是实时处理。5.3 这个工具适合谁用如果你手里有大量老动画文件并且愿意花一个下午处理一小批这个工具会很香。如果你想要的是实时增强播放那应该去看播放器插件而不是做批处理超分工具。同样如果只是为了在手机上临时看一集没必要做超分手机屏幕小480p 也够看。超分修复的核心价值在长时间观看、投影设备、以及保存老动画副本这件事上它是给自己留的修复版而不是解决临时观看需求的快捷方式。6. 结尾真正给孩子看之前还要想清楚的事工具做完我给孩子放了一集修复后的老动画。孩子的评价是比以前清楚多了但对成年人来说修复版的观感还是和老动画本身的审美习惯有出入。超分后的画面太干净有些老动画特有的颗粒感和柔焦感没了像是一张被 AI 磨皮的老照片。我现在的建议是处理时分开两个版本一个修复版一个原版保留。修复版给孩子看原版留着自己怀念。毕竟老动画不只是画质差那种介于胶片和数字之间的旧日质感也是记忆的一部分。另外超分修复只适合自己收藏和家庭观看。把修复后的完整动画分享到公共平台会涉及版权问题要谨慎对待。最终这个工具对家庭场景的意义是让经典故事以新一代孩子看得惯的画质继续流传而不是把过去的东西改造成另一种东西。最后分享一个小经验批量处理前先截取 200 帧样片试效果确认模型档位和参数对了再跑全量。我第一次处理全集就是因为没先试样处理完后发现线条太锐利全部重新跑白花几个小时。