Jyrki Alakuijala 博士、Google, Inc.
Vincent Rabaud 博士，Google, Inc.
上次更新日期：2017 年 8 月 1 日
抽象：我們會在無損和失真模式中，比較 WebP 編碼器/解碼器的資源使用情形。我們使用 12,000 張網路語料庫，從網路上隨機選出 12,000 張半透明的 PNG 圖片，並簡化評估方式來呈現效能變化。我們已重新壓縮語料庫中的 PNG，以便比較 WebP 圖片與大小最佳化的 PNG 檔案。從我們的結果中，我們發現 WebP 是適合網路 PNG 的理想方案，而適用於網路的 PNG 和處理速度。
簡介
WebP 支援無損和半透明圖片，因此可做為 PNG 格式的替代方案。PNG 壓縮作業中使用的許多基本技術 (例如字典程式碼、Huffman 編碼和色彩索引轉換) 也在 WebP 中支援，因此在最糟的情況下，這樣做會導致速度和壓縮密度相近。同時，一些新功能 (例如不同色彩管道區分的熵代碼、反向參照距離的 2D 位置，以及最近所使用顏色的色彩快取)，讓大多數圖片都能提高壓縮密度。
在這項工作中，我們會比較 WebP 和使用 pngcrush 和 ZopfliPNG 進行高度壓縮的 WebP 效能。我們按照最佳做法重新壓縮了網路圖片的參照語料，並對照這個語料庫並用無損和有損 WebP 壓縮。除了參考語料庫以外，我們選擇兩張較大的圖片：一張較大的圖片，另一張圖成圖像，速度和記憶體用量基準。
研究顯示速度比 PNG 更快，且壓縮速度比現今 PNG 格式低 23%。幸好，WebP 取代了今天的 PNG 圖片格式更有效率。而且，支援無損 Alpha 測試的有損圖片壓縮，能進一步提昇網站運作速度。
方法
指令列工具
我們使用下列指令列工具來測量效能：
cwebp 和 dwebp這些工具屬於 libwebp 程式庫 (從頭部編譯)。
轉換。這是 ImageMagick 軟體 (6.7.7-10 2017-07-21) 的指令列工具部分。
pngcrush 1.8.12 (2017 年 7 月 30 日)
ZopfliPNG (2017 年 7 月 17 日)
我們使用指令列工具及其各自的控制旗標。舉例來說，如果我們參照了 cwebp -q 1 -m 0，就表示 cwebp 工具已使用 -q 1 和 -m 0 旗標叫用。
圖片中心
已選取三個語料庫：
單一攝影圖片 (圖 1)
具有透明度的單一圖形圖片 (圖 2) 以及
網路語料庫：從網際網路檢索為隨機選擇的 12,000 張 PNG 圖片，圖片是否為暫時性的。這些 PNG 圖片經過轉換、pngcrush、ZopfliPNG 和每張圖片的最小版本都經過最佳化處理。
圖 1. 相片圖片，1024 x 752 像素。火口呼吸 「Jaipur Maharaja Brass Band」，作者：Luc Viatour，根據創用 CC 授權相片 姓名標示 - 相同方式分享 3.0 未攜碼授權。作者網站請按這裡。
圖 2. 圖形圖片，1024 x 752 像素。Google 圖表工具的美術拼貼圖片
為評估現有格式 PNG 的完整功能，我們已使用多種方法壓縮所有原始 PNG 圖片：
每個元件對齊 8 位元：轉換 input.png -depth 8 output.png
ImageMagick(1) 不含預測工具：轉換 input.png -quality 90 output-candidate.png
ImageMagick 搭配自動調整預測工具：轉換 input.png -quality 95 output-candidate.png
Pngcrush(2)：pngcrush -brute -rem tEXt -rem tIME -rem iTXt -rem zTXt -rem gAMA -rem cHRM -rem iCCP -rem sRGB -rem alla -rem text input.png-can output-cand
ZopfliPNG(3)：zopflipng --lossy_personalized input.png output-candidate.png
搭配所有篩選條件的 ZopfliPNG：zopflipng --iterations=500 --filters=01234mepb --lossy_8bit --lossy_personalized input.png output-candidate.png
成果
我們針對網路語料庫中的每張圖片計算壓縮密度 (相對於針對三種方法的最佳化 PNG 圖片大小)：
WebP 無損 (預設設定)
最小尺寸的 WebP 無損 (-m 6 -q 100)
保持 WebP 無損和 WebP 損失 (預設設定)。
我們整理了這些壓縮係數，如圖 3 所示。
圖 3. PNG 壓縮密度會做為 1.0 的參考。系統會使用無損和有損方法壓縮相同的圖片。系統會計算每張圖片的大小比率與壓縮 PNG 檔案，並對大小比例進行排序，並在無損壓縮和有損壓縮時顯示。至於有損壓縮曲線，系統會選擇無損壓縮，這種情況下會產生較小的 WebP 圖片。
WebP 不僅具有最高品質 (轉換) 的 PNG 壓縮密度，也超越了以最高品質 (轉換) 的 libpng 壓縮密度，以及 ZopfliPNG (表 1)、編碼 (表 2) 和解碼 (表 3) 的速度，與 PNG 相比非常可觀。
表 1. 使用不同壓縮方法的三個語料庫中每像素數平均位元數。
| 圖片集 | 轉換 -品質 95 | ZopfliPNG | WebP 無損 - 第 0 季 - m 1 | WebP 無損 (預設設定) | WebP 無損 -m 6 - 第 100 季 | WebP 有損 (使用 Alpha 版) |
|---|---|---|---|---|---|---|
| 相片 | 12.3 | 12.2 | 10.5 | 10.1 | 9.83 | 0.81 |
| 血腥 | 1.36 | 1.05 | 0.88 | 0.71 | 0.70 | 51 萬 |
| 網站 | 6.85 | 5.05 | 4.42 | 4.04 | 3.96 | 1.92 |
表 2. 壓縮語料庫和不同壓縮方法的平均編碼時間。
| 圖片集 | 轉換 -品質 95 | ZopfliPNG | WebP 無損 - 第 0 季 - m 1 | WebP 無損 (預設設定) | WebP 無損 -m 6 - 第 100 季 | WebP 有損 (使用 Alpha 版) |
|---|---|---|---|---|---|---|
| 相片 | 0.500 秒 | 8.7 秒 | 0.293 秒 | 0.780 秒 | 8.440 秒 | 0.111 秒 |
| 血腥 | 0.179 秒 | 14.0 秒 | 0.065 秒 | 0.140 秒 | 3.510 秒 | 0.184 秒 |
| 網站 | 0.040 秒 | 1.55 秒 | 0.017 秒 | 0.072 秒 | 2.454 秒 | 0.020 秒 |
表 3. 使用不同方法和設定壓縮的三個圖片檔平均解碼時間。
| 圖片集 | 轉換 -品質 95 | ZopfliPNG | WebP 無損 - 第 0 季 - m 1 | WebP 無損 (預設設定) | WebP 無損 -m 6 - 第 100 季 | WebP 有損 (使用 Alpha 版) |
|---|---|---|---|---|---|---|
| 相片 | 0.027 秒 | 0.026 秒 | 0.027 秒 | 0.026 秒 | 2027 年 | 0.012 秒 |
| 圖像 | 0.049 秒 | 0.015 秒 | 0.005 秒 | 0.005 秒 | 0.003 | 0.010 秒 |
| 網站 | 0.007 秒 | 0.005 秒 | 0.003 秒 | 0.003 秒 | 0.003 | 0.003 秒 |
記憶體剖析
針對記憶體剖析，我們記錄了由 /usr/bin/time -v 回報的常駐集合大小上限。
如果是網路語料庫，單獨使用最大的圖片就能定義最大記憶體用量。為了讓記憶體測量結果更加完善，我們會使用一張攝影圖片 (圖 1) 概略介紹記憶體用量。圖像圖片會提供類似的結果。
我們針對 libpng 和 ZopfliPNG 測量了 10 至 19 MiB，在 -q 0 -m 1 和 -q 95 (預設值為 -m) 的設定中測量出 25 MiB 和 32 MiB (WebP 無損編碼)。
在解碼實驗中，轉換 1x1 大小對 libpng 和 ZopfliPNG 產生的 PNG 檔案會使用 10 MiB。使用 cwebp 時，WebP 無損解碼使用 7 MiB，以及 3 MiB 的損失解碼。
結論
我們證明瞭編碼和解碼速度皆位於 PNG 的同一個網域中。編碼階段的記憶體用量會增加，但解碼階段至少會在比較 cwebp 和 ImageMagick 轉換時的行為降低。
針對超過 99% 的網路圖片，壓縮密度會更好，這表示在從 PNG 到 WebP 的情況下，壓縮密度比較容易。
在以預設設定執行 WebP 時，WebP 的壓縮率比 libpng 高出 42%，且較 ZopfliPNG 高出 23%。這表示 WebP 可望加速載入含有大量圖片的網站。
參考資料
外部連結
下列獨立研究並非由 Google 贊助，Google 不一定能提供所有內容正確的正確性。