[{"data":1,"prerenderedAt":562},["ShallowReactive",2],{"\u002Fposts\u002Fhow-we-record-pictures":3,"surround:\u002Fposts\u002Fhow-we-record-pictures":553},{"id":4,"title":5,"body":6,"createdAt":545,"description":15,"extension":546,"meta":547,"navigation":548,"path":549,"seo":550,"stem":551,"__hash__":552},"posts\u002Fposts\u002F2022\u002Fhow-we-record-pictures.md","我们是如何记录图片的",{"type":7,"value":8,"toc":536},"minimark",[9,12,16,21,24,27,38,46,62,65,68,72,83,89,100,157,165,168,171,174,178,181,188,193,198,201,216,221,224,227,232,235,242,246,260,277,300,307,312,319,322,327,330,333,336,340,343,348,368,375,386,391,398,403,406,410,417,420,427,429,432,437,443,458,461,466,473,476,480,483,486,504,507,516,521,526,529,532],[10,11,5],"h1",{"id":5},[13,14,15],"p",{},"作为 Web 开发者，我们不可避免地经常与不同的图片格式打交道。比如我们可能都会知道 PNG 可以支持透明度，jpg 可以压缩到较低的质量，而 gif 则可以显示动图……但是，你知道这些不同的图片格式是如何产生的、并且演进至今的吗？",[17,18,20],"h2",{"id":19},"origin","起源",[13,22,23],{},"最早的图片格式如今已经不可考证，但可以肯定的是，从计算机诞生之初，数字图片就已经存在了，正如早在没有计算机时我们就创造了“杨辉三角”这样的图形。不过在互联网诞生之后，由于信息（biao qing bao）传递的效率飞速提升，我们才有了更多机会看到数字图片格式的发展。",[13,25,26],{},"1982 年，随着网络社交的开始，互联网上开始出现了一种被称为 ASCII Art 的艺术形式。人们开始使用一些字符来构成一些复杂的图形：",[28,29,34],"pre",{"className":30,"code":32,"language":33},[31],"language-text"," ██████╗ ██████╗ ███╗   ███╗███╗   ███╗ █████╗ ███████╗\n██╔════╝██╔═══██╗████╗ ████║████╗ ████║██╔══██╗██╔════╝\n██║     ██║   ██║██╔████╔██║██╔████╔██║███████║███████╗\n██║     ██║   ██║██║╚██╔╝██║██║╚██╔╝██║██╔══██║╚════██║\n╚██████╗╚██████╔╝██║ ╚═╝ ██║██║ ╚═╝ ██║██║  ██║███████║\n ╚═════╝ ╚═════╝ ╚═╝     ╚═╝╚═╝     ╚═╝╚═╝  ╚═╝╚══════╝\n","text",[35,36,32],"code",{"__ignoreMap":37},"",[13,39,40,41,45],{},"这实际上就是一种非常直观的计算机图片存储方式：在上面这张图里，我们可以把每一个单元格看成是显示屏幕的一个光学元件。当这些光学元件展示一张图片时，有些可能不发光（对应上面的空白部分），有些可能具有不同的颜色（对应上面的 █ 或者 ║）。通过这种方式，我们用一种非常符合计算机直觉的“编码”保存了这张图片——这里我不妨将其命名为 ",[42,43,44],"em",{},"Commas 编码"," 吧。",[13,47,48,49,53,54,57,58,61],{},"通过 Commas 编码，",[50,51,52],"strong",{},"我们只需要保存一个二维数组，对应图中的不同位置，在数组的每一项记录对应的字符（颜色）","。这就是我们现在看到的绝大多数图片的保存方式：",[50,55,56],{},"点阵图","，或者用术语来描述：",[50,59,60],{},"位图","。",[13,63,64],{},"如果使用我们上面描述的方式保存这张图片，它的存储效率是怎样的呢？",[13,66,67],{},"没错，实际上上面的代码块就是图片文件本身！因为我们用了 Unicode 而非二进制的方式保存，它的像素数是 55*6，每一个像素需要用一个 Unicode 字符存储。假设我们使用 UCS-2 编码，则这张图片使用我们的编码方式需要 660B 的存储空间。",[17,69,71],{"id":70},"pnm","PNM: 色彩与二进制",[13,73,74,75,78,79,82],{},"在真实的计算机世界里，真的有像 Commas 编码这种图片格式吗？事实上还真有。在万维网还没有诞生的年代，就已经有了一种用于电子邮件传输的图片格式，它叫做 PBM（Portable BitMap）。在现在，它使用 ",[35,76,77],{},".pbm"," 后缀和 ",[35,80,81],{},"image\u002Fx‑portable‑bitmap"," MIME 类型。",[13,84,85],{},[86,87],"img",{"alt":37,"src":88},"https:\u002F\u002Fthumb.wikimedia.org\u002Fwikipedia\u002Fcommons\u002Fthumb\u002F1\u002F15\u002F50x50x1b.svg\u002F250px-50x50x1b.svg.png",[13,90,91,92,95,96,99],{},"PBM 是一种",[50,93,94],{},"单色图片","，这意味着它只有黑色和白色两种颜色，在游戏美术中这通常被称为 ",[50,97,98],{},"1-bit","。在存储时，我们可以使用 0 和 1 代表黑白两种颜色。比如上面的 COMMAS 图片，如果用 PBM 它的编码方式如下：",[28,101,105],{"className":102,"code":103,"language":104,"meta":37,"style":37},"language-pbm shiki shiki-themes material-theme-lighter material-theme material-theme-palenight","P1\n# This is comment\n55 6\n0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 0 0 1 1 1 0 0 0 0 1 1 1 0 1 1 1 0 0 0 0 1 1 1 0 0 1 1 1 1 1 0 0 1 1 1 1 1 1 1 0\n1 1 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 0 0 0 1 1 0 1 1 0 0 0 0 0 0\n1 1 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 1 1 0 1 1 1 1 0 1 1 0 1 1 0 1 1 1 1 0 1 1 0 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 0\n1 1 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 1 1 0 0 1 1 0 0 1 1 0 1 1 0 0 1 1 0 0 1 1 0 1 1 0 0 0 1 1 0 0 0 0 0 0 1 1 0\n0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 0 0 1 1 0 0 0 0 0 0 1 1 0 1 1 0 0 0 0 0 0 1 1 0 1 1 0 0 0 1 1 0 1 1 1 1 1 1 1 0\n","pbm",[35,106,107,115,121,127,133,139,145,151],{"__ignoreMap":37},[108,109,112],"span",{"class":110,"line":111},"line",1,[108,113,114],{},"P1\n",[108,116,118],{"class":110,"line":117},2,[108,119,120],{},"# This is comment\n",[108,122,124],{"class":110,"line":123},3,[108,125,126],{},"55 6\n",[108,128,130],{"class":110,"line":129},4,[108,131,132],{},"0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 0 0 1 1 1 0 0 0 0 1 1 1 0 1 1 1 0 0 0 0 1 1 1 0 0 1 1 1 1 1 0 0 1 1 1 1 1 1 1 0\n",[108,134,136],{"class":110,"line":135},5,[108,137,138],{},"1 1 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 1 1 0 0 1 1 1 1 0 1 1 0 0 0 1 1 0 1 1 0 0 0 0 0 0\n",[108,140,142],{"class":110,"line":141},6,[108,143,144],{},"1 1 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 1 1 0 1 1 1 1 0 1 1 0 1 1 0 1 1 1 1 0 1 1 0 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 0\n",[108,146,148],{"class":110,"line":147},7,[108,149,150],{},"1 1 0 0 0 0 0 0 1 1 0 0 0 0 1 1 0 1 1 0 0 1 1 0 0 1 1 0 1 1 0 0 1 1 0 0 1 1 0 1 1 0 0 0 1 1 0 0 0 0 0 0 1 1 0\n",[108,152,154],{"class":110,"line":153},8,[108,155,156],{},"0 1 1 1 1 1 1 0 0 1 1 1 1 1 1 0 0 1 1 0 0 0 0 0 0 1 1 0 1 1 0 0 0 0 0 0 1 1 0 1 1 0 0 0 1 1 0 1 1 1 1 1 1 1 0\n",[13,158,159],{},[42,160,161,162,164],{},"你可以将它保存为一个 ",[35,163,77],{}," 文件，并利用 macOS 的图片查看器查看它",[13,166,167],{},"比起 Commas 编码，PBM 失去了表达颜色的能力，但多了注释结构。不过单色显然是无法满足我们发送表情包的需要的，至少连黑白电视也是支持不同亮度的黑色的。为了让 PBM 支持灰度，我们可以将 0 和 1 扩展为 0-255，这就是 PGM；更进一步地，我们还可以用 255 255 255 来将每个像素扩展为真彩色，也就是我们熟悉的 RGB 编码，这就是 PPM。在 PBM 开头的 P1 就起到了描述编码的作用，P1 P2 和 P3 分别代表 PBM、PGM 和 PPM 三种格式，他们被统称为 PNM。",[13,169,170],{},"现在，我们来考虑一下存储空间吧。PBM 使用 ASCII 明文存储，上面的图片文本长度是 575，因此它占用 575B。当然我们还可以进一步压缩，在去除注释后，它的长度是 557B，但也仅限于此了；如果使用支持色彩的 PPM，每个像素可能要占 11 个文本长度，于是一张简单的 55*6 的 COMMAS Logo 图需要使用 3,857B 来保存！",[13,172,173],{},"有什么方法可以进一步压缩图片呢？聪明的你一定可以想到，我们可以使用二进制。PBM 的编码可以使用 P4-P6 表示它使用二进制保存。于是我们可以用两个字节表示编码，两个 Int32 也就是 8 个字节表示尺寸，后面的 330 个像素可以将每一个真彩色转换成 3 个字节的色彩空间，这样我们一共只需要 1,000B 就能够存储上面的 COMMAS Logo 图了，而且还是支持真彩色的！",[17,175,177],{"id":176},"gif","GIF: 色彩空间与编码压缩",[13,179,180],{},"在 20 世纪 80 年代，1K 的尺寸依然是无法想象的——只是一张小小的 Logo，竟然比 Commas 的使用文档还要大！有什么办法能够继续优化尺寸呢？",[13,182,183,184,187],{},"在当时那个年代，在我们甚至很难购买到支持真彩色的显示屏的时候，使用真彩色编码图片无疑是一种浪费。我们也可以缩小色彩空间来针对每个像素减少其占用的空间。在 1-bit 之外，同样有一种常见于像素游戏的画风叫做 ",[50,185,186],{},"8-bit","，意思就是用 8bit 也就是 1 个字节来保存颜色，我们只需要将颜色限制为 256 种，就能将用于色彩的存储进一步压缩。假设我们将 PPM 的 Commas Logo 缩小到 256 种颜色的范围，每一个像素就能用 1 个字节来保存了，这样上面的 1,000B 的 COMMAS Logo 图就能压缩到 340B，甚至比文本格式的 PBM 图还要小！",[13,189,190],{},[86,191],{"alt":37,"src":192},"https:\u002F\u002F66.media.tumblr.com\u002Ff7cd096f108d83c988169096361972fc\u002Ftumblr_otjfqziQrH1qze3hdo1_500.gifv",[13,194,195],{},[42,196,197],{},"玻璃的光影只需要使用四种颜色即可完成。",[13,199,200],{},"另一方面，学过数据结构的同学能够想到一种常见的压缩方式：霍夫曼编码。简单地来说就是我们可以记录一份字典，用更小的比特序列来记录更常出现的字符。比如 commas，如果用 ASCII 的话，每一个字母都要 1 个字节也就是 8bit，但如果用 1 表示 m，10 表示 c，11 表示 o……我们只需要 12 bit 就能表达这个字符串了！只要字典占用的空间小于压缩减少的空间，霍夫曼编码就能有效减少文件尺寸。",[13,202,203,204,207,208,211,212,215],{},"沿着这样的思路，一种主流的图片格式终于诞生了，它就是 GIF。尽管我们现在提起 GIF 就会想到动图，但实际上，GIF 是最早流行起来的图片的编码方式。GIF 的全称是 ",[50,205,206],{},"G","raphics ",[50,209,210],{},"I","nterchange ",[50,213,214],{},"F","ormat，也就是“图像交换格式”的意思，显然它就是为了高效传输而诞生的。",[13,217,218],{},[86,219],{"alt":37,"src":220},"https:\u002F\u002Fupload.wikimedia.org\u002Fwikipedia\u002Fcommons\u002Fthumb\u002F4\u002F46\u002FZt2012.gif\u002F220px-Zt2012.gif",[13,222,223],{},"GIF 使用了一种叫做 LZW 的压缩技术，它与几乎所有现代压缩软件师出同源。比起标准的霍夫曼编码，它的字典是动态生成的，因此需要传输的尺寸将会进一步减小。所以 GIF 就相当于用压缩文件来编码图片，这能不厉害嘛！",[13,225,226],{},"另外，在推出后不久，Netscape Navigator 支持了 GIF 的多帧动画，以及定义动画重复能力的功能——这下表情包王者们发挥的空间来了！GIF 很快风靡互联网，包含 Netscape 定义的动画格式变成了事实标准。",[13,228,229],{},[86,230],{"alt":37,"src":231},"https:\u002F\u002Fblog.hubspot.com\u002Fhubfs\u002FSmiling%20Leo%20Perfect%20GIF.gif",[13,233,234],{},"那么，为什么现在除了动图之外，我们都不再使用 GIF 了呢？一方面是由于 GIF 仅支持 256 种颜色，对于摄影图片来说这几乎是无法忍受的；另一方面则是因为一家公司的骚操作：",[13,236,237,238,241],{},"GIF 是历史上首个提供电子邮件服务的公司 CompuServe 开发并开放给大家使用的，但是另一家公司优利系统却声称自己申请了 ",[50,239,240],{},"LZW 中 W 的专利","，需要大家交纳高额的专利费……于是很快，开源社区开始抵制 GIF 并开始开发新的图片格式。因此尽管 2006 年开始 GIF 不再被专利限制，一个巨人已经悄然站在了 GIF 的前面，它就是—— PNG。",[17,243,245],{"id":244},"png","PNG: 开放",[13,247,248,249,252,253,256,257,259],{},"PNG 的全称是 ",[50,250,251],{},"P","ortable ",[50,254,255],{},"N","etwork ",[50,258,206],{},"raphics，即“便携式网络图片”。这意味着从设计之初它就面向：",[261,262,263,267,270],"ul",{},[264,265,266],"li",{},"面向 Web 展示场景",[264,268,269],{},"更小的体积",[264,271,272,276],{},[273,274,275],"del",{},"取代 GIF","。实际上，确实如此！",[13,278,279,280,282,283,285,286,288,289,299],{},"PNG 的诞生离不开 GIF 的作死，正如 PNG 也被解释为 ",[50,281,251],{},"NG is ",[50,284,255],{},"ot ",[50,287,206],{},"IF……在 GIF 选择专利收费的时候，开源社区提出了一种新的图片格式。PNG 从诞生之初就是完全无需许可的，由 IETF 作为 RFC 2083 发布，正如我们所知道的很多互联网基础协议一样（例如 RFC 791 IP、RFC 1034 DNS、RFC 2616 HTTP\u002F1.1，",[273,290,291,292],{},"以及迄今为止最快的传输协议 RFC 1149 ",[293,294,298],"a",{"href":295,"rel":296},"https:\u002F\u002Fzh.wikipedia.org\u002Fwiki\u002F%E4%BB%A5%E9%B8%9F%E7%B1%BB%E4%B8%BA%E8%BD%BD%E4%BD%93%E7%9A%84%E7%BD%91%E9%99%85%E5%8D%8F%E8%AE%AE",[297],"nofollow","IPoAC"," 等等），并在发布后不久就成为了 W3C 的推荐标准。",[13,301,302,303,306],{},"或许 PNG 能够取代 GIF 是一件很容易理解的事情：毕竟，谁不喜欢白瓢呢？更何况 PNG 完美解决了 GIF 的另一个痛点：PNG 支持真彩色。然而，PNG 至今仍然是最主流的网络图片格式，这就值得我们思考了。事实上，PNG 的最大特点在于它是",[50,304,305],{},"向前兼容","的。",[13,308,309],{},[86,310],{"alt":37,"src":311},"https:\u002F\u002Fupload.wikimedia.org\u002Fwikipedia\u002Fcommons\u002F4\u002F47\u002FPNG_transparency_demonstration_1.png",[13,313,314,315,318],{},"PNG 格式与 PNM 和 GIF 类似，都由一个协议头+多个内容块构成，但 PNG 在标准制订时就规定了块可以分为两类：",[50,316,317],{},"关键数据块和辅助数据块","。PNG 解析器必须支持关键数据块的解析，而对于辅助数据块则是能识别就识别，不能识别可以忽略。",[13,320,321],{},"这个特性有什么用呢？我们可以重新回顾一下，我们会在什么场景下使用 GIF 而不是 PNG 呢？显然，最常见的场景就是上面所说的动图。在 2004 年，Mozilla 推出了 APNG 格式。APNG 将动画的第一帧作为 PNG 的关键数据块，而后续帧和其他动画信息则作为辅助数据块，这样即使是在不支持 APNG 的场景下，这些图片也能展示为静态的图片了。",[13,323,324],{},[86,325],{"alt":37,"src":326},"https:\u002F\u002Fupload.wikimedia.org\u002Fwikipedia\u002Fcommons\u002F1\u002F14\u002FAnimated_PNG_example_bouncing_beach_ball.png",[328,329],"br",{},[13,331,332],{},"另一个你可能感兴趣的问题或许是，我们经常使用 TinyPNG 这样的工具来对 PNG 做压缩，那么一张 PNG 图片是如何被压缩的呢？尤其是在我们已经知道，GIF 为其压缩算法保留了专利的情况下？",[13,334,335],{},"实际上 PNG 和 GIF 的算法非常相似。前面我们提到，GIF 为 LZW 中的 W 部分声明了专利，而剩下的 LZ 部分实际上就是 LZW 的原始算法——LZ77，它来自于名字首字母 L 和 Z 的两位大佬在 1977 年提出的压缩算法。PNG 的压缩正是基于 LZ77 的另一种算法：DEFLATE，这也正是 Web 领域常见的 GZIP 的压缩算法。尽管细节不同，但基于动态字典的思路与 GIF 是类似的，这也保证了 PNG 具有高效的压缩效率。",[17,337,339],{"id":338},"jpeg","JPEG: 有损压缩",[13,341,342],{},"事情已经发展到了这一阶段：PNG 几乎就要一统江湖了，但是为什么没有呢？最主要的原因依然是 LZ77——它的压缩效率相比原始数据已经很高了，但是还远远不够。像 LZ77 这样的压缩算法与霍夫曼编码类似：数据多样性越差，压缩效率就越高。这意味着对于早期互联网上的那种剪贴画，PNG 是很有优势的；但随着图像复杂程度升高，PNG 能够压缩的空间也越来越有限了。有什么办法能够压缩那些复杂的图片，例如摄影作品呢？",[13,344,345],{},[86,346],{"alt":37,"src":347},"https:\u002F\u002Fthumb.wikimedia.org\u002Fwikipedia\u002Fcommons\u002Fthumb\u002F4\u002F45\u002FCliparts_%28examples%29.png\u002F960px-Cliparts_%28examples%29.png",[13,349,350,351,354,355,357,358,361,362,364,365,61],{},"JPEG 就是这样诞生的。JPEG 实际上是 ",[50,352,353],{},"J","oint ",[50,356,251],{},"hotographic ",[50,359,360],{},"E","xperts ",[50,363,206],{},"roup，也就是“联合图像专家组”的意思，我们通常所说的 JPEG 就是这个专家组提出的第一种编码标准，在 JPEG 之后实际上还有 JPEG 2000 这样更高级的标准，但并没有能够撼动 JPEG 的地位（后文会提到）。事实上，JPEG 比 PNG 的出现还要更早，但比起 GIF 粗暴的 256 色化和 PNG 偏执的无损压缩，JPEG 采取了一种更实用主义的策略：",[50,366,367],{},"面向人眼识别的有损压缩",[13,369,370,371,374],{},"不同于我们在 PNM 中使用的 RGB 色彩空间，JPEG 使用的是一种叫做 YUV 的色彩空间。YUV 三个字母分别代表亮度、色调和饱和度，这和现代更流行的 HSL 很接近。正如设计师们推崇 HSL 的主要原因是 HSL 更接近于人眼对色彩的感受方式，因此更适合做渐变处理，YUV 也被广泛应用电视色彩调频领域，原因就在于：",[50,372,373],{},"人眼对于亮度的感受要高于色调和饱和度","。你可以试试开启或关闭手机的夜览模式和原彩显示，再试试调整亮度，就会发现，我们对亮度的敏感程度是非常高的。",[13,376,377,378,381,382,385],{},"不仅如此，",[50,379,380],{},"人眼对于在一定范围内的亮度差异较为敏感","，例如我们会明显感觉到 10% 和 20% 比 20% 和 25% 更接近，但却难以区分 10% 和 90% 与 20% 和 80% 两种对比的差异。通过一些矩阵变换的技巧，我们可以将频域上的一些细节舍弃，这个过程被称为",[50,383,384],{},"量化","。这是 JPEG 有损压缩的最主要来源，通常 JPEG 压缩时可以选择压缩质量，影响的就是量化过程的系数。",[13,387,388],{},[86,389],{"alt":37,"src":390},"https:\u002F\u002Fupload.wikimedia.org\u002Fwikipedia\u002Fcommons\u002Fb\u002Fb2\u002FJPEG_compression_Example.jpg",[13,392,393,394,397],{},"从上面这张图我们就可以看出来，一些亮度变化明显的部分是 JPEG 损失最多的地方，例如鸟喙周围会有明显的噪点。尽管如此，对于我们通常看到的图片，JPEG 都能在合理地保证质量的前提下大幅压缩图像的尺寸，这尤其体现在一些",[50,395,396],{},"绘画作品","中，因为这些作品通常都有相对均匀的亮度。",[13,399,400],{},[86,401],{"alt":37,"src":402},"https:\u002F\u002Fthumb.wikimedia.org\u002Fwikipedia\u002Fcommons\u002Fthumb\u002Fd\u002Fd7\u002FMeisje_met_de_parel.jpg\u002F960px-Meisje_met_de_parel.jpg",[13,404,405],{},"然而，专利问题在 JPEG 身上依然未能幸免，2002 年一家公司宣称自己拥有 JPEG 的专利，这在 PC 领域引发轩然大波，这与 JPEG 专家组创立之初期望的免版税标准背道而驰。此案经过 4 年的扯皮，最终以庭外和解的方式解决了。此事件同时暴露了 JPEG 2000 存在的专利风险，导致尽管 JPEG 2000 在技术上更加先进，却最终没有流行起来。",[17,407,409],{"id":408},"webp","WebP: 金声玉振",[13,411,412,413,416],{},"数据压缩是一个非常经典的信息学问题。我们之所以能够压缩数据，往往是因为这些数据",[50,414,415],{},"本身存在冗余信息","。例如霍夫曼编码就利用了不同的数据出现的频率不一致，这就是一种统计学冗余。但不论如何，我们都没有办法在 1bit 里面传递 2bit 的信息，因为信息也需要受到熵的限制，",[13,418,419],{},"截至此时，也许我们已经把所有能够使用的方式都穷尽了：我们尝试了二进制编码、压缩算法，甚至针对人眼的观感放弃了图像的一部分信息……但是，真的结束了吗？",[13,421,422,423,426],{},"开动我们的脑筋仔细想想，会不会有一种可能，我们可以将图片信息中更多的部分",[50,424,425],{},"变成冗余","呢？",[328,428],{},[13,430,431],{},"让我们把视线从图片转向其他领域。有一个看起来和 JPEG 很有关系的格式是 MPEG，但是实际上二者的关系就和张飞与王菲差不多。但正如 JPEG 实际上是专家组的名称，MPEG 实际上也是如此，它实际上是一个提出了音视频领域多种编码标准的组织。我们通常所说的 MPEG 实际上是 MPEG-1，是一种音频标准，它最经典的应用是 MPEG-1 第 3 音频层，俗称 MP3。而 MPEG 发布的最具影响力的标准当属 MPEG-4，其中包含了 27 个子部分。每一个部分分别规定的视频的编码、控制、示例、优化方式等等。我们最熟悉的应当是第 14 部分，俗称 MP4。",[13,433,434],{},[86,435],{"alt":37,"src":436},"https:\u002F\u002Fstarecat.com\u002Fcontent\u002Fwp-content\u002Fuploads\u002Fmp3-mp4-mp5-level-of-entertainment.jpg",[13,438,439,440,61],{},"在 MPEG-4 中，视频编码的部分是由第二部分（XVID）和第十部分（AVC）组成的，其中 AVC 更加高级；同时，由于 AVC 是 MPEG 和国际电信联盟共同制定的，因此这个规范在国际电信联盟也有一个别名，它就是 ",[50,441,442],{},"H.264",[13,444,445,446,449,450,453,454,457],{},"H.264 通过只记录帧与帧之间的变化，得以将视频大幅压缩，也就是我们通常所说的“",[50,447,448],{},"运动补偿","”。显然比起 GIF 对图片的每帧都进行保存，这种方式的存储效率要高出几个数量级！除了运动补偿外，还有一些高级的压缩手段，例如“",[50,451,452],{},"帧内预测","”。这意味着，在解码器对某一帧进行解码时，",[50,455,456],{},"可以根据某个单元相邻的单元来预测该单元的值，从而使视频文件只需要记录实际值和预测值的差值就足够了","。由于其极高的压缩效率，H.264 很快统治了视频编码领域。",[13,459,460],{},"但是，正如 GIF 和 JPEG 面对的一样，MPEG 的标准实际上是包含专利的。因此，很多公司试图开发能够代替 H.264 的视频编码。Google 在 2010 年收购的一家叫做 On2 的公司就是做这件事情的。收购完成不久后，Google 就在当年的 Google I\u002FO 上宣布开源 On2 的最新视频编码 VP8，为什么呢？因为于此同时，Google 推出了一个新的开源视频格式，也就是本章节的主角的兄弟——WebM。",[13,462,463],{},[86,464],{"alt":37,"src":465},"https:\u002F\u002Fdiginomica.com\u002Fsites\u002Fdefault\u002Ffiles\u002Fimages\u002F2020-07\u002F23451BCC-062C-4B5E-9D8C-4B247E8C74E0.jpeg",[13,467,468,469,472],{},"我们现在知道，WebM 实际上并未掀起多大波澜，但在当时仍然是划时代般的进步，尤其是在半年后，Google 基于 VP8 技术再次给出了新的图片格式 WebP 的时候。在经历了那么多版权和专利纠纷后，Web 领域终于又有了",[50,470,471],{},"开源+免版税","的新格式，并且还是图片+视频打包的！",[13,474,475],{},"正是因为 WebP 技术是从 VP8 衍生而来的，因此它继承了视频领域的有损压缩手段，这就是前面提到的“帧内预测”。WebP 会使用每个块上方的三个块和左侧的三个块进行预测，并且包含了 H.264 的四种帧内预测模式，这也就是 WebP 能够做到比 PNG 更小的原因——通过帧内预测实现了更多原始信息的冗余化。在此基础之上，WebP 同样使用了字典编码等等无损压缩技术，从而使图片的尺寸降到了尽可能低的程度。",[17,477,479],{"id":478},"future","展望",[13,481,482],{},"WebP 已经是图片压缩的终结了吗？当然不！",[13,484,485],{},"在 WebP 诞生之初实际上不支持无损压缩和透明通道，并且它的有损压缩甚至不如 JPEG；但正是因为开源的力量，让 WebP 逐渐成为了目前最具优势的主流 Web 图片格式。那么现在，除了 WebP 我们还有哪些选择呢？",[13,487,488,489,492,493,495,496,499,500,503],{},"如果说有哪种格式表现超越 WebP，BPG 一定是其中的一个。前面我们提到，WebP 的实现来自于 VP8，而 VP8 又来自于 H.264。现在你也许知道，H.264 已经不足以满足如今大量的 4k、8k 甚至更高的显示需要，因此 2013 年的时候国际电信联盟发布了新的视频标准 H.265，学名叫做 HEVC（",[50,490,491],{},"H","igh ",[50,494,360],{},"fficiency ",[50,497,498],{},"V","ideo ",[50,501,502],{},"C","oding，高效视频编码）。HEVC 在 H.264 之上做了诸多改进，例如帧内预测就从 4 种模式上升到了 33 种！",[13,505,506],{},"BPG 使用了基于 HEVC 帧内预测算法的有损压缩，这意味着它的性能要显著领先于 JPEG 甚至 WebP。然而，由于 HEVC 与 H.264 一样保留版权，这也成为了 BPG 并没有大规模流行的主要原因。",[13,508,509,510,515],{},"在无损压缩领域有没有呢？显然也是有的，",[293,511,514],{"href":512,"rel":513},"https:\u002F\u002Fgithub.com\u002FFLIF-hub\u002FFLIF",[297],"FLIF"," 就是其中的典型。FLIF 是 2015 年发布的，并且也是完全开源的。FLIF 采用和 H.264 类似的一种动态学习的压缩算法，在无损压缩方面将压缩性能优化到了新高度。但作为一个纯社区项目，FLIF 在发布后不久就逐渐式微，但其核心思路被 JPEG 的新标准 JPEG XL 继承，并且 JPEG XL 最终也在 2020 年作为免版税标准发布；BPG 和 FLIF 也最终启发了 MPEG，发布了基于 HEVC 的图片格式 HEIF。",[13,517,518],{},[86,519],{"alt":37,"src":520},"https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FgJJachY651c\u002Fmaxresdefault.jpg",[13,522,523],{},[42,524,525],{},"WebP 的后现代艺术",[13,527,528],{},"故事的最后则重新回到我们的卷王 Google 身上。在 VP8 对标 H.264 而国际电信联盟发布了 H.265 之后，Google 推出了 VP9 来对标 H.265；尽管不及预期，但最终促成了 AOMedia（开放标准联盟，由 Google、苹果、微软、Facebook、Mozilla 等创建）的成立。基于 VP10 的 AV1 正是 AOMedia 开发的用以代替 H.265 的最新免版税标准。",[13,530,531],{},"2021 年起 Google 开始开发下一代 WebP，被称为 WebP 2，便是基于 AV1 视频编码。或许在不久之后，我们就能看到新的图片格式横空出世，并建立它的天下。",[533,534,535],"style",{},"html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":37,"searchDepth":117,"depth":117,"links":537},[538,539,540,541,542,543,544],{"id":19,"depth":117,"text":20},{"id":70,"depth":117,"text":71},{"id":176,"depth":117,"text":177},{"id":244,"depth":117,"text":245},{"id":338,"depth":117,"text":339},{"id":408,"depth":117,"text":409},{"id":478,"depth":117,"text":479},"2022-06-09","md",{},true,"\u002Fposts\u002Fhow-we-record-pictures",{"title":5,"description":15},"posts\u002F2022\u002Fhow-we-record-pictures","0jjEIDTx8mmkQjU-_tAmOMTjXUxHZzUJmBJKqKs0znE",[554,558],{"title":555,"path":556,"stem":557,"children":-1},"JavaScript 黑历史","\u002Fposts\u002Fthe-charming-javascript","posts\u002F2022\u002Fthe-charming-javascript",{"title":559,"path":560,"stem":561,"children":-1},"不要使用 DOM 的 onxxx 属性的第一万个理由","\u002Fposts\u002Fdo-not-use-dom-onxxx","posts\u002F2022\u002Fdo-not-use-dom-onxxx",1792500630764]