跳過肉眼？全面解讀Google最新發布的JPEG壓縮演算法Guetzli

導讀：本文介紹了Google的圖片壓縮軟體Guetzli，並通過一些測試指出了該軟體的使用注意點。

你可能已經知道，現在網頁文件的平均大小比Doom遊戲的安裝文件還還大。

文件變大的原因之一是圖片的增加，並且還需要支持更高的解析度。

Google來拯救了

Google剛剛發布了一種新的JPEG壓縮演算法：Guetzli。該演算法的主要思想是重點保留人眼可以輕鬆識別的細節，同時跳過眼睛無法注意的細節。

我不是專家，但預期的結果是獲得一個感知質量相同，但文件大小更小的圖像。

這不是一種新的圖像格式，而是一種壓縮JPEG圖像的新方法。這意味著不需要一個定製的圖像查看器，而是可以由任何一個能渲染JPEG的軟體來顯示。

現實生活中Guetzli

在我的一個項目中，有一個包含很多圖片的主頁（僅主頁就有大約30Mb，其中27M是圖片）。

我決定給Guetzli一個嘗試的機會，為了說服我們的產品所有者和設計師質量損失是可以接受的，我試著把這個新的演算法應用在一張沒有使用的高解析度的圖片上（一張8574×5715，22MB的JPEG圖片） 。

它崩潰了。

根據google所說（並且我的經驗證實了這些數字），Guetzli每一百萬像素的圖像大約需要佔用300MB的內存（因此，我的圖像大約需要15GB），而當時我沒有這麼大的內存（六個節點伺服器，兩個docker容器，chromium和幾個electron實例所佔用的內存使得我的電腦不符合要求）。

在清理了一些不重要的進程之後，我重新試了一次，Guetzli佔用了12GB的內存，但是成功了。

Google還表示，Guetzli處理一張圖片每一百萬像素大概需要一分鐘的時間，我差不多也花了這麼多時間（總時間略超過40分鐘）。

壓縮後的圖像不到7MB（原始大小為22MB），我無法通過肉眼來確定哪個是壓縮過的（我們的設計師可以，但是承認差異「小到令人難以置信」）。

6.9M home-guetzli.jpg

22M home-raw.jpg

我使用的是Guetzli默認的品質設置（從84到100，如果要低於84，你需要自己編譯並更改這個最小值）進行的壓縮。

更多的測試以及一些成功的例子

然後，我決定為該圖像嘗試使用不同的品質設置（我寫了一個非常簡單的腳本，從而無需每40分鐘重新啟動一次，並且在我睡覺的時候也能夠運行）。

結果在這裡（Guetzli的默認品質因素似乎是95）。

6.9M ./home-guetzli.jpg

22M ./home-raw.jpg

產品所有者和設計師均同意使用84這個品質因素。然後我轉換了所有的圖片，我們從主頁從30MB變為不到8MB（其中3MB是CSS和腳本）。

應該注意到的是，我們的圖片之前並沒有進行任何形式的壓縮。

附加說明

在我的機器上安裝Guetzli很順利（有人在archlinux上創建了一個包含Guetzli的AUR包，非常感謝這個人），並且可以直接運行它（只要你擁有足夠的內存）。

似乎還有一個brew包（針對Mac OS用戶），但是我沒有測試它。

對於超大的圖片，Guetzli需要佔用大量的內存和CPU時間（很多時候是相對的，不要指望著在運行的時候能夠做其他事情）。如果RAM不是你的瓶頸，那你甚至可以考慮針對不同的圖片並行運行多個Guetzli實例，因為它僅佔用一個核心（僅作為寫入）。

作為一個JPEG編碼器，它不能輸出PNG（因此沒有透明度），但它可以轉換和壓縮PNG圖片。

運行效率與圖片的初始質量有關：我注意到壓縮比範圍大約為大圖像上的7倍到小圖像上的2倍之間。在小圖片上，質量損失也更加明顯。

在少數情況下，我也發現色飽和度存在損失（在我這個案例中，這個是可以接受的）。

長話短說

給Guetzli一個嘗試，它可能會給你一個不可接受的結果（特別是低品質），但它也會讓你的網站減少幾MB的大小。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！