Peek: 考虑/建议作为选项/默认为新的有损 GIF 编码器 lossygif

大声笑 :) 但是，是的，绝对。 我现在主要关心的是如何构建设置。 我想让用户在不需要大量研究的情况下轻松地在不同的选项之间进行选择。

@phw很酷； 好点，用户体验/可发现性很重要！ 感谢您对 Peek 🙂 的持续工作。

这些设置可以简化为：

[x] 快速转换
[x] 高品质
[x] 小文件

选择两个。

您是否测试过 lossygif 是否也为“常见”屏幕截图带来了巨大优势？ 据我了解，我读过的文章主要用于压缩电影片段（如上例所示）...

它对截图也有一点帮助，因为抗锯齿、图标和渐变可以被有损压缩。
它将有一种令人讨厌的趋势，使完全平坦和白色的区域看起来很脏，因为当它选择少量白色像素与少量白色像素和一个浅灰色像素时，后者似乎是更好的压缩。

@kornelski感谢您的投入。

我用 15 秒的快速屏幕录制做了一些初步测试，使用 Peek 使用的选项转换由 Peek 生成的中间视频文件。 视频本身是这个 github 问题跟踪器的屏幕录制，所以纯色区域，没有太多颜色（不是 gifski 展示其实力的区域）。 使用 ffmpeg 将视频帧提取到单个文件，并使用 ffmpeg、gifski、gifsicle 和 giflossy 转换为 gif。 文件大小：

• Ffmpeg：7.2 MB
• gifski（质量 60）：10.0 MB（在某些点上有更好的颜色）

现在我可以使用 gifsicle / giflossy 作为这些输出的后处理器来进一步优化它们：

对于 ffmpeg：

• gifsicle（优化 3）：6.7 MB，-7%
• giflossy（优化 3，有损 50）：4.5 MB，-38%

对于 gifski：

• gifsicle（优化 3）：9.6 MB，-4%
• giflossy（优化 3，有损 50）：9.6 MB，-4%

因此，在使用 ffmpeg 时，使用 giflossy 确实会显着减小文件大小。 它增加了一些额外的后期处理时间，但我没有对此进行任何测量。 如果只有 gifsicle 可用，它并没有多大帮助。 将 giflossy 作为后处理器添加到 gifski 也没有多大帮助，但这是意料之中的。

默认情况下，我倾向于只使用 giflossy 作为后处理器，并且可能会添加一个选项来禁用它。

这是我可以生成的最小文件：