JPEG解码

　　与具体的编码数据空间相比，jpeg文件头占据非常小乃至可以忽略不计的大小。

　　仍然拿JPEG解码--(1)JPEG文件格式概览中的《animal park》这张图片来举例，从跳过SOS(FF DA)的TAG开始——offset=0x153，

就真正进入了编码数据区域，如下图所示：

　　其占据的比例为：0x153/0x9721 = 339/38689 = 0.876%，还不到1%，其他jpeg图片也是类似情况。

　　但是，就是这么小的数据区域，却是至关重要的地方，某些关键的地方一个字节出错了的话，解码就会出错（例如huffman table

中数据），或者重建出的yuv图像异常（例如quantization table中数据）！

　　本篇是该系列的第三篇，主要介绍jpeg头信息解析，其中除了huffman table重建较复杂外，其他TAG的解析都比较容易。

1. APP0——FF EO

　　先贴出这段区域：

　　从ASCII值可以看出，保存了JFIF——JPEG File Interchange Format（JPEG文件交换格式），后面的几个字节应该是version信

息吧，没深究。

2. DQT——FF DB

　　量化表有两个，上面贴图只高亮了其中一个表。

　　从offset=0x16开始的两个字节（0x00 43）为这段区域的size=67，后面的一个字节为表的ID——0x00=0（可以看到第二张表中对

应位置offset=0x5D处为0x1）。

　　跳过前面三字节从offset=0x19处开始的64字节，即为量化表中量化值。其中需要说明的是，量化值是固定为64字节的，因为按8X8

进行DCT变换的。

　　工具解析的结果如下：

　　需要补充两点：

　　A.亮度信号的Y分量使用DQT表一，UV分量使用表二。

　　B.亮度信号通常采用细量化（量化值较小），对应位置处，表一通常比表二值要小。此量化原因是人眼对亮度信号比较敏感，采用颗粒度

较细来量化，细量化引入的一个问题会消耗更多的数据空间。

3. SOF——FF C0

　　在该JPEG解码系列中第一篇已经详细介绍过了，不再赘述。工具解析如下：

4. DHT——FF C4

　　共有四张表，上面只贴出第一张表。

　　DHT表的重建有些复杂，涉及底层更多关于数据压缩领域的知识，可以参考“范式霍夫曼编码”相关材料，本博文不再做介绍该编码原理。

但会针对具体个例进行说明，如果重建霍夫曼表。这是至关重要的一环，因为关系着后面霍夫曼解码，如果表有误，后面会解码异常。

　　4.1 表分类

　　　　重建霍夫曼表。一般分为四个表：DC0，DC1，AC0，AC1，因为Y分量使用两个表：DC0+AC0，而UV分量也使用两个表：DC1+AC1。

　　4.2 几个名词及解释

　　　　这个几个名词是个人按照自己的理解来定义的，读者需按照这个来解读，因为我的解码工具就是按照这个来使用的。

　　　　例如，parseDHT显示的下图：

　　　　几个名词：序号（SequenceNum）、码字长度（CodeWidth）、码字（Code）、信源值/权值（CodeVal）。

　　　　SequenceNum：序号，依次递增，从0到totalCodeCnt-1。totalCodeCnt值不确定，取决于编码端编码出的数量。

　　　　　　　　　　　　上面图示的第一列数字，是依次递增的，多一个编码数据就多一行。　　　　CodeWidth：　　编码数据的宽度（码字宽度——二进制数据的bit位宽），宽度都是从2开始，最大为16。当某个码字Code的宽度为16时，表示用16位的

　　　　　　　　　　编码数据来表示某个像素值(确切讲并不是像素值，而是RLE的值！)，当然，其出现的概率非常低，否则会出现编码数据量大于信源数据量了。

　　　　　　　　　　　　另外，码字宽度必须是依次递增的，中间不可能有跳变，因为霍夫曼编码理论上会尽量用较窄的码字来表示信源。-->也有可能产生跳变！

　　　　　　　　　　但一般概率较低，曾经遇到过。　　　　　　　　　　　　相同码字宽度的若干码字，其码字依次递增。例如，图示第3-5行，码字宽度为3，其对应的码字为0x4,0x5,0x6，即二进制:100,101,110。

　　　　　　　　　　Question：每当码字宽度加一时，码字如何变化？

　　　　　　　　　　　　上一个码字值加1后，末尾再补一个零（即——加1右移）。当宽度增加二时，先将上一个码字值加1后再补两个零。增加三时类似，但出现

　　　　　　　　　　概率极低。例如上图中，从CodeWidth中2->3过渡，Code值变化为：01 -> 100；从CodeWidth的3 -> 4过渡，Code值变化为：110 ->1110。

　　　　　　　　　　　　值得注意的一点：码字宽度，不一定都是依次递增，有可能产生跳变，目的是使后面的码字不溢出，也就是补两个或多个零的情况。　　　　Code：　码字，全部码字要求各不相等。因其是编码数据，而霍夫曼编码要求读取的完整的n位比特位的码字Code，不能与其他码字Code的前n位相等，

　　　　　　　因此宽度值从2位的00开始。

              　　　　  例如，上面码字Code中间的四行分别为：0x5,0x6,0xe,0x1e，（二进制表示：101，110，1110，11110）的编码数据，其真正代表的CodeVal信源

　　　　　　值为4，3，5，6。由此也可以看出，信源值4出现的频率/概率最高（如果仅仅这四个做比较的话是这样（再极端情况是：P4=P3>P5>P6），如果通盘比较，

　　　　　　当然是第一行0x1出现的概率最大），因为要用最小(最窄)的编码数据来表示频率最高的信源值。这是huffman编码理论中的一个核心概念——出现概率最大

　　　　　　的值的编码宽度最窄，这样最利于压缩数据。

　　　　CodeVal：信源值（应该是接近信源的值，不是量化后的值，其值是RLE行程编码值，由两部分组成，高四位和低四位）。

　　　　　　　即编码内容，也是霍夫曼树叶子节点权值，在解码时需要用Code来恢复出这种值。 　　　　　　　该值的宽度由量化精度决定，通常为8位，代表yuv图形单个像素值采样精度为8位，该值是唯一的，不能重复。——》 描述错误，不是这种情况，后面再解释。

　　4.3 重建步骤

　　　　以例子来展示，不使用《animal park》，使用如下这一串值(红色➕号分割不同意义的值，我自己添加的)：

　　　　FF C4 00 1D 00 00 03 01 01 01 01 01 01 01 00 00 00 00 00 00 00 + 04 05 06 03 02 01 00 09 07 08

　　　　step1. 剔除掉表示size的00 1D以及表示table_id的00，剩余： 00 03 01 01 01 01 01 01 01 00 00 00 00 00 00 00 + 04 05 06 03 02 01 00 09 07 08

　　　　　　其中，前16个数值表示含义————码字宽度（CodeWidth）为n的码字（Code）的数量，其中n从1递增到16（可以表示为该位置的index，但是其是从1开始递增），

　　　　因为最小宽度为1，最大宽度为16。　　　　　　通常，宽度为1的码字不会使用，而编码是从2位开始，例如第一个码字通常为0b00，来表示出现频率最高的那个信源值。有些位置上的值为0，表示该码字宽度无

　　　　对应的码字，像第一个位置和最后7个位置的0，就没有对应的码字。      　　　　从上面分析，可以得到结论：总共使用码字的数量————16个位置上的数值之和，也即是totalCodeCnt=10（3+1+1+1+1+1+1+1），也是霍夫曼树中叶子节点的个数。

　　　　step2. 前16个字节后面的若干个字节数据：04 05 06 03 02 01 00 09 07 08　　　　　　其表示码字宽度依次递增时所对应的信源值（CodeVal），其数量必然等于totalCodeCnt，因为一个有效码字（前16Byte不为0的）对应一个信源值。

　　　　step3. 对应关系生成　　　　　　前16Bytes的第2个位置的03，代表码字宽度为2的码字数量为3，那么其分别为：0b00，0b01，0b10，其对应的信源值分别为后面的0x04,0x05,0x06                       。。。。。。3。。。 。01。。。。。。。。3。。。 。。。1 。。。。。。。0b110。。。。。。。。。。。。。。。。。。。 。0x03 　　　　　　。。。。。。4。。。。  01。。。。。。。。4。。。。。。1。。。。。。。。 0b1110。。。。。。。。。。。。。。。。。。。0x02　　　　　　以此类推，直到最后一个码字宽度为9的码字0x1fe，以及其代表的信源值0x08。

　　4.4 重建算法

　　　　本人工具提供了一个重建huffman表的算法，感兴趣的可以参考。写的不是太简洁，但能正常重建DHT。

　　需要注意的是，最后3Bytes是描述所用的profile，但是基本上都是使用的baseline，这个值是固定的。

　　工具解析结果如下：

6. 其他补充

　　有些图片带缩略图——thumbnail，其存在的目的是解码大图太耗费时间，而如果jpeg图片中还嵌套着另外一份小图（缩略图），则利用该小图解码可以缩短解码大图时间，

来达到尽快展示给用户看的目的。

　　jpeg文件格式支持这种方式，该小图其实也是一幅分辨率较小的jpeg图片，其一般会放在APP1下的Exif段。

　　带thumbnail的图片，thumbnail的部分，其完整保留了前面几个小节介绍的各个TAG段。文件中，如果搜索"FF E0"，会发现找到两个，一个是主图的，另外一个是缩略图的。