原因是我在写公众号文章的时候,公众号编辑器只能上传最大10M
的GIF
,而我刚好需要上传的GIF
超过了这个阈值。
所以我就随便搜了一个压缩GIF
的工具,有一些压缩完了下载需要付费,有一些不付费就只能压缩低于某个阈值的文件。
不过也能理解吧,毕竟别人也是需要赚钱的,这种文件的处理如果放在服务端做,那必然是要耗费不少资源的,如果放在纯前端做,又不能保证文件处理的速度。
然后我就想着GIF
压缩应该不难吧,应该有现成的工具库吧,于是我就开始动手去实现一个GIF
压缩工具。这里我很执拗地要去实现一个纯客户端的GIF
压缩(也不知道为啥我这么执拗。)
初探GIF压缩
我们都知道GIF
是一张张静态的图片播放形成的动图,所以我一开始就想着,如果我有一个库,能帮我把GIF
所有帧都抽取出来,然后我对所有帧的图片进行一个缩放的有损压缩,压缩完之后再把所有图片合成一个新的GIF
,那么我不就把GIF
给压缩了么。
然后我就找到了gif.js
和omggif.js
这两个库:
omggif
负责解析GIF
,获取GIF
的每一帧图像- 把获取到的每一帧图像进行处理了之后,使用
gif.js
合成GIF
那么可以写出下面的代码,以下的代码就是一个分离GIF
帧+合成GIF
的代码,还没有加上压缩每一帧的逻辑:
但是我分离帧之后发现,分离出来的帧相当奇怪
而且合并之后的GIF
感觉完全被破坏掉了,我不清楚是不是我的这种思路本身就是不可行的,还是说这两个库不能这么用。是不是我这样做了之后导致描述GIF
的信息丢了?(比如调色盘或者其他的一些全局信息,评论区有大神可以指导一下么)
这种方式不可行之后,我又尝试了一下别的方式。这一次我不再寄希望于纯js
实现的库,而是往wasm
方向去探索。
然后我尝试使用Rust
去解析GIF
,并返回所有解析后的图片给前端,前端再去做有损压缩,但这一做法耗时太长,也不是成功的尝试,所以代码就不放出来了。
接着我就想到了ffmpeg
,我知道它有压缩GIF
的功能,而且他也有成熟的wasm
版本,可以便捷地在前端引入使用,但是它压缩后近10M
的体积依旧让人望而生畏。
gifsicle
在继续搜索GIF
压缩等关键词时,发现了gifsicle
这个库。它是一个用于处理GIF
图像的命令行工具和库,提供了很多功能包括创建、编辑、优化和调整GIF
。
与ffmpeg
对比起来,它是一个更专注于GIF处
理的库,所以体积会比ffmpeg
肯定小不少,所以我就想着能不能弄一个它的wasm
版本移植到浏览器中使用。
后面还真让我找到了它对应的wasm
版本,具体链接可以查看:gifsicle-wasm-browse,这个库GZip
压缩之后只有150K
左右,完全不用担心体积问题。
使用gifsicle
的时候,常常使用如下的手段去减少GIF
的体积:
-O
参数:- O1:该选项对应于轻度优化,它会执行一些基本的优化步骤,删除无用的图像数据和元数据,以减小文件大小。这个级别的优化通常执行较快,但可能不会最大限度地减小文件大小。
- O2:中度优化比轻度优化更深入,它可能会花费更多的时间来寻找更多的优化机会。这通常会导致更好的压缩比和更小的文件大小。
- O3:最大优化级别会执行最深入的优化,可能需要更多的时间来完成,但通常会实现最大的文件大小减小。这个级别的优化可能对CPU和内存的需求更高。
--loosy
:--lossy
会减少图像中使用的颜色数量,从而减小颜色表的大小。这会导致颜色的近似和失真,因为原始的颜色信息会被近似为颜色表中的颜色。- 高
--lossy
程度下,一些微小的图像细节可能会被去除,以进一步减小文件大小。这可能导致图像的一些细节在视觉上的损失
- 减少颜色数:
GIF
中每个像素可以使用图像调色板中的一种颜色,而颜色数量表示这些不同颜色的总数。GIF
使用的颜色调色板通常是8
位色,允许最多256
种不同的颜色。- 减少GIF的颜色数量可以降低图像的文件大小,因为图像中使用的颜色越少,每个像素的颜色信息所需的位数就越少。然而,减少颜色数量也可能导致图像的视觉质量下降,尤其是对于包含大量颜色细节的图像。
- 删除注释和元数据
- 裁剪和缩小:最直观的压缩手段,属于有损压缩
- 调整帧速率:相当于减少组成这个
GIF
文件的图片数量,也是有损压缩
暂无评论内容