这些杠杆,按实际作用大小排序
尺寸排第一。体积随像素数走,从 640 像素宽降到 480 像素,等于在动任何编码参数之前先砍掉约 44% 的像素。其次是帧数,几乎线性:帧率减半,文件差不多也减半。
颜色数量排第三,而且没大家想的那么线性——256 降到 128 通常在视觉上几乎无感,却能省 20% 到 30%;而 32 降到 16 一般会明显变难看,换来的收益却小得多。抖动排最后,而且它可能让文件变大:它把平坦好压的区域换成了噪点,代价是体积,买到的是更平滑的渐变。
把 GIF 压小,并且在按下导出之前就看到结果。颜色数量、抖动方式和尺寸各自对画质和体积有多大影响都看得见,预估体积会跟着你调的参数实时更新。
这个预估是真的编码了样本帧算出来的,不是套公式。
按顺序往下做,前两步就能解决大部分问题。
拖进来就行。帧会在本地解码并铺在时间轴上,你能直观看到自己到底在为什么付费。
裁掉首尾的废帧、降低帧率、缩小画布。这三件事对体积的影响远大于任何编码器参数。
从 256 色往下走,一边看预览一边看预估体积。在你第一次看出差别的地方停下。
样本帧会用你当前的参数真的编码一遍,再按整条时间轴外推。我们的竞品调研里,这是唯一一项没人做的能力。
2 到 256 色任选。录屏和扁平插画常常在 32 色下毫发无损,而那大约是同一个文件 256 色时的三分之一大。
扁平图形用"关闭",需要稳定纹理且好压缩时用有序抖动,照片渐变用 Floyd–Steinberg。三者在断层和体积之间的取舍确实不同。
整个文件一套调色板,省掉逐帧色表,也让颜色在循环时不再抖动。它是默认项,因为它几乎总是对的那个答案。
尺寸排第一。体积随像素数走,从 640 像素宽降到 480 像素,等于在动任何编码参数之前先砍掉约 44% 的像素。其次是帧数,几乎线性:帧率减半,文件差不多也减半。
颜色数量排第三,而且没大家想的那么线性——256 降到 128 通常在视觉上几乎无感,却能省 20% 到 30%;而 32 降到 16 一般会明显变难看,换来的收益却小得多。抖动排最后,而且它可能让文件变大:它把平坦好压的区域换成了噪点,代价是体积,买到的是更平滑的渐变。
GIF 是 1987 年的格式,封顶 256 色,也没有帧间运动补偿。一段五秒的视频,做成 GIF 有 3MB,做成 MP4 或 WebM 常常不到 300KB,画质还更好。如果投放的地方收视频——如今大多数聊天工具、文档工具和社交平台都收——这是 10 倍的差距,怎么调参数都追不上。
那 GIF 什么时候仍然是对的?当你需要一个能内联播放、无限循环,并且在邮件客户端和老旧 wiki 里没有播放器也能显示的文件时。那时候它就值这些字节,而上面这些杠杆就是你手上全部的牌。
这是起点而不是规矩——你这个文件的真相由预估值告诉你。
| 录屏、界面 | 32–64 色 · 不抖动 · 12fps |
|---|---|
| 插画、扁平色块 | 16–32 色 · 不抖动 |
| 实拍视频 | 128 色 · Floyd–Steinberg · 12–15fps |
| 照片幻灯片 | 128–256 色 · Floyd–Steinberg |
| 画面里文字多 | 颜色别降太狠,改缩尺寸 |
同一个工作台,对着另一件事使。