图片加水印与 GIF 制作怎么用？拆帧、合成与体积控制
加水印只能证明归属、不能阻止盗用，位置与透明度的选择决定了它是否影响观看；GIF 拆帧时的残影来自帧处置方式与增量帧；做动图时体积则受帧数、尺寸和颜色数三者共同支配。
- 水印只能证明图片归属，不能阻止盗用；四角水印裁剪即可去除，平铺水印难清除但明显影响观感
- GIF 拆帧出现残影，是因为多数帧只存储变化区域（增量帧），解码时未按帧处置方式恢复背景，前一帧内容被保留下来
- GIF 单帧最多 256 色，动图GIF制作器用中位切分量化到 255 色加 1 个透明槽
- GIF 延迟字段的单位是 1/100 秒，动图GIF制作器把最小值钳制在 20 毫秒，比它更小的设置不会让播放更快
- GIF 体积的调整优先级是 输出尺寸 > 帧数 > 颜色数 > 延迟，边长减半体积约降到四分之一
- 动图GIF制作器一次合成的上限是宽 × 高 × 帧数不超过 700 万像素，超出会直接报错
#水印只能证明归属，不能阻止盗用
水印的作用是让图片可追溯，而不是让图片拿不走。 裁掉几个像素、用修复画笔涂一遍，四角水印就没了；平铺水印虽然难清除，代价是整张图的观感都在下降。
| 使用场景 | 建议做法 | 会被怎么绕过 |
|---|---|---|
| 博客、公众号署名 | 右下角小字，透明度 40%-60% | 裁掉右下角即可 |
| 商品图、作品集 | 平铺，透明度 20%-35% | 需逐块修复，成本高 |
| 内部资料流转 | 居中大字，透明度 15%-25% | 遮住主体，但能看清来源 |
| 样稿防盗用 | 平铺 + 旋转 30° | 修复成本最高，观感最差 |
防盗用强度和观感是此消彼长的，没有两全的参数。 判断标准只有一个：这张图被去掉水印之后还剩多少价值。价值高就上平铺，价值低用轻水印就够。
#位置、透明度与旋转怎么取值
九宫格解决「不压主体」，平铺解决「裁不掉」，先想清楚你要防哪一种。 图片加水印 提供九宫格定位，位置和边距按图片尺寸自动计算，导出为原始分辨率的 PNG，不经过有损压缩。
#透明度滑杆范围是 5%-100%
默认值为 60%。低于 15% 的水印在浅色背景上几乎看不见，用曲线工具拉一下对比度就能抹掉；实用区间是 20%-50%，平铺取低端，四角署名取高端。
#旋转范围是 -45° 到 +45°
水平文字容易被图片自身的横线掩盖，也容易被按行涂抹。旋转 30°-45° 后水印会跨越多行像素，想把水印修掉而不伤内容就难得多。
#平铺的间距由字号决定
平铺模式下水印按固定间距铺满整张图，间距约为当前字号的 0.8 倍，没有单独的距离滑杆。所以调大字号会同时放大水印和间距，铺得更稀但每一块更大。
先加水印、再缩尺寸，顺序不要反。反过来做会让水印边缘发虚，因为缩放插值会把它和新压缩的噪点一起糊掉。加水印后用 图片压缩 减体积。
#GIF 拆帧为什么会有残影
残影的根源是 GIF 的增量存储：多数帧只记录画面变化的那一小块矩形，解码时必须叠加到前一张画布上。 解码器如果把每一帧都当成独立的完整图像来画，上一帧的内容就会残留下来 —— 这就是残影。
| 帧处置方式 | 值 | 本帧画完后做什么 | 不处理时会怎样 |
|---|---|---|---|
| Unspecified | 0 | 由解码器决定，通常等同保留 | 可能残留上一帧 |
| Do not dispose | 1 | 保留本帧，下一帧叠加其上 | 正常，但依赖前帧 |
| Restore to background | 2 | 把本帧矩形清回背景色 | 出现前一帧的残影 |
| Restore to previous | 3 | 恢复本帧绘制前的画面 | 出现叠加的多帧 |
GIF 帧提取器 在浏览器里按规范逐帧重建：先读取逻辑屏幕的背景色，再对每一帧判断处置方式，处置方式 2 清回背景色、处置方式 3 恢复绘制前的画面，所以拆出来的静态图与播放时看到的一致。
如果你自己写脚本拆帧，只调用解码器的逐帧 RGBA 接口而不处理帧处置方式，结果几乎一定有残影。这不是 GIF 文件坏了，而是缺了合成这一步。
只剩两种情况仍然会让人觉得「不对」：
- 设计成 sprite 图集、带透明通道的 GIF：浏览器实际是清透明，而不是恢复背景色
- 帧矩形比整幅画布小时，矩形以外的区域沿用上一帧的内容
#GIF 合成的体积控制
GIF 体积大致等于 帧数 × 单帧像素数 × 颜色复杂度，调整优先级依次是 输出尺寸 > 帧数 > 颜色数 > 延迟。 尺寸的收益是平方级的，颜色数很快见底。
| 杠杆 | 怎么调 | 体积收益 | 代价 |
|---|---|---|---|
| 输出尺寸 | 自动/首帧/自定义宽高 | 边长减半，体积约降到 1/4 | 画面变小 |
| 帧数 | 删帧、减少过渡帧 | 线性下降 | 动作变卡 |
| 颜色数 | 量化到不超过 255 色 | 中等，很快见底 | 渐变出现色带 |
| 延迟 | 调大毫秒数 | 几乎为零 | 播放变慢 |
要从 8MB 掉到 5MB 以内，先缩尺寸，再删帧，别去动延迟。 延迟只改变播放速度，对体积几乎没有影响，这是最常见的无效操作。
按这个顺序做通常一次就够：
- 在 动图GIF制作器 里把输出尺寸从「自动（取最大帧）」改为固定宽高，先砍到 480px 宽
- 用 ↑↓ 或拖拽删掉重复帧和过渡帧，24 帧的动作通常能压到 15-18 帧
- 还不够小就继续降尺寸，GIF 单帧最多 256 色，制作器量化到 255 色加 1 个透明槽
- 重新「制作 GIF」，对比下载后的实际体积
一次合成的上限是宽 × 高 × 帧数不超过 700 万像素，超出会直接报错。600×400 只能放 29 帧，800×600 只能放 14 帧 —— 帧数多的时候先降输出尺寸。
延迟在 GIF 里以 1/100 秒为单位存储，制作器把小于 20 毫秒的设置钳制到 20 毫秒：
你设置 100 ms → 写入延迟字段 10（单位 1/100 秒）
你设置 10 ms → 被钳制为 20 ms → 写入 2延迟字段的单位是 1/100 秒，理论上限是每秒 50 帧；20 毫秒的下限意味着再往下调不会让播放更快，只会让文件「看起来设得更快」而已。
#什么时候该用哪个工具
| 你想做的事 | 用哪个 | 说明 |
|---|---|---|
| 给图片加署名或防盗水印 | 图片加水印 | 文字/Logo、九宫格、平铺、旋转，导出 PNG |
| 把 GIF 拆成单帧静态图 | GIF 帧提取器 | PNG/WebP/JPEG 可选，单张下载或 ZIP 打包 |
| 把多张图片做成动图 | 动图GIF制作器 | 增删、替换、排序、逐帧延迟、循环方式 |
| 动图太大需要减体积 | 动图GIF制作器 | 先改输出尺寸，再删帧 |
| 水印加完后要缩小文件 | 图片压缩 | 质量、尺寸、格式三条线 |
| 水印 Logo 要先裁好尺寸 | 图片裁剪 | 1:1 / 4:3 / 16:9 预设 |
| 水印 Logo 要保留透明背景 | 图片格式转换 | PNG 与 WebP 保留透明通道 |
#常见问题
#加了水印能防止别人盗图吗？
不能。水印只能证明归属，无法阻止复制。四角水印裁剪几个像素就能去掉，平铺水印需要用修复工具逐块处理，成本更高但依然可以去除。真正有效的手段是降低对外发布图片的分辨率，而不是加大水印强度。
#为什么我拆出来的 GIF 帧有重影？
因为解码时没有处理帧处置方式。GIF 的多数帧只存储变化区域，必须叠加到前一帧的画布上，并在处置方式为 2 时把该矩形清回背景色、为 3 时恢复绘制前的画面。用 GIF 帧提取器 拆帧可以直接得到合成后的正确画面。
#GIF 超过 5MB 传不上去，先改哪个参数？
先改输出尺寸。边长减半体积约降到四分之一，收益是平方级的；删帧是线性收益，排在第二位。延迟只影响播放速度，对体积几乎没有影响，调它属于无效操作。
#水印导出后图片反而变大了正常吗？
正常。水印工具按原始分辨率导出 PNG，PNG 无损所以体积通常大于原 JPEG。如果只是用于发布，可以再用 图片压缩 转成 JPEG 或 WebP。格式与质量参数的取舍可以参考 图片压缩指南。
#拆帧导出的 PNG 颜色和原 GIF 不一样？
GIF 单帧最多 256 色，拆出的静态图忠实地保留这 256 色，所以渐变区域会出现色带。这是 GIF 格式本身的限制，不是拆帧造成的。要减少色带，只能回到源头用颜色更丰富的素材重新制作。
#一个动图最多能做多少帧？
制作器的合成上限是宽 × 高 × 帧数不超过 700 万像素。600×400 可以放 29 帧，800×600 只能放 14 帧。需要更多帧就先降低输出尺寸。