图像格式转换实验报告.doc_第1页
图像格式转换实验报告.doc_第2页
图像格式转换实验报告.doc_第3页
图像格式转换实验报告.doc_第4页
图像格式转换实验报告.doc_第5页
已阅读5页,还剩2页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

实验1 图像格式转换实验报告 学 号:12224506 姓 名:陈振辉 班 级:5班 一、实验目的掌握两种以上图像的格式,重点掌握BMP图像格式。二、实验原理:1、JPEG文件的解码过程。读入文件的相关信息按照上述的JPEG文件数据存储方式,把要解码的文件的相关信息一一读出,为接下来的解码工作做好准备。参考方法是,设计一系列的结构体对应各个标记,并存储标记内表示的信息。其中图像长宽、多个量化表和哈夫曼表、水平/垂直采样因子等多项信息比较重要。以下给出读取过程中的两个问题。1)整个文件的大体结构JFIF格式的JPEG文件(*.jpg)的一般顺序为:SOI(0xFFD8)APP0(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个字节分别表示116位的编码码字在哈夫曼树中的个数。编码内容这个字段记录了哈夫曼树中各个叶子结点的权。所以,上一字段(不同位数的码字数量)的16个数值之和就应该是本字段的长度,也就是哈夫曼树中叶子结点个数。4)建立哈夫曼树读出哈夫曼表的数据后,就要建立哈夫曼树。初步了解图像数据流的结构a)在图片像素数据流中,信息可以被分为一段接一段的最小编码单元(Minimum CodedUnit,MCU)数据流。所谓MCU,是图像中一个正方矩阵像素的数据。矩阵的大小是这样确定的:查阅标记SOF0,可以得到图像不同颜色分量的采样因子,即Y、Cr、Cb三个分量各自的水平采样因子和垂直采样因子。大多图片的采样因子为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*8,所以每个MCU的数据单元个数为Hmax*Vmax。另外JPEG的压缩方法与BMP文件有所不同,它不是把每个像素的颜色分量连续存储在一起的,而是把图片分成Y,Cr,Cb三张子图,然后分别压缩。而三个颜色分量的采样密度(即采样因子)可能一样(例如1:1:1)也可能不一样(例如4:1:1)。每个MCU内部,数据的顺序是Y、Cr、Cb。如果一个颜色分量有多个数据单元,则顺序是从左到右,从上到下。颜色分量单元的内部解码1)理论说明“颜色分量单元”是笔者为说明问题而建立的概念,指的是MCU中某个颜色分量的一个8*8数据块,例如上面提到的Y1、Cr1、Cb1都是一个颜色分量单元。图像数据流是以位(bit)为单位存储信息的。并且内部的数据都是在编码时通过正向离散余弦变换(FDCT)进行时空域向频率域变换而得到的结果,所以对于每个颜色分量单元都应该由两部分组成:1个直流分量和63个交流分量。解码的过程其实就是哈夫曼树的查找过程。 颜色分量单元内部综合运用了RLE行程编码和哈夫曼编码来压缩数据。每个像素的数据流由两部分构成:编码和数值,并且两者基本以互相隔开方式出现(除非该编码的权值为零)。具体读入单个颜色分量单元的步骤如下:a)从此颜色分量单元数据流的起点开始一位一位的读入,直到读入的编码与该分量直流哈夫曼树的某个码字(叶子结点)一致,然后用直流哈夫曼树查得该码字对应的权值。权值(共8位)表示该直流分量数值的二进制位数,也就是接下来需要读入的位数。b)继续读入位数据,直到读入的编码与该分量交流哈夫曼树的某个码字(叶子结点)一致,然后用交流哈夫曼树查得该码字对应的权值。权值的高4位表示当前数值前面有多少个连续的零,低4位表示该交流分量数值的二进制位数,也就是接下来需要读入的位数。c)不断重复步骤b,直到满足交流分量数据结束的条件。而结束条件有两个,只要满足其中一个即可:当读入码字的权值为零,表示往后的交流变量全部为零;已经读入63个交流分量。d)各个数值的译码是按下表进行的:直流系数的差分编码把所有的颜色分量单元按颜色分量(Y、Cr、Cb)分类。每一种颜色分量内,相邻的两个颜色分量单元的直流变量是以差分来编码的。也就是说,通过步骤3解码出来的直流变量数值只是当前颜色分量单元的实际直流变量减去前一个颜色分量单元的实际直流变量。也就是说,当前直流变量要通过前一个颜色分量单元的实际(非解码)直流分量来校正:DCn=DCn-1+Diff其中Diff为差分校正变量,也就是直接解码出来的直流系数。但如果当前颜色分量单元是第一个单元,则解码出来的直流数值就是真正的直流变量。反量化不同的颜色分量使用不同的量化表,这个可以从标记段SOF中的颜色分量信息字段查得。一般是Y分量使用量化表0,而Cr、Cb两个分量共同使用量化表1。反量化的过程比较简单。只需要对8*8的颜色分量单元的64个值逐一乘以对应的量化表内位置相同的值则可。图像内全部的颜色分量单元都要进行反量化。反Zig-zag编码如果将反量化后的每个8*8颜色分量单元的每个元素编号,如下图4,那么各反Zig-zag编码的过程就是把矩阵元素按图5重新排列。关于量化和反Zig-zag编码的先后顺序,笔者查阅的几份资料有不同的见解。经过实践试验,解码的过程中,是应该直接用文件提供的量化表反量化矩阵数据,再将其反Zig-zag编码才能正确解码。隔行的正负纠正这个问题比较特别,因为在笔者认真阅读的几份资料中都没有提及此问题。而是笔者通过对已知图像进行JPEG编码压缩,然后和该图的JPEG文件数据对比发现的问题。具体原因不明。实际上,就是必须对每个颜色分量单元的奇数行(每个颜色分量单元有8行,假设把它按0、1、6、7编出行号),即1、3、5、7行,进行取相反数操作(正的变负,负的变正)。反离散余弦变换之前提到,文件中的数据是在编码时通过正向离散余弦变换(FDCT)进行时空域向频率域变换而得到的结果,所以现在解码就必须将其反向离散余弦变换(IDCT),就是把颜色分量单元矩阵中的频率域数值向时空域转换。并且,原来的频率域的矩阵大小为8*8,则经过反向离散余弦变换后,时空域的矩阵仍然是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分量各自只有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*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; / 位图文件保留字,必须为0DWORD bfOffBits; / 位图数据的起始位置,以相对于位图文件头的偏移量表示,以为单位 BITMAPFILEHEADER; 位图信息头:BMP位图信息头数据用于说明位图的尺寸等信息。typedef struct tagBITMAPINFOHEADERDWORD biSize; / 本结构所占用数LONGbiWidth; / 位图的宽度,以像素为单位LONGbiHeight; / 位图的高度,以像素为单位WORD biPlanes; / 目标设备的级别,必须为1WORD biBitCount/ 每个像素所需的位数,必须是1(双色),4(16色),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 BITMAPINFOHEADER bmiHeader; / 位图信息头RGBQUAD bmiColors1; / 颜色表 BITMAPINFO; 位图数据:位图数据记录了位图的每一个像素值,记录顺序是在扫描行内是从左到右,扫描行之间是从下到上。位图的一个像素值所占的数:当biBitCount=1时,8个像素占1个;当biBitCount=4时,2个像素占1个;当biBitCount=8时,1个像素占1个;当biBitCount=24时,1个像素占3个;Windows规定一个扫描行所占的数必须是4的倍数(即以long为单位),不足的以0填充, 一个扫描行所占的数计算方法:DataSizePerLine= (biWidth* biBitCount+31)/8; / 一个扫描行所占的数

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论