圖像已經(jīng)發(fā)展成人類溝通的視覺語言。無論傳統(tǒng)互聯(lián)網(wǎng)還是移動互聯(lián)網(wǎng)，圖像一直占據(jù)著很大部分的流量。如何在保證視覺體驗的情況下減少數(shù)據(jù)流量消耗，一直是圖像處理領(lǐng)域研究的熱點。也誕生了許多種類的圖像格式JPEG、PNG 、GIF、WEBP、HEVC，以及騰訊公司自研的WXAM和SHARPP格式。

騰訊TEG - 架構(gòu)平臺部圖片存儲系統(tǒng)TPS 作為超大規(guī)模的圖片平臺，圖片數(shù)萬億張存儲量百P，下載帶寬數(shù)T，一直需要嚴重關(guān)注圖像壓縮技術(shù)的發(fā)展。本文就近幾年圖像壓縮技術(shù)的發(fā)展、新格式的出爐，和圖片存儲系統(tǒng)TPS在實際業(yè)務上的落地實踐做個簡單的介紹。以及在不斷出現(xiàn)的新格式被逐步應用之后，兼容性最好的傳統(tǒng)老格式JPEG依然地位高居不下占據(jù)大幅帶寬，如何在老格式上也繼續(xù)挖掘優(yōu)化點，是本文重點介紹的內(nèi)容。在開始介紹之前先大概總結(jié)下各個格式在兼容性、圖像大小以及編解碼性能上的優(yōu)勢和劣勢。

Webp和HEVC的面世

JPEG、PNG、GIF在互聯(lián)網(wǎng)暢行了多年后，2010年Google提出了一種新的圖片壓縮格式 — webp，給圖片壓縮優(yōu)化提供了一個新方向。Webp相比JPEG多了一個預測模式，在相同ssim得分下，有損WebP相比可減少25%~34%的大小，有損WebP也支持透明通道，大小通常約為對應PNG的1/3。

借助Webp的開放性和平臺兼容性，互聯(lián)網(wǎng)的推廣應用變得很暢順，這是webp相比JPEG2000和JPEGXR能取得成功的關(guān)鍵原因。Chrome和opera瀏覽器都支持webp，它們占據(jù)了一半的瀏覽器市場份額，另外Android系統(tǒng) 4.0以上版本也默認支持webp格式。

在這個背景下，TEG架構(gòu)平臺部圖片存儲系統(tǒng)TPS，快速推出了webp解決方案，如下圖所示。并在QQ相冊、微信朋友圈、微信公眾號、QQ看點、騰訊新聞、騰訊視頻等公司絕大多數(shù)的圖片業(yè)務開啟使用。總共節(jié)省了超過500G的帶寬，每年成本節(jié)省額度大幾千萬元。

很快，HEVC/H265到來了，它是當前最新一代的視頻編碼技術(shù)，基于該標準壓縮出來的圖片大小可降到JPEG的46%，動圖相對gif甚至可以降低到原來的20%大小，這相比webp又有了極大的提升，這個節(jié)省量可以說是相當可觀了。但相應的，它的編解碼速度相比jpg要差非常多，處理延時大同時設(shè)備資源消耗量也非常巨大。于是騰訊微信團隊和SNG音視頻團隊經(jīng)過大量研究和開發(fā)工作，分別推出了自研的性能業(yè)界領(lǐng)先的高效圖片壓縮內(nèi)核WXAM和SHARP，不犧牲壓縮的情況下，編解碼速度數(shù)倍于知名開源工程x265，甚至超過了webp。

為了進一步提升處理速度，我們甚至對它們的編碼在FPGA硬件卡進行實現(xiàn)，進一步降延時降低到了cpu的1/4以內(nèi)。

雖然WXAM/SHARP并沒有外界的瀏覽器支持，但公司內(nèi)的各大手機app都推動進行了解碼庫封裝來支持解析，圖片存儲系統(tǒng)進行適配輸出后，又一次優(yōu)化掉了將近500G的帶寬，年化收益大幾千萬。

?

JPEG優(yōu)化之路

WEBP/WXAM/SHARP紛紛落地之后，統(tǒng)計公司業(yè)務的圖片帶寬，JPEG帶寬占比仍然超過1/3。原因主要有，各類不兼容這些格式的瀏覽器、不便進行改造的app、其他不可控的第三方過來的訪問。再統(tǒng)計騰訊云的萬象優(yōu)圖產(chǎn)品的帶寬，外部業(yè)務的JPEG甚至超過了90%，終端兼容門檻始終是個很大的障礙。

那在JPEG帶寬上我們還能做些什么呢？

通常圖像處理服務在編碼JPEG圖像時會調(diào)整圖像量化表，以減少圖像的大小，即通過降低圖片質(zhì)量值的方式。我們根據(jù)不同業(yè)務要求設(shè)置不同的質(zhì)量參數(shù)，還對特定圖片做降級處理，比如二維碼為主體的圖片，降低更多質(zhì)量并不影響查看體驗。但這些畢竟還是容易肉眼可見的有損調(diào)整，于是就有了基于人眼視覺特性來對JPEG做進一步壓縮的guetzli，它可以讓JPEG圖片平均減少30%的大小。壓縮效果不比webp差，卻沒有webp的解碼端兼容性問題。

采用傳統(tǒng)方法處理圖像調(diào)整圖像質(zhì)量為85，得到處理后圖像大小為48403字節(jié)。

Libjpeg編碼圖像：進行心理視覺編碼得到圖像大小為32449字節(jié)

guetzli編碼的圖像：采用心理視覺方法編碼出的圖像，肉眼無法感知其差異，其大小是libjpeg編碼圖像的67%

基于心理視覺的方法

1.? 編碼原理

年初google發(fā)表了關(guān)于使用心理視覺來進行圖像處理的guetzli論文，在該文中描述了相關(guān)優(yōu)化的主要依據(jù)：

• 人眼錐細胞敏感光譜的重疊，RGB三個通道之間是有聯(lián)系的，黃色光會降低藍色光的敏感度，因此黃色區(qū)域附近的藍色可以使用低精度編碼

• 人眼的藍色空間分辨率低于在紅色和綠色，并在高分辨率旁邊沒有藍色的受體因此藍色的高頻變化可以使用低精度編碼

• 視覺圖像中的精細結(jié)構(gòu)依賴于附近視覺變化的量級，因此可以在有大量視覺噪音的地方使用低精度編碼

下圖展示了人眼對黃色區(qū)域附近的藍色不敏感（圖像引用自guetzli論文）

黃色背景上的hello world！文字不易被觀察，將上圖分別采用libjpeg和guetzli編碼后，將藍色通道轉(zhuǎn)換為灰度圖如下圖所示：

上半部分jpeg編碼針對黑色背景和黃色背景，藍色通道均采用相同的精度保存，而下半部分guetzli編碼藍色在黃色背景下存儲時采用低精度的編碼。

guetzli編碼圖像處理過程主要分為以下三個大的迭代過程：

• 第一次迭代，取得最優(yōu)的全局量化表

• 第二次迭代，計算每個塊中的哪些系數(shù)可供消零（低分辨率部分），且消零后視覺評價體系上圖像無差別

• 第三次迭代，將第二次迭代的消零序列，進行消零嘗試，先進行大幅度消零計算其得分和文件大小，然后根據(jù)文件大小適當回調(diào)消零的系數(shù)

因為有了這些消零的部分，使得圖像相對于原圖在編碼時產(chǎn)生更多的連續(xù)的0，這樣在進行游程編碼時能夠減少數(shù)據(jù)量。

原始處理過程：

2.? 性能優(yōu)化

Guetzli處理過程有非常多次的大小迭代，計算量極大， 加上google官方的版本未進行太多的優(yōu)化，存在大量重復計算以及流程冗余。Guetzli單圖計算消耗，相比jpeg編碼高出兩個數(shù)量級，呈百倍關(guān)系。處理延時遠遠超出在線使用的可承受范圍，更關(guān)鍵的是，設(shè)備消耗過大。按分辨率500x500的圖片來看，平均處理一張延時10秒以上，單圖必須被下載1000次節(jié)省下帶寬成本才能抵消一次的處理設(shè)備成本消耗。隨著圖片分辨率增大，延時上升到分鐘級甚至小時級別，非常驚人。

為了能夠在現(xiàn)網(wǎng)應用，需要對算法進行移植改造提升其處理速度。圖像處理的過程中的很多計算是可以并行的，那么利用GPU來并行化加速處理，很自然的成為了我們的解決思路。和SNG增值產(chǎn)品部開發(fā)運維團隊組成公司圖片業(yè)務的Guetzli落地推廣的聯(lián)合項目：實現(xiàn)了算法優(yōu)化改造，并線下進行了千萬級別的圖片測試驗證，確定了機器選型和資源調(diào)度上線。這里的主要優(yōu)化和效果如下：

• Jpeg圖像采樣方式較多，而官方版本僅支持420與444采樣格式，為支持所有的采樣，我們在應用中擴展了圖像編解碼函數(shù)，采用libjpeg-turbo進行圖像數(shù)據(jù)解碼，完整支持所有jpeg采樣，同時ibjpeg-turbo相對于libjpeg在編解碼上做了一定的優(yōu)化，能夠提升解碼過程的性能。

• 由于視覺評價體系中大量計算是分別針對圖像三個通道進行處理，同時也會將圖像按照不同的塊進行分割計算以及圖像卷積操作，單個塊或者通道計算量大，所有塊或通道需要重復上百萬次計算，計算過程完全相同且塊與塊之間的計算相對獨立不會有相互的影響。那么這些計算過程能夠并行，我們擴展了butteraugli視覺評價體系，將這些繁復可并行的計算全部移植到GPU上能大幅減少計算延遲。

• 在第二次迭代計算可供消零的系數(shù)過程中，當消零后的圖像誤差超過了允許的全局誤差之后，后續(xù)的可供消零序列將變得不再有意義，我們將計算過程提前終止掉，這樣去除了后續(xù)大量的無效冗余運算，從計算流程上減少了編碼延遲。
  

• 算法實現(xiàn)中大量采用雙精度進行計算，我們支持將雙精度調(diào)整為單精度加速計算過程，減少雙精度帶來的大量性能消耗，不過由于精度上的損失會使得輸出結(jié)果與官方工具有些差異，但是精度的損失反映到圖像上的影響微乎其微。

• 由于圖像大小在一定的范圍內(nèi)波動，圖像數(shù)據(jù)通常在數(shù)百KB內(nèi)波動，圖像需要連續(xù)的內(nèi)存、顯存空間，那么優(yōu)化內(nèi)存、顯存使物理內(nèi)存空間上連續(xù)能夠提高內(nèi)存讀寫速度。利用tcmalloc替換glibc的內(nèi)存管理，提升主機端內(nèi)存訪問性能。應用內(nèi)池化顯存能夠減少設(shè)備驅(qū)動的調(diào)用，提升圖像大數(shù)據(jù)塊的分配和釋放性能。這樣優(yōu)化后能夠減少內(nèi)存和顯存的碎片、由于內(nèi)存連續(xù)也提高了訪問性能。

• 在計算處理過程中有許多冗余函數(shù)來生成固定的參數(shù)序列，將這些函數(shù)合并或預處理展開后減少計算流程上的函數(shù)調(diào)用冗余。

• 從主機內(nèi)存到設(shè)備顯存的數(shù)據(jù)拷貝是需要經(jīng)過PCIE總線，數(shù)據(jù)拷貝帶寬受到GPU物理布局方式以及PCIE總線帶寬兩方面的影響，那么針對一些較小分辨率的圖像，為了平衡傳輸延遲和計算延遲，我們按圖像分辨率將計算拆分，圖像大于某一分別率之后計算延遲遠遠超過傳輸延遲時，這部分計算轉(zhuǎn)移至GPU上進行，否則在CPU上完成計算。

• 現(xiàn)網(wǎng)實際應用中，在GPU上提供異構(gòu)計算服務時同樣有一些需要注意的地方，為了避免GPU空閑時驅(qū)動程序釋放設(shè)備導致新應用啟動時長過長，我們需要將設(shè)備持久化保持在驅(qū)動程序中。

• 為了避免在GPU上部署應用時創(chuàng)建GPU Context的性能開銷，應用應該僅在啟動時創(chuàng)建GPU Context后續(xù)所有計算均在同一Context上使用不同的流來完成。合理的使用流能夠有效提升GPU吞吐。

• 圖像處理過程對GPU設(shè)備的利用是一個波動的狀態(tài)，而單個進程通常不能完全有效的利用GPU，為了提升GPU利用率，提升編碼集群的吞吐量，需要部署多個應用進程綁定到同一GPU，具體綁定數(shù)量需要考慮顯存大小與實際應用的GPU利用率。

改造后的平均處理延時下降到原來的10%以內(nèi)，下圖GI1和G6代表改造的庫跑在GPU設(shè)備上的延時，M10表示改造前的官方庫的延時。

?

3.? 業(yè)務落地

經(jīng)過上述改造后，已經(jīng)有望上線服務業(yè)務了。我們對當前圖片平臺架構(gòu)做了部分調(diào)整：采用異步壓縮，持久化存儲，控制CDN緩存時間的方式來貼合業(yè)務使用。基本架構(gòu)如下圖所示：

guetzli下載架構(gòu)

1. 源站需要根據(jù)當前圖像的格式以及緩存時間靈活的設(shè)置CDN緩存時間

2. 編碼集群要根據(jù)其處理能力和請求時間合理的處理請求

下載流程如下：

guetzli下載流程

1. 當緩存命中后，需要判斷緩存圖像是否已經(jīng)編碼過，若在編碼周期內(nèi)，則向CDN前端返回臨時緩存。否則返回持久緩存

2. 若緩存沒有命中，則從存儲系統(tǒng)中查詢落地的編碼圖像，若落地圖像不存在，則將原圖返回給CDN設(shè)置臨時緩存，同時異步發(fā)起圖像編碼。若已存在則直接將圖像返回給CDN且持久緩存

4.? 業(yè)務落地現(xiàn)狀

針對當前webp/wxam/sharpp無法覆蓋的場景，采用心理視覺的圖像處理方法，能夠在保證圖像質(zhì)量的前提下，大幅減少圖像大小，節(jié)省用戶流量并提升下載體驗。上述方案已經(jīng)在QQ增值業(yè)務、騰訊視頻、QQ音樂、QQ看點、LOL視頻官網(wǎng)中心等業(yè)務上進行了應用，騰訊視頻、微信公眾號、頭像等適合落地的圖片業(yè)務也在測試中。騰訊云的萬象優(yōu)圖產(chǎn)品，也可以在控制臺一鍵開啟。

這些優(yōu)化紛紛落地后，總共節(jié)省上T的帶寬，用戶下載延時減少20%以上。未來還會有更多的發(fā)展。2017下半年IPhone又新推出了HEIF格式，并對iphone7以上支持硬編解，讓IOS對hevc的兼容提供了重大便利，隨著ios11的普及，預計未來眾多圖片業(yè)務會朝著heif格式收攏。圍繞節(jié)省用戶和服務器帶寬，以及提升用戶下載體驗的目標，我們會繼續(xù)前行，讓帶寬壓到最小，讓圖片越來越清晰。

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的如何节省1T图片带宽？解密极致图像压缩！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。