1992 年诞生的 JPEG 是一种非常成熟且成功的静态图像编码,但它确实不再适应 18 年后的今天,流量费用如此宝贵,在不影响图像质量的情况下,如果减少每一张图片的大小是可以节约大量成本的。
本文,Netflix 的技术团队提到了 JPEG 的几个后继者:JPEG 2000、Webp 和 HEIF(HEIC)。JPEG 2000,未能推广开;Webp 是 Google 主推的格式,目前用的确实挺多,但现在一般用它作为 PNG 的代替品;HEVC 是 AVC 的后继者,编码效率出色, 但是有个问题就是它的专利费用。
在这一背景下,Netflix 决定采用 AVIF。事实上,从 Windows 10 Insider build 18305 开始,Microsoft 已开始添加对 AVIF 图像格式的支持。Microsoft 并不是唯一一个致力于添加对 AVIF 图像格式支持的组织。VLC 早已引入了支持,Mozilla 也计划在未来增加支持。
摘要
我们需要一个 JPEG 的替代方案,要求如下:
能够得到广泛支持;
具有更高的压缩效率;
具有更广泛的特性集。
我们认为 AV1 图像文件格式( AV1 Image File Format,AVIF)具备这样的潜力。使用我们开源的框架,就可以看到 AVIF 的压缩效率,并与之前的所有图像编解码器进行比较。
Netflix 的图像压缩
Netflix 的会员可以在智能电视、手机、平板电脑、个人电脑和连接到电视屏幕的流媒体设备上享受 Netflix 的服务。用于浏览目录和提供推荐的用户界面(User Interface,UI)在所有设备类别都有着丰富的图像和图形。下图是 iOS 上的 Netflix 应用的截图。
截图为撰写本文时,在 iOS(iPhone 7)上的 Netflix 用户界面
图像资源可以是基于标题的静止帧,也可以是特殊的现场摄影或其组合。资源也可以是来源于影片制作过程中产生的艺术创作。
如上所述,图像资源通常具有在图像上合成的渐变、文本和图像,例如 Netflix 的标志或其他标题特定的符号,如“The Witcher”电影的徽章。这种特殊处理导致了各种各样的特征,而这些特征并不一定会出现在自然图像中。硬边(包括边缘两侧存在色度差异的边缘)很常见,需要很好的细节保存,因为它们通常出现在显著的位置,并传递重要信息。同样,保留人物面部的细节也是非常重要的。在某些情况下,背景纹理复杂,会表现出广泛的频率范围。
在摄取图像资源之后,压缩管道会开始启动,并准备好要交付给设备的压缩图像资源。目标是使压缩后的图像看起来尽可能接近原始图像,同时减少所需的字节数。鉴于用户界面以图像为主的特性,压缩好这些图像是至关重要的。而这涉及到色度子采样( color subsampling)、编解码器参数和编码分辨率的正确组合等。
用于各种客户端设备和用户界面中各种空间的的压缩图像资源是从相应的原始图像源创建的
让我们以色度子采样为例。基于人类视觉系统对亮度比色度更敏感这一事实,我们选择了 4:2:0 采样方式,而不是原来的 4:4:4 采样方式,将需要进行编码的样本数量减半(在所有 3 个色彩平面上计数)。但是,4:2:0 采样方式可能会在具有颜色过渡的地方出现色渗和锯齿的现象。下面,我们在 4:4:4 采样方式的原始源和转换为 4:2:0 采样方式的源之间切换。切换显示仅仅有色度子采样引入的损失,甚至在编解码器进入图片之前也是如此。
在以 4:4:4 采样方式的原始源图像与转换为 4:2:0 采样方式的原始源图像之间切换。只显示作品的顶部。读者可以放大网页,查看由于 4:2:0 采样方式而出现的 Netflix 标志周围的锯齿。
然而,在某些源图像中,由于 4:2:0 采样方式造成的损失对来人类视觉感知来说并不明显,那么,在这种情况下,使用 4:2:0 采样方式可能是有利的。理想情况下,编解码器应该能够支持这两种子采样格式。但是,有些编解码器只支持 4:2:0 采样方式,如 Webp,下面讨论的就是这样一种流行的编解码器。
图像编码格式概述
JPEG 格式于 1992 年推出,得到了广泛的应用。它支持各种色度子采样,包括 4:2:0、4:2:2、4:4:4。JPEG 可以摄取 RGB 数据,并将其转换为亮度色度表示,然后再执行有损压缩。采用离散余弦变换(discrete cosine transform,DCT)对 8x8 样本块进行解相关变换。接下来是量化和熵编码。然而,JPEG 仅限于 8 位图像,并且缺乏对 alpha 通道的支持。最新的 JPEG-XT 标准将 JPEG 扩展到更高的位深度,支持 alpha 通道、无损压缩和更多的向后兼容方式。
基于离散小波变换(discrete wavelet transform,DWT)的 JPEG 2000 格式,在 2000 年作为 JPEG 格式的后继格式被引入。它带来了一系列附加特性,如空间可扩展性、感兴趣区域编码、支持的位深度范围、灵活的色彩平面数、无损编码等。随着运动的扩展,在 2004 年,它被接受为数字电影的视频编码标准。
Webp 格式是 Google 在 2010 年左右推出的。Google 为 Android 设备和 Chrome 浏览器带来了解码支持,还发布了供开发者添加到其他平台(如 iOS)上的应用程序的库。Webp 是基于 VP8 视频编码格式的帧内编码。Webp 并不具备 JPEG 2000 的所有灵活性。但是,它确实支持无损编码和无损 alpha 通道,因此,在某些情况下 Webp 成为 PNG 的更高效、更快速的替代方案。
高效视频编码(High-Efficiency Video Coding,HEVC)是 H.264 的后继产品,又名高级视频编码(Advanced Video Coding,AVC)格式。HEVC 帧内编码可以封装在高效图像文件格式(High-Efficiency Image File Format,HEIF)。最值得注意的是,Apple 设备用来存储记录图像的正是这种格式。
类似的,AV1 图像文件格式(AV1 Image File Format,AVIF)允许封装 AV1 帧内编码内容,从而利用 AV1 相对于前身实现的优异压缩收益。在下一节中,我们将介绍 AVIF 的一些吸引人的技术特性。
JPEG 委员会正在寻求一种名为 JPEG XL 的编码格式,其中包括一些旨在帮助从传统 JPEG 格式转换的功能。现有的 JPEG 文件可以无损地转码为 JPEG XL,同时实现文件大小的减小。还包括一个轻量级的转码过程,可返回到 JPEG 格式,以便为只支持旧版 JPEG 的客户端提供服务。
AVIF 技术特点
尽管现代视频编解码器主要是为了视频而开发的,但是视频编解码器中的帧内编码工具与图像压缩工具并没有什么太大的不同。鉴于现代视频编解码器的巨大压缩收益,它们作为图像编码格式还是很有吸引力的。重用现有硬件进行视频压缩 / 解压有潜在的好处。考虑到依赖于操作系统的用户界面组成的特殊性,以及移动未压缩图像像素的架构含义,硬件中的图像解码可能并不是一个主要的动力。
在图像编码格式方面,动态图像专家组(Moving Picture Experts Group,MPEG)已将与编解码器无关的通用图像容器格式进行了标准化:ISO/IEC 23000-12 标准(又称 HEIF)。最值得一提的是,HEIF 已经用于存储 HEVC 编码的图像(在其 HEIC 变体中),但也能够存储 AVC 编码的图像,甚至 JPEG 编码的图像。开发媒体联盟(Alliance for Open Media,AOM)最近对这种格式进行了扩展,以指定 AVIF 格式的 AV1 编码图像的存储。基本的 HEIF 格式提供了图像格式应有的典型特性,例如:支持任何图像编解码器,能够使用有损或无损模式进行压缩,支持不同的子采样和位深度等。此外,该格式还允许存储一系列动画帧(为动画 GIF 提供了一种期待已久的高效替代方案),并能够制定 alpha 通道(这在用户界面中非常有用)。由于 HEIF 格式借鉴了下一代视频压缩的技术,因此该格式允许保留元数据,如色彩色域和高动态范围(high dynamic range,HDR)等信息。
图像压缩比较框架
我们开源了基于 Docker 的框架,用于比较各种图像编解码器。主要特点包括:
使用 Python 3 编码编排(使用并行化)和见解生成。
易于重现的结果。
易于控制的目标质量范围。
由于该框架允许用户为目标编解码器指定目标质量(使用某种指标),并将这些结果存储在本地数据库中,人们可以很容易地利用 Bjontegaard-Delta(BD)码率来比较不同的编解码器,因为目标点可以限制在一个有用或有意义的质量范围内,而不是盲目扫过编码器参数范围(如质量因素)与固定的参数值并落在任意质量点上。
下面是一个例子,例子中的这些调用会生成压缩图像,以供选择符合指定 SSIM 和 VWAF 值的编解码器,并在目标质量方面具有理想的容差:
对于后续比较中涉及的各种编解码器和配置,读者可以查看共享仓库中的实际命令行。我们尝试从每个编解码器 / 配置中获得最佳的压缩效率。读者可以自由地尝试对框架内的编码命令进行更改。此外,与收集以下结果时使用的版本相比,各个软件实现的新版本可能已经发布。例如,收集以下结果时,与在 GitHub 上使用的框架快照中的版本相比,Kakadu 演示应用程序的软件更新版本现在是可用的。
可视化示例
在这一节中,我们通过比较 JPEG 和最新技术的可视化示例,来欣赏压缩社区在过去 30 年来所做的工作。
下图所示的编码图像是说明性质的,意在比较不同目标比特率下的视觉质量。请注意,说明性编码的质量并不能代表 Netflix 在实际服务中使用的流媒体图像资源所使用的高质量条形图,并且其本质上纯粹是教育性质的。
下图显示的是来自 Kodak 数据集的原始源图像和相应的结果,其中,JPEG 444@20429 字节;AVIF 444@19788 字节。JPEG 编码在天空、池塘以及屋顶上显示出了非常明显的块状伪影现象。AVIF 编码要好得多,虽然屋顶上还有一些模糊和纹理损失的现象,但块状伪影现象更少。考虑到压缩系数约为 59x(原始图像的尺寸为 768x512,因此需要 768x512x3 字节,而压缩后的图像为 20k 字节),这样的结果仍然还是很了不起的。
Kodak 数据集中的原始图像
JPEG 444@20419 字节
AVIF 444@19788 字节
对于同一个源,下图显示的是 JPEG 444@40276 字节 和 AVIF 444@39819 字节 的比较。JPEG 编码在天空中仍然有可见的块状伪影,以及屋顶边缘周围和几个位置出现了色渗现象。但是,AVIF 图像此时已经可以与原始图像相当,压缩系数为 29x。
JPEG 444@40276 字节
AVIF 444@39819 字节
下图显示的是来自 Kodak 数据集的另一幅原始源图像,以及相应的结果,其中,JPEG 444@13929 字节,AVIF 444@4176 字节。JPEG 编码在大多数边缘(尤其是倾斜的边缘)周围显示出了块状伪影,以及出现了颜色失真现象。尽管 AVIF 编码的大小是 JPEG 编码的三分之一,但它看起来“更干净”。它并不是原版的完美再现,但压缩系数为 282x,这一点是值得称赞的。
Kodak 数据集的另一幅原始源图像
JPEG 444@13939 字节
AVIF 444@4176 字节
下图显示的是同一图像的结果,但比特预算(bit-budget)稍高一些:JPEG 444@19787 字节 与 AVIF 444@20120 字节。JPEG 编码仍然在倾斜边缘周围出现块状伪影,而 AVIF 编码看起来与原始源图像几乎相同。
JPEG 444@19787 字节
AVIF 444@20120 字节
下图显示的是来自 Netflix(内部)1142x1600 分辨率“Boxshot-1”数据集的原始图像,然后是 JPEG 444@69445 字节 和 AVIF 444@40811 字节。在 JPEG 编码中可以看到严重的带状和块状伪影以及色彩失真现象。但在 AVIF 编码中,情况就没那么严重了,实际上,它小了 29kB。
Netflix(内部)Boxshots-1 数据集的原始源图像
JPEG 444@69445 字节
AVIF 444@40811 字节
下图显示的是稍微增加比特预算的同一图像的结果。JPEG 444@80101 字节 和 AVIF 444@85162 字节。在 JPEG 编码中仍然可以看到出现了带状和块状伪影,而 AVIF 编码看起来非常接近于原始源图像。
JPEG 444@80101 字节
AVIF 444@85162 字节
总体结果
下面显示的是公共数据集和 Netflix 内部数据集的结果。所使用的参考编解码器是来自 JPEG-XT 参考软件的 JPEG,使用 JPEG 标准的附件 K 中定义的标准量化矩阵。以下是以 BD 码率为基准测试和报告的编解码器和 / 或配置。
这些实验中的编码分辨率与源分辨率相同。对于 4:2:0 采样方式,在 4:2:0 子采样域计算质量度量。同样,对于 4:4:4 采样方式,在 4:4:4 子采样域中计算质量度量。除了与各种质量度量(如 SSIM、MS-SSIM、VIF 和 PSNR)相关的 BD 码率外,我们还是用 SSIM 作为度量来显示码率 - 质量曲线图。
Kodak 数据集;24 幅图像;768x512 分辨率
我们已经上传了 PNG 格式的源图像,以方便参考。此数据集的版权归 Kodak 所有。
给定一个质量度量,对于每个图像,我们考虑两条独立的码率 - 质量曲线。一条曲线与基线(JPEG)相关,另一条曲线与目标编解码器相关。我们将两者进行比较,并计算 BD 码率,它可以解释为在考虑的质量区域内相同质量的平均百分率降低。负值意味着码率降低,因此与基线相比更好。作为最后一步,我们报告的数据集中所有图像的 BD 码率的算数平均值。我们还在下表中突出显示了最佳性能。
CLIC 数据集;303 幅图像;2048x1320 分辨率
我们从公开的数据集中选择了一个图像子集,作为与 CVPR 联合举办的机器学习图像压缩挑战赛(CLIC) 的一部分。我们已经上传了我们选定的 303 幅 PNG 格式的源图像,以方便参考。这些源图像版权归 CLIC 所有。
广告牌数据集(Netflix 内部);223 幅图像;2048x1152 分辨率
广告牌图像通常比缩略图样的 Boxshot 图像占据更大的画布,并且通常是横幅的。左右两侧的任一侧都可以覆盖文本或图形,而另一侧则具有突出的字符、风景或艺术照。下面是一个例子。广告牌源图像是 Netflix 内部的,因此不属于公共数据集。
广告牌数据集中的原始源图像示例
Boxshots-1 数据集(Netflix 内部),100 幅图像,1142x1600 分辨率
与广告牌图像不同,Boxshot 图像是垂直的,通常,表示不同标题的 Boxshot 图像在用户界面中并排显示。该数据集的示例在上面的可视化示例小节中展示。Boxshots-1 源图像是 Netflix 内部的,因此不属于公共数据集。
Boxshots-2 数据集(Netflix 内部),100 幅图像,571x800 分辨率
Boxshots-2 数据集也有垂直的 Boxshot 图像,但分辨率较低。Boxshots-2 源图像是 Netflix 内部的,因此不属于公共数据集。
在这一点上,谨慎的做法是在这里讨论不使用 VMAF 作为质量度量。在之前的工作中,我们已经表明,对于类似于 JPEG 的失真和类似于 Boxshot 和广告牌的数据集,VMAF 与感知质量有很高的相关性。然而,到目前为止,VMAF 是一种经过训练和开发的度量,用于判断编码视频而非静态图像。在我们的测试中,与图像编解码器范围相关的失真范围比 VMAF 开发过程中考虑的范围更广,因此,对于这些编解码器来说,它可能不是图像质量的准确度量。此外,现在的 VMAF 模型并非为了捕获色度伪影而设计的,因此除了其他色度伪影之外,无法区分 4:2:0 和 4:4:4 的采样方式(这也适用于我们使用的其他一些测量度量,但由于缺乏替代方法,我们倾向于使用经过最充分测试和记录的图像质量度量)。这并不是说 VMAF 在图像质量上是非常不准确的,而是说,我们不会在评估图像压缩算法时使用它,因为此时有如此广泛多样的编解码器。我们即将进行一些激动人心的工作,以提高 VMAF 的准确性,包括各种编解码器、分辨率(包括乐谱中的色度通道)。话虽如此,仓库中的代码可以计算 VMAF,我们鼓励读者尝试一下,看看 AVIF 是否像本文那样在 VMAF 方面表现出色。
在很宽泛的质量范围内,峰值信噪比(PSNR)与感知质量的相关性并不高。然而,如果编码是以高峰值信噪比为目标进行的,那么就会有一个超支比特,但可以肯定的是,高峰值信噪比分数意味着接近于原始值。通过感知驱动的度量标准,我们有时会在很少的情况下看到失败的表现,在这种情况下,分数高得不合理,但缺乏视觉质量。
关于子采样的有趣观察
除了上述质量计算之外,我们还有以下观察结果,揭示了现代编解码器中一个令人鼓舞的趋势。在执行了 4:2:0 采样方式的编码之后,让我们假设我们对图像进行解码,将其向上转换为 4:4:4 采样方式,然后通过与 4:4:4 格式的原始源进行比较来计算各种度量。我们将此配置称为“444u”,以区别上述“编码 - 子采样”和“质量 - 计算 - 子采样”匹配的情况。在选择的度量中,PSNR_AVG 是一个考虑了所有 3 个通道(1 个亮度和 2 个色度)的度量指标。对于像 JPEG 这样的旧式编解码器,与以 4:2:0 采样方式进行编码相比,在以 4:4:4 采样方式进行编码时,比特预算将会在更多的采样中呈稀疏分布。这表明,与 4:2:0 采样方式相比,4:4:4 采样方式进行 JPEG 编码的 PSNR_AVG 较差,如下图所示。但是,在给定一个码率目标的情况下,使用诸如 HEVC 和 AVIF 这样的现代编解码器,最好的方法就是在广泛的比特率范围内对 4:4:4 采样方式进行编码。
使用现代编解码器(如以 PSNR_AVG 为度量判断的 AVIF)进行 4:4:4 采样方式的编码更好。
我们发现,使用现代编解码器,在整个“实用”码率区域内,当以 4:4:4 采样方式进行编码时,PSNR_AVG 比以 4:2:0 采样方式进行编码时更高,即使对于其他更实用的数据集,如 Boxshots-1 也是如此。有趣的是,在 JPEG 中,我们看到了一个交叉,即,在超过一定的码率之后,以 4:4:4 采样方式进行编码才会开始变得更有效率。这种交叉类似于在多个空间分辨率上编码时交叉的码率 - 质量曲线。下图所示,是 Boxshots-1 数据集中两个不同源图像的码率 - 质量曲线,比较了 JPEG 和 AVIF 在 444u 和 444 配置下的码率 - 质量曲线。
用现代编解码器(如 AVIF)用 PSNR_AVG 作为度量标准,以 4:4:4 采样方式进行编码更好。
用现代编解码器(如 AVIF)用 PSNR_AVG 作为度量标准,以 4:4:4 采样方式进行编码更好。
AVIF 支持与下一步
虽然 AVIF 提供了卓越的压缩效率,但它仍处于早期部署阶段。有各种各样的工具可以生成和使用 AVIF 图像。值得注意的是,开放媒体联盟正在开发一个名为 libavif 的开源库,可以对 AVIF 图像进行编码和解码。这个库的目标是简化来自图像社区中软件的集成。例如,在各种浏览器(例如 Google Chrome)中已经开始了这种集成,我们预计,在不久的将来会看到对 AVIF 图像的广泛支持。大量的工作还在进行中,特别是来自 dav1d 团队的工作,该团队使 AVIF 图像解码尽可能快,包括 10 位图像。可以想象,在我们最近宣布在 Android 系统上测试 AV1 视频之后,我们将很快会在 Android 系统上测试 AVIF 图像。
上面使用的数据集具有标准的动态范围(standard dynamic range,SDR)8 位图像。在 Netflix 中,我们也在为用户界面开发 HDR 图像,并计划使用 AVIF 对这些 HDR 图像资源进行编码。这是我们之前工作的延续,我们实验了 JPEG 2000 作为 HDR 图像的压缩格式,我们期待 AVIF 可以提供卓越的压缩收益。
致谢
我们要感谢 Marjan Parsa、 Pierre Lemieux、 Zhi Li、 Christos Bampis、 Andrey Norkin、 Hunter Ford、 Igor Okulist、 Joe Drago、 Benbuck Nason、 Yuji Mano、 Adam Rofer 和 Jeff Watts 的贡献和合作。
原文链接:
https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4
评论