libheif 是一个用于 HEIF 与 AVIF 图像文件格式的开源解码与编码库,由 struktur AG 于 2017 年发起,主要作者为 Dirk Farin。它本身只负责解析和封装 HEIF 容器,实际的图像压缩解码交由 libde265、x265、libaom、dav1d 等第三方编解码器完成,并通过插件机制接入这些后端。由于 HEIC 与 AVIF 是智能手机和部分网页采用的图像格式,libheif 成为多数开源图像软件读写这类文件的基础组件。
定义
libheif 是一个符合 ISO/IEC 23008-12:2017 标准的 HEIF 与 AVIF 文件格式解码器和编码器,同时部分支持 ISO/IEC 23008-12:2022 第二版规定的功能。它处理的是 HEIF 这一容器格式,即负责读懂文件内部的组织结构,而把像素数据的具体压缩与解压缩交给外部的编解码器库完成。
除了常见的 HEIC 和 AVIF,该库还支持以 VVC、AVC、JPEG、JPEG-2000 以及 ISO/IEC 23001-17 未压缩格式编码的 HEIF 图像,其中后一种编解码器直接内置于库中。库本身以 C++ 编写,但对外暴露的是纯 C 接口,以方便被其它编程语言调用[1]。
原理
HEIF 是一种基于 ISO 基础媒体文件格式的容器,文件中可以并列存放主图像、缩略图、深度图、透明通道和辅助图像等多个图像项,并可附带 EXIF、XMP 等元数据。libheif 的职责是把容器解析成图像项,再依据每一项记录的压缩格式类型调用对应的编解码后端,把码流还原为可供程序使用的像素平面。解码结果可以按 RGB、YCbCr 等色彩空间输出,并支持交错排列的通道布局。
编码方向则相反:调用者先通过 heif_context_get_encoder_for_format() 指定目标压缩格式,再设置质量参数,由库把像素数据交给后端编码器生成码流,最后写入文件。判断选用哪个后端的方式,是在构建时通过 CMake 变量为每种编解码器分别开启支持,或将其编译为可动态加载的插件[2]。
色彩转换环节是这类库的常见瓶颈,libheif 可以借助 libsharpyuv 提升 YCbCr 与 RGB 互转的质量[2]。针对超大分辨率图像,库提供了分块解码路径,允许把图像切成瓦片逐块处理,并在解码多块图像时并行执行,以避免整幅图像必须一次性装入内存[1]。
发展历程
libheif 由德国软件公司 struktur AG 于 2017 年启动,早期版权声明署名为 struktur AG 与 Dirk Farin,当时项目的定位仅为 HEIF 解码器,编码功能尚在计划之中[3]。2018 年 1 月,该项目被提交收录进 Debian 发行版,当时的版本号还是带有提交哈希的 0.0.1[4]。
此后的版本逐步扩充编解码能力。1.6.2 版本加入对 HEIX 图像的支持,可处理 10 位、12 位色深以及 4:2:2 色度采样[5]。1.7.0 版本于 2020 年 6 月发布,通过 libaom 增加了 8 位 AVIF 图像的读写能力,并引入插件架构以便接入其它编解码器[6]。
1.14.0 版本开始,各个编解码后端既可在构建时静态链接进库,也可编译为运行时动态加载的独立插件[7]。1.16.0 版本移除了早期的 autotools 构建文件,改用 CMake 构建系统,并加入 HEIF 第二版定义的区域标注与用户注释功能[7]。1.17.0 版本进一步支持 JPEG 与 JPEG-2000 封装进 HEIF,并新增 Kvazaar、ffmpeg 等多个编解码插件[8]。项目的主要维护者是 Dirk Farin,他以独立开发者身份承担 libheif 与 libde265 的维护工作。
应用
libheif 是多数开源图像软件处理 HEIF 与 AVIF 时采用的底层实现。直接依赖它的软件包括 GIMP、Krita、ImageMagick、GraphicsMagick、darktable、digiKam、libvips 以及 Node.js 的 sharp 等。由于 ImageMagick、libvips 和 GDAL 等库在许多服务端图像流水线中被使用,libheif 也间接进入了大量网络服务与内容管理系统。
在地理信息领域,libheif 是 GDAL 读取 HEIF 栅格数据的后端,并被用于实现 GeoHEIF 相关的元数据与分块访问能力[1]。在桌面环境方面,库内含 gdk-pixbuf 加载器,可让 GNOME 桌面直接显示 HEIC 与 AVIF 缩略图。库还随附 heif-dec、heif-enc、heif-info 等命令行工具,用于在 JPEG、PNG、TIFF、WebP 等格式与 HEIF、AVIF 之间转换,并可在必要时输出图像序列或 MP4 视频。
为方便不同技术栈使用,社区提供了多种语言绑定,例如 Python 的 pyheif 与 pillow-heif、Rust 的 libheif-sys、.NET 的 libheif-sharp 以及 Node.js 模块 libheif-js。此外,libheif 可通过 emscripten 编译为 JavaScript 与 WebAssembly,使浏览器端也能直接解码这类图像[1]。
局限
libheif 自身不实现视频编解码算法,任何压缩格式的读写都必须依赖外部编解码库。这带来两重限制:一是功能覆盖取决于构建时启用了哪些插件,二是部分后端带有独立的许可证条件,例如 x265 采用 GPL 授权,因此把它编入程序会影响整体许可安排,库为此提供了许可更为宽松的 Kvazaar 作为替代[2]。ffmpeg 解码插件虽然能调用硬件解码器,但在部分码流上表现尚不正确,因此当 libde265 可用时库仍优先选择后者[2]。
HEIF 容器格式结构灵活、取值范围宽泛,许多特性定义较为宽松,需要验证的特性组合数量极大。这一特点使文件解析的安全处理难度较高,据项目说明,仅 2026 年 1 月至 8 月期间就发布了 37 项安全公告,其中多数由使用该库的组织借助自动化工具发现。为此,libheif 设置了安全限制,防止超大图像耗尽内存或被构造的输入用于拒绝服务,并允许开发者在确有需要时逐项调整这些限制[2]。
此外,库对标准的覆盖并非完整。按发行版打包说明,libheif 符合 ISO/IEC 23008-12:2017,对 2022 年第二版的能力只是部分支持。内部元数据压缩、未压缩图像等特性在构建选项中仍被标注为实验性,尚未作为稳定的动态插件提供[2]。
参见
参考资料
- 24-042r1(PDF) [引用日期2026-10-14]
- libheif [引用日期2026-10-14]
- libheif [引用日期2026-10-14]
- debian.net 上的网页 [引用日期2026-10-14]
- 720166 – media-libs/libheif-1.7.0 version bump [引用日期2026-10-14]
- strukturag/libheif - The Wayback Machine [引用日期2026-10-14]
- libheif [引用日期2026-10-14]
- Releases · strukturag/libheif - Skip to content [引用日期2026-10-14]