8

我在调整 Cinemagraph 的大小时遇到​​问题。如果您不知道，它们是仅对图像的一部分进行动画处理的 gif，与整个图像进行动画处理的常规 gif 相比。这是一个 node.js 示例：

// ![http://i.imgur.com/Qb1m0.gif][1]

var gm = require('gm')

var file = 'Qb1m0.gif',
    frags = file.split('.')

gm(file)
  //.noProfile()
  //.quality(80)
  .resize(200, 200)
  .write(frags[0] + '_200.' + frags[1], function(err) {
    if (err) console.error(err)
  })

// Result:
// ![http://i.imgur.com/eFqak.gif][2]

等效的 cmd 行代码是：

gm convert Qb1m0.gif -resize 200x200 cinema_200.gif

知道发生了什么吗？

原始动画GIF：

原来的

调整大小的动画 GIF：

调整大小

4

3 回答 3

20

我确实比 GraphicsMagick 更了解 ImageMagick。对于 ImageMagick，以下语句适用：

  • 如果 GIF 包含透明度，则几乎不可能使用简单的命令行（例如您提供的命令行）直接调整动画GIF 的大小。

  • 如果动画 GIF 不包含透明度，甚至很难做到这一点。

我认为这对于 GraphicsMagick 是一样的，真​​的。

背景说明

如果您使用 来查看原始 GIF identify，您会发现并非每个帧都具有相同的尺寸：

识别 Qb1m0.gif
 Qb1m0.gif[1] GIF 720x416 720x416+0+0 8 位伪类 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[1] GIF 471x122 720x416+160+75 8 位伪类 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[2] GIF 471x121 720x416+160+76 8 位伪类 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[3] GIF 471x123 720x416+160+75 8 位伪类 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[4] GIF 471x123 720x416+160+75 8 位伪类 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[5] GIF 471x123 720x416+160+75 8 位伪类 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[6] GIF 471x123 720x416+160+75 8 位伪类 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[7] GIF 471x123 720x416+160+75 8 位伪类 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[8] GIF 471x122 720x416+160+76 8 位伪类 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[9] GIF 471x123 720x416+160+75 8 位伪类 256c 920KB 0.000u 0:00.009
 Qb1m0.gif[10] GIF 471x123 720x416+160+75 8 位伪类 256c 920KB 0.000u 0:00.000
 Qb1m0.gif[11] GIF 471x123 720x416+160+75 8 位伪类 256c 920KB 0.000u 0:00.000
 Qb1m0.gif[12] GIF 471x123 720x416+160+75 8 位伪类 256c 920KB 0.000u 0:00.000
 Qb1m0.gif[13] GIF 471x122 720x416+160+76 8 位伪类 256c 920KB 0.000u 0:00.000
 Qb1m0.gif[14] GIF 471x123 720x416+160+75 8 位伪类 256c 920KB 0.000u 0:00.000
 Qb1m0.gif[15] GIF 471x123 720x416+160+75 8 位伪类 256c 920KB 0.000u 0:00.000

这些尺寸变化是为了减小文件大小而对动画 GIF进行帧优化的结果。

还有其他优化在起作用，它们确实减少了使用的颜色数量。这两种类型的优化都不能很好地与-resize操作结合起来。

-resize是为单个图像设计的，并使生成的单个图像看起来尽可能好。这通常会为图像添加新的颜色值。这确实与 GIF 的设计目的相矛盾：使用严格限制的颜色表（最多 256 种颜色）。在动画序列中，下一个图像/帧-resize可能会产生与前一个完全不同的颜色表——但对于一个工作良好的动画，您需要一个跨所有帧的通用颜色表。

-resize将每个帧图像与其他图像完全分开处理，并且不考虑“帧优化”（它倾向于为放置在具有自己偏移量的公共画布上的每个帧创建不同的宽度+高度）。

因此，调整大小的图像远非理想地保存为单个图像的有限 GIF 文件格式，更不用说用于动画 GIF 的多帧了。结果是在调整大小的图像中大量减少了颜色。

然后是透明度问题：大多数动画 GIF 确实大量使用了透明度。透明度经常用于实现压缩优化，通常图像的外观根本不需要透明度。

在这种情况下发生的情况是：-resize在叠加图像中创建半透明像素。当图像被保存回 GIF 文件格式时，这些像素随后被转换为完全透明或完全不透明：两者都会为生成的动画产生严重的颜色失真，远离原始颜色。

一般程序

通常，调整动画 GIF 大小的最佳程序是：

  1. 合并（去优化）动画。这将为动画的所有帧创建相同大小的单个图像。

  2. 对动画进行完整的 GIF 优化序列：不仅是帧优化，还有颜色优化。

“简单”命令

要仍然尝试运行“简单”调整大小命令，您可以试试这个：

convert                        \
  http://i.imgur.com/Qb1m0.gif \
 -coalesce                     \
 -resize 200x200               \
  cinema_200.gif

结果：

 结果

此命令将解决帧优化问题。它将纠正由此产生的问题，但会增加文件大小。

但是，当涉及到边缘时，它可能仍会显示“阶梯”伪影，因为调整大小的帧将出现可怕的锯齿。这是因为抗锯齿需要边缘周围的半透明颜色，但 GIF 无法保存-resize操作员生成的半透明颜色。

于 2012-09-06T20:01:40.700 回答
0

您也可以尝试添加-layers optimize 更多详细信息 https://imagemagick.org/script/command-line-options.php#layers

于 2019-03-18T18:45:16.763 回答
0

还有一个非常好的与使用gifsicle工具的 ImageMagick 解决方案无关，它产生更小的结果 gif 并且没有任何闪烁问题，也没有特殊的命令行参数，因此非常简单，工作速度也更快。像这样使用它：

gifsicle --scale 0.25 -i input.gif > output.gif

或者

gifsicle --resize 24x24 -i input.gif > output.gif
于 2020-09-25T12:24:01.013 回答