上周同事抱着一台笔记本过来，说活动页面需要一段“会动的羊”，原素材是一个16帧的GIF，背景里还有人走动，问能不能只把羊抠出来、换到产品背景上、再导出成新的GIF。我翻了一圈现成工具：在线抠图站只吃静态图，Photoshop能逐帧抠但边缘在播放时跳闪得厉害，硬抠一轮要几十分钟。最后一咬牙，用两个晚上写了一个处理GIF内动态元素抠图的小工具，把运动区域检测、逐帧蒙版生成、透明GIF合成整条链路都跑通了。这篇文章就把工具的思路、代码和踩坑记录一起整理出来，适合有Python基础、平时要处理动图素材的设计师、运营或做图像处理的同学参考。全程以“动态元素”为核心来拆解，不讲虚的。
1. 先搞清楚GIF里“动态元素”到底难在哪里
1.1 静态抠图是空间问题，动态抠图是时间和空间的联合问题
很多人刚接触这个需求时的第一反应是：GIF不就是一堆静态图拼在一起吗？把每一帧都抠一遍，合成回去不就完了？这个思路理论上成立，实际上工作量非常大，而且成果往往惨不忍睹。
静态图抠图本质是一个空间分割问题：目标物体在一张图里，边缘、颜色、对比度都是可见的，用色彩聚类、边缘检测、语义分割模型都能做。但GIF里的动态元素不一样，目标在每一帧的形状、位置、遮挡关系都在变。比如一个人奔跑的GIF，他的手臂在帧与帧之间可能有几十像素的位移，边缘轮廓跟着剧烈变化。如果你把每一帧当独立图片去抠，再拼成GIF，播放起来会看到轮廓像海浪一样起伏，边缘一会儿粗一会儿细，颜色一会儿亮一会儿暗。
更麻烦的是，动态GIF的“前景”和“背景”往往是靠运动语义区分的，而不是靠颜色或边缘。举个例子：背景里有棵树，树和人的颜色都偏深绿深棕色，静态分割器很容易把人和树糊在一起。但人眼一眼就能分清，因为树不动、人在动。所以做动态抠图，第一步往往不是“分割”，而是先搞清楚哪里在动。
1.2 GIF格式本身带来的三个隐藏麻烦
除了“动态”带来的算法难度，GIF这个格式本身还有三个坑，做工具之前必须心里有数。
第一是256色调色板限制。GIF的每一帧最多只能有256种颜色，而且全局调色板理论上只有一个。这意味着你在每一帧上精细抠出来的半透明边缘，保存回去时颜色会被强行量化，半透明像素会变成带噪点的硬边。很多时候你会发现，原图看着还行，一旦保存成GIF，边缘立刻“碎”了。
第二是局部帧优化。为了减小文件体积，很多GIF并不是每一帧都保存整张画面，而是只保存“变化的那一小块区域”，靠前帧画面叠加出来的。用Pillow或OpenCV直接拆帧时，如果不做帧重建，你可能拿到的某一帧只有左上角一小块内容，其余地方是空的或者残留上一帧的画面。
第三是压缩伪影。GIF用无损LZW压缩，但颜色量化过程本身就是有损的。运动物体边缘附近，经常会出现一圈颜色奇怪的噪点，半透明像素被硬量化成不透明或全透明。这些噪点在单帧上不显眼，一旦抠图换到新背景上，就会变成一圈明显的“毛边”。
1.3 什么样的动态主体适合自动抠
不是所有GIF都适合自动处理，我实测下来把场景分成三类：
- 背景静止或缓慢变化、目标动作明显：效果最好，帧差法或背景建模就能把前景拎出来。
- 背景复杂但目标运动方向稳定：可以自动做候选区域，再配合交互式框选，用颜色模型和光流一起锁住目标。
- 镜头晃动、背景也有人走动、目标又小又乱：纯自动很容易翻车，需要逐帧人工干预，工具能做的只是帮你把重复劳动降到最低。
所以这个工具我一开始就没打算做成“全自动点一下就出结果”，而是自动检测 + 人工确认 + 蒙版传播的半自动路线，把机器擅长的事和人的判断结合起来。
2. 工具的整体架构：为什么选“半自动分割”路线
2.1 技术栈选择：Python + OpenCV + Pillow 的理由
这个工具我全部用Python写，核心依赖只有三个：OpenCV、Pillow、NumPy。
OpenCV负责图像处理算法：灰度转换、光流计算、形态学操作、GrabCut分割，这些模块非常成熟。Pillow负责GIF的帧级读写、调色板控制、最终保存，尤其是它对GIF透明通道和调色板的控制粒度比OpenCV要细。NumPy就是中间的粘合剂，因为OpenCV的图像本质是NumPy数组。
有人会问为什么不用FFmpeg直接处理。FFmpeg在转码、抽帧、加滤镜方面很强，但它不理解“目标语义”，你没法让它“只保留那只羊”。也有人问为什么不用C++写，效率更高。但对这种工具型项目，开发效率比极致性能重要得多，Python脚本随时可以改，OpenCV底层的算法复杂度已经帮我们挡掉了大部分性能问题。
顺带说明一下，我最终的形态不是一个GUI软件，而是一个命令行工具：输入GIF路径、模式参数、阈值参数，输出新的GIF。设计成命令行是为了方便批量处理，也是因为这个工具的核心价值在算法链路，不在界面交互。
2.2 工作流设计：自动预检、运动检测、人工确认、蒙版传播、合成
整个处理流程我设计成五个阶段，每个阶段都有明确的输入输出，方便随时做人工介入：
- 自动预检：读取GIF帧数、尺寸、帧率，估算运动强度，判断这个GIF适合哪种模式。
- 运动检测：计算帧间差分、光流运动幅度，得到“哪里在动”的候选区域。
- 人工确认：在首帧或某帧上，用户框选/点选目标，把纯算法结果修正为用户真实意图。
- 蒙版传播：把确认过的目标蒙版，通过光流、颜色模型传播到其余每一帧。
- 合成输出：把每一帧的前景像素保存到透明GIF，或粘贴到新背景。
为什么必须要有“人工确认”这一步？因为纯运动检测只知道“有东西在动”，不知道“哪个动的才是你想要的”。背景里摇动的树叶、飘动的云、晃动的人影，运动幅度可能比你的目标还大。用户在首帧上花两秒钟框一下，后面几百帧就能自动传播，这比任何花哨的自动算法都可靠得多。
2.3 三种模式的适用场景与取舍
工具内部我分了三种模式，供不同场景选择：
| 模式 | 用户操作量 | 适用场景 | 出图质量 | 耗时 |
|---|---|---|---|---|
| 全自动运动分割 | 零操作 | 背景固定、目标动作大 | 中，可能有背景残留 | 快 |
| 交互式框选 + 传播 | 首帧画一个框 | 背景复杂、目标明确 | 高 | 中 |
| 手动逐帧修正 | 每N帧微调蒙版 | 目标运动无规律、遮挡严重 | 很高 | 慢 |
我平时用得最多的是第二种。它平衡了使用成本和效果：第一帧框选目标，第一帧用GrabCut生成初始蒙版，再用光流把蒙版传播到后续帧，每隔几帧用户扫一眼，如果发现蒙版漂移，就在关键帧上修一下，重新传播。这像是一个“半自动关键帧动画”的思路——人工只在关键帧给方向，机器负责中间帧的补全。
3. 核心Pipeline实战：拆帧、运动检测、蒙版生成
3.1 第一步：拆帧与帧重建
通过Pillow拆GIF帧，最直接的方式是ImageSequence.Iterator。但如果某个GIF内部有局部帧优化，直接copy出来的帧可能是不完整的画面。我在工具里做了保险式的帧重建：把上一帧的完整画布作为底色，再把当前帧的内容叠加上去，这样即便当前帧只存了一个局部小块，也能得到正确的完整画面。
from PIL import Image, ImageSequence def load_gif_frames(gif_path): im = Image.open(gif_path) frames = [] canvas = None for frame in ImageSequence.Iterator(im): cur = frame.convert("RGBA") if canvas is None: canvas = cur.copy() else: # 以旧画布为底，叠加上当前帧，保证局部帧不缺块 new_canvas = Image.new("RGBA", im.size) new_canvas.paste(canvas, (0, 0)) new_canvas = Image.alpha_composite(new_canvas, cur) canvas = new_canvas.copy() frames.append(canvas.convert("RGB")) return frames这里有个细节值得留意：alpha_composite会把当前帧的非透明区域覆盖到旧画布上，这能应对大多数“局部帧只存变化区域”的情况。但如果是那种动图里明确要求“先恢复成背景色，再画新内容”的帧（GIF的disposal method为2的情况），逻辑上应该先清空画布，再贴当前帧。严谨版需要在frame.info里读disposal字段，按四种规则分别处理：不处理、保留上一帧、恢复背景色、恢复上一帧。现实中我遇到的大部分素材，用上面的叠加逻辑都能跑通，真遇到画面错乱的GIF，再手动切到严谨模式。
3.2 第二步：运动前景检测的三种做法
拿到完整帧序列之后，第一步是找出“哪些区域在动”。我实测下来，光靠一种方法容易被骗，所以我一般把帧差法和稠密光流的结果做合并。
帧差法是最朴素的：连续两帧做差值，像素值变化大的地方就是运动区域。它的优点是快、直观，缺点是当物体匀速运动且帧率较高时，前后两帧几乎重叠，目标内部被“抵消”了，最后只剩一个轮廓边缘。而且物体一旦停下来，帧差值立刻归零，目标直接消失。
稠密光流能给出每个像素的运动矢量，不只是“变没变”，而是“往哪里动、动了多少”。我一般用Farneback算法，对GIF这种小尺寸动画已经足够快。光流的好处是能捕捉到帧差法容易漏掉的内部纹理变化，坏处是噪声多，纹理稀疏区域（大片纯色背景）光流很容易算出错误的运动场。
实际代码里，我把两者取或集合并做形态学处理，再用面积过滤去掉噪声：
import cv2 import numpy as np def compute_motion_masks(frames, thr_motion=0.8, thr_diff=20): masks = [] prev_gray = None for i, rgb in enumerate(frames): gray = cv2.cvtColor(np.array(rgb), cv2.COLOR_RGB2GRAY) gray = cv2.GaussianBlur(gray, (3, 3), 0) if prev_gray is not None: flow = cv2.calcOpticalFlowFarneback( prev_gray, gray, None, pyr_scale=0.5, levels=3, winsize=15, iterations=3, poly_n=5, poly_sigma=1.2, flags=0 ) mag, _ = cv2.cartToPolar(flow[..., 0], flow[..., 1]) _, mag_mask = cv2.threshold(mag, thr_motion, 255, cv2.THRESH_BINARY) diff = cv2.absdiff(prev_gray, gray) _, diff_mask = cv2.threshold(diff, thr_diff, 255, cv2.THRESH_BINARY) combined = cv2.bitwise_or(mag_mask, diff_mask) kernel = cv2.getStructuringElement(cv2.MORPH_ELLIPSE, (5, 5)) combined = cv2.morphologyEx(combined, cv2.MORPH_CLOSE, kernel, iterations=4) combined = cv2.morphologyEx(combined, cv2.MORPH_OPEN, kernel, iterations=2) # 去掉极小连通域 n, labels, stats, _ = cv2.connectedComponentsWithStats(combined, 8) clean = np.zeros_like(combined) for j in range(1, n): if stats[j, cv2.CC_STAT_AREA] >= 80: clean[labels == j] = 255 masks.append(clean) prev_gray = gray return masks关于Farneback光流参数，我多说一句：winsize=15算是一个比较稳的默认值，太小容易满屏噪声，太大又会让运动边缘变得模糊。poly_n=5是多项式展开邻域尺寸，一般用5比较均衡。如果GIF分辨率非常小，比如只有160x120，可以把levels降到2，书里不会写这些，但你实测几十张后自然会找到感觉。
帧差法和光流合并之后，得到的蒙版本质是“候选运动区域”，还不是“目标蒙版”。因为目标内部的纹理若太均匀、移动速度又慢，光流计算的结果往往是残缺的，只有边缘一圈。所以还需要接一轮后处理。
3.3 第三步：蒙版后处理，把mask洗干净
这一步的目的是把软件算出来的原始蒙版洗成“能直接用”的抠图mask，我按顺序做四件事：
- 闭运算：先膨胀再腐蚀，把断开的边缘连接起来，填补细小的内部裂缝。
- 开运算：先腐蚀再膨胀，去掉独立的杂点。
- 连通域过滤：把面积小于阈值的小块直接抹掉，通常背景里风吹树叶、画面噪点都会被这一步清掉。
- 边缘羽化：在蒙版边缘做高斯模糊，让抠出来的目标边缘带半透明过渡，而不是一刀切的硬边。
def refine_mask(mask, close_iter=4, open_iter=2, min_area=80): kernel = cv2.getStructuringElement(cv2.MORPH_ELLIPSE, (5, 5)) mask = cv2.morphologyEx(mask, cv2.MORPH_CLOSE, kernel, iterations=close_iter) mask = cv2.morphologyEx(mask, cv2.MORPH_OPEN, kernel, iterations=open_iter) n, labels, stats, _ = cv2.connectedComponentsWithStats(mask, 8) clean = np.zeros_like(mask) for i in range(1, n): if stats[i, cv2.CC_STAT_AREA] >= min_area: clean[labels == i] = 255 clean = cv2.GaussianBlur(clean, (5, 5), 0) return clean这一步做完，得到的蒙版已经可以用来抠图了。但要注意，羽化蒙版之后一定要配合背景处理，否则后面换背景时会出现白边（具体解法在第四章细说）。
3.4 第四步：交互式分割与蒙版跨帧传播
自动检测在简单背景GIF上效果不错，但背景复杂时，运动候选区域可能包含多个物体，或者目标被背景物体遮挡断裂。这时候就需要用户介入，我用的是GrabCut加光流传播的组合。
第一帧让用户画一个矩形框住目标，然后跑GrabCut：
def grabcut_initial_mask(img_rgb, rect): mask = np.zeros(img_rgb.shape[:2], np.uint8) bgd = np.zeros((1, 65), np.float64) fgd = np.zeros((1, 65), np.float64) rect = tuple(int(v) for v in rect) cv2.grabCut(img_rgb, mask, rect, bgd, fgd, 5, cv2.GC_INIT_WITH_RECT) fg = np.where((mask == 1) | (mask == 3), 255, 0).astype(np.uint8) return fg拿到第一帧的蒙版之后，需要把它传播到后续帧。我用的传播思路是：先用光流把上一帧的蒙版warps到当前帧，再用当前帧的颜色统计做局部修正，防止光流漂移。
这个思路的代码实现比运动检测简单，但效果依赖参数。核心逻辑是：
def propagate_mask(prev_mask, prev_gray, cur_gray, shape=(0, 0)): flow = cv2.calcOpticalFlowFarneback( prev_gray, cur_gray, None, 0.5, 3, 15, 3, 5, 1.2, 0 ) h, w = cur_gray.shape y, x = np.mgrid[0:h, 0:w].astype(np.float32) fx = x + flow[..., 0] fy = y + flow[..., 1] warped = cv2.remap(prev_mask, fx, fy, cv2.INTER_NEAREST) return warped传播之后，蒙版会在几十帧内逐渐漂移或丢失碎片。应对办法是关键帧机制：每隔8~10帧，自动把当前蒙版展示给用户看一眼，如果发现明显偏差，用户在这一帧重新框选一次，重新开始传播。这个机制虽然让使用过程中多了几次点击，但换来的是最终输出质量稳定，不容易出现目标肢体飞出蒙版外的可悲场面。
4. 合成新GIF的关键细节
4.1 透明GIF保存的正确姿势
当每一帧的蒙版都算好之后，就能把原图的前景像素提出来，输出为透明背景的GIF。但这个环节有个大坑：Pillow保存GIF时不支持RGBA直接保存，必须转成P模式（调色板模式），然后把某一种调色板索引定义为透明色。
最稳妥的写法是：先用第一帧做一次255色量化生成一个全局调色板，让每一帧都在同一个调色板上量化，保证颜色稳定，再把透明区域统一指向最后一个索引（比如255），保存时通过transparency=255声明该索引是透明色。
from PIL import Image def save_transparent_gif(frames_rgba, out_path, duration=80, loop=0): first_rgb = frames_rgba[0].convert("RGB") palette_img = first_rgb.quantize(colors=255) transparent_idx = 255 saved = [] for f in frames_rgba: rgba = f.convert("RGBA") p = rgba.convert("RGB").quantize( colors=255, palette=palette_img, dither=Image.DITHER_FLOYDSTEINBERG ) # 把透明像素统一指向透明索引 alpha = rgba.getchannel("A").point(lambda a: 255 if a < 128 else 0) p.paste(transparent_idx, (0, 0), alpha) saved.append(p) # 把透明索引对应的调色板项设为黑色 pal = list(saved[0].getpalette()) off = transparent_idx * 3 pal[off:off + 3] = [0, 0, 0] for img in saved: img.putpalette(pal) saved[0].save( out_path, save_all=True, append_images=saved[1:], duration=duration, loop=loop, transparency=transparent_idx, disposal=2, )这段代码里有三个细节比较讲究。第一是quantize时传了同一个palette_img，这样所有帧共享颜色表，不会出现“同一个物体在每一帧里颜色都不一样”的问题。第二是dither=FLOYDSTEINBERG开启了误差扩散抖动，对渐变区域有帮助，但会让文件体积稍微变大。第三是disposal=2，它告诉播放器“显示完当前帧后恢复成背景色”，直接避免下一帧叠加残影。
4.2 帧间颜色一致性：统一调色板是第一要务
很多人在合成GIF时会忽略一个隐蔽问题：如果每一帧独立做颜色量化，那么同一种颜色在不同帧里可能被分配为不同的调色板索引，播放时整个画面会像霓虹灯一样闪烁。尤其是动图中有大面积渐变、天空、皮肤阴影这些区域时，闪烁感非常明显。
统一调色板之后，闪烁问题会大大缓解，代价是文件体积略涨。因为全局调色板要为整段动画的所有颜色留位置，每帧的局部颜色表达不够“精准”。这是一个良性的取舍，用在动态抠图场景里，稳定性远比那几KB重要。
如果你发现统一调色板后颜色仍然有跳变，还可以检查一下quantize时传入的palette参数是否真的生效了。Pillow在不同版本里对palette参数的支持程度略有差异，有的版本需要先把palette_img转成P模式再传入，有的版本支持RGB模式直接传入。实测在Pillow 10.x上，传P模式是稳定的。
4.3 换背景时如何避免边缘白边
把透明GIF贴到新背景上之后，最常见的视觉效果是目标边缘有一圈发白的半透明边。原因是抠图蒙版比目标实际边缘大了一圈，把原来属于旧背景的、颜色较亮的像素也留了下来。
解决办法是“先收缩，再羽化”：把蒙版先向内收缩1~2像素，让前景范围略微小于真实目标，然后再做高斯模糊让边缘平滑。这相当于用一点点目标边缘的真实损失，换取边缘过渡的自然感。对真人、动物这类主体来说，牺牲1像素的细节几乎看不出来，但白边会消失得非常干净。
如果白边不全是亮色，而是泛着旧背景的颜色（比如绿幕抠出来泛绿光），还需要做一个简单的去边处理：沿边缘把RGB值往中灰色方向拉一点，降低饱和度。这一步有点像电视领域的去色边算法，原理简单但效果立竿见影。
5. 实测踩坑记录：四条高频问题的完整排查链路
5.1 幽灵背景：合成后第N帧出现前一帧的残影
第一次把合成GIF保存出来之后，我发现一个怪现象：第3帧开始，目标背后会隐隐出现第2帧的轮廓，越往后越明显，像鬼影一样。
我的排查链路是这样的。先怀疑是蒙版没更新，把每一帧蒙版单独导出来检查，发现蒙版本身是干净的。再怀疑是帧本身有问题，把每一帧画面单独保存成PNG，画面也没有重叠。那问题就出在保存参数上。
去查GIF的格式规范就会发现，GIF播放器在显示新一帧时，如果上一帧没有被指定清理方式，默认会保留在画布上。我没设disposal参数，Pillow保存时用了默认值，于是每一帧叠在上一帧上面，叠得多了画面就脏了。
修复方式就是把保存参数里的disposal=2显式加上，重新合成后鬼影消失。这个坑非常隐蔽，因为单帧看没有任何问题，必须播放起来才看得到。所以我后来把disposal=2写死在保存函数里，不再依赖默认行为。
5.2 边缘Halo：抠出来的目标白边发亮
另一个高频问题是，目标边缘在透明背景上看是干净的，一贴到深色背景上，边缘就出现一圈发亮的白边。
根因有两层。第一层是原GIF本身在目标边缘附近就混入了旧背景的高亮像素，静态看图不明显，动态播放根本不会注意到。第二层是我早期版本的蒙版保存得太“大方”，羽化半径过大，把边缘那些高亮像素一起保留了下来。
解决方法是组合拳：蒙版先做1像素腐蚀收缩，再做2像素高斯羽化。如果还是有轻微白边，就对边缘像素做一个降饱和处理：把边缘区域的多通道像素向灰度方向压缩，保留亮度但降低彩色偏移。实测下来这个组合能够把绝大多数halo压下去，尤其适合白色背景、浅色背景的GIF素材。
5.3 循环播放时首尾帧颜色跳变
GIF默认循环播放，首尾相接。如果第一帧和最后一帧的调色板状态不一致，播放到最后一帧再回到第一帧时，画面颜色会突然跳一下。这个在本地单帧预览时完全看不出来，只有循环播放时才暴露。
我把保存流程改成“全帧统一调色板”之后，这个问题消除了大半。但还有一种情况是首尾帧本身的画面状态差异很大，比如第一帧是从背景里“生”出来的，最后一帧正在往画面外移。这种情况下调色板解决不了，需要在合成前对首尾帧做一次状态微调：把最后一帧的目标位置稍作平移，或者让最后一帧渐隐结束，让循环点更自然。具体做法是在输出时，对最后一帧做一个透明度渐变，让目标在末帧淡出，循环回第一帧时视觉上过渡平滑。
5.4 大尺寸GIF内存暴涨与速度优化
第一次处理一张1024x768、100多帧的GIF时，脚本直接占了好几个GB内存，运行速度更是慢到让人怀疑人生。排查发现瓶颈在光流计算：Farneback稠密光流越大的分辨率计算量增长越夸张，而且我们是对每一帧都做计算，没有缓存。
我的优化策略是降分辨率计算蒙版，再放大蒙版贴回原图。具体流程是：先把帧缩放到宽度不超过480px的小图，在小图尺寸上算光流、算运动蒙版、算GrabCut分割；拿到小尺寸蒙版后，用cv2.resize放大回原图尺寸，再做一次1像素的羽化修复边缘。这样计算量能降一个量级，蒙版精度损失很小，因为光流和分割本来就不需要像素级细节支撑。
另外，对不需要精确运动的帧，我加了缓存机制：如果当前帧的光流结果和上一帧非常接近，就直接复用上一帧的蒙版，不再重新计算。这对那种“主体动一下、停两秒”类型的GIF特别有效，能省掉一大半无谓计算。
6. 从脚本到工具：扩展思路与参数建议
6.1 接入更强的分割引擎提升上限
当前方案的蒙版质量上限，受限于GrabCut和光流本身的算法能力。如果手上的GIF目标形状复杂、遮挡严重，或者背景和前景颜色高度相似，这套组合容易吃力。现在做分割有个更优的选择：在第一帧用SAM（Segment Anything Model）这类交互式分割模型，用户点一下目标中心，模型直接吐出一个高质量初始蒙版，再配合我上面讲的光流传播机制，把蒙版推到后续帧。
这样修改最大的收益是初始蒙版质量大幅提升，尤其在人形、动物、常见物体上，SAM生成的分割边缘比GrabCut干净太多。代价是需要引入模型推理环境，对部署要求高一些。如果你只是本地自用，可以考虑用轻量的MobileSAM变体，在CPU上的推理速度也能接受。
6.2 工程化改造：命令行、批量处理、Web界面
工具从能跑到好用，中间还隔着一个“参数工程”的距离。我最开始所有阈值都写在代码里，后来改成命令行参数：输入GIF路径、输出路径、模式、光流阈值、帧差阈值、最小连通域面积、羽化半径。这样批量处理文件夹时，一行命令遍历上百个GIF，或者接进自动化管线都很方便。
再往后，还可以用Gradio或Flask套一个简单的Web界面，让不写代码的同事自己拖GIF上去，框一下目标，下载结果。核心算法还是同一套，界面只是把交互动作变成鼠标操作。如果你经常需要给运营同事产出动图素材，这个包装非常值得做，能省不少沟通成本。
6.3 一套默认参数表和我最后的经验
随手整理一份我反复调出来的默认参数，直接抄走作为起点即可：
| 参数 | 推荐值 | 适用说明 |
|---|---|---|
| Farneback winsize | 15 | 小尺寸GIF降到8~10 |
| 光流运动阈值 | 0.8 | 值越大，运动候选越少 |
| 帧差阈值 | 20 | 值越大，对光线变化越钝感 |
| 闭运算核 | 5x5椭圆 | 默认即可 |
| 最小连通域面积 | 80px | 过滤背景噪点 |
| 蒙版收缩 | 1px | 消除白边 |
| 高斯羽化半径 | 2px | 边缘平滑 |
| 统一调色板颜色数 | 255 | 留出1个索引给透明 |
最后分享一个个人体会：别迷信某一个算法能包打天下，哪怕是SAM也有翻车的时候，真正让工具好用的，是“算法自动算一遍，人眼扫一眼，再补一刀”的半自动流程。我用这套工具处理过几百张大小不同的GIF，大部分素材能在一个合理时间内拿到干净结果，少部分模糊、抖动、遮挡严重的动图，最后还是靠关键帧手工修正兜底，但这个兜底成本已经比逐帧用Photoshop抠低了数倍。这也就是这个工具最让我满意的地方。
