JPEG(Joint Photographic Experts Group)是联合图像专家组的英文缩写。 该组织从1986年正式开始制订静止数字图像的压缩编码标准，该标准于1992年正式通过，称为JPEG标准。 JPEG是第一个数字图像压缩的国际标准，它不仅适于静止图像的压缩，对 于电视图像序列的帧内压缩也常采用JPEG算法，因此JPEG是一个适用范围广泛的通用标准。

为了减少各分量之间的相关性，减少数据的冗余，通常会把RGB颜色空间转换成YUV来进行各分量的编码。

该步骤的作用是，图像内容平均亮度较高，将0电平移到中间，平均亮度降低， 便于DCT变换量化后直流的系数大大降低，也就降低了数据量。

将灰度级 2 n 2^n 2n的像素值，全部减去 2 n − 1 2^{n-1} 2n−1，数据形式由无符号数变为有符号数(补码)，单极性数据变为双极性数据。

该步骤主要是用于去除图像数据之间的相关性，便于量化过程去除图像数据的空间冗余。

将图像分为8×8的像块；对于宽（高）不是8的整数倍的图像，使用图像边缘像素填充，以不改变频谱分布。然后对每一个子块进行DCT（Discrete Cosine Transform，离散余弦变换）。 DCT变换： 其中，C是8x8的DCT变换二维核矩阵， f ( x , y ) f(x,y) f(x,y)是原始的数据。由于DCT变换是一个正交变换，故 C T = C − 1 \boldsymbol{C^T}=\boldsymbol{C^{-1}} CT=C−1。

变换核矩阵如下所示： 需要特别强调的是，DCT是一种无损变换，也无法对图像进行压缩，这样做的目的是在为下一步的量化做准备。

量化器主要是利用人眼视觉特性设计而成的矩阵量化DCT系数，减少视觉冗余。 将DCT变换后的临时结果，除以各自量化步长并四舍五入后取整，得到量化系数。 JPEG系统分别规定了亮度分量和色度分量的量化表，色度分量相应的量化步长比亮度分量大。 在量化步骤中，JPEG采用了中平型(Midtread)的均匀量化器。关于中平型量化器的更多信息可以查看：作业：Lloyd - Max标量量化器条件的推导

量化是编码流程中唯一会引入误差也是唯一会带来压缩的步骤。Y、UV各一张表，共两张表。

8×8图像块经过DCT变换之后得到的DC直流系数有两个特点：

根据这个特点，JPEG算法使用了差分脉冲调制编码(DPCM)技术，对相邻图像块之间量化DC系数的差值DIFF进行编码：

DPCM是对于DC系数处理时所需要用到的预测编码方法。此方法在之前的实验中已经有详细说明。

对DPCM后算出的DIFF差值使用Huffman编码。 将其分成类别，类似于指数的Golomb编码（只不过Golomb是一元码+定长码），也就是类别ID使用规范哈夫曼编码，类内索引使用定长码（自然码）。

所以，DC系数会产生一张长度为16的Huffman码表。

对于量化后的数据，我们将其分为两路进行处理。一路是AC通路，一路是DC通路。ZigZag Scan+RLE是用于AC通路的，这是因为AC分量出现较多的0。JPEG采用对0系数的游程长度编码。而对非0值，则要保存所需数和实际值。 在编码之前，需要把二维的变换系数矩阵转换为一维序列，由于量化之后右下角高频系数大部分为零，采用ZigZag Scan读取可以制造较长的零游程，提高编码效率。在扫描中，如果后续的系数全部为零，则用“EOB”表示块结束。 在扫描后，采用RLE进行编码。

例：例如，现有一个字符串，如下所示： 57,45,0,0,0,0,23,0,-30,-8,0,0,1,000… 经过RLE之后，将呈现出以下的形式： (0,57) ; (0,45) ; (4,23) ; (1,-30) ; (0,-8) ; (2,1) ; (0,0) 注意，如果AC系数之间连续0的个数超过16，则用一个扩展字节(15,0)来表示16连续的0。

所以，最后总共有4张Huffman码表（亮度DC，亮度AC，色度DC，色度AC）。

那么，这些码表如何存储？源数据又放在哪里？针对这些未解之谜，接下来我们就分析JPEG的存储结构。

某个图象的一个8*8方块的亮度值： Level Offset 后：

DCT变换后： 量化后：

其中，参照的量化表是： 随后，对于这个8*8方块的亮度量化后的数据分别进行AC和DC两路的编码。

由于后面需要导出码表等操作，势必需要掌握jpeg的存储格式。因此，我们针对实验所用的testrgb-2x2.jpg，作一个完整解析。

JPEG以segment组成。每个segment都有一个名字，为其segment marker.我们逐一对每个marker进行分析。

整个文件以SOI开始，EOI结束。中间包含了APP0字段，两个DQT字段，一个SOF0字段，四个DHT字段，然后包含所有的ImageData数据。每个字段的作用都会在下面详细解释。

图像以SOI（Start of Image）标志图像开始，内容为固定值FFD8。

接下来是APP0字段。APP0字段是应用程序保留标记0。 该字段以FFE0开启，后面包含信息：

DQT就是DCT后的两张量化表，一张AC,一张DC。每张量化表都由FFDB字段开始。随后的4个字节说明了该字段的长度，然后存放的就是量化表。

量化表中的第一个字节被分成了高四位和低四位来用。高四位表示了该量化表的精度，0：8位；1：16位；低四位表示了量化表ID，取值范围为0～3；接下来是所有的表项，数量为(64×(精度+1))字节，里面都是量化的系数。量化表中的数据按照Z字形保存量化表内8x8的数据 。 该jpeg文件存放了0和1两张码表。

SOF0[0]为帧图像开始marker.以FFC0为开始标记 后两个字节标注数据长度；然后一个字节标注了每个颜色分量每个像素的位数（8），然后表明了行数和每行的采样点数，然后附上了三个components体信息。每个component都是一个颜色分量，内含颜色索引ID、Sample factor（高四位水平因子、低四位垂直因子）、和采用的量化表号。

DHT是存放Huffman码表的地方。该Marker以FFC4作为开始标记。然后是字段长度，类型(AC/DC)，索引(Index)，位表(bit table)，值表(value table)。

表的内容如课件所示。

一共有4张DHT，对应AC/DC的Y/UV。

在大量的图像数据开始前，还有一个SOS字段。该字段表明了扫描开始，说明了数据是如何组织的。该字段以FFDA开始，然后表明了字段的长度，然后说明了颜色分量数，该与SOF字段中的数据应该是保持一致的。然后针对于每一个颜色分量信息，给出了每个分量的DC/AC使用的哈夫曼表编号。

然后是)谱选择开始、谱选择结束和谱选择固定值003F00。然后就是正式的图像数据了。

从main入口开始，我们观察到程序设定了两个模式，一个跑分模式(benchmark_mode)和一个转换图像模式（convert_one_image）。由于我们这次不涉及到跑分模式，我们只对转换图像模式（convert_one_image）进行分析。 我们跳入函数convert_one_image，查看里面干了什么。首先，将程序加载到内存中然后就关闭；然后解码jpeg(这是最主要的工作)；然后获取图像大小；然后获取每个通道的内存地址；拥有了获取的这些信息后，才可以以想要的输出方式存储。然后系统对于解码后的文件进行了写出，以用户选择的模式进行写出。

在该函数中，设置了这些变量：

可以看到，后面的处理都是针对于jdec这个指针指向的jdec_private结构体进行处理的：

所以，我们有必要对于jdec_private这个结构体进行一个分析。

jdec_private是每一个JPEG的码流中的一小块的结构体，包含了所有完整的内容的定义。

在jedc_private 中，定义了指向三个components的指针和三个components结构体（下面详述其意义）；定义了图像的宽高；码流长度、始末指针；还有三张量化表（最终只用到两张，Y一张，UV一张）；以及DC\AC各四张哈夫曼表（实际各用两张）。

components主要用于单个颜色通道的DCT变换后的值的存储；以及指明使用了哪个huffman_table和量化table。

huffman_table这个结构体主要用于存储所有的Huffman表。huffman表分为快速的查找表和慢速表。

在tinyjpeg_parse_header中，解析了JPEG的文件头。在读完SOI后，调用parse_JFIF对于每个Marker进行解析。这个解析过程持续到遇到了sos Marker，也就是扫描行开始。

我们输入的JPEG文件需要先解码DQT，也就是量化表。在这一步里，构建起了对应的编号的量化表。通过信息的剥离，在parse_DQT()首先找到了对应的需要创建的是哪张量化表，然后就开始调用build_quantization_table开始创建了。

从中我们可以看出，量化表的建立传入了两个参数，一个是正式的要写入的量化表qtable，另一个是参考表（reftable），是从流中读取的数据。 对于这个数据，首先程序设定了一个比例因子， scalefactor[0] = 1 ；scalefactor[k] = cos(k*PI/16) * sqrt(2) for k=1…7，且存的是倒数，这是便于进行乘法运算的。 这里主要是因为，在编码的时候，进行了人眼视觉特性设计而成的矩阵量化DCT系数，解码的时候需要进行反操作。 且采用了zigzag扫描：

因此，我们如果想要输出量化表，其实在这一步后面把ref_table表输出就可以了。码流里直接读出来的量化表是真正的量化表。后来计算出来的量化表，乘了比例因子，是为了辅助浮点dct ，idct 运算用的。如果是浮点运算，在编码端要乘比例因子，所以在解码端也要乘。具体的代码添加见下面。

接下来该JPEG头中是SOF,故解析了SOF，帧图像开始marker。这段解析较为简单，主要读出了图像的通道数量、图像的宽和高、每个通道的ID、水平垂直采样因子和使用的量化表等。

接下来就到了Huffman码表的解析。

因此，想要完成这个任务非常容易，只需要将所有内容写入到一个文件中，输出一个.yuv文件即可。

将所有内容全部写入一个文件中，再次运行程序，已成功生成了我们所需的文件，打开进行查看：

至此，修改程序输出为YUV已完成。

我们想要在程序执行的过程中获得一些调试信息时候，可以使用之前打开的TRACE文件进行输出。TRACE可以在代码中的任意地方进行条件编译。比如下面这段：

也就是说，当TRACE被设定为1，程序的if条件成立，就会执行这段宏内的条件编译内容，完成对于trace文件的写入。

至于TRACE和输出文件的设定，是在cpp头宏定义的：

所以，我们想关闭TraceFile的输出，设置TRACE=0即可。

在4.1小节我们已经说明，量化矩阵会在哪里产生，也就是build_quantization_table里。现在我们在该函数末尾加上一个TRACE，写上输出它的代码：

输出结果：

默认的代码中已经输出了所有的Huffman码表。在3.3中我们可以看出，AC和DC的Huffman码表都是在build_huffman_table函数中完成建立的。因此我们进入这两个函数，然后对他们进行查看，并输出码表。函数中已经写好：

我们可以在TRACE文件里看到所有码表内容。完整的输出可以在附录中查询到。

首先采用类似TRACEFILE文件的方式添加宏定义：

然后添加文件读写：

图像的解码在解出jpeg头后的tinyjpeg_decode函数中完成。因此，我们跳转进该函数,首先添加需要开的buffer：

在循环里：

我们通过计数器，可以看到最后计数下来是4096个像素：

因此，在我们的打开图像时候应该选择64*64的4：2：0的图像。

可以看到效果：

使用python对图像进行统计