什么是 WebP?为什么我应该使用它?
WebP 是一种有损和无损压缩的方法,可用于网络上发现的各种摄影、半透明和图形图像。有损压缩的程度是可以调整的,以便用户可以在文件大小和图片质量之间进行权衡。WebP 的压缩率通常比 JPEG 和 JPEG 2000 高出 30%,并且不会降低图片质量(请参阅对比研究)。
WebP 格式主要是为了创建尺寸更小、更美观的图片,帮助提升网页加载速度。
哪些网络浏览器原生支持 WebP?
希望提高网站性能的网站站长可以轻松为当前图片创建经过优化的 WebP 替代方案,并有针对性地将其投放到支持 WebP 的浏览器。
- WebP 有损支持
- Google Chrome(桌面设备)17 及更高版本
- Android 版 Google Chrome 版本 25+
- Microsoft Edge 18 及更高版本
- Firefox 65 及更高版本
- Opera 11.10 及更高版本
- 原生网络浏览器,Android 4.0 及更高版本 (ICS)
- WebP 有损、无损和 alpha 支持
- Google Chrome(桌面版)23+
- Android 版 Google Chrome 版本 25+
- Microsoft Edge 18 及更高版本
- Firefox 65 及更高版本
- Opera 12.10 及更高版本
- 原生网络浏览器,Android 4.2 及更高版本 (JB-MR1)
- 淡月 26 岁以上
- 支持 WebP 动画
- Google Chrome(桌面版和 Android 版)32 及更高版本
- Microsoft Edge 18 及更高版本
- Firefox 65 及更高版本
- 歌剧 19+
另请参阅 Wikipedia WebP 文章。
如何检测 WebP 的浏览器支持情况?
您可能只想将 WebP 图片投放给能够正确显示的图片,并回退到不支持的格式。幸运的是,有几种技术可用于检测 WebP 支持(客户端和服务器端)。某些 CDN 提供商在其服务中提供 WebP 支持检测。
通过 Accept 标头进行服务器端内容协商
Web 客户端通常会发送“接受”请求标头,以表明他们愿意接受哪些内容格式作为响应。如果浏览器事先表示它会“接受”图片/webp 格式,则网络服务器知道它可以安全地发送 WebP 图片,从而大大简化内容协商。如需了解详情,请访问以下链接。
现代主义者
Modernizr 是一个 JavaScript 库,用于在网络浏览器中方便地检测 HTML5 和 CSS3 功能支持。查找 Modernizr.webp、Modernizr.webp.lossless、Modernizr.webp.alpha 和 Modernizr.webp.animation 属性。
HTML5 <picture>
元素
HTML5 支持 <picture>
元素,可让您按优先级顺序列出多个备选图片目标,以便客户端能够请求可以正确显示的第一个候选图片。请参阅 HTML5 Rocks 相关讨论。<picture>
元素始终受更多浏览器支持。
使用您自己的 JavaScript
另一种检测方法是尝试解码使用特定功能的非常小的 WebP 图片,并检查是否成功。示例:
// check_webp_feature:
// 'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
// 'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
var kTestImages = {
lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
};
var img = new Image();
img.onload = function () {
var result = (img.width > 0) && (img.height > 0);
callback(feature, result);
};
img.onerror = function () {
callback(feature, false);
};
img.src = "data:image/webp;base64," + kTestImages[feature];
}
请注意,图片加载是非阻塞和异步的。这意味着,最好将依赖于 WebP 支持的所有代码都加入回调函数中。
Google 为什么要以开放源代码的形式发布 WebP?
我们坚信开源模型的重要性。借助开源的 WebP,任何人都可以处理该格式并提出改进建议。根据您提供的意见和建议,我们相信 WebP 会随着图形格式逐渐成为更加有用的工具。
如何将我的个人图片文件转换为 WebP 格式?
您可以使用 WebP 命令行实用程序将个人图片文件转换为 WebP 格式。如需了解详情,请参阅使用 WebP。
如果您要转换许多映像,可以使用平台的 shell 来简化操作。例如,如需转换文件夹中的所有 jpeg 文件,请尝试以下操作:
Windows:
> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )
Linux / macOS:
$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done
我该如何评判自己的 WebP 图片质量?
目前,您可以查看 WebP 文件,方法是将其转换为使用无损压缩的常见格式(如 PNG),然后在任何浏览器或图片查看器中查看 PNG 文件。如需快速了解 WebP 质量,请参阅此网站上的图库,获取并排的照片对比。
如何获取源代码?
转换器代码位于 WebP 开源项目页面的下载部分中。该轻量级解码器和 VP8 规范的代码位于 WebM 网站上。如需了解容器规范,请参阅 RIFF 容器页面。
WebP 图片的大小上限是多少?
WebP 与 VP8 兼容,并采用 14 位的宽度和高度。 WebP 图片的最大像素尺寸为 16383 x 16383。
WebP 格式支持哪些颜色空间?
与 VP8 比特流一致,有损 WebP 专门与 8 位 Y'CbCr 4:2:0(通常称为 YUV420)映像格式兼容。如需了解详情,请参阅 RFC 6386 中的第 2 部分“格式概览”和 VP8 数据格式和解码指南。
无损 WebP 仅支持 RGBA 格式。请参阅 WebP 无损比特流规范。
WebP 图片能否大于其源图片?
是,通常在从有损格式转换为 WebP 无损格式时,反之亦然。这主要是因为色差(YUV420 与 ARGB)以及它们之间的转换。
典型的情形有以下三种:
- 如果源图片采用无损 ARGB 格式,则 YUV420 的空间降采样将引入比原始颜色更难压缩的新颜色。如果来源采用的是 PNG 格式,且颜色较少,则通常会发生这种情况:转换为有损 WebP(或类似于有损 JPEG)可能会使文件变大。
- 如果源文件是有损格式,使用无损 WebP 压缩来捕获来源的有损性质通常会使文件变大。这并非 WebP 中的问题,例如,在将 JPEG 来源转换为无损 WebP 或 PNG 格式时,可能会发生这种情况。
- 如果源文件采用有损格式,并且您正尝试将其压缩为采用较高质量设置的有损 WebP,例如,如果尝试将质量为 80 的 JPEG 文件转换为质量为 95 的 WebP 文件,通常会导致文件较大,即使这两种格式都有损耗。评估来源质量通常是不可能的,因此如果文件大小始终较大,建议降低目标 WebP 质量。
另一种可能的方法是避免使用质量设置,而应使用
cwebp
工具中的-size
选项或等效的 API 定位给定的文件大小。例如,如果以原始文件大小的 80% 为目标,可能更可靠。
请注意,将 JPEG 来源转换为有损 WebP,或将 PNG 来源转换为无损 WebP,不容易出现这种文件大小意外的问题。
WebP 是否支持渐进式或隔行显示?
WebP 不提供 JPEG 或 PNG 格式的渐进式或交错解码刷新。这可能会给解码客户端的 CPU 和内存带来过大的压力,因为每次刷新事件都需要经过一次完全解压缩系统。
平均而言,解码逐行 JPEG 图像相当于解码基准 3 次。
或者,WebP 提供增量解码,即所有可用的比特流传入字节都尝试尽快生成可显示的样本行。这既节省了客户端的内存、CPU 和重绘工作,又提供了有关下载状态的视觉提示。增量解码功能可通过高级解码 API 获得。
如何在我的 Android 项目中使用 libwebp Java 绑定?
WebP 支持 JNI 与 swig/
目录中的简单编码器和解码器接口的绑定。
在 Eclipse 中构建库:
- 确保随 NDK 工具一起安装 ADT 插件,并且 NDK 路径已正确设置(偏好设置 > Android > NDK)。
- 创建一个新项目:File > New > Project > Android Application Project。
- 将 libwebp 克隆或解压缩到新项目中名为
jni
的文件夹。 - 将
swig/libwebp_java_wrap.c
添加到LOCAL_SRC_FILES
列表。 - 右键点击新项目,然后依次选择 Android Tools 和 Add Native Support ...,以将库添加到您的 build 中。
打开项目属性,然后转到 C/C++ Build > Behaviour。将
ENABLE_SHARED=1
添加到Build (Incremental build)
部分,以将 libwebp 构建为共享库。注意:设置
NDK_TOOLCHAIN_VERSION=4.8
通常可以提高 32 位 build 的性能。将
swig/libwebp.jar
添加到libs/
项目文件夹中。构建您的项目。这将创建
libs/<target-arch>/libwebp.so
。在运行时使用
System.loadLibrary("webp")
加载库。
请注意,您可以使用 ndk-build
和随附的 Android.mk
手动构建该库。在这种情况下,您可以重复使用上述的某些步骤。
如何将 libwebp 与 C# 搭配使用?
可将 WebP 构建为导出 libwebp API 的 DLL。随后可以使用 C# 导入这些函数。
构建 libwebp.dll。这会正确设置 WEBP_EXTERN 以导出 API 函数。
libwebp> nmake /f Makefile.vc CFG=release-dynamic
将 libwebp.dll 添加到您的项目中,并导入所需的函数。 请注意,如果您使用简单的 API,则应调用
WebPFree()
以释放返回的所有缓冲区。[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)] static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride, float quality_factor, out IntPtr output); [DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)] static extern int WebPFree(IntPtr p); void Encode() { Bitmap source = new Bitmap("input.png"); BitmapData data = source.LockBits( new Rectangle(0, 0, source.Width, source.Height), ImageLockMode.ReadOnly, PixelFormat.Format32bppArgb); IntPtr webp_data; const int size = WebPEncodeBGRA(data.Scan0, source.Width, source.Height, data.Stride, 80, out webp_data); // ... WebPFree(webp_data); }
为什么要使用动画 WebP?
与动画 GIF 相比,WebP 的优势
WebP 支持具有 8 位 Alpha 通道的 24 位 RGB 颜色,而 GIF 只有 8 位颜色和 1 位 Alpha 通道。
WebP 既支持有损压缩,也支持无损压缩;事实上,单个动画可以结合使用有损和无损帧。GIF 仅支持无损压缩。WebP' 有损压缩技术非常适合基于真实视频创建的动画图像,这种视频越来越受欢迎。
WebP 需要的字节数少于 GIF1。转换为有损 WebP 的动画 GIF 小 64%,而无损 WebP 小 19%。这在移动网络上尤为重要。
有跳转时,WebP 可以缩短解码时间。在 Blink 中,滚动或更改标签页可以隐藏和显示图片,导致动画暂停,然后跳到不同的点。如果 CPU 使用率过高导致动画丢帧,可能还要求解码器在动画中前进。在这些情况下,动画 WebP 的总解码时间是 GIF 的 0.57 倍2,因此可减少滚动过程中的卡顿现象并加快 CPU 利用率峰值的恢复速度。这是因为 WebP 比 GIF 具有两个优势:
WebP 图片会存储有关每个帧是否包含 Alpha 值的元数据,这样就无需解码帧即可做出判定。这样可以更准确地推断指定帧所依赖的前一帧,从而减少对前帧的不必要解码。
与现代视频编码器非常相似,WebP 编码器以启发方式定期添加关键帧(大多数 GIF 编码器都没有这样做)。这显著改善了长动画中的跳转效果。为了方便插入此类帧而不显著增加图片大小,除了 GIF 使用的帧处理方法之外,WebP 还为每个帧添加了'混合方法标志。这样一来,关键帧便可以像整个图片已被清空为背景颜色一样绘制,而不会强制上一帧完全尺寸。
动画 WebP 与动画 GIF 的缺点
在缺少跳转的情况下,WebP 的直线解码比 GIF 更需要 CPU 密集型处理。有损 WebP 所用的解码时间是 GIF 的 2.2 倍,而无损 WebP 的解码时间是 GIF 的 1.5 倍。
WebP 支持并不像 GIF 支持那么普遍,后者实际上是通用的。
为浏览器添加 WebP 支持会增加代码占用空间和攻击面。在 Blink 中,大约还需要 1500 行代码(包括 WebP 多路分配库和 Blink 端 WebP 图像解码器)。请注意,如果 WebP 和 WebM 共用更常见的解码代码,或者如果 WebP 的功能在 WebM 中使用,则将来可能会减少此问题。
为何不直接在 <img>
中支持 WebM?
从长远来看,支持 <img>
标记内的视频格式可能是有意义的。不过,为了同时让 <img>
中的 WebM 填充动画 WebP 的提议角色,这样做现在会出现问题:
在解码依赖于上一帧的帧时,WebM 需要比动画 WebP 多出 50% 的内存才能保留最低数量的上一帧3。
视频编解码器和容器支持因浏览器和设备而异。为方便内容自动转码(例如,为了节省带宽的代理),浏览器需要添加接受标头,以指明其图片代码支持的格式。甚至可能不够,因为“video/webm”或“video/mpeg”等 MIME 类型仍然不支持编解码器(例如 VP8 与 VP9)。另一方面,WebP 格式实际上已冻结,如果发布该格式的供应商同意提供动画 WebP,则所有 UA 中的 WebP 行为应保持一致;由于“image/webp”accept 标头已用于表明支持 WebP,因此无需更改新的“accept”标头。
Chromium 视频堆栈针对流畅播放进行了优化,并假设一次仅播放一两个视频。因此,该实现会积极消耗系统资源(线程、内存等),以最大限度地提高播放质量。此类实现并不能很好地扩展到多个同步视频,因此需要重新设计,以便与包含大量图片的网页配合使用。
WebM 目前并未采用 WebP 的所有压缩技术。因此,与替代方案相比,此图片在 WebP 压缩方面的性能明显提高:
1 对于 GIF 动画与 WebP 之间的所有比较,我们使用语料库中包含约 7000 张从网络中随机选取的 GIF 动画图片。这些图片已通过 'gif2webp' 工具(使用最新的 libwebp 源代码树,于 2013 年 10 月 8 日构建)而转换为动画 WebP。比较数字是这些图像的平均值。
2 截至 2013 年 10 月 8 日,使用最新 libwebp + ToT Blink 通过基准工具计算解码时间。“使用还原功能解码时间”的计算方法是:“解码前五帧,清除帧缓冲区缓存,解码接下来的 5 帧,依此类推”。
3 WebM 在内存中保留 4 个 YUV 参考帧,每个帧存储(宽度 + 96)*(高度 + 96)像素。对于 YUV 4:2:0,我们需要每 6 像素 4 字节(或每像素 3/2 字节)。因此,这些参考帧使用 4*3/2*(width+96)*(height+96)
字节的内存。另一方面,WebP 只需要上一帧(采用 RGBA),即 4*width*height
字节的内存。
4 动画 WebP 渲染需要 Google Chrome 版本 32 及更高版本