GIF表情包制作：视频转GIF、逐帧动画与压缩优化实战

把一段视频做成 GIF 表情包，绝大多数人第一次尝试的结果都是三兆起步、颜色发脏、边缘一圈锯齿，发到群里还要被聊天软件再压一遍。问题其实不在软件不好用，而在 GIF 这个格式本身的上限被大多数人忽略了：它没有帧间运动补偿，只有 LZW 无损压缩，每帧颜色表最多 256 色，帧延迟精度只有 1/100 秒。这几条硬限制决定了 GIF 表情包制作的核心从来不是“做出来”，而是“做完之后还剩多少体积预算”。这篇文章我按视频转 GIF、逐帧动画、压缩优化三段来拆，把每一步为什么要这么做讲透，把参数间的相互影响、GIF 格式本身的限制边界，以及我这些年反复踩过的坑一起摊开说。适合已经把动图做出来但被体积和画质卡住的人，也适合从零开始想给自己做一套专属表情的人，工具链我尽量压在命令行开源方案上，不需要装庞大的商业套件。

1. 先算清楚：GIF 的体积极限到底卡在哪

1.1 三个成本项：颜色、帧数、像素面积

做 GIF 之前，先在脑子里建立一个成本模型，比盲目调参数有用得多。GIF 的体积近似取决于三个乘数：单帧像素面积、帧数、每像素平均比特数（受颜色数和画面复杂度影响）。像素面积是宽乘高，尺寸减半面积就是四分之一，这是所有手段里性价比最高的一刀。帧数等于时长乘帧率，帧率从 30 降到 12，帧数直接砍掉六成。每像素比特数是最玄学的一项，它跟颜色表大小、画面噪点多少、有没有大面积渐变都有关系。

我一般用这个粗算公式给体积定个预期：

预估体积 ≈ 宽 × 高 × 帧数 × 平均每像素比特数 ÷ 8

举个实感一点的例子：480×270 的画幅、12fps、3 秒 36 帧，如果平均每像素 4 bit，算出来是 480×270×36×4÷8 ≈ 2.3MB。实际因为 LZW 压缩对大面积同色区域很友好，通常能做到 1.2MB 到 1.8MB 之间。而同样内容把画幅换成 320×180，其他不变，预估值直接掉到 1MB 出头，实测一般落在 500KB 到 800KB。这就是为什么老手做表情包第一件事不是调色，是先定尺寸。

影响范围也得说清楚：尺寸不只影响体积，还影响观感。聊天窗口里的动图默认显示宽度通常在 200 到 300 像素之间，你做 800 像素宽，用户看到的还是被缩到 300 显示，多出来的像素全部浪费在传输和内存上。所以“按最终显示尺寸的 1.5 到 2 倍生产”是个比较稳的经验值，留一点余量给高清屏，又不至于把体积堆到没意义。

1.2 工具链选型：为什么我最终固定在这四件套

工具选型这件事，我用过很多组合，最后稳定下来的是四件：ffmpeg负责解码、裁剪、变速、调色板和合成，gifsicle负责帧间优化和有损量化，ImageMagick负责 PNG 序列的批量处理和元信息修正，再加一个能看逐帧的位图编辑器负责手修。

选 ffmpeg 做主力，理由是它的滤镜链可以一次性表达完整流程。很多人习惯用带界面的转换工具，点点鼠标就出图，问题在于界面工具通常只暴露“帧率”和“尺寸”两个参数，调色板策略、抖动算法、帧间差分全被藏起来，而这些恰恰是决定体积和观感的关键。ffmpeg 的palettegen/paletteuse是业界公认做得比较扎实的实现，两遍法出来的颜色质量明显好于单遍直接转。

gifsicle 的价值在于它做了 ffmpeg 不太擅长的两件事：一是帧间差异优化，把“这一帧和上一帧相同的像素”改成透明色只画变化部分；二是有损量化，通过--lossy在 LZW 之前先把相近颜色合并，压出来的体积经常能再降 30% 到 50%。代价是可能出现色带，这个后面会讲阈值。

ImageMagick 我主要用来处理逐帧动画那一路的 PNG 序列，比如统一补边、批量调色、按延迟时间合成。它的-delay单位是 1/100 秒，跟 GIF 原生单位一致，比 ffmpeg 的 fps 表达更精确，做那种“每帧停 0.08 秒”的定格动画更顺手。

至于位图编辑器，只用来做一件事：手修首帧和循环衔接帧。自动流程解决不了“这两帧之间人物动作跳了”这种问题，必须人眼看。

注意：不要在同一套流程里混用多个工具的量化步骤。ffmpeg 调色板量化一次，gifsicle 再 lossy 一次，色带会叠加得非常明显，尤其是肤色和天空渐变，两层损失之后基本救不回来。

1.3 一条完整链路的拆解思路

我把整条链路拆成六步，顺序是有讲究的，不能随意调换：

1. 定画幅：根据最终投放场景定宽高，这一步先做，因为它决定了后面所有参数的基准。
2. 截取与变速：从源素材里切出要的那几秒，必要时做速度调整。
3. 抽帧与减帧：把帧率降到目标值，顺手把重复帧丢掉。
4. 生成调色板：基于实际要用的帧统计颜色分布。
5. 合成与抖动：用调色板把帧序列合成 GIF。
6. 帧间优化与有损压缩：gifsicle 收尾，然后人眼验收。

为什么调色板一定要放在减帧之后？因为palettegen是统计型的，它会扫过你喂给它的所有帧然后算出一张最优颜色表。如果你先做调色板再减帧，颜色表里就会混进一堆最终不会出现的颜色，白白占掉色位，让真正需要的颜色被挤掉。这个顺序错了，画面会莫名其妙地发灰。

同理，抖动也必须放在最后合成阶段，不能在中间格式里提前抖。中间格式如果用了无损编码（比如 PNG 序列或者高码率 H.264），抖动图案会被完整保留下来，然后在最终量化时又被压一遍，噪点翻倍，体积暴涨。我见过有人为了“画质好”把中间文件存成抖动过的 PNG，结果最终 GIF 比不抖的版本大了将近一倍，画质还更脏。

2. 素材准备：源头没选好，后面全是补救

2.1 视频源的挑选与截取原则

源素材的质量决定天花板。这里有个反直觉的点：不要用已经被压过好几轮的短视频当源。那种素材本身的块效应和色带在缩小尺寸后不会消失，反而会在 GIF 的 256 色量化里被放大成一块块的色斑。如果你手上只有这种素材，宁可先做一次轻度的降噪和去块，再进流程。

截取的时候我习惯多留 0.3 到 0.5 秒的余量，两头都留。原因是 ffmpeg 的-ss快速定位会吸附到最近的关键帧，如果源视频关键帧间隔大（有些录屏素材十几秒才一个关键帧），精确切点会偏。留余量之后在后面的裁剪或抽帧阶段再修掉，比切少了再回头重新导要省事。

截取时长上有个经验值：表情包动图控制在 1.5 到 3 秒最舒服。太短表达不清动作，太长循环起来像在放幻灯片。如果是那种“点头”“摇头”“鼓掌”的单动作，1 秒到 1.5 秒足够；如果是带前摇的完整动作，2.5 秒左右。超过 4 秒的动图，在聊天场景里基本没人会看完一整轮循环，体积却翻倍。

2.2 画幅、构图与安全区

画幅比例优先选正方形或者接近正方形。理由是聊天软件的表情面板通常按正方形格子展示，非正方形的动图要么被裁掉两边，要么被缩放到格子内留出大片留白，两种情况都难看。常见的做法是把主体居中，裁成 1:1，两侧多余的部分直接切掉。

构图上有几个实操细节值得说。主体要占画面的 60% 以上，因为最终显示尺寸可能只有 200 多像素宽，主体太小就糊成一团。眼神方向要留白，人脸朝右看就往右边多留空间，否则会有压迫感。别把动作的起始帧放在画面边缘，很多动图循环时首尾帧位移大，边缘会出现“跳一下”的观感。

如果你的源素材背景很乱，考虑做一个简单处理：在中间格式阶段用模糊或者纯色遮罩压一下背景。这不是为了好看，是为了减少颜色数量。背景越干净，palettegen能省下的色位越多，主体部分的颜色就越准。这是个很实用的取舍——牺牲一点背景细节，换来主体肤色不发绿。

2.3 中间格式的选择

中间格式我一般选两种之一：PNG 序列或者高码率 H.264 的 mp4。

PNG 序列的好处是无损、可逐帧处理、能直接接 ImageMagick 和手修流程；坏处是文件多、占磁盘、处理慢。一秒钟 12 帧、三秒的素材就是 36 个文件，还好；如果是 30fps 十秒的素材，300 个 PNG，磁盘和 IO 都会有点压力。所以 PNG 序列适合最终帧数不多的情况，比如手绘动画或者帧数已经压到 15 以内的视频转 GIF。

高码率 H.264 的好处是体积小、顺序读写快，适合帧数多的中间过程；坏处是有损。这里的关键是码率要开得足够高，高到损失可以忽略。我用-crf 16到-crf 18，配合-preset slow，这个档位的损失在后续 256 色量化面前完全可以忽略不计。千万不要用-crf 28这种为了省空间的档位做中间文件，那个损失会跟后面的量化叠加。

提示：中间文件不要用 JPEG 序列。JPEG 的 8×8 块效应在缩小尺寸后会变成细密的网格纹理，这些纹理在palettegen统计时会被当成真实颜色变体，大量吞噬色位，最终 GIF 会脏得很难看。

3. 视频转 GIF：两遍调色板法的完整实操

3.1 为什么必须走两遍

GIF 的颜色表是全局的（也可以每帧局部，但体积会上去），一张表最多 256 个色位。问题在于，视频转 GIF 的时候你并不知道接下来要画的这些帧会用到哪些颜色。单遍法的做法是边解码边量化，第一帧用了一套颜色，第十帧发现颜色不够了，只能就近映射，于是渐变区域出现色带、肤色偏绿。

两遍法的思路很简单：第一遍先“看一遍”所有帧，统计出一张最贴合的颜色表；第二遍再拿这张表去上色。多花的代价是一次完整解码，收益是颜色准确度大幅提升。这一步的差异在高饱和、多渐变的素材上特别明显，比如夕阳、霓虹灯、带虚化的背景。

palettegen的stats_mode参数决定了它怎么统计。full是默认值，统计所有像素；diff只统计帧与帧之间有变化的像素。什么时候用diff？当画面大部分区域静止、只有局部在动的时候，比如人物坐在固定背景前说话，用diff能把色位集中到动的部分，人脸颜色更准。但如果画面整体都在动（镜头摇、大面积粒子），用diff反而会让静态区域的颜色在切换帧时跳变，这时候老老实实用full。

3.2 完整命令与逐段解释

我常用的三段式命令，先做中间文件，再生成调色板，最后合成：

# 第一步：截取 + 缩放 + 抽帧，产出高质量中间文件 ffmpeg -ss 00:00:03.2 -to 00:00:06.2 -i source.mp4 \ -vf "fps=12,scale=480:-1:flags=lanczos" \ -c:v libx264 -crf 17 -preset slow -pix_fmt yuv420p \ intermediate.mp4 # 第二步：基于中间文件统计调色板 ffmpeg -i intermediate.mp4 \ -vf "fps=12,scale=480:-1:flags=lanczos,palettegen=max_colors=128:stats_mode=diff" \ palette.png # 第三步：合成 GIF，带抖动和帧间差分 ffmpeg -i intermediate.mp4 -i palette.png \ -lavfi "fps=12,scale=480:-1:flags=lanczos[x];[x][1:v]paletteuse=dither=bayer:bayer_scale=4:diff_mode=rectangle" \ -loop 0 output.gif

逐段说一下。-ss放在-i前面是快速定位，会吸附到关键帧，速度快但有偏差；放在后面是精确定位，慢但准。我在第一步为了速度放前面，多留了 0.2 秒余量。scale=480:-1里的-1表示高度按比例自动算，但要注意——如果算出奇数，某些编码器会报错，稳妥写法是scale=480:-2，强制取偶数。flags=lanczos是缩放算法，比默认的 bicubic 锐一点，适合缩小图像；代价是稍微慢一点，但对这种短素材完全无所谓。

第三步的diff_mode=rectangle值得单独讲。它让编码器只在画面发生变化的矩形区域内重绘，静止区域留透明。这个选项在人物动作幅度小的素材上能把体积压掉 20% 到 40%。风险是某些老播放器对局部重绘支持不好，会出现残影。我的经验是：主流浏览器和聊天软件都没问题，但如果你的 GIF 要用在比较老的嵌入式设备或者某些论坛的图片预览里，建议关掉它，稳妥优先。

3.3 裁切、变速与去黑边

实际素材很少能直接拿来用，经常要裁掉字幕条、去掉黑边、调一下速度。

裁切用crop=w:h:x:y，四个参数分别是宽、高、左上角横坐标、纵坐标。比如要裁掉底部 60 像素的字幕条，源是 1920×1080，写法是crop=1920:1020:0:0。如果只想保留中间的正方形区域，crop=1080:1080:420:0表示从横坐标 420 开始切一个 1080×1080 的方块。注意滤镜链的顺序：crop要写在scale前面，先裁再缩，这样缩放算法处理的像素更少，边缘也更干净。反过来先缩再裁，缩放时的插值会把画面外的像素混进来，边缘会出现一圈半透明的脏边。

去黑边可以用cropdetect滤镜自动探测：

ffmpeg -i source.mp4 -vf "cropdetect=24:16:0" -f null - 2>&1 | grep crop

输出的crop=w:h:x:y直接抄进正式命令里。参数24是判定阈值，16是每次探测跳过的行数，这两个值一般不用改。

变速用setpts，比如加速一倍是setpts=0.5*PTS，减速一倍是setpts=2.0*PTS。这里有个坑：变速要配合fps滤镜重新抽帧，否则原视频的帧时间戳会被保留，出来的 GIF 时间轴会乱。正确写法是在setpts后面紧跟fps=12。另外减速会导致帧重复，加速会导致帧丢失，如果是加速，抽帧之后画面会有跳帧感，这种素材建议换更高帧率的源，或者接受这种“定格感”——有时候定格感反而是表情包想要的效果。

3.4 抖动算法的取舍

抖动是 GIF 制作里最容易被忽略、但影响最大的一项。原理是：当一张颜色表里没有某个颜色时，用相邻的两种颜色交错排布来模拟，肉眼在一定距离看会混合成目标色。抖动能让渐变看起来平滑，代价是引入噪点，噪点在 LZW 压缩里是灾难——它破坏了同色区域的连续性，压缩率大幅下降。

paletteuse支持几种抖动方式，实测对比大概是这样：

bayer还有个bayer_scale参数，取值 0 到 5。数字越小，抖动颗粒越细越密；数字越大，颗粒越粗越稀。我一般用 3 到 5，因为粗颗粒在缩小显示时更容易糊成一片均匀色，观感反而好，而且压缩率更高。bayer_scale=2以下的细颗粒在小尺寸 GIF 上基本是纯噪点，白白浪费体积。

注意：抖动一旦加上就没法在后期去掉。如果你的素材是扁平风格的插画或者纯色背景的卡通，直接dither=none，观感反而更干净，体积还能省一大截。判断标准很简单——原图里有没有大面积平滑渐变，没有就别抖。

4. 逐帧动画：从拆帧临摹到纯手绘

4.1 三条路线怎么选

不是所有表情包都能从视频里剪出来。很多时候你想要的是一段夸张的、带节奏感的动作，视频里根本没有，这时候就得做逐帧动画。我把路线分成三条，按上手难度排序：

第一条，视频拆帧再手修。把一段视频抽成 PNG 序列，挑出关键姿态，手动调整五官、加特效、改夸张程度。这条路适合有一点绘画基础但不想从零画的人，效率高，神态也自然，因为底子是真实动作。缺点是版权和肖像问题要自己把握，用真人素材做表情包，尤其是商用，风险不小。

第二条，纯手绘逐帧。从一个空白画布开始，一帧一帧画。这条路最自由，风格最统一，也最慢。画一个 12 帧的简单动作，熟练的人大概两三个小时，新手可能要一整天。适合想做一整套风格统一表情的人。

第三条，图片拼合加关键帧变换。拿一张静态图，通过位移、旋转、缩放、形变做出简单动作，比如“抖动”“放大”“左右摇摆”。这条路最快，十分钟能出一个，很多“摇一摇”“点头”类的表情包就是这么做的。缺点是可表达的动作类型有限，做不出复杂的肢体运动。

我的建议是混着用：主体动作走第二条保证质量，简单的强调动效走第三条补数量。一套 16 个表情里，有 3 到 4 个是精心画的，剩下的是简单变换，整体观感就不会太差。

4.2 帧率与循环点的设计

逐帧动画的帧率跟视频转 GIF 不一样，不是越高越好。12fps 是手绘动画的经典档位，画面有轻微的“顿感”，这个顿感是风格的一部分，很多经典二维动画都是这个节奏。8fps 更夸张，适合做那种“卡帧”搞笑效果。24fps 看起来流畅，但对逐帧绘制的工作量要求翻倍，性价比不高。

循环点的设计是逐帧动画最考验功力的地方。一个完美的循环，最后一帧的下一帧应该等于第一帧，而不是最后一帧等于第一帧。这个区别很关键：如果你的序列是 A B C D，循环播放是 A B C D A B C D，那么 D 到 A 的过渡必须自然。很多人做成 A B C D D A B C D D，中间卡了一帧重复，看起来就会“顿一下”。

实践中的处理办法是把首帧复制一份放到序列末尾，然后检查 A→B 和 D→A 的位移量是不是接近。如果 D 到 A 的距离明显大于其他相邻帧的间距，说明这一帧画“远”了，需要往回收一点。这个检查我一般直接用肉眼循环播放，看个十几遍，跳的地方一眼就能看出来。

还有一种情况是非对称循环，比如一个“左看右看”的动作，左边停两帧，右边停一帧。这种节奏感强的循环，靠帧延迟来实现比靠帧数更省。具体做法是让停留的帧重复出现，或者在合成时给这一帧设置更长的延迟。

4.3 透明背景与描边的处理

GIF 的透明是 1 bit 的，也就是说每个像素要么全透明要么全不透明，没有半透明。这个限制直接导致一个问题：抗锯齿的边缘会变成一圈白边或者黑边。因为画图软件导出的 PNG 边缘是半透明的，转成 GIF 时这些半透明像素要么被填成背景色，要么被丢掉，两种情况都会留下硬边。

解决思路有三个。第一个是描边，给主体的边缘加一圈 1 到 2 像素的不透明轮廓线，把半透明区域完全盖住。卡通风格的表情包用这招最合适，描边本身就是风格的一部分，加完反而更好看。描边颜色选深色，跟主体有对比就行。

第二个是贴合背景，不做透明，直接用聊天界面的背景色（浅灰或者白色）当底色。这样边缘可以直接跟背景融合，不需要抗锯齿。缺点是换个深色主题的聊天界面就会露出一块白框。

第三个是牺牲边缘，把半透明像素全部压成不透明，接受轻微的锯齿。在小尺寸显示时，锯齿其实不太明显，尤其是 200 像素宽的时候。这个方案最省事，我做一些自己用的小表情时经常这么干。

如果是导出 PNG 序列再合成，还有个细节：每帧的透明区域大小要一致。有些画图软件导出时会自动裁掉四周的透明像素，导致每帧尺寸不一样，合成出来的 GIF 会跳动。解决办法是导出时勾选“保持画布尺寸”，或者在 ImageMagick 合成时加统一画布参数。

4.4 PNG 序列合成 GIF 的完整操作

手绘完成后，导出的文件按frame_0001.png这样编号，放到一个目录里，然后：

# 统一画布尺寸，防止帧大小不一致导致抖动 magick mogrify -background none -gravity center -extent 480x480 frames/*.png # 用调色板两遍法合成，保证颜色准确 magick frames/*.png -coalesce -colors 128 -dither FloydSteinberg palette.png magick frames/*.png -coalesce -colors 128 -dither FloydSteinberg -delay 8 -loop 0 anim.gif

-delay 8表示每帧停留 8/100 秒，也就是 80 毫秒，换算成帧率是 12.5fps。这个单位跟 GIF 原生单位一致，比 ffmpeg 的 fps 表达精确。如果你要 12fps，理论上应该填 8.33，但 GIF 只接受整数，只能填 8（12.5fps）或者 9（11.1fps）。这个取整误差在长时间动画上会累积，三秒的动画能差出好几帧，所以短动画尽量用能整除的帧率，比如 10fps（delay 10）、20fps（delay 5）、25fps（delay 4）。

-coalesce这个参数很多人不知道是干什么的。它的作用是“展开”帧，如果前面某一帧做过局部优化（只画了变化部分），-coalesce会把它恢复成完整帧，避免合成时出现残影。手绘导出的序列一般不需要，但从别处来的 GIF 再处理时必须加。

5. 压缩优化：把体积从 8MB 压到 800KB

5.1 参数的敏感度排序

很多人压缩 GIF 的方式是一个个参数试，试到体积达标为止。效率太低。我按实测的敏感度排了个序，从上到下依次调整，能最快找到甜点：

按这个顺序调，通常两三轮就能从 8MB 压到 800KB 以内。如果压不下来，说明问题在源头——素材本身太复杂、动作幅度太大、时长太长，这时候应该回头改素材，而不是继续在压缩参数上抠。

这里补一句影响范围的分析：压缩不是只影响文件大小，它影响的是一整条体验链。体积大了，聊天软件上传会失败或者被二次压缩；帧率低了，动作会卡；颜色少了，肤色会发绿；抖动加了，画面会有噪点感。这四者之间是互相牵制的，没有一个参数能单独解决所有问题。所以我一般先定一个硬指标——比如“必须小于 1MB”——然后在这条线上去找画质最优的组合，而不是先追求画质再看体积。

5.2 有损压缩的阈值在哪里

gifsicle 的--lossy是最有效的一招，它做的其实是在 LZW 编码前把相近颜色合并，降低编码复杂度。取值从 0 到 200 左右，数字越大压得越狠。

实测下来，40 到 80 是甜点区间。40 的时候几乎看不出差别，体积能降 20% 到 30%。80 的时候，纯色区域和硬边区域仍然干净，但渐变区域开始出现轻微色带，肤色会有一点点偏。超过 100 之后，色带变得明显，尤其是在天空、烟雾、虚化背景这类大面积渐变的区域。到 150 以上，基本是能看但不好看，除非你的素材是纯色块卡通。

判断阈值的方法很简单：找一个渐变区域，放大到 200%，看有没有出现阶梯状的色块。如果有，就往回调 20。另外注意，--lossy只对-O2及以上优化级别有效，-O1用了不起作用。

5.3 一个可复用的压缩脚本

我把整套流程写成了一个脚本，输入视频、输出 GIF，中间参数全部可调。逻辑是：先按最大预算做一版高质量，然后逐级降参直到达标。

#!/usr/bin/env bash # 用法: ./togif.sh input.mp4 3.0 6.0 480 IN="$1"; START="$2"; END="$3"; WIDTH="$4" TARGET_KB=900 FPS=12 ffmpeg -y -ss "$START" -to "$END" -i "$IN" \ -vf "fps=${FPS},scale=${WIDTH}:-2:flags=lanczos" \ -c:v libx264 -crf 17 -preset slow -pix_fmt yuv420p /tmp/_mid.mp4 for COLORS in 128 96 64; do ffmpeg -y -i /tmp/_mid.mp4 \ -vf "fps=${FPS},scale=${WIDTH}:-2:flags=lanczos,palettegen=max_colors=${COLORS}:stats_mode=diff" \ /tmp/_pal.png ffmpeg -y -i /tmp/_mid.mp4 -i /tmp/_pal.png \ -lavfi "fps=${FPS},scale=${WIDTH}:-2:flags=lanczos[x];[x][1:v]paletteuse=dither=bayer:bayer_scale=4:diff_mode=rectangle" \ -loop 0 /tmp/_raw.gif gifsicle -O3 --lossy=60 --colors "$COLORS" /tmp/_raw.gif -o "/tmp/out_${COLORS}.gif" SIZE=$(du -k "/tmp/out_${COLORS}.gif" | cut -f1) echo "colors=${COLORS} -> ${SIZE}KB" if [ "$SIZE" -le "$TARGET_KB" ]; then cp "/tmp/out_${COLORS}.gif" "output.gif" echo "达标，采用 colors=${COLORS}，体积 ${SIZE}KB" break fi done

这个脚本的核心思路是从高质量往下降，而不是从低质量往上加。降的过程中一旦达标就停，能保住尽可能多的画质。反过来从 64 色开始加，你永远不知道 96 色是不是也够用，加到最后往往是浪费。

脚本里没做的是尺寸自动降级。如果三个颜色档位都不达标，就该考虑改WIDTH了——从 480 降到 400，面积减少 30%，通常就能过线。我把这一步留成手动，因为尺寸变化对观感影响最大，最好人眼确认。

5.4 效果验证与回退

压缩完必须验证三件事，缺一不可。

第一是逐帧看颜色。用能逐帧播放的工具过一遍，重点看渐变区域和肤色。色带、色斑、颜色跳变都在这一步暴露。如果有问题，回退到上一档颜色数。

第二是实际尺寸播放。把 GIF 缩到 200 像素宽在浏览器里循环播放，这才是用户看到的真实效果。很多在原始尺寸下看得见的瑕疵，缩小之后就消失了；反过来，有些在原始尺寸下看不出的抖动噪点，缩小之后会变成一片脏灰。这一步不能省。

第三是循环点检查。盯着画面看至少十个循环，看首尾衔接处有没有跳。常见问题是最后一帧的位移量大，接回第一帧时画面“弹”一下。这种情况要么补一帧过渡，要么把首帧复制到末尾做衔接。

回退策略上，我的做法是每一步都留中间文件。_mid.mp4、_pal.png、_raw.gif、out_128.gif全部保留，改了哪一步就只重跑那一步之后的部分。不做这个的话，调一次参数就要从头解码一次视频，三五轮下来时间全浪费在重复解码上。

6. 常见问题排查实录

6.1 颜色、速度、循环的典型故障

GIF 整体发绿或者发灰。八成是调色板统计的帧跟实际合成的帧不一致。常见原因是第一步中间文件用了-ss快速定位，实际截取的起点跟后面palettegen读到的起点有偏移，统计到的颜色和实际用到的颜色对不上。解决办法是把-ss移到-i后面做精确定位，或者干脆把中间文件先切好，后面两步都读同一个文件。

播放速度比预期快或慢。GIF 的延迟单位是 1/100 秒，且是整数。12fps 对应的延迟是 8.33，取整成 8，实际播放是 12.5fps，快了 4%。如果帧数多，这个误差会累积成肉眼可见的差异。还有一个更隐蔽的原因：延迟值小于 2 的时候，部分播放器会强制按 10 处理，也就是 100ms。所以如果你的 GIF 帧率高于 50fps，实际播放会被强行降速到 10fps，看起来就是卡。这个坑我在做高帧率动图时踩过，排查了半天才发现是格式的锅，不是工具的问题。

首帧被吞掉。有些播放器和平台会跳过第一帧，直接从第二帧开始播。解决办法是把第一帧复制一份放到最前面，或者让第一帧停留时间稍长一点。另一个原因是首帧如果是纯色或者空白，某些优化算法会把它判为“无内容”直接删掉，加个明显的元素就行。

循环时有残影。diff_mode=rectangle的后遗症。某些播放器对局部重绘的处理是把上一帧残留下来，导致画面越播越脏。关掉diff_mode重新合成，体积会大一点，但兼容性没问题。

透明背景变成了黑底或者白底。GIF 的透明色是调色板里的一个索引，如果调色板生成时没把透明色单独留出来，透明区域会被填成调色板里的某个颜色。用 ImageMagick 的时候加-background none，用 ffmpeg 的时候确保输入是带 alpha 的 PNG 序列并且加了-gifflags +transdiff。

6.2 平台适配与体积上限

不同投放场景对 GIF 的限制差别很大，这个必须提前确认，否则做完发现传不上去，返工成本很高。

聊天类应用的自定义表情上传，口径通常在 500KB 到 1MB 之间，动图消息的上限宽一些，普遍在 5MB 以内。社交媒体发帖的动图上限一般在 5MB 到 10MB，但超过 5MB 之后加载会明显变慢，实际体验不好。网页里嵌的 GIF，单张建议控制在 1MB 以内，因为 GIF 是逐帧解码的，一张 5MB 的图在低端设备上能把内存吃掉一大块。

除了体积，还有几个容易被忽略的限制。尺寸上限：有些平台会拒绝超过 1000 像素的动图，或者自动缩放到 500 像素以内，缩放的算法还不如你自己缩得好看。帧数上限：部分平台限制单张动图不超过 300 帧，超了会被截断。时长上限：聊天类动图常见限制是 10 秒，超过之后要么截断要么转成静态图。

我的做法是按最严格的场景做一版，其他场景用这一版。具体就是按 400 像素宽、12fps、2 秒、1MB 以内做一版通用的，需要更清晰的地方再单独出一版大的。这样虽然多做一个文件，但省掉了每次换场景都要重新压的麻烦。

6.3 问题速查表

6.4 几条不上文档的经验

做了这么多版表情包，有几条经验是文档里不会写、但每次都能省事或者救命的。

第一，永远留一个"母版"。母版指的是最高质量的那一版：原始尺寸、30fps、256 色、无损。所有平台版本都从母版降级生成，不要从已经压过的版本再压。二次压缩的色带叠加非常明显，尤其是压过两轮之后，画质断崖式下跌。母版体积可能几十兆，但存着绝对值得。

第二，先做最丑的那一版。听起来反直觉，但这是我最常用的做法：先把参数调到很难看的程度（低分辨率、低帧率、低色数），确认这个动作在最低画质下还能被看懂。如果看不懂，说明动作本身设计得不够清晰，再怎么提高画质都救不回来。这个检查能省掉大量"做完发现不能用"的返工。

第三，颜色数不要死磕 128。很多人默认用 128 色，但实际素材差异很大。纯色背景的卡通 64 色完全够，甚至 32 色都行；带虚化的人像 128 色都紧张，得上 192。判断方法是看画面里有几种主要色系——肤色系、背景色系、衣服色系，每种大概需要 20 到 40 个色位来表现明暗层次。算下来就心里有数了。

第四，抖动是一把双刃剑，宁可不抖。新手容易觉得"加了抖动更专业"，实际上大部分表情包素材是扁平风格，抖动只会让画面变脏、体积变大。真的需要抖的时候，bayer_scale=4或5这种粗颗粒比细颗粒效果好得多，远看是一片均匀的过渡，近看才看得出是点阵。

第五，用真实聊天窗口做最终验收。所有在自己的播放器里看起来完美的 GIF，都应该实际发到聊天里看一眼。聊天软件的背景色、缩放算法、有没有二次压缩，全都会影响最终效果。我做过一个深色背景的表情，自己电脑上看边缘干干净净，发到浅色主题的聊天窗口里露出一圈白边，只能重做。

第六，建立自己的参数档案。做过十几个表情之后你会发现，同一种风格的素材，最优参数基本是固定的。把每次的参数记下来——画幅、帧率、颜色数、lossy 值、最终体积——下次遇到同类素材直接套用，省掉摸索的时间。我用一个纯文本文件记，一行一个，很简单但很管用。

这套流程跑顺之后，一个视频转 GIF 的表情包从选素材到出成品，大概十五分钟。手绘的会慢很多，但那一部分的时间主要花在画上，导出和压缩的环节是一样的。真正耗时间的永远是判断——判断这个动作能不能看懂、这个颜色够不够、这个体积还能不能再压一点。工具只是把这个判断变成现实的手段。