图像格式转换实验报告

《图像格式转换实验报告》由会员分享，可在线阅读，更多相关《图像格式转换实验报告（6页珍藏版）》请在金锄头文库上搜索。

1、 实验 1 图像格式转换实验报告学 号：12224506 姓 名：陈振辉 班 级：5 班 一、实验目的掌握两种以上图像的格式，重点掌握 BMP 图像格式。二、实验原理：1、JPEG 文件的解码过程。 读入文件的相关信息按照上述的 JPEG 文件数据存储方式，把要解码的文件的相关信息一一读出，为接下来的解码工作做好准备。参考方法是，设计一系列的结构体对应各个标记，并存储标记内表示的信息。其中图像长宽、多个量化表和哈夫曼表、水平/ 垂直采样因子等多项信息比较重要。以下给出读取过程中的两个问题。1）整个文件的大体结构JFIF 格式的 JPEG 文件(*.jpg)的一般顺序为：SOI(0xFFD8)A

2、PP0(0xFFE0)APPn(0xFFEn)可选DQT(0xFFDB)SOF0(0xFFC0)DHT(0xFFC4)SOS(0xFFDA)压缩数据EOI(0xFFD9)2）字的高低位问题JPEG 文件格式中，一个字（16 位）的存储使用的是 Motorola 格式, 而不是 Intel 格式。也就是说, 一个字的高字节（高 8 位）在数据流的前面, 低字节（低 8 位）在数据流的后面，与平时习惯的 Intel 格式不一样。.3）读出哈夫曼表数据在标记段 DHT 内，包含了一个或者多个的哈夫曼表。 不同位数的码字数量 JPEG 文件的哈夫曼编码只能是 116 位。这个字段的 16 个字节分别表

3、示 116 位的编码码字在哈夫曼树中的个数。编码内容这个字段记录了哈夫曼树中各个叶子结点的权。所以，上一字段（不同位数的码字数量）的 16 个数值之和就应该是本字段的长度，也就是哈夫曼树中叶子结点个数。 4）建立哈夫曼树读出哈夫曼表的数据后，就要建立哈夫曼树。初步了解图像数据流的结构a) 在图片像素数据流中，信息可以被分为一段接一段的最小编码单元（Minimum CodedUnit，MCU ）数据流。所谓 MCU，是图像中一个正方矩阵像素的数据。矩阵的大小是这样确定的：查阅标记 SOF0，可以得到图像不同颜色分量的采样因子，即 Y、Cr、Cb三个分量各自的水平采样因子和垂直采样因子。大多图片的

4、采样因子为 4：1：1 或1：1：1。其中，4：1：1 即（2*2）：（1*1）：（1*1） ） ；1：1：1 即（1*1）：（1*1）：（1*1） 。记三个分量中水平采样因子最大值为 Hmax，垂直采样因子最大值为 Vmax，那么单个 MCU 矩阵的宽就是 Hmax*8 像素，高就是 Vmax*8 像素。如果，整幅图像的宽度和高度不是 MCU 宽度和高度的整数倍，那么编码时会些数值填充进去，保证解码过程中 MCU 的完整性（解码完成后，可直接忽视图像宽度和高度外的数据） 。在数据流中，MCU 的排列方法是从左到右，从上到下。b) 每个 MCU 又分为若干个数据单元。数据单元的大小必定为 8*

5、8，所以每个 MCU 的数据单元个数为 Hmax*Vmax。另外 JPEG 的压缩方法与 BMP 文件有所不同，它不是把每个像素的颜色分量连续存储在一起的，而是把图片分成 Y，Cr，Cb 三张子图，然后分别压缩。而三个颜色分量的采样密度（即采样因子）可能一样（例如 1：1：1）也可能不一样（例如 4：1：1） 。每个 MCU 内部，数据的顺序是 Y、Cr、Cb。如果一个颜色分量有多个数据单元，则顺序是从左到右，从上到下。颜色分量单元的内部解码1）理论说明“颜色分量单元” 是笔者为说明问题而建立的概念，指的是 MCU 中某个颜色分量的一个 8*8 数据块，例如上面提到的 Y1 、Cr 1、Cb

6、1 都是一个颜色分量单元。图像数据流是以位（bit）为单位存储信息的。并且内部的数据都是在编码时通过正向离散余弦变换（FDCT）进行时空域向频率域变换而得到的结果，所以对于每个颜色分量单元都应该由两部分组成：1 个直流分量和 63 个交流分量。解码的过程其实就是哈夫曼树的查找过程。颜色分量单元内部综合运用了 RLE 行程编码和哈夫曼编码来压缩数据。每个像素的数据流由两部分构成：编码和数值，并且两者基本以互相隔开方式出现（除非该编码的权值为零） 。具体读入单个颜色分量单元的步骤如下：a）从此颜色分量单元数据流的起点开始一位一位的读入，直到读入的编码与该分量直流哈夫曼树的某个码字（叶子结点）一致，

7、然后用直流哈夫曼树查得该码字对应的权值。权值（共 8 位）表示该直流分量数值的二进制位数，也就是接下来需要读入的位数。b）继续读入位数据，直到读入的编码与该分量交流哈夫曼树的某个码字（叶子结点）一致，然后用交流哈夫曼树查得该码字对应的权值。权值的高 4 位表示当前数值前面有多少个连续的零，低 4 位表示该交流分量数值的二进制位数，也就是接下来需要读入的位数。c）不断重复步骤 b，直到满足交流分量数据结束的条件。而结束条件有两个，只要满足其中一个即可：当读入码字的权值为零，表示往后的交流变量全部为零；已经读入 63 个交流分量。d）各个数值的译码是按下表进行的：直流系数的差分编码把所有的颜色分量

8、单元按颜色分量（Y 、Cr、Cb）分类。每一种颜色分量内，相邻的两个颜色分量单元的直流变量是以差分来编码的。也就是说，通过步骤 3 解码出来的直流变量数值只是当前颜色分量单元的实际直流变量减去前一个颜色分量单元的实际直流变量。也就是说，当前直流变量要通过前一个颜色分量单元的实际（非解码）直流分量来校正：DCn=DCn-1+Diff其中 Diff 为差分校正变量，也就是直接解码出来的直流系数。但如果当前颜色分量单元是第一个单元，则解码出来的直流数值就是真正的直流变量。 反量化不同的颜色分量使用不同的量化表，这个可以从标记段 SOF 中的颜色分量信息字段查得。一般是 Y 分量使用量化表 0，而 C

9、r、Cb 两个分量共同使用量化表 1。反量化的过程比较简单。只需要对 8*8 的颜色分量单元的 64 个值逐一乘以对应的量化表内位置相同的值则可。图像内全部的颜色分量单元都要进行反量化。反 Zig-zag 编码如果将反量化后的每个 8*8 颜色分量单元的每个元素编号，如下图 4，那么各反Zig-zag 编码的过程就是把矩阵元素按图 5 重新排列。关于量化和反 Zig-zag 编码的先后顺序，笔者查阅的几份资料有不同的见解。经过实践试验，解码的过程中，是应该直接用文件提供的量化表反量化矩阵数据，再将其反 Zig-zag 编码才能正确解码。隔行的正负纠正这个问题比较特别，因为在笔者认真阅读的几份资

10、料中都没有提及此问题。而是笔者通过对已知图像进行 JPEG 编码压缩，然后和该图的 JPEG 文件数据对比发现的问题。具体原因不明。实际上，就是必须对每个颜色分量单元的奇数行（每个颜色分量单元有 8 行，假设把它按 0、1、6、7 编出行号） ，即 1、3、5、7 行，进行取相反数操作（正的变负，负的变正） 。反离散余弦变换之前提到，文件中的数据是在编码时通过正向离散余弦变换（FDCT）进行时空域向频率域变换而得到的结果，所以现在解码就必须将其反向离散余弦变换（IDCT） ，就是把颜色分量单元矩阵中的频率域数值向时空域转换。并且，原来的频率域的矩阵大小为 8*8，则经过反向离散余弦变换后，时空

11、域的矩阵仍然是 8*8。设正负纠正后的频率域矩阵为 Fuv，而反向离散余弦变换后的矩阵为 fij，其中0u,v,i,j7。YCrCb 向 RGB 转换要在屏幕上显示图像，就必须以 RGB 模式表示图像的颜色。所以，解码时需要把YCrCb 模式向 RGB 模式转换。正如前面提到，并不是每种颜色分量的采样因子都一样，所以转换时需要注意。如果采样因子是 1：1：1，则每一个像素点的 3 个颜色分量都被采样，所以没有问题。但4：1：1 的采样因子就不一样了。由“初步了解图像数据流的结构”一节中对 4：1：1 的采样因子的分析，可以知道一个 MCU 里有 4 个 Y 分量单元，而 Cr 分量和 Cb 分

12、量各自只有 1 个分量单元。以图 2 为例，仅有的一个 Cr 分量单元（红色的 64 个采样点）应该平铺用于 4 个 Y 分量单元，即左上角 16 个值用于 Y1，右上角 16 个值用于 Y2，左下角 16 个值用于 Y5，右下角 16 个值用于 Y6。换句话说，一个 Cr 采样点服务于 4个 Y 采样点。对于 Cb 分量，道理一样。另外，由于离散余弦变化要求定义域的对称，所以在编码时把 RGB 的数值范围从0，255统一减去 128 偏移成-128，127。因此解码时必须为每个分量加上 128。具体公式如下：R=Y +1.402*Cb +128;G=Y-0.34414*Cr -0.71414

13、*Cb +128;B=Y +1.772*Cb +128;还有一个问题，通过变换得出的 R、G、B 值可能超出了其定义域，所以要作出检查。如果大于 255，则截断为 255；如果小于 0，则截断为 0。2、BMP 文件格式 BMP 文件头：BMP 文件头数据结构含有 BMP 文件的类型、文件大小和位图起始位置等信息。typedef struct tagBITMAPFILEHEADERWORD bfType; / 位图文件的类型，必须为 BMDWORD bfSize; / 位图文件的大小，以为单位WORD bfReserved1; / 位图文件保留字，必须为 0WORD bfReserved2;

14、/ 位图文件保留字，必须为 0DWORD bfOffBits; / 位图数据的起始位置，以相对于位图文件头的偏移量表示，以为单位 BITMAPFILEHEADER; 位图信息头：BMP 位图信息头数据用于说明位图的尺寸等信息。typedef struct tagBITMAPINFOHEADERDWORD biSize; / 本结构所占用数LONGbiWidth; / 位图的宽度，以像素为单位LONGbiHeight; / 位图的高度，以像素为单位WORD biPlanes; / 目标设备的级别，必须为 1WORD biBitCount/ 每个像素所需的位数，必须是 1(双色),4(16 色)，

15、8(256 色)或24(真彩色)之一DWORD biCompression; / 位图压缩类型，必须是 0(不压缩),1(BI_RLE8 压缩类型)或 2(BI_RLE4 压缩类型)之一DWORD biSizeImage; / 位图的大小，以为单位LONG biXPelsPerMeter; / 位图水平分辨率，每米像素数LONG biYPelsPerMeter; / 位图垂直分辨率，每米像素数DWORD biClrUsed;/ 位图实际使用的颜色表中的颜色数DWORD biClrImportant;/ 位图显示过程中重要的颜色数 BITMAPINFOHEADER;、 颜色表：颜色表用于说明位图中的颜色，它有若干个表项，每一个表项是一个RGBQUAD 类型的结构，定义一种颜色。typedef struct tagRGBQUAD BYTE rgbBlue;/ 蓝色的亮度(值范围为 0-255)BYTE rgbGreen; / 绿色的亮度(值范围为 0-255)BYTE rgbRed; / 红色的亮度(值范围为 0-255)BYTE rgbReserved;/ 保留，必须为 0 RGBQUAD;位图信息头和颜色表组成位图信息，BITMAPINFO 结构定义如下:typedef struct tagBITMAPINFO BITM