WebP 相对于 PNG、JPG 有什么优势？

love

后台 用户组 论坛 附件相关 允许附件类型: 填上webp 就可以上传了  

WebP 图片格式派生自 VP8 视频编码，同时提供有损压缩和无损压缩：

• 有损 WebP 压缩使用的图像编码方式与 VP8 视频编解码器中压缩视频关键帧的方法相同。利用图像已编码部分预测未编码部分，将图像细分来进行预测处理，分块越细预测越准确。获取编码数值后将原图像数据减去预测数据得到差值，仅对差值进行编码，以此控制大小；
• 无损 WebP 压缩使用已知的图像片段来精确地重建新的像素，在无法找到相应的匹配值的情况下，使用本地调色板进行优化。
  

有损 WebP VS JPG

△ JPG vs 有损 WebP

当 WebP 将 JPG 压缩到相当于原图 90% 质量 时，图片体积减少了 50% 左右。当 WebP 将 JPG 压缩到相当于原图 80% 质量时，图片体积则减少了 60%~80%。

有损 WebP 压缩性能优于 JPG 的原因主要是其预测编码技术先进，并且宏块自适应量化也带来了压缩效率的提升，而布尔算术编码与霍夫曼编码相比提升了 5%~10% 的压缩性能。无损 WebP 对比 PNG

△ PNG 原图、PNG 无损、 WebP 无损对比

上图是 PNG 原图与 WebP 无损的对比，WebP 无损对 PNG 图片的优化到达了 20%~40% 。

love

除了视频，图片占据了 PC 和 App 的大部分流量，为运营方带来高额的成本支出，同时过多的图片加载会影响到网站与 App 的加载速度。因此在保证图片质量的前提下缩小图片的体积就成了迫在眉睫的事情。

目前，传统的图片格式如 JPEG、PNG、GIF 等格式的图片已经没有太多可以优化的空间，而 Google 推出 WebP 格式在图片压缩方面有了新的突破。

WebP 的诞生及原理

WebP 的诞生起初是因为 Google 开发了一种基于 VP8 视频编码格式的 WebM 视频格式，Google 的工程师意识到 WebM 格式非常适合压缩关键帧，由此开发了 WebP 图片格式。

WebP 最初发布于 2010 年，主要目标是使图片质量和 JPEG 格式质量相同的情况下，减少图片文件的体积，籍此减少互联网上图片的发送时间和流量消耗。发布不久之后，WebP 便被整合到 Chrome 以及 Android 系统中，并且 Google 发布了函数库，让 iOS 应用等其他工具支持 WebP 格式。

WebP 图片格式派生自 VP8 视频编码，同时提供有损压缩和无损压缩：

• 有损 WebP 压缩使用的图像编码方式与 VP8 视频编解码器中压缩视频关键帧的方法相同。利用图像已编码部分预测未编码部分，将图像细分来进行预测处理，分块越细预测越准确。获取编码数值后将原图像数据减去预测数据得到差值，仅对差值进行编码，以此控制大小；
• 无损 WebP 压缩使用已知的图像片段来精确地重建新的像素，在无法找到相应的匹配值的情况下，使用本地调色板进行优化。
  
  
  

Webp使图片体积减少45%

与其他图片格式相比，WebP 集合了多种图片文件格式的特点。它像 JPEG 一样适合压缩照片和其他细节丰富的图片，像 GIF 一样可以显示动态图片，像 PNG 一样支持透明图像。根据 Google 的测试，WebP 无损压缩图片比 PNG 图片少了 45％ 的文件体积，即使这些 PNG 图片在使用 pngcrush 和 PNGOUT 处理后，WebP 依旧可以减少 28％ 的文件体积。

WebP 应用效果

随着浏览器对 WebP 支持的普及，目前也有越来越多的互联网开始使用 WebP，这里分享几个数据：

YouTube 的视频略缩图采用 WebP 后，网页加载速度提升了 10%；

Google Chrome 应用商店采用 WebP 后，每天可以节省几 TB 的带宽，页面加载时间减少了30% 左右；

花瓣网在 2017 年 5 月开启 WebP 后，在网站总体请求量没有减少的情况下，整体带宽下降了近 50%。

WebP 格式兼容情况

虽然 WebP 的使用给实际应用带来了很多好处，且 Google Chrome 和 Opera 浏览器以及许多其他工具和软件库都支持 WebP，但是到目前为止也并非所有浏览器都支持 WebP， IE、Edge、Firefox、Safari 就均未支持 WebP 格式。

love

WebP 有损压缩
WebP 有损压缩使用的图像编码方式与 VP8 视频编解码器 WebM 格式压缩视频关键帧的方法相同，WebP 格式的图片本质就是 WebM 文件中被压缩的帧。
进行有损压缩时，WebP 会将图片划分为两个 8x8 色度像素宏块和一个 16x16 亮度像素宏块。在每个宏块内，编码器基于之前处理的宏块来预测冗余动作和颜色信息。通过图像关键帧运算，使用宏块中已解码的像素来绘制图像中未知部分，从而去除冗余数据，实现更高效的压缩。
WebP 编码器四种帧内预测模式：
H_PRED（水平预测）：用宏块左边的列 L 的填充块的每一列；
V_PRED（垂直预测）：用宏块上边的行 A 的填充宏块的每一行；
DC_PRED（DC预测）：用行 A 和列 L 的像素的平均值作为宏块唯一的值来填充宏块；
TM_PRED（TrueMotion预测）：除了行 A 和列 L 之外，用宏块上方和左侧的像素P、A（从P开始）中像素块之间的水平差异以列 L 为基准拓展每一行。



△ WebP 有损压缩预测模式
当图片处理到此处时，还剩下小的残差，通过 FDCT （正向离散余弦变换），让变换后的数据低频部分分布在数据块左上方，而高频部分集中于右下方实现更高效的压缩。
最后是将结果量化并进行熵编码。WebP 使用的是布尔算术编码作为熵编码方式，直接把输入的消息编码为一个满足(0.0 ≤ n < 1.0)的小数n。

△ WebP有损压缩所涉及的步骤
有损 WebP VS JPG

△ JPG vs 有损 WebP
当 WebP 将 JPG 压缩到相当于原图 90% 质量 时，图片体积减少了 50% 左右。当 WebP 将 JPG 压缩到相当于原图 80% 质量时，图片体积则减少了 60%~80%。
有损 WebP 压缩性能优于 JPG 的原因主要是其预测编码技术先进，并且宏块自适应量化也带来了压缩效率的提升，而布尔算术编码与霍夫曼编码相比提升了 5%~10% 的压缩性能。
WebP 无损压缩
WebP 无损压缩采用了预测变换、颜色变换、减去绿色变换、彩色缓存编码、LZ77 反向参考等不同技术来处理图像，之后对变换图像数据和参数进行熵编码。下文将对 WebP 的技术点进行一 一解析：
预测变换
预测空间变换通过利用相邻像素的数据相关性减少熵。在预测变换中，对已解码的像素预测当前像素值，并且仅对差值（实际预测）进行编码。预测变换有 13 种不同的模式，使用较多的是左、上、左上以及右上的像素预测模式，其余为左、上、左上和右上组合的平均值预测模式。
颜色变换
借助颜色变换去除每个像素的 R，G 和 B 值。彩色变换时保持绿色（G）值原样，根据绿色（G）值变换红色（R）值，再根据绿色值转换蓝色（B）值，最后根据红色（R）值进行转换。
如果与预测变换的情况一样，就需要将图像划分为宏块，并且对于宏块中的所有像素使用相同的变换模式。变换模式分为 3 种：green_to_red，green_to_blue和red_to_blue。
减去绿色变换
“减去绿色变换”从每个像素的红色、蓝色值中减去绿色值。当此变换存在时，解码器需要将绿色值添加到红色和蓝色。
彩色缓存编码
无损 WebP 压缩使用已经看到的图像片段来重构新的像素。如果没有找到对应的匹配值，可以使用本地调色板，同时本地调色板也会不断更新最近使用的颜色。

△ 更新本地色彩缓存
无损 WebP 对比 PNG

△ PNG 原图、PNG 无损、 WebP 无损对比（资料来源：http://isparta.github.io/compare-webp/#12345）
上图是 PNG 原图与 WebP 无损的对比，WebP 无损对 PNG 图片的优化到达了 20%~40% 。
WebP 与主流图片格式功能对比

△ 各图片格式功能对比
如何开启 WebP 图片格式
目前 WebP 图片格式依托于其优异的图片压缩性能以及兼备无损和有损两种压缩算法，在各大网站和 App 得到普及，那么要如何在网站中开启 WebP 格式呢？

△ 又拍云控制台 WebP 自适应开启方式
又拍云目前已经支持 WebP 图片格式转换，而且还支持 WebP 自适应功能，在后台一键开启 WebP 自适应功能，即可通过 CDN 平台智能判断客户端浏览器是否支持 WebP 解码，如果支持则返回 WebP格式图片，如果不支持则会返回原图，在客户端以及源站无需任何改动。