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

问题描述

我们正在建立一个在线视频编辑服务。其中一个功能允许用户将短片段从视频导出为动画GIF。 Imgur有文件大小限制<

Gif文件大小取决于帧数，颜色深度和图像内容本身：实心的平面颜色导致非常

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

然后，为了最大化gif质量，我使用略有不同的参数进行了几个gif渲染尝试 - 在gif调色板中改变帧数和颜色数。

每个渲染都需要时间和CPU资源 - 这是我想要优化的。 / p>

问题：根据实际图片估算最佳渲染设置的一种智能方法，以尽可能接近文件大小限制，并至少将渲染尝试次数最小化为2-3？

解决方案

GIF图像格式使用LZW压缩。臭名昭着的算法专利的所有者，Unisys，积极追求版税支付正如图像格式受欢迎。结果很好，我们让PNG感谢。

LZW可以压缩图像的量是非常不确定的，并且在很大程度上取决于图像内容。您最多可以为用户提供一个启发式算法，用于估算最终的图片文件大小。 用彩色条显示成功预测。你可以通过转换只是第一帧很快的颜色。这将不需要很长的384x216图像，它运行在人类时间，只有几分之一秒。

然后将第一个图像的有效压缩率推广到后续帧。

你不能真正知道它是否超过了原始帧的大小，因此应该具有可比的压缩率。网站的大小限制，直到您对整个序列进行编码。所以一定要强调在你的UI设计，你的预测只是一个估计，所以你的用户不会失望太多。当然，为他提供了降低尺寸的工具，像最近邻插值，使图像中的像素更大。专注于使后面的帧更小也可以得到很好的回报，GIF编码器通常不会自己这样做。 YMMV。

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 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.

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

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.

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

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?

解决方案

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.

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.

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屋！