Guetzli:谷歌家的東西可能也沒有想像的辣麼美

望昕宇,騰訊後臺工程師,專一圖片壓縮及存儲系統一百年不動搖,並致力於作一名相關前沿技術的人話翻譯家。算法

這兩天筆者的朋友圈被Google開源JPEG編碼器Guetzli刷屏,「圖片大小減少35%」、「質量不變」這樣的字眼刺激了咱們的腎上腺,OMG的yajunwang同窗也爲咱們帶來了第一手的測試資料——谷歌開源圖片壓縮算法Guetzli實測體驗報告框架

若是這樣的神器真的如此神,那還有WebP啥事兒呢。因而咱們抱着強烈的好奇心實地考察了這個連名字都不知道怎麼唸的新鮮事物。工具

結論是:測試

  1. 在基於相同客觀質量(以ssim爲評價標準)的條件下觀察主觀視覺效果,Guetzli的優點是有效改善了傳統JPEG在低質量條件下「振鈴效應」產生的僞影;劣勢是Guetzli編碼出的圖片在質量較低時(quality=70)有必定的「鈍化效應」,對於圖片中細節精細的部分,Guetzli丟掉了較多的信息。優化

  2. 一樣基於相同客觀質量條件下(並不以填的quality參數爲標準,爲何不以它爲標準參見「原理解析」小節)圖片大小與傳統jpg相比並沒有明顯優點。400300組Guetzli大概比傳統jpg的編碼結果減少了19%,800600組Guetzli和傳統jpg基本持平,1920*1080組Guetzli反而大出了10%。google

  3. 延時方面,Guetzli編碼器對於主流的非高清圖規格(如400300, 800600)的處理延時在秒級或10+秒級,業務主流jpg壓縮工具對於相同規格的處理延時均在50ms之內編碼

原理解析:

Guetzli基於一樣來源於google的圖片視覺差別評價工具Butteraugli。Butteraugli的評價體系基於三個傳統方法沒有考慮的原則:翻譯

  • 人眼對強黃色光附近藍光變化是不敏感的,所以黃光區域附近的藍光能夠用更少的bit來編碼code

  • 人眼對藍光有着較低的空間分辨率,視網膜中用於分辨高清細節的區域沒有藍色光的受體,故高頻區域的藍色光部分能夠用更粗的粒度編碼。視頻

  • 將圖像中的噪聲區域分辨出來進行粗粒度的編碼。

基於這三點,Guetzli主要從兩方面下手來進行:

  1. 對全局量化表進行微調,這一步和咱們調整質量參數本質上是同樣的

  2. 對DCT係數的高頻部分進行有選擇的丟棄。

第二步就比較tricky了。一般在咱們使用例如libjpeg等工具壓縮jpg圖片時下降質量參數本質上就是在量化步驟按照必定規則丟棄高頻信息,最終反映在jpg的quality中。Guetzli至關於繞開了制定好的量化規則下降了質量並且不告訴用戶,讓用戶覺得仍然保持了質量(怎麼感受google也有了一點流氓氣質呢,2333)。因此在後續測試中咱們發現,**在相同ssim條件下,傳統jpg的質量參數能夠比Guetzli編碼出來的jpg低大約20個點。**緣由主要就在這裏。

Guetzli總的處理流程是嘗試多種量化表及DCT係數兩個方面的可能性,而後分別將嘗試的結果放到Butteraugli評測工具中評分,最後選擇一張它認爲最好的結果返回給用戶。因此它的處理時延特別長。用verbose參數打開Guetzli的log能夠發現,平均一張圖大概它將嘗試接近30次的迭代。

測試樣本:

分別選取400300, 800600, 19201080三種分辨率的jpg格式圖片各10張(原本還選取了40323024的iPhone照片分辨率圖片作測試,可是因爲時間有限,這部分待後續進行)。三種分辨率的圖片在選取的過程當中綜合考慮主色調的不一樣、明暗灰度的不一樣、場景的不一樣(人工合成的圖片仍是天然風景照)以考察該編碼是否儘量多的適用於不一樣場景。

測試場景及指標:

該編碼器有quality參數能夠指定,註釋掉對於quality必須大於84部分的代碼以後能夠設置0-100任意值,通過第一輪初步測試發現,quality<70 如下的時候其實編碼出的圖片已經沒有變化(爲何還須要進一步研究),故實際選取 quality 70, 75, 80, 85, 90爲測試對象。從編碼時延、同psnr(ssim)指標下圖片size的對比以及視覺效果還有內存消耗四個方面進行評估。

測試環境及工具:

C1機型:Intel Xeon CPU E3-1230 V2 3.30GHz

測試工具:ImageMagick、Guetzli編碼器、evalvid視頻質量評價工具集

測試結果:

時延、內存消耗、帶寬節省

SSIM檢測

檢測方法是首先分別用ImageMagick和Guetzli分別用40-90的quality參數進行從新解碼和編碼,而後對每一個質量的結果圖與原圖分別解碼成yuv源數據格式,最後用evalvid視頻質量評測工具集中的psnr工具進行ssim評測,框架圖可表示爲:

當咱們設定了以ssim1=ssim2爲標準時候反過來再觀察兩種編碼工具各自設定的quality值。通過統計發現,傳統jpg的質量比Guetzli的質量平均大約小21。舉個例子也就是說,傳統jpg的50質量和Guetzli編碼器的70質量在客觀質量評價體系當中是等價的。

同ssim下圖片大小對比:

應用場景的思考

Guetzli編碼器本質上弱化了quality參數在編碼流程中的做用,能夠比喻爲jpg編碼界的「小米」,其效果相似於增強版的七牛圖片「瘦身」功能。

所以對於圖片細節要求不高且對圖片質量不甚瞭解的用戶或者當面對一個業務由於須要節省流量同時又不但願圖片質量受太大影響而對質量參數選擇困難時,Guetzli是一個不錯的入門選擇。從流程方面看,屢次的迭代以及新的評價工具的加入是延時過長的主要緣由,也許利用GPU並行化會是一個不錯的優化方向。


相關推薦:

谷歌開源圖片壓縮算法Guetzli實測體驗報告 圖片流量節省大殺器:基於CDN的sharpP自適應圖片技術實踐 【騰訊雲的1001種玩法】 Laravel 整合萬向優圖圖片管理能力,打造高效圖片處理服務


閱讀原文,本文由騰雲閣受權發佈,經社區容許後方可轉載。更多技術文章,請訪問騰雲閣

相關文章
相關標籤/搜索