我正在使用 ImageMagick 将一组 png 图像转换为单个 gif。我希望此 gif 能够尽快循环播放。
这大概是我期望的输出（感谢维基百科)：
这是我实际得到的输出：
在我的浏览器 (Firefox 17) 上，预期的 gif 运行速度是实际 gif 的两倍多。这让我很惊讶，因为我指定了每帧应该有 0 延迟。
首先，我通过从 Wikipedia 借来的 gif 展开创建了 36 个 png：
--caution: command generates 36 pngs
convert.exe newton.gif newton_%d.png
然后我将coalescepng 重新组合成一个 gif。
convert.exe -dispose none -delay 0 newton_%d.png[0-35] -coalesce output.gif
identify确认每一帧都没有延迟：
identify.exe -format "%T, " output.gif
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
事实上，这比原来的延迟要小：
identify.exe -format "%T, " newton.gif
5, 2, 2, 2, 2, 2, 2, 2, 2, 4, 2, 2, 2, 2, 2, 2, 2, 2, 5, 2, 2, 2, 2, 2, 2, 2, 2, 4, 2, 2, 2, 2, 2, 2, 2, 2,
实际 gif 比预期 gif 的延迟要小。那么为什么预期的 gif 比实际的 gif 快两倍？
答案1
我进行了实验并创建了 10ms（延迟 = 1）版本。
看起来渲染 gif 的程序往往不遵守 0 百分之一秒的延迟率。相反，它们使用比您选择的小值大得多的值。
我无法真正评论他们这样做的原因。我遇到过不止一个原因，而且很可能都是猜测。
一般来说，我建议您在所有情况下都使用至少百分之二秒的延迟。
来源（表明出现这种情况的原因有多种。有些相对较旧）：
答案2
看来@DavidMah是对的。在我的Linux系统上，最小延迟是0.5：
convert -dispose none -delay 0.4 newton_%d.png[0-35] -coalesce output0.4.gif
convert -dispose none -delay 0.5 newton_%d.png[0-35] -coalesce output0.5.gif
convert -dispose none -delay 1 newton_%d.png[0-35] -coalesce output1.gif
由于某种原因，这些图像似乎无法在我的浏览器中正确显示。使用本地图像查看器 ( eom)，第一张图片与原始问题中的图片一样慢，其他两张图片都比维基百科的要快。无论如何，我还是会发布，以防这是我的浏览器特有的问题。无论如何，如果您尝试上面发布的命令，您应该会获得更快的速度。
更新：似乎有两个问题。浏览器（至少是 Linux 上运行的 Firefox 和 Chromium）无法显示延迟小于 1.5 的 gif。1.5 运行良好，1.4 运行缓慢。我的图像查看器可以处理 0.5 及以上的延迟。尝试下载上述图像之一并在您最喜欢的图像查看器中打开它。另外，看看这些：
convert -dispose none -delay 1.4 newton_%d.png[0-35] -coalesce output1.4.gif
convert -dispose none -delay 1.5 newton_%d.png[0-35] -coalesce output1.5.gif
更新 2：@DavidMah 在下面的评论中指出，小数值四舍五入为最接近的整数。因此，1.4 四舍五入为 1，这太慢了，而 1.5 四舍五入为 2，这是可以接受的。
答案3
我使用延迟符号取得了更大的成功XxY，本质上x就像/，所以如果你指定-delay 1x20，则帧将显示 1/20 秒。