如何估计 GIF 文件大小? [英] How to estimate GIF file size?

问题描述

我们正在构建在线视频编辑服务.其中一项功能允许用户将视频中的一小段导出为 gif 动画.Imgur 有文件大小限制 每个上传的动画 gif 为 2Mb.

We're building an online video editing service. One of the features allows users to export a short segment from their video as an animated gif. Imgur has a file size limit of 2Mb per uploaded animated gif.

Gif 文件大小取决于帧数、颜色深度和图像内容本身:纯色会产生非常轻的 gif，而一些随机颜色的电视噪声动画会很重.

Gif file size depends on number of frames, color depth and the image contents itself: a solid flat color result in a very lightweight gif, while some random colors tv-noise animation would be quite heavy.

首先，我将每个视频帧导出为最终 GIF 帧大小(固定，384x216)的 PNG.

First I export each video frame as a PNG of the final GIF frame size (fixed, 384x216).

然后，为了最大限度地提高 gif 质量，我进行了几次 gif 渲染尝试，参数略有不同 - gif 调色板中不同的帧数和颜色数.在保持文件大小限制的情况下具有最佳质量的渲染将上传到 Imgur.

Then, to maximize gif quality I undertake several gif render attempts with slightly different parameters - varying number of frames and number of colors in the gif palette. The render that has the best quality while staying under the file size limit gets uploaded to Imgur.

每次渲染都需要时间和 CPU 资源——这是我想要优化的.

Each render takes time and CPU resources — this I am looking to optimize.

问题:根据实际图像估计最佳渲染设置、尽可能接近文件大小限制并至少最小化渲染尝试次数的明智方法是什么?到 2-3?

Question: what could be a smart way to estimate the best render settings depending on the actual images, to fit as close as possible to the filesize limit, and at least minimize the number of render attempts to 2–3?

推荐答案

GIF 图像格式使用 LZW 压缩.臭名昭著的算法专利所有者 Unisys 在图像格式流行之际，积极追求版税支付.结果很好，我们得到了 PNG 的感谢.

The GIF image format uses LZW compression. Infamous for the owner of the algorithm patent, Unisys, aggressively pursuing royalty payments just as the image format got popular. Turned out well, we got PNG to thank for that.

LZW 可以压缩图像的量是非常不确定的，很大程度上取决于图像内容.您充其量可以为用户提供一种估计最终图像文件大小的启发式方法.例如，用彩色条显示成功预测.您可以通过仅转换第一帧来快速为其着色.对于 384x216 图像，这不会花费很长时间，它在人类时间中运行，不到一秒钟.

The amount by which LZW can compress the image is extremely non-deterministic and greatly depends on the image content. You, at best, can provide the user with a heuristic that estimates the final image file size. Displaying, say, a success prediction with a colored bar. You'd can color it pretty quickly by converting just the first frame. That won't take long on 384x216 image, that runs in human time, a fraction of a second.

然后将第一张图像的有效压缩率外推到后续帧.其中应该只编码与原始帧的微小​​差异，因此应该具有可比的压缩率.

And then extrapolate the effective compression rate of that first image to the subsequent frames. Which ought to encode only small differences from the original frame so ought to have comparable compression rates.

在对整个序列进行编码之前，您无法真正知道它是否超出了站点的大小限制.所以一定要在你的 UI 设计中强调你的预测只是一个估计，所以你的用户不会太失望.当然，还为他提供缩小尺寸的工具，例如最近邻插值，使图像中的像素更大.专注于使后面的帧更小也可以带来丰厚的回报，GIF 编码器本身通常不能很好地做到这一点.天啊.

You can't truly know whether it exceeds the site's size limit until you've encoded the entire sequence. So be sure to emphasize in your UI design that your prediction is just an estimate so your user isn't going to disappointed too much. And of course provide him with the tools to get the size lowered, something like a nearest-neighbor interpolation that makes the pixels in the image bigger. Focusing on making the later frames smaller can pay off handsomely as well, GIF encoders don't normally do this well by themselves. YMMV.

这篇关于如何估计 GIF 文件大小?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！