前几天录了一段 3 秒的操作 demo，想贴进 README，顺手用在线工具转了个 GIF。默认参数出来 1.9MB，Git 推仓库时嫌大；把参数往"小了压"调，又糊得看不出界面在动。来回试了几次才意识到，GIF 这东西"又糊又大"根本不是转换工具的问题，是格式本身的设计决定的，参数只是在这个既定框架里做取舍。
这篇笔记把 GIF 的存储方式捋一遍，再用同一段视频、三组参数做个实测，看看每一档参数到底买到了什么、牺牲了什么。
一、GIF 为什么天然糊：每像素只有一个调色板索引
GIF（GIF89a）的图像数据不存颜色值，存的是调色板索引。文件里有一张全局色彩表（Global Color Table），最多 256 个条目；每个像素记录的是"第几个条目"，再用 LZW 压缩。
这意味着不管源视频是百万色的连续渐变，还是 YUV 4:2:0 采样的高清帧，转 GIF 时都要先做一步色彩量化：把整帧的颜色归并到最多 256 个代表色里。界面上那些平滑的阴影、渐变高光，量化之后就会出现一条条色带——这就是"糊"的主要来源，跟分辨率关系反而没那么大。
还有一个容易被忽略的点：GIF 没有半透明，只有"透明或不透明"两种状态，所以半透明遮罩、毛玻璃效果转过去也会失真。
二、体积为什么大：全量帧和差分帧
GIF89a 支持两种帧存储方式：
- 第一帧（或关键帧）：整帧全图；
- 后续帧：可以只存与前一帧的差异区域（差分帧），LZW 对这种局部更新压缩得不错。
所以 GIF 的体积不是"帧数翻倍体积翻倍"的线性关系——运动画面里相邻帧大部分区域没变，差分帧只记录变化的部分。后面实测数据能看到这个效应。
三、帧率到底多高才够用
动图和视频的观看场景不一样：GIF 多数时候是"扫一眼"的信息载体，人眼对 10~15fps 的连贯动作已经不会觉得"卡"，但对色带非常敏感。所以对 demo 演示这类内容，帧率先砍、分辨率次之、调色板最后动通常是收益最高的顺序——帧率对体积的影响是实打实的线性叠加（帧数 = 帧率 × 时长），而画质感知主要由调色板和分辨率决定。
四、三组参数实测
同一段 3 秒的 MP4 源视频，输出宽度固定 480px，只动帧率和调色板颜色数两个参数。转换用的是工具派上的视频转 GIF 工具，参数面板可以直接调这两项：
| 组 | 帧率 | 调色板颜色数 | 输出帧数 | 实际颜色数 | 体积 |
|---|---|---|---|---|---|
| A | 10 | 128 | 30 | 123 | 1.88 MB |
| B | 10 | 16 | 30 | 15 | 0.91 MB |
| C | 30 | 128 | 90 | 123 | 3.27 MB |
处理完成后的下载界面，可以直接预览动图效果：
把调色板从 128 降到 16，面板上就是这个滑块的位置：
三个观察：
- 调色板砍掉一半多（128→16），体积减半（1.88→0.91 MB）。 颜色数影响的是每个索引值的熵，LZW 对小调色板的压缩率明显更高。代价是量化更狠，渐变区域的色带更重——对界面演示这种"色块多、渐变少"的内容，16 色其实还能看；对人物、风景视频就明显糊了。
- 帧率拉高三倍（10→30），体积只涨了 74%（1.88→3.27 MB），不是三倍。 印证了差分帧的判断：画面里大部分静止区域在后续帧里不产生数据。但 3 秒 90 帧的 GIF 在 README 里自动循环播放，视觉上跟 30 帧那版没有本质区别，多出来的 1.4MB 属于白花。
- 实际颜色数这一列值得注意：设 128 色调色板，量化后实际用到 123 色；设 16 色则精确压到 15 色。调色板是上限，不是承诺。
五、参数取舍清单
把这次的结论记成几条，下次转 GIF 前对一遍：
- 动图糊的主因是 256 色上限，这是格式的硬约束，转出花来也绕不过；能做的只是别把调色板设得太小、分辨率别缩太狠。
- 卡与不卡和帧率的关系比想象中弱，10~15fps 对演示动图足够；帧率是体积杠杆，不是画质杠杆。
- 时长比参数更值得先砍：3 秒能说清的事别转 10 秒，帧数随时长线性涨，这是最无副作用的减法。
- 转完用
identify -verbose或 PIL 读一下实际帧数和颜色数，验证参数真的生效了：
from PIL import Image, ImageSequence
im = Image.open("demo.gif")
print(im.size, sum(1 for _ in ImageSequence.Iterator(im)), "frames")
print(len(im.convert("RGB").getcolors(maxcolors=10**6)), "colors")
相关工具：gjupai.com
