??想了解更多內(nèi)容，請訪問：??

??51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)??

??https://ost.51cto.com??

【本期看點】

• 讓你意想不到的 PNG 工作方式。
• 詳解 MPEG 十八代隱秘關(guān)系。
• AV1 | H.266 王座之戰(zhàn)，誰才是最終贏家。
• 不妨走走未曾設(shè)想的醫(yī)學(xué)道路。
• 細(xì)胞神經(jīng)網(wǎng)絡(luò)也可以很瘋狂。
• 懂了!原來這就是人眼視覺系統(tǒng)(HVS)。

【技術(shù)DNA】

【智慧場景】

無損壓縮

LZ 編碼的應(yīng)用

概述

最流行的 LZ 算法實現(xiàn)是最初由 Phil Katz 設(shè)計 的 deflate 算法。Deflate 是一種無損數(shù)據(jù)壓縮算法，使用 LZ 算法和霍夫曼編碼的組合，它是由 Jean-loup Gailly 和 Mark Adler 開發(fā)的流行 zlib庫 的一部分。 Jean-loup Gailly 也在廣泛使用的 gzip 算法中使用 deflate。deflate 算法也被用于 PNG 圖像格式。

歷史

1. UNIX compress 命令

是 LZW 最早的應(yīng)用之一。字典的大小是可以適應(yīng)的。我們從大小為 512 的字典開始。 這意味著傳輸?shù)拇a字長度為 9 位。一旦字典填滿，字典的大小將增加一倍，達(dá)到 1024 個條目。此時傳輸?shù)拇a字有 10 位。字典越填越大，其大小逐漸增加一倍。通過這種方式，在編碼過程的前一部分，當(dāng)字典中的字符串不是很長時，用來編碼它們的碼字也會有更少的位。碼字的最大大小 bmax 可由用戶到 9 到 16 之間，16 位是默認(rèn)值。一旦字典包含 2bmax 條目，壓縮就成為一種靜態(tài)字典編碼技術(shù)。此時，算法監(jiān)視壓縮比。如果壓縮比低于閾值，則將刷新字典，并重新啟動字典構(gòu)建過程。這樣，詞典總是反映了源的地方特征。

2. 圖像壓縮 png 格式

它是如何工作的?

• 好問題!上傳 PNG(可移植網(wǎng)絡(luò)圖形)文件時，圖像中的相似顏色將組合在一起。這種技術(shù)稱為“量化”。通過減少顏色數(shù)量，24 位 PNG 文件可以轉(zhuǎn)換為小得多的 8 位索引彩色圖像。所有不必要的元數(shù)據(jù)也被剝離。結(jié)果更好的PNG文件，100%支持透明度。
• 在上圖中，文件大小減小了70%以上。我有極好的視力，但也無法發(fā)現(xiàn)差異!使用優(yōu)化的圖像來節(jié)省帶寬和加載時間。

PNG 標(biāo)準(zhǔn)是在互聯(lián)網(wǎng)上開發(fā)的第一個標(biāo)準(zhǔn)之一。它的開發(fā)動機(jī)是 Unisys(它已經(jīng)從 Sperry 那里獲得了 LZW 的專利)和 CompuServe 在 1994 年 12 月的一項聲明，他們將開始向支持 GIF 的軟件作者收取版稅。這一聲明導(dǎo)致了數(shù)據(jù)壓縮領(lǐng)域的一場革命，而這場革命正是 Usenet 壓縮組的核心。社區(qū)決定開發(fā)一個無專利的 GIF 替代品，三個月內(nèi)，PNG 誕生了。(了解更多關(guān)于 PNG 和軟件的詳細(xì)歷史，請訪問由 Greg Roelof 維護(hù)的 PNG 網(wǎng)站http://www.libpng.org/pub/png/。)

創(chuàng)建 PNG 格式的動機(jī)是，1994 年 12 月 28 日，Unisys 獲得了 Unisys 頒發(fā)的專利，即圖形交換格式 GIF 中使用的 Lempel–Ziv-Welch (LZW) 數(shù)據(jù)壓縮算法。該專利要求所有支持GIF的軟件支付版稅，導(dǎo)致Usenet用戶的批評。

其中一位是Thomas Boutell，他于1995年1月4日在Usenet新聞組"comp.graphics"上發(fā)布了一個前身討論線程，其中他設(shè)計了一個免費替代GIF的計劃。流行的JPEG查看器QPEG的作者 Oliver Fromme 提出了 PING 名稱，最終成為PNG，便攜式網(wǎng)絡(luò)圖形(PNG)格式旨在取代較舊，更簡單的 GIF 格式，并在某種程度上取代更復(fù)雜的 TIFF 格式。PNG is Not GIF.

后來實現(xiàn)的其他建議包括Deflate壓縮算法和24位顏色支持，GIF中缺乏后者也激勵團(tuán)隊創(chuàng)建他們的文件格式。該小組后來被稱為PNG開發(fā)小組，隨著討論的迅速擴(kuò)大，它后來使用了與 CompuServe 論壇相關(guān)的郵件列表。[2][8]

.png

PNG的完整規(guī)范于1996年10月1日在W3C的批準(zhǔn)下發(fā)布，后來于1997年1月15日作為 RFC 2083 發(fā)布。該規(guī)范于1998年12月31日修訂為1.1版，解決了伽馬和色彩校正的技術(shù)問題。1999年8月11日發(fā)布的1.2版增加了該塊作為規(guī)范的唯一變化，1.2的重新格式化版本于2003年11月10日作為W3C標(biāo)準(zhǔn)的第二版發(fā)布[9]，并于2004年3月3日作為國際標(biāo)準(zhǔn)(ISO/IEC 15948：2004)發(fā)布。[10][1]

iTXt

雖然GIF允許動畫，但決定PNG應(yīng)該是單圖像格式。

2001年，PNG的開發(fā)者發(fā)布了多圖像網(wǎng)絡(luò)圖形 MNG 格式，支持動畫。MNG實現(xiàn)了適度的應(yīng)用程序支持，但在主流Web瀏覽器中還不夠，并且在網(wǎng)站設(shè)計者或發(fā)布者中沒有使用。

2008年，某些Mozilla開發(fā)人員發(fā)布了具有類似目標(biāo)的動畫便攜式網(wǎng)絡(luò)圖形 APNG 格式。APNG 是一種基于 Gecko 和 Presto 的Web瀏覽器本機(jī)支持的格式，也常用于索尼 PlayStation Portable 系統(tǒng)上的縮略圖(使用正常的PNG文件擴(kuò)展名)。

2017年，基于 Chromium 的瀏覽器采用了 APNG 支持。2020年1月，Microsoft Edge 開始基于 Chromium ，從而繼承了對 APNG 的支持。有了這個，所有主流瀏覽器現(xiàn)在都支持 APNG 。

圖像壓縮 gif 格式

圖形交換格式(GIF) 是由 Compuserve 信息服務(wù)公司開發(fā)的，用于對圖形圖像進(jìn)行編碼。它是 LZW 算法的另一種實現(xiàn)，非常類似于 Unix 中的 compress 命令。

GIF圖像使用 Lempel-Ziv-Welch(LZW) 無損數(shù)據(jù)壓縮技術(shù)進(jìn)行壓縮，以減小文件大小而不會降低視覺質(zhì)量。雖然 GIF 不是作為動畫媒介設(shè)計的，但它在一個文件中存儲多個圖像的能力自然建議使用這種格式來存儲動畫序列的幀。

為了便于顯示動畫，GIF89a規(guī)范添加了圖形控制擴(kuò)展(GCE)，該擴(kuò)展允許以時間延遲繪制文件中的圖(幀)，從而形成視頻剪輯。動畫 GIF 中的每個幀都由其自己的 GCE 引入，該 GCE 指定在繪制幀后等待的時間延遲。默認(rèn)情況下，動畫僅顯示一次幀序列，并在顯示最后一幀時停止。

為了使動畫能夠循環(huán)播放，Netscape 在 20 世紀(jì) 90 年代使用應(yīng)用程序擴(kuò)展塊(旨在允許供應(yīng)商將特定于應(yīng)用程序的信息添加到 GIF 文件中)來實現(xiàn) Netscape 應(yīng)用程序塊(NAB)。

這個塊放置在動畫幀序列之前，指定幀序列應(yīng)該被播放的次數(shù)(1到65535次)或它應(yīng)該連續(xù)重復(fù)(0表示永遠(yuǎn)循環(huán))。對這些重復(fù)動畫的支持首先出現(xiàn)在 Netscape Navigator 2.0 版本中，然后擴(kuò)展到其他瀏覽器。大多數(shù)瀏覽器現(xiàn)在都能識別并支持NAB，盡管它并不是GIF89a規(guī)范的嚴(yán)格組成部分。

場景

2014年4月，4chan 增加了對大小小于3MB、長度小于2分鐘的無聲 WebM 視頻的支持 [70][71]，2014年10月，Imgur 開始將上傳到該網(wǎng)站的所有GIF文件轉(zhuǎn)換為視頻，并為HTML播放器的鏈接提供帶有擴(kuò)展名的實際文件的外觀。[72]73

聊完了GIF，我們再回到PNG。

壓縮

PNG 使用 2 級壓縮過程：

• 預(yù)壓縮：過濾(預(yù)測)
• 壓縮：放氣

過濾

在應(yīng)用 Deflate 之前，通過預(yù)測方法轉(zhuǎn)換數(shù)據(jù)。當(dāng)前 PNG 規(guī)范中只有一種篩選器方法(表示為方法 0)，因此在實踐中，唯一的選擇是將哪種篩選器類型應(yīng)用于每行。對于此方法，篩選器根據(jù)先前相鄰像素的值預(yù)測每個像素的值，并從實際值中減去像素的預(yù)測顏色。

放氣

PNG 使用 DEFLATE，這是一種非專利的無損數(shù)據(jù)壓縮算法，涉及LZ77和霍夫曼編碼的組合。許可DEFLATE實現(xiàn)，如 zlib ，是廣泛使用的。

與具有有損壓縮的格式(如 JPEG)相比，選擇高于平均值的壓縮設(shè)置會延遲處理，但通常不會導(dǎo)致文件大小明顯變小。

編程接口

Deflate可以免費在很多編程語言中使用。C語言通常使用zlib庫。C++語言可以使用7-Zip/AdvanceCOMP。Java語言包含在標(biāo)準(zhǔn)庫java.util.zip中。Microsoft .NET Framework 2.0包含在System.IO.Compression命名空間中。

• PKZIP：該算法最早的實現(xiàn)。
• zlib / gzip：標(biāo)準(zhǔn)參考實現(xiàn)(standard reference implementation)，由于其公共可用性，得到了及其廣泛的使用。
• Crypto++：C++開源實現(xiàn)。
• 7-Zip/AdvanceCOMP：Igor Pavlov的C++開源自由實現(xiàn)
• PuTTY: 一份單獨實現(xiàn)
• Hyperbac：C++與匯編實現(xiàn)
• Zopfli：Google的C實現(xiàn)

衍生產(chǎn)品

MNG

PNG 本身不支持動畫。MNG 是 PNG 的擴(kuò)展，MNG 共享 PNG 的基本結(jié)構(gòu)和塊，但它要復(fù)雜得多，并且具有不同的文件簽名，這會自動使其與標(biāo)準(zhǔn) PNG 解碼器不兼容，這導(dǎo)致 MNG 幾乎不支持或大多數(shù) Web 瀏覽器或應(yīng)用程序。

APNG

MNG的復(fù)雜性導(dǎo)致了Mozilla基金會開發(fā)人員提出APNG。

它基于 PNG，支持動畫，比 MNG 更簡單。今天，APNG 格式目前被所有主要的 Web 瀏覽器廣泛支持。在 Firefox 3.0 及更高版本，Pale Moon(所有版本)中支持APNG，最新版本的 Opera 支持 APNG，因為引擎已更改為 Blink、iOS 8 和 Safari 8 for OS X Yosemite 上的最新版本的 Safari，它們使用支持 APNG 的 WebKit 引擎。Chromium 59.0 增加了對 APNG 的支持，緊隨其后的是谷歌 Chrome 瀏覽器。Microsoft Edge 現(xiàn)在通過基于 Chromium 的新引擎支持 APNG。

有損壓縮

有損壓縮即指原始信息序列中的一些信息丟失的壓縮，這便意味著原始信息一經(jīng)有損壓縮過程操作后，不能再由生成的序列重新還原而得到。在此之前，多數(shù)朋友潛意識里可能會默認(rèn)有損壓縮的意義是相比無損壓縮，為了實現(xiàn)更好的壓縮比，致使對相同源數(shù)據(jù)操作后，得到的結(jié)果質(zhì)量相對會更差。其實呢，并非如此——舉個常見的例子：對同一元圖像，對其均按100%質(zhì)量存儲，得到的jpg格式大小可能是4M左右，而png格式大小卻達(dá)到了40M。

那么，jpg相比png少的幾十M大小的數(shù)據(jù)究竟是什么呢? 其中，除舍棄的部分人眼不可察覺的顏色位之外，還包括大多數(shù)要還原回元圖像所需的必需數(shù)據(jù)。因此，信息丟失并不意味著輸出質(zhì)量降低。但，大多數(shù)有損壓縮技術(shù)的使用方式高度依賴于被壓縮的媒體，就像音頻的有損壓縮與圖像的有損壓縮十分不同。

多媒體場景中的圖像視頻壓縮

多媒體圖像如今已然成為日常生活中不可獲缺的組成部分。圖像中編碼的信息量是相當(dāng)大的，即便帶寬和存儲能力方面有了長足的進(jìn)步，但若不對圖像進(jìn)行壓縮，許多應(yīng)用的成本仍然會較高。

JPEG和相關(guān)的MPEG格式是多媒體壓縮的典型范例，它們均在實踐中被廣泛應(yīng)用，同時也使用了諸如Huffman碼、算術(shù)編碼、游程編碼、標(biāo)量量化等技術(shù)。

其中，JPEG用于靜態(tài)圖像，在網(wǎng)絡(luò)上被作為攝影圖像的標(biāo)準(zhǔn);MPEG是基于JPEG的一種變體，用于視頻編碼(每一幀都使用JPEG的變體編碼)。二者均為有損格式。

發(fā)展進(jìn)程

目前，視頻編碼方式主要分為三大系列：

H.26x系列(由ITU[國際電傳視訊聯(lián)盟]主導(dǎo))，包括H.261、H.262、H.263、H.264、H.265、H.266…

MPEG系列(由ISO[國際標(biāo)準(zhǔn)組織機(jī)構(gòu)]下屬的MPEG[動態(tài)圖像專家組]開發(fā))，包括MPEG-1、MPEG-2、MPEG-4、MPEG-7、MPEG-21…

其他系列，包括AMV、AVS、Bink、CineForm、Cinepak、Dirac、DV、Indeo、Video、Pixlet、RealVideo、RTVideo、SheerVideo、Smacker、Sorenson Video、Theora、VC-1、VP3、VP6、VP7、VP8、VP9、WMV…

基礎(chǔ)格式

① JPEG

JPEG是聯(lián)合攝影專家組開發(fā)的圖像壓縮標(biāo)準(zhǔn)，目的是在不影響圖像質(zhì)量的情況下盡可能減少自然的、像照片一樣的真彩圖像(每個像素值都分成R、G、B三個基色分量，每個基色分量直接決定其基色的強(qiáng)度)的文件大小，但它不能很好地處理雙層(黑白)圖像，也不能處理偽彩色圖像(將實際是索引值的每個像素值作為色彩查找表CLUT中相應(yīng)項的入口地址，再根據(jù)該地址查找出實際R、G、B的強(qiáng)度值)。JPEG在“連續(xù)色調(diào)”圖像上效果最好，若是有許多跳躍的色值則效果不太好。

基本步驟

顏色空間轉(zhuǎn)換：

若顏色分量是獨立不相關(guān)的，便可以獲得最好的壓縮效果。因此，這一步主要是通過線性變換將RGB分量轉(zhuǎn)換為信息集中分布在亮度而非色度上的YCbCr分量模式。

色度采樣(可選)：

利用YCbCr的特性，去除一些Cb和Cr元素，即可在這一步取得初步的壓縮效果。如，將RGB為4:4:4的格式轉(zhuǎn)換為YCbCr為4:2:2的格式，便獲得了壓縮比為 12/8=1.5 的壓縮效果。

離散余弦變換(DCT)：

這一步，將YCbCr的每個分量轉(zhuǎn)換成一個領(lǐng)域表示，以便后續(xù)操作。

量化：

JPEG編碼簡單將頻域中的每個分量除以一個常量，經(jīng)過一番四舍五入。結(jié)果是，許多高頻的分量被四舍五入為了零，其余大部分分量則變成了較小的正數(shù)或負(fù)數(shù)，只需要更少的位進(jìn)行存儲。因此，整個過程中主要的有損操作都在這一步完成。

熵編碼：

詳見《??輕翻那些永垂不朽的詩篇??》中相關(guān)內(nèi)容。

② MPEG

MPEG全稱動態(tài)圖像專家組。理論上，因為視頻流是離散圖像序列，MPEG則使用這些連續(xù)幀之間的特殊或時間關(guān)系壓縮視頻流。基于之前許多方法，可見，一種技術(shù)越能有效利用一段數(shù)據(jù)中的某些關(guān)系，數(shù)據(jù)壓縮的效果便越好。

MPEG標(biāo)準(zhǔn)主要有五個，MPEG-1、MPEG-2、MPEG-4、MPEG-7及MPEG-21。其委員會組建于1988年，專門負(fù)責(zé)為CD制定視頻和音頻標(biāo)準(zhǔn)。第一個公開標(biāo)準(zhǔn)是MPEG-1, ISO/IEC 11172，于 1993 年首次發(fā)布。

MPEG算法只對視頻幀序列的新生部分和運動部分的信息進(jìn)行編碼，如下圖三個序列中的小人便是MPEG編碼壓縮時需要考慮的范疇。

基本應(yīng)用

下一代格式

隨著互聯(lián)網(wǎng)的數(shù)字視頻消費的持續(xù)增長，包括UHD、VR和流媒體等服務(wù)，以及社交網(wǎng)絡(luò)的視頻分享，電信基礎(chǔ)設(shè)施的可用帶寬正在接受挑戰(zhàn)。AV1和H.266是新一代視頻格式，將被廣泛應(yīng)用從而應(yīng)對以上問題。

③ AV1

開放媒體聯(lián)盟(AOMedia)于2015年成立，作為一個開發(fā)開放、免版稅的多媒體交付技術(shù)的聯(lián)盟。其在2018年發(fā)布了第一個視頻壓縮格式AV1，《??AV1 Video Codec | Alliance for Open Media??》，比其前身VP9的壓縮能力增強(qiáng)了約30%。AV1格式已經(jīng)得到了許多網(wǎng)絡(luò)平臺的支持，包括安卓、Chrome、微軟Edge和火狐，以及多個基于網(wǎng)絡(luò)的視頻服務(wù)提供商，包括YouTube、Netflix、Vimeo，已經(jīng)開始大規(guī)模推出AV1流媒體服務(wù)。

優(yōu)點

1. 免收專利費。
2. 與VP9和H.265相比，有著明顯的編碼效率提升。

Source: Graphics & Media Lab Video Group, Moscow State University。

從圖中可以看到，相較于VP9與H.265，AV1編碼效率有近30%的提升。

編碼質(zhì)量測試

為了驗證AV1的編碼效果，使用Youtube提供的分別為480p、720p、1080p、4K的VP9編碼格式和480p、720p、1080p的AV1編碼格式??視頻樣本??進(jìn)行測試。

由于目前支持硬解AV1編碼的GPU芯片較少，只能依靠軟解，因此在實際測試AV1視頻播放時較為卡頓。

上圖分別取自1080P分辨率下AV1與VP9的表現(xiàn)效果。可以看出，AV1比VP9擁有更好的清晰度。

結(jié)論

對比VP9，AV1擁有更好的編碼效率，其普及對于流視頻具有重要意義，用戶可在帶寬及消耗流量不變的情況下觀看畫面質(zhì)量更清晰的視頻。

④ H.266

簡稱 H.266 的通用視頻編碼(Versatile Video Coding，VVC)，由德國弗勞恩霍夫海因里希赫茲研究所(Fraunhofer HHI)于2020年7月正式發(fā)布。

該新一代MPEG視頻標(biāo)準(zhǔn)由國際電聯(lián)(ITU-T)和國際標(biāo)準(zhǔn)化組織(ISO)聯(lián)合開發(fā)，過去三年，包括蘋果、愛立信、英特爾、華為、微軟、高通、索尼等在內(nèi)的企業(yè)，一直在努力推動這項新技術(shù)的發(fā)展。

與簡稱 H.265 的高效視頻編碼(High Efficiency Video Coding, HEVC)前身一樣，H.266有望將視頻文件的比特率和大小降低 50% 左右，同時不會在視覺保真度上產(chǎn)生明顯的差異，主要面向4K、8K服務(wù)。簡單來說，基于H.265編碼的一段90分鐘UHD 4K視頻需要10GB左右，而基于 H.266 則僅需5GB。

與AV1的爭奪戰(zhàn)

隨著全球互聯(lián)網(wǎng)視頻需求的增長，MPEG 正在推動 H.266 / VCC 及其它兩個標(biāo)準(zhǔn)的發(fā)展。其中 MPEG-5 Part 1又被稱作基礎(chǔ)視頻編碼(Essential Video Coding，EVC)，由華為、高通、三星等企業(yè)牽頭制定;Part 2又被稱作低復(fù)雜度增強(qiáng)視頻編碼(LCEVC)。在2020年5月，EVC)編碼標(biāo)準(zhǔn)正式被提升為最終國際標(biāo)準(zhǔn)(FDIS)狀態(tài)。

因此，MPEG 的此番發(fā)力，與免專利費的 AV1 開放標(biāo)準(zhǔn)所帶來的強(qiáng)大競爭有直接關(guān)系。

英國廣播公司(BBC)研發(fā)部門去年進(jìn)行的初步測試顯示，VVC 的成績很是鼓舞人心，因為新標(biāo)準(zhǔn)較 HEVC 和 AV1 節(jié)省了大量的比特率，尤其是在 4K UHD 文件的支持上。

??想了解更多內(nèi)容，請訪問：??

??51CTO和華為官方合作共建的鴻蒙技術(shù)社區(qū)??

??https://ost.51cto.com??