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
　　
　　3.0M ./home-raw.http://www.yuheng119.com/  jpg.guetzli84.jpg
　　
　　3.4M ./home-raw.jpg.guetzli87.jpg
　　
　　4.2M ./home-raw.jpg.guetzli90.jpg
　　
　　5.5M ./home-raw.jpg www.huazhyyule99.cn .guetzli93.jpg
　　
　　8.8M ./home-raw.jpg.guetzli96.jpg
　　
　　18M ./home-raw.http://www.acnet.cn/ jpg.guetzli99.jpg
　　
　　產品所有者和設計師均同意使用84這個品質因素。然后我轉換了所有的圖片，我們從主頁從30MB變為不到8MB（其中3MB是CSS和腳本）。
　　
　　應該注意到的是，我們的圖片之前並沒有進行任何形式的壓縮。
　　
　　附加說明
　　
　　在我的機器上安裝Guetzli很順利（有人在archlinux上創建了一個包含Guetzli的AUR包，非常感謝這個人），並且可以直接運行它（只要你擁有足夠的內存）。
　　
　　似乎還有一個brew包（針對Mac OS用戶），但是我沒有測試它。
　　
　　對於超大的圖片，Guetzli需要占用大量的內存和CPU時間（很多時候是相對的，不要指望着在運行的時候能夠做其他事情）。如果RAM不是你的瓶頸，那你甚至可以考慮針對不同的圖片並行運行多個Guetzli實例，因為它僅占用一個核心（僅作為寫入）。
　　
　　作為一個JPEG編碼器，它不能輸出PNG（因此沒有透明度），但它可以轉換和壓縮PNG圖片。
　　
　　運行效率與圖片的初始質量有關：我注意到壓縮比范圍大約為大圖像上的7倍到小圖像上的2倍之間。在小圖片上，質量損失也更加明顯。
　　
　　在少數情況下，我也發現色飽和度存在損失（在我這個案例中，這個是可以接受的）。
　　
　　長話短說
　　
　　給Guetzli一個嘗試，它可能會給你一個不可接受的結果（特別是低品質），但它也會讓你的網站減少幾MB的大小。