告别臃肿图片：用libavif轻松实现AVIF图片压缩，一份完整上手指南

告别臃肿图片：用libavif轻松实现AVIF图片压缩，一份完整上手指南

【免费下载链接】libaviflibavif - Library for encoding and decoding .avif files项目地址: https://gitcode.com/gh_mirrors/li/libavif

网页打开越来越慢、手机相册越来越满，问题往往就出在图片上。AVIF图片压缩格式能在画质几乎不变的前提下把文件体积砍掉一半，而libavif正是处理这种格式最省心的开源库——编码、解码、命令行工具一应俱全，从今天开始，你也能轻松上手。

先聊一个每天都在发生的窘境

你有没有遇到过这样的情况：精心排版的文章配了几张高清图，页面加载却慢得像回到了拨号时代；手机里存了上千张照片，128G 的空间转眼就见底；电商详情页动辄十几张图，每次刷新都要等上好几秒。

根子在图片体积上。JPEG 压到一定程度就开始出现恼人的色块和模糊，PNG 虽然无损但体积大得吓人，WebP 虽好却总在兼容性上让人头疼。大家真正想要的，是一个能同时满足"压得狠、画质好、格式新"的图片格式——这就是 AVIF 登场的理由。

同样是压缩，AVIF 凭什么能省下一半体积

AVIF 的底层是新一代视频编码标准 AV1，你可以把它理解为"用视频编码的思路来处理静态图片"。相比 JPEG 的块状压缩，AV1 的帧内编码、更精细的预测与变换技术，让它在同等画质下能压得更小。

更重要的是，它不是只有"压得小"这一个优点：

libavif 完整支持 AV1 的所有 YUV 采样格式（4:2:0、4:2:2、4:4:4）与 8/10/12 位深，连 alpha 透明通道也一并照顾到了。无论是图标这种简单图形，还是细节丰富的摄影作品，它都能找到最优的编码参数。

这张 1024x684 的 16 位焊接件照片（tests/data/weld_16bit.png）细节丰富，是验证 AVIF图片压缩质量的理想素材——项目测试里它还有对应的 12 位压缩版本（tests/data/weld_sato_12B_8B_q0.avif）可供对比。

认识 libavif：一个库，五种编解码器任你挑

可能你会问：AV1 编码那么复杂，我要自己搞定一切吗？当然不用。libavif 把这些复杂的活全部封装好了，你只需要选一个喜欢的"引擎"。

libavif 支持切换多种 AV1 编解码后端：

想追求解码速度就上 dav1d，想压缩率最大化就选 libaom，全凭你的场景决定。库本身用 C99 编写，跨平台、体积可控、BSD 许可，既能嵌入到桌面软件，也能跑在移动端——项目里甚至自带 Android 的 JNI 封装（android_jni/）和 gdk-pixbuf 插件（contrib/gdk-pixbuf/），集成起来非常省事。

动手安装：一条命令，或从头编译

大部分场景其实不用编译，直接用系统包管理器装就行：

# macOS brew install libavif # Debian/Ubuntu sudo apt install libavif-dev # Windows（vcpkg） vcpkg install libavif

如果你想把整个构建过程攥在自己手里，或者想换一个编码器后端，那就源码编译。先把仓库克隆下来：

git clone https://gitcode.com/gh_mirrors/li/libavif

然后按需配置 CMake。这里有一份"全都要本地编译"的完整命令，适合开发调试：

cmake -S libavif -B libavif/build \ -DCMAKE_BUILD_TYPE=Release \ -DAVIF_CODEC_AOM=LOCAL \ -DAVIF_BUILD_APPS=ON cmake --build libavif/build --config Release --parallel

几个关键开关先记下来：AVIF_CODEC_AOM决定用哪个编码器（LOCAL自动下载编译，SYSTEM用系统已装的）；AVIF_BUILD_APPS=ON才会生成我们要用的avifenc和avifdec工具；AVIF_LIBYUV则用来加速色彩空间转换，默认开启，建议保留。

小提示：不启用任何编码器时 CMake 会报错，至少得开一个。日常学习用AVIF_CODEC_AOM=LOCAL是最省心的选择。

出第一张图：两行命令完成图片格式转换

编译安装好之后，把任何一张 PNG、JPEG 或 Y4M 视频帧转成 AVIF，只需要一行命令：

avifenc -q 75 input.png output.avif

-q是质量参数（0-100，越大画质越好、体积也越大），75 是个不错的起步值。想转回来也简单：

avifdec output.avif decoded.png

项目测试目录里的这张灰度照片（tests/data/kodim03_grayscale_cicp.png）在压缩转换后仍能保留细腻的影调过渡，肉眼几乎看不出差别。

自己手头没有合适的图片？没关系，仓库的 tests/data/ 和 tests/data/io/ 目录里躺着大量现成素材，比如 kodim03_yuv420_8bpc.avif，装好工具后直接拿它们练手就行。

想写进自己的程序？核心 API 其实只有四步

命令行工具适合日常使用，但如果你要做网站后端、桌面软件或 App，就需要调用库本身了。别被 C 接口吓到，整个编码流程清晰得很：

1. 用avifImageCreate创建一张 128x128、8 位深、YUV444 的图像；
2. 有 RGB 数据就用avifImageRGBToYUV转成 YUV（有 YUV 原始数据则直接分配平面填充）；
3. 创建avifEncoder，设置quality、speed、线程数等参数；
4. 调用编码接口输出成内存数据，再写入文件。

解码则是相反的流程：读取文件、avifDecoderParse、逐帧取出avifImage、转回 RGB 显示。想抄作业的话，examples/ 目录下的 avif_example_encode.c、avif_example_decode_file.c 都是完整可运行的最小示例，照着改就行。完整的函数与结构体说明都在 include/avif/avif.h 里，注释写得相当细致。

进阶玩法：动画、HDR 增益映射与元数据

当你能跑通基础的编解码，就该看看 libavif 更"高级"的部分了。

动画序列。AVIF 支持像 GIF 那样的动图，但压缩率和画质完全不在一个量级。编码时设置keyframeInterval、timescale等参数，就能把一组 Y4M 视频帧压成带动画的 .avif 文件。仓库里的 colors-animated-8bpc.avif 就是这类测试资源。

HDR 增益映射。这是相当前沿的特性：一张图里同时打包 SDR（标准动态范围）和 HDR（高动态范围）两个版本，普通屏幕看到正常效果，HDR 显示器上自动呈现更丰富的亮度层次。相关逻辑在 src/gainmap.c，还附带了一个 avifgainmaputil 命令行工具，专门处理增益映射的提取、合成与色调映射。

元数据。转码最怕丢信息，libavif 对 EXIF、XMP、ICC 色彩配置文件的透传支持得很完整。你可以在编码前通过avifImageSetMetadataExif、avifImageSetMetadataXMP把拍摄参数和版权信息写进去。

测试目录里的这张照片（tests/data/dog_exif_extended_xmp_icc.jpg）同时携带 EXIF、XMP 和 ICC 三份元数据，专门用来验证压缩转换过程中的信息保留情况。

收尾之前，给你三条实战建议

第一，质量和速度之间永远有取舍。-q决定画质，speed决定编码耗时，追求极致体积就用默认质量档位慢慢编，追求实时预览就调高 speed。

第二，按内容选位深。网页图标用 8 位足够，专业摄影和后期场景用 10 位甚至 12 位，能避免带状色阶。灰度图、透明图也各有对应的优化路径。

第三，验证比什么都重要。项目 tests/ 下有大量 golden 测试和对比资源（比如 sofa_grid1x5_420.avif 这种分块编码样本），动手改参数之前，先用它们做基准，心里才有底。

到这里，你已经从"听说过 AVIF"走到了"能自己压缩、转换、集成"这一步。把仓库克隆下来，用 avifenc 压一张你最熟悉的照片，看看文件体积的变化——相信我，第一次看到体积减半而画质无损的那一刻，你会回来感谢自己今天的尝试。

【免费下载链接】libaviflibavif - Library for encoding and decoding .avif files项目地址: https://gitcode.com/gh_mirrors/li/libavif