【转】图像文件格式
出自：http://dbis.nankai.edu.cn/multimedia/dmtjc6.htm
第6章 图像文件格式
本章从大量的图像文件格式中选择了三种常用的图像文件结构和一种正在推广的图像文件格式进行介绍，目的是为读者分析图像和编程提供一个概貌。BMP位图格式是Windows上画图软件(Paint)使用的格式，GIF和JFIF是因特网上几乎所有Web浏览器都支持的图像文件格式，使用GIF文件格式的动画软件也得到广泛使用。PNG是20世纪90年代中期开始开发的图像文件存储格式，其目的是企图替代GIF和TIFF文件格式。现在开发的几乎所有的图像处理软件都支持这些格式。学习本章内容时，重点是了解图像文件的组织和结构，为我们今后开发新的文件格式提供思路，因此只需要阅读每节开头的“简介”和“文件结构”即可，详细内容不必深究。若要编程，则需要仔细阅读本章内容以及本章后面提供的参考文献[1][2]。
6.1 BMP文件格式
6.1.1 简介
位图文件(Bitmap-File，BMP)格式是Windows采用的图像文件存储格式，在Windows环境下运行的所有图像处理软件都支持这种格式。Windows 3.0以前的BMP位图文件格式与显示设备有关，因此把它称为设备相关位图(device-dependentbitmap，DDB)文件格式。Windows 3.0以后的BMP位图文件格式与显示设备无关，因此把这种BMP位图文件格式称为设备无关位图(device-independent bitmap，DIB)格式，目的是为了让Windows能够在任何类型的显示设备上显示BMP位图文件。BMP位图文件默认的文件扩展名是BMP或者bmp。
6.1.2 文件结构
位图文件可看成由4个部分组成：位图文件头(bitmap-file header)、位图信息头(bitmap-information header)、彩色表(color table)和定义位图的字节阵列，它们的名称和符号如表6-01所示。
表6-01 BMP图像文件组成部分的名称和符号
|
位图文件的组成 |
结构名称 |
符号 |
|
位图文件头(bitmap-file header) |
BITMAPFILEHEADER |
bmfh |
|
位图信息头(bitmap-information header) |
BITMAPINFOHEADER |
bmih |
|
彩色表(color table) |
RGBQUAD |
aColors[] |
|
图像数据阵列字节 |
BYTE |
aBitmapBits[] |
位图文件结构可综合在表6-02中。
表6-02 位图文件结构内容摘要
偏移量
域的名称
大小
内容
图像文件头
0000h
标识符(Identifier)
2 bytes
两字节的内容用来识别位图的类型：
‘BM’： Windows 3.1x, 95, NT, …
‘BA’：OS/2 Bitmap Array
‘CI’：OS/2 Color Icon
‘CP’：OS/2 Color Pointer
‘IC’： OS/2 Icon
‘PT’：OS/2 Pointer
0002h
File Size
1 dword
用字节表示的整个文件的大小
0006h
Reserved
1 dword
保留，设置为0
000Ah
Bitmap Data Offset
1 dword
从文件开始到位图数据开始之间的数据(bitmap data)之间的偏移量
000Eh
Bitmap Header Size
1 dword
位图信息头(Bitmap Info Header)的长度，用来描述位图的颜色、压缩方法等。下面的长度表示：
28h - Windows 3.1x, 95, NT, …
0Ch - OS/2 1.x
F0h - OS/2 2.x
0012h
Width
1 dword
位图的宽度，以像素为单位
0016h
Height
1 dword
位图的高度，以像素为单位
001Ah
Planes
1 word
位图的位面数
图像信息头
001Ch
Bits Per Pixel
1 word
每个像素的位数
1 - Monochrome bitmap
4 - 16 color bitmap
8 - 256 color bitmap
16 - 16bit (high color) bitmap
24 - 24bit (true color) bitmap
32 - 32bit (true color) bitmap
001Eh
Compression
1 dword
压缩说明：
0 - none (也使用BI_RGB表示)
1 - RLE 8-bit / pixel (也使用BI_RLE4表示)
2 - RLE 4-bit / pixel (也使用BI_RLE8表示)
3 - Bitfields (也使用BI_BITFIELDS表示)
0022h
Bitmap Data Size
1 dword
用字节数表示的位图数据的大小。该数必须是4的倍数
0026h
HResolution
1 dword
用像素/米表示的水平分辨率
002Ah
VResolution
1 dword
用像素/米表示的垂直分辨率
002Eh
Colors
1 dword
位图使用的颜色数。如8-位/像素表示为100h或者 256.
0032h
Important Colors
1 dword
指定重要的颜色数。当该域的值等于颜色数时，表示所有颜色都一样重要
调色板数据
0036h
Palette
N * 4 byte
调色板规范。对于调色板中的每个表项，这4个字节用下述方法来描述RGB的值：
1字节用于蓝色分量
1字节用于绿色分量
1字节用于红色分量
1字节用于填充符(设置为0)
图像数据
0436h
Bitmap Data
x bytes
该域的大小取决于压缩方法，它包含所有的位图数据字节，这些数据实际就是彩色调色板的索引号
6.1.3 构件详解
1. 位图文件头
位图文件头包含有关于文件类型、文件大小、存放位置等信息，在Windows 3.0以上版本的位图文件中用BITMAPFILEHEADER结构来定义：
typedef struct tagBITMAPFILEHEADER { /* bmfh */
UINT bfType;
DWORD bfSize;
UINT bfReserved1;
UINT bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER;
其中：
bfType 说明文件的类型.
bfSize 说明文件的大小，用字节为单位
bfReserved1 保留，设置为0
bfReserved2 保留，设置为0
bfOffBits 说明从BITMAPFILEHEADER结构开始到实际的图像数据之间的字节偏移量
2. 位图信息头
位图信息用BITMAPINFO结构来定义，它由位图信息头(bitmap-information header)和彩色表(color table)组成，前者用BITMAPINFOHEADER结构定义，后者用RGBQUAD结构定义。BITMAPINFO结构具有如下形式：
typedef struct tagBITMAPINFO { /* bmi */
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[1];
} BITMAPINFO;
其中：
bmiHeader 说明BITMAPINFOHEADER结构
bmiColors 说明彩色表RGBQUAD结构的阵列
BITMAPINFOHEADER结构包含有位图文件的大小、压缩类型和颜色格式，其结构定义为：
typedef struct tagBITMAPINFOHEADER { /* bmih */
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER;
其中：
biSize 说明BITMAPINFOHEADER结构所需要的字节数
biWidth 说明图像的宽度，以像素为单位
biHeight 说明图像的高度，以像素为单位
biPlanes 为目标设备说明位面数，其值设置为1
biBitCount 说明位数/像素，其值为1、2、4或者24
biCompression 说明图像数据压缩的类型。其值可以是下述值之一：
BI_RGB：没有压缩；
BI_RLE8：每个像素8位的RLE压缩编码，压缩格式由2字节组成
(重复像素计数和颜色索引)；
BI_RLE4：每个像素4位的RLE压缩编码，压缩格式由2字节组成
biSizeImage 说明图像的大小，以字节为单位。当用BI_RGB格式时，可设置为0
biXPelsPerMeter 说明水平分辨率，用像素/米表示
biYPelsPerMeter 说明垂直分辨率，用像素/米表示
biClrUsed 说明位图实际使用的彩色表中的颜色索引数
biClrImportant 说明对图像显示有重要影响的颜色索引的数目，如果是0，表示都重要。
现就BITMAPINFOHEADER结构作如下说明：
(1) 彩色表的定位
应用程序可使用存储在biSize成员中的信息来查找在BITMAPINFO结构中的彩色表，如下所示：
pColor = ((LPSTR) pBitmapInfo + (WORD) (pBitmapInfo->bmiHeader.biSize))
(2) biBitCount
biBitCount=1 表示位图最多有两种颜色，黑色和白色。图像数据阵列中的每一位表示一个像素。
biBitCount=4 表示位图最多有16种颜色。每个像素用4位表示，并用这4位作为彩色表的表项来查找该像素的颜色。例如，如果位图中的第一个字节为0x1F，它表示有两个像素，第一像素的颜色就在彩色表的第2表项中查找，而第二个像素的颜色就在彩色表的第16表项中查找。
biBitCount=8 表示位图最多有256种颜色。每个像素用8位表示，并用这8位作为彩色表的表项来查找该像素的颜色。例如，如果位图中的第一个字节为0x1F，这个像素的颜色就在彩色表的第32表项中查找。
biBitCount=24 表示位图最多有2^24＝16 777 216种颜色。bmiColors(或者bmciColors)成员就为NULL。每3个字节代表一个像素，其颜色由R、G、B字节的相对强度决定。
(3) ClrUsed
BITMAPINFOHEADER结构中的成员ClrUsed指定实际使用的颜色数目。如果ClrUsed设置成0，位图使用的颜色数目就等于biBitCount成员中的数目。
(4) 图像数据压缩
① BI_RLE8：每个像素为8位的RLE压缩编码，可使用编码方式和绝对方式中的任何一种进行压缩，这两种方式可在同一幅图中的任何地方使用。
编码方式：由2个字节组成，第一个字节指定使用相同颜色的像素数目，第二个字节指定使用的颜色索引。此外，这个字节对中的第一个字节可设置为0，联合使用第二个字节的值表示：
●第二个字节的值为0：行的结束。
●第二个字节的值为1：图像结束。
●第二个字节的值为2：其后的两个字节表示下一个像素从当前开始的水平和垂直位置的偏移量。
绝对方式：第一个字节设置为0，而第二个字节设置为0x03～0xFF之间的一个值。在这种方式中，第二个字节表示跟在这个字节后面的字节数，每个字节包含单个像素的颜色索引。压缩数据格式需要字边界(word boundary)对齐。
[例6.1] 用十六进制表示的8位压缩图像数据如下：
03 04 05 06 00 03 45 56 67 00 02 78 00 02 05 01 02 78 00 00 09 1E 00 01
这些压缩数据可解释为 ：
|
压缩数据 |
扩展数据 |
|
03 04 |
04 04 04 |
|
05 06 |
06 06 06 06 06 |
|
00 03 45 56 67 00 |
45 56 67 |
|
02 78 |
78 78 |
|
00 02 05 01 |
从当前位置右移5个位置后向下移一行 |
|
02 78 |
78 78 |
|
00 00 |
行结束 |
|
09 1E |
1E 1E 1E 1E 1E 1E 1E 1E 1E |
|
00 01 |
RLE编码图像结束 |
② BI_RLE4：每个像素为4位的RLE压缩编码，同样也可使用编码方式和绝对方式中的任何一种进行压缩，这两种方式也可在同一幅图中的任何地方使用。这两种方式是：
编码方式：由2个字节组成，第一个字节指定像素数目，第二个字节包含两种颜色索引，一个在高4位，另一个在低4位。第一个像素使用高4位的颜色索引，第二个使用低4位的颜色索引，第3个使用高4位的颜色索引，依此类推。
这个字节对中的第一个字节设置为0，第二个字节包含有颜色索引数，其后续字节包含有颜色索引，颜色索引存放在该字节的高、低4位中，一个颜色索引对应一个像素。此外，BI_RLE4也同样联合使用第二个字节中的值表示：
●第二个字节的值为0：行的结束。
●第二个字节的值为1：图像结束。
●第二个字节的值为2：其后的两个字节表示下一个像素从当前开始的水平和垂直位置的偏移量。
[例6.2] 用十六进制数表示的4位压缩图像数据：
03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01 04 78 00 00 09 1E 00 01
这些压缩数据可解释为 ：
|
压缩数据 |
扩展数据 |
|
03 04 |
0 4 0 |
|
05 06 |
0 6 0 6 0 |
|
00 06 45 56 67 00 |
4 5 5 6 6 7 |
|
04 78 |
7 8 7 8 |
|
00 02 05 01 |
从当前位置右移5个位置后向下移一行 |
|
04 78 |
7 8 7 8 |
|
00 00 |
行结束 |
|
09 1E |
1 E 1 E 1 E 1 E 1 |
|
00 01 |
RLE图像结束 |
3. 彩色表
彩色表包含的元素与位图所具有的颜色数相同，像素的颜色用RGBQUAD结构来定义。对于24-位真彩色图像就不使用彩色表，因为位图中的RGB值就代表了每个像素的颜色。彩色表中的颜色按颜色的重要性排序，这可以辅助显示驱动程序为不能显示足够多颜色数的显示设备显示彩色图像。RGBQUAD结构描述由R、G、B相对强度组成的颜色，定义如下：
typedef struct tagRGBQUAD { /* rgbq */
BYTE rgbBlue;
BYTE rgbGreen;
BYTE rgbRed;
BYTE rgbReserved;
} RGBQUAD;
其中：
rgbBlue 指定蓝色强度
rgbGreen 指定绿色强度
rgbRed 指定红色强度
rgbReserved 保留，设置为0
4. 位图数据
紧跟在彩色表之后的是图像数据字节阵列。图像的每一扫描行由表示图像像素的连续的字节组成，每一行的字节数取决于图像的颜色数目和用像素表示的图像宽度。扫描行是由底向上存储的，这就是说，阵列中的第一个字节表示位图左下角的像素，而最后一个字节表示位图右上角的像素。
6.2 GIF文件格式
6.2.1 简介
GIF(Graphics Interchange Format)是CompuServe公司开发的图像文件存储格式，1987年开发的GIF文件格式版本号是GIF87a，1989年进行了扩充，扩充后的版本号定义为GIF89a。
GFI图像文件以数据块(block)为单位来存储图像的相关信息。一个GIF文件由表示图形/图像的数据块、数据子块以及显示图形/图像的控制信息块组成，称为GIF数据流(Data Stream)。数据流中的所有控制信息块和数据块都必须在文件头(Header)和文件结束块(Trailer)之间。
GIF文件格式采用了LZW(Lempel-Ziv Walch)压缩算法来存储图像数据，定义了允许用户为图像设置背景的透明(transparency)属性。此外，GIF文件格式可在一个文件中存放多幅彩色图形/图像。如果在GIF文件中存放有多幅图，它们可以像演幻灯片那样显示或者像动画那样演示。
6.2.2. 文件结构
GIF文件结构的典型结构如图6-01所示。为下文说明方便，在构件左边加了编号。
|
1 |
Header |
GIF文件头 | ||
|
2 |
Logical Screen Descriptor |
逻辑屏幕描述块 |
||
|
3 |
Global Color Table |
全局彩色表 |
||
|
… 扩展模块(任选) … |
||||
|
4 |
Image Descriptor |
图形描述块 |
||
|
5 |
Local Color Table |
局部彩色表(可重复n次) |
可 |
|
|
6 |
Table Based Image Data |
表式压缩图像数据 |
重 |
|
|
7 |
Graphic Control Extension |
图像控制扩展块 |
复 |
|
|
8 |
Plain Text Extension |
无格式文本扩展块 |
n |
|
|
9 |
Comment Extension |
注释扩展块 |
个 |
|
|
10 |
Applicaton Extension |
应用程序扩展块 |
||
|
… 扩展模块(任选) … |
||||
|
11 |
GIF Trailer |
GIF文件结束块 |
图6-01 GIF文件结构
数据块可分成3类：控制块(Control Block)，图形描绘块(Graphic-Rendering Block)和专用块(Special Purpose Block)。
(1) 控制块：控制块包含有用来控制数据流(Data Stream)或者设置硬件参数的信息，其成员包括：
●GIF文件头(Header)
●逻辑屏幕描述块(Logical Screen Descriptor)
●图形控制扩展块(Graphic Control Extension)
●文件结束块(Trailer)
(2) 图形描绘块：包含有用来描绘在显示设备上显示图形的信息和数据，其成员包括：
●图像描述块(Image Descriptor)
●无格式文本扩展块(Plain Text Extension)
(3) 特殊用途数据块：包含有与图像处理无关的信息，其成员包括：
●注释扩展块(Comment Extension)
●应用扩展块(Application Extension)
除了在控制块中的逻辑屏幕描述块(Logical Screen Descriptor)和全局彩色表(Global Color Table)的作用范围是整个数据流(Data Stream)之外, 所有其他控制块仅控制跟在它们后面的图形描绘块。
6.2.3 构件详解
1. GIF文件头
文件头描述块(Header)定义GIF数据流(GIF Data Stream)，它的结构如图6-02所示。文件头描述块(Header)由GIF标记域(Signature)和版本号(Version)域组成，是一个由6个固定字节组成的数据块，它们用来说明使用的文件格式是GIF格式及当前所用的版本号。GIF标记域(Signature)存放的是“GIF”，版本号域存放的是1987年5月发布的“87a”或者1989年7月发布的“89a”，或者更加新的版本号。
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
字节号 |
域的名称 |
数据类型 |
|||
|
0 |
|||||||||||||
|
Signature |
1 |
GIF标记 |
3 Bytes |
||||||||||
|
2 |
|||||||||||||
|
3 |
|||||||||||||
|
Version |
4 |
版本号 |
3 Bytes |
||||||||||
|
5 |
|||||||||||||
图6-02 标记/版本数据块的结构
2. 逻辑屏幕描述块
逻辑屏幕描述块(Logical Screen Descriptor)包含定义图像显示区域的参数，包括背景颜色信息。这个数据块中的坐标相对于虚拟屏幕的左上角，不一定是指显示屏的绝对坐标，这就意味可以参照窗口软件环境下的窗口坐标或者打印机坐标来设计图像显示程序。逻辑屏幕描述块的结构如图6-03所示：
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
字节号 |
域的名称 |
类型 |
||||
|
Logical Screen Width |
0 |
逻辑屏幕宽度 |
Unsigned |
|||||||||||
|
1 |
(以像素为定单位) |
|||||||||||||
|
Logical Screen Height |
2 |
逻辑屏幕高度 |
Unsigned |
|||||||||||
|
3 |
(以像素为定单位) |
|||||||||||||
|
G |
CR |
S |
Size |
4 |
包装域 |
见图6-04 |
||||||||
|
Background Color Index |
5 |
背景颜色索引 |
Byte |
|||||||||||
|
Pixel Aspect Ratio |
6 |
像素宽高比 |
Byte |
|||||||||||
图6-03 屏幕描述块的结构
逻辑描述块包含7个字节。字节0和字节1用来说明逻辑显示屏的宽度，字节3和字节4用来说明逻辑显示屏的高度，字节4用来描述彩色表的属性，字节5用来指定背景颜色索引，字节6用来计算像素的宽高比。现作如下说明：
(1) 屏幕描述块中的第5个字节称为包装域(Packed Fields)，它的位结构如图6-04所示，它由4个子域组成：
① 全局彩色表标志(Global Color Table Flag )域G用来说明是否有全局彩色表存在。如果G＝1，表示有一个全局彩色表(Global Color Table)将紧跟在这个逻辑屏幕描述块(Logical Screen Descriptor)之后；这个标志也用来选择背景颜色索引(Background Color Index)。如果G＝1，背景颜色索引(Background Color Index)域中的值就用作背景颜色的索引。
② 彩色分辨率(Color Resolution)域CR用来表示原始图像可用的每种基色的位数(实际值减1)。这个位数表示整个调色板的大小，而不是这幅图像使用的实际的颜色数。例如，如果该域的值CR＝3，说明原始图像可用每个基色有4位的调色板来生成彩色图像。
③ 彩色表排序标志(Sort Flag)域S用来表示全局彩色表(Global Color Table)中的颜色是否按重要性(或者称使用率)排序。如果S＝0，表示没有重要性排序；如果S＝1表示最重要的颜色排在前。这样做的目的是辅助颜色数比较少的解码器能够选择最好的颜色子集，在这种情况下解码器就可选择彩色表中开始段的彩色来显示图像。
④ 全局彩色表大小(Size of Global Color Table)域Size表示表示每个像素的位数，它用来计算全局彩色表(Global Color Table)中包含的字节数。在全局彩色表标志(Global Color Table Flag)域G＝0时就不需要计算，G＝1时就要计算彩色表的大小，具体计算见下文的“3.全局彩色表”。
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
Global Color Table Flag |
Color Resolution |
Sort Flag |
Size of Global Color Table |
||||
图6-04 逻辑屏幕描述块中的包装域结构
(2) 屏幕描述块中的第6个字节是背景颜色索引(Background Color Index)，它是彩色表的一个索引值，用来指定背景颜色。如果全局彩色表标志(Global Color Table Flag)域G＝0，这个域的值也设置为0。
(3) 像素宽高比(Pixel Aspect Ratio)域中的值是一个因数，是计算原始图像像素的宽高比的一个近似值。如果该域的值范围为1～255，如果不等于0，宽高比的近似值按下式计算：
Aspect Ratio = (Pixel Aspect Ratio + 15) / 64
像素宽高比(Pixel Aspect Ratio)定义成像素的宽度与高度之比，比值的范围在4:1～1:4之间，其增量为1/64。
3. 全局彩色表
由于一个GIF文件可以包含多幅彩色图像，每幅彩色图像也许都包含适合自身特点的彩色表，所以一个GIF文件可以有好几个彩色表。但归纳起来只有两类：全局彩色表(Global Color Table)或局部彩色表(Local Color Table)。全局彩色表可用于图像本身没有带彩色表的所有图像和无格式文本扩展块(Plain Text Extension)，而局部彩色表只用于紧跟在它后面的一幅图像。在处理全局彩色表和局部彩色表时需要注意下面一些规则。
① 如果GIF文件包含全局彩色表(Global Color Table)，而且要显示的图像本身又带有局部彩色表，那末显示该幅彩色图像时就用它自己的彩色表，而不用全局彩色表。在这种情况下，解码器就首先保存全局彩色表(Global Color Table)，然后使用局部彩色表(Local Color Table)来显示图像，最后再回复全局彩色表(Global Color Table)。
② 全局彩色表(Global Color Table)和局部彩色表(Local Color Table)都是可选择的。由于这个原因，解码器最好要保存全局彩色表(Global Color Table)，一直到出现另一个全局彩色表(Global Color Table)为止。这样做之后，对于包含完全没有彩色表的一幅或者多幅彩色图像的GIF文件就可以使用最后保存的全局彩色表(Global Color Table)进行处理。
③如果同类型的图像能够使用相同的彩色表来显示，编码器就要尽可能使用一个全局彩色表(Global Color Table)；如果没有彩色表可用，解码器就可以使用计算机系统提供的彩色表或者解码器自身的彩色表。
④ 全局彩色表(Global Color Table)存在与否由逻辑屏幕描述块(Logical Screen Descriptor)中字节5的全局彩色表标志(Global Color Table Flag )域G的值确定。如果存在，彩色表就紧跟在逻辑屏幕描述块(Logical Screen Descriptor)之后。彩色表的表项数目等于2(n +1)，其中n=b2b1b0，每个表项由3个字节组成，分别代表R、G、B的相对强度，因此彩色表的字节数就等于3×2(n+1)。彩色表的结构如图6-05所示。
|
7 6 5 4 3 2 1 0 |
字节号 |
域的名称 |
数据类型 |
|
red intensity |
0 |
红色索引 000 |
Byte |
|
green intensity |
1 |
绿色索引 000 |
Byte |
|
blue intensity |
2 |
蓝色索引 000 |
Byte |
|
red intensity |
3 |
红色索引 001 |
Byte |
|
green intensity |
4 |
绿色索引 001 |
Byte |
|
blue intensity |
5 |
蓝色索引 001 |
Byte |
|
… |
… |
… |
|
|
… |
… |
… |
|
|
red intensity |
745 |
红色索引 255 |
Byte |
|
green intensity |
746 |
绿色索引 255 |
Byte |
|
blue intensity |
767 |
蓝色索引 255 |
Byte |
图6-05 彩色表结构
局部彩色表与全局彩色表有相同的存储格式。
4. 图像描述块
GIF图像文件格式可包含数量不限的图像，而且也没有一个固定的存放顺序，仅用一个字节的图像分隔符(Image Separator)来判断是不是图像描述块。每一幅图像都由一个图像描述块(Image Descriptor)、可有可无的局部彩色表(Local Color Table)和图像数据组成。每幅图像必须要落在逻辑屏幕描述块(Logical Screen Descriptor)中定义的逻辑屏(Logical Screen)尺寸范围里。
图像描述块(Image Descriptor)之前可以有一个或者多个控制块，例如图形控制扩展块(Graphic Control Extension)，其后可以跟着一个局部彩色表(Local Color Table)。无论前后是否有各种数据块，图像描述块(Image Descriptor)总是带有图像数据。
图像描述块(Image Descriptor)的结构如图6-06所示。
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
字节号 |
域的名称 |
类型 |
||||
|
Image Separator |
0 |
图像分隔符 |
Byte |
|||||||||||
|
Image Left Position |
1 |
图像左边位置 |
Unsigned |
|||||||||||
|
2 |
(以像素为定单位) |
|||||||||||||
|
Image Top Position |
3 |
图像顶部位置 |
Unsigned |
|||||||||||
|
4 |
(以像素为定单位) |
|||||||||||||
|
Image Width |
5 |
图像宽度 |
Unsigned |
|||||||||||
|
6 |
(以像素为定单位) |
|||||||||||||
|
Image Height |
7 |
图像高度 |
Unsigned |
|||||||||||
|
8 |
(以像素为定单位) |
|||||||||||||
|
9 |
包装域 |
见图6-07 |
||||||||||||
图6-06 图像描述块的结构
在图6-06中，图像分隔符(Image Separator)用来标识图像描述块的开始，该域包含固定的值：0x2C；图像左边位置(Image Left Position)是相对于逻辑屏幕(Logical Screen)最左边的列号，逻辑屏幕最左边的列好定义为0；图像顶部位置(Image Top Position) 是相对于逻辑屏幕(Logical Screen)顶部的行号，逻辑屏幕顶部的行号定义为0。
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
Local Color Table Flag |
Interlace Flag |
Sort Flag |
Reserved |
Size of Local Color Table |
|||
图6-07 图像描述块中的包装域结构
图像描述块(Image Descriptor)中的第9个字节称为包装域(Packed Fields)字节，它的位结构如图6-07所示，它由5个子域组成：
① 局部彩色表标志(Local Color Table Flag )域L用来说明是否有局部彩色表存在。如果L＝1，表示有一个局部彩色表(Local Color Table)将紧跟在这个图像描述块(Image Descriptor)之后;如果G＝0，表示图像描述块(Image Descriptor)后面没有局部彩色表(Local Color Table)，该图像要使用全局彩色表(Global Color Table)。
② 交插显示标志(Interlace Flag)域I用来表示该图像是不是交插图像(Interlaced Images)。如果I＝0，表示该图像不是交插图像，如果I＝1表示该图像是交插图像。使用该位标志可知道图像数据是如何存放的。GIF文件格式定义了两种数据存储方式：一种是按图像行连续顺序存储，这个顺序与显示器上显示行的顺序相同；另一种按交插方式存储。交插图像按行分成如下所示的4组(Group)：
Group 1：每隔8行组成一组，从第0行开始显示 /第1遍交插
Group 2：每隔8行组成一组，从第4行开始显示 /第2遍交插
Group 3：每隔4行组成一组，从第2行开始显示 /第3遍交插
Group 4：每隔2行组成一组，从第1行开始显示 /第4遍交插
由于显示图像需要较长的时间，使用这种方法存放和显示图像数据，人们就可以在图像显示完成之前看到这幅图像的概貌，而不觉得显示时间长。图6-08说明了这种交插图像的存储和显示顺序。
|
行号 |
像 点 |
交插遍次 |
||||
|
0 |
…………………………………… |
1 |
||||
|
1 |
…………………………………… |
4 |
||||
|
2 |
…………………………………… |
3 |
||||
|
3 |
…………………………………… |
4 |
||||
|
4 |
…………………………………… |
2 |
||||
|
5 |
…………………………………… |
4 |
||||
|
6 |
…………………………………… |
3 |
||||
|
7 |
…………………………………… |
4 |
||||
|
8 |
…………………………………… |
1 |
||||
|
9 |
…………………………………… |
4 |
||||
|
10 |
…………………………………… |
3 |
||||
|
11 |
…………………………………… |
4 |
||||
|
12 |
…………………………………… |
2 |
||||
|
13 |
…………………………………… |
4 |
||||
|
14 |
…………………………………… |
3 |
||||
|
15 |
…………………………………… |
4 |
||||
|
16 |
…………………………………… |
1 |
||||
|
17 |
…………………………………… |
4 |
||||
|
18 |
…………………………………… |
3 |
||||
|
19 |
…………………………………… |
4 |
||||
图6-08 交插图像显示顺序
③ 彩色表排序标志(Sort Flag)域的含义与全局彩色表(Global Color Table)中(Sort Flag)域的含义相同。
④ 保留(Reserved)。
⑤ 局部彩色表大小(Size of Local Color Table)域的值用来计算局部彩色表(Global Color Table)中包含的字节数。
5. 局部彩色表
局部彩色表(Local Color Table)用于紧跟在它后面的图像。彩色表是否存在取决于图像描述块(Image Descriptor)中局部彩色表标志(Local Color Table Flag)位的设置。彩色表的结构和大小与全局彩色表(Global Color Table)完全相同。
6. 表基图像数据
GIF图像采用了LZW算法对实际的图像数据进行压缩。为了提高压缩编码的效率，对LZW编码器输出的代码采用可变长度码VLC(variable-length-code)，不是用位数高度的代码来表示输出，而且代表码字的位数是可变的。
表基图像数据(Table Based Image Data)由LZW最小代码长度(LZW Minimum Code Size)和图像数据(Image Data)组成，如图6-09所示。LZW最小代码长度域的值用来确定图像数据中LZW代码使用的初始位数。图像数据(Image Data)由数据子块(Data Sub-blocks)序列组成。
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
域的名称 |
类型 |
||||
|
LZW Minimum Code Size |
LZW最小代码长度
|
Byte |
|||||||||||
|
Image Data |
图像数据 |
Data Sub-blocks |
图6-09 图像数据的存储格式
数据子块(Data Sub-blocks)的结构如图6-10所示，这是一个可变长度的数据块，其长度由块大小域(Block Size)域中的值确定，字节数在0～255之间。
|
7 6 5 4 3 2 1 0 |
字节号 |
域的名称 |
数据类型 |
|
Block Size |
0 |
块大小 |
Byte |
|
1 |
Byte |
||
|
Byte |
|||
|
Data Values |
数值 |
Byte |
|
|
Byte |
|||
|
… |
… |
||
|
… |
… |
||
|
Byte |
|||
|
多 |
Byte |
||
|
到 |
Byte |
||
|
255 |
Byte |
图6-10 数据子块的结构
7. 图形控制扩展块
图形控制扩展块(Graphic Control Extension)包含处理图形描绘块时要使用的参数，它的结构如图6-11所示。现说明如下：
(1) 扩展导入符Extension Introducer)用于识别扩展块的开始，域中的值是一个数值等于0x21的固定值。
(2) 图形控制标签(Graphic Control Label)用于标识当前块是一个图形控制扩展块，域中的值是一个数值等于0xF9的固定值。
(3) 块大小(Block Size)用来说明该扩展块所包含字节数，该字节数是从这个块大小(Block Size)域之后到块结束符之间的字节数。
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
字节号 |
域的名称 |
类型 |
||||
|
Extension Introducer |
0 |
扩展导入符 |
Byte |
|||||||||||
|
Graphic Control Label |
1 |
图形扩展标签 |
Byte |
|||||||||||
|
Block Size |
0 |
块大小 |
Byte |
|||||||||||
|
<Packed Fields> |
1 |
包装域 |
See below |
|||||||||||
|
Delay Time |
2 |
延时时间 |
Unsigned |
|||||||||||
|
Transparent Color Index |
3 |
透明彩色索引 |
Byte |
|||||||||||
|
Block Terminator |
0 |
块结束符 |
Byte |
|||||||||||
图6-11 图像描述块的结构
(4) 包装域的结构如图6-12所示。处理方法(Disposal Method)规定图形显示之后译码器要用表6-03中所述方法进行处理。
表6-03 包装域规定的处理方法
|
域值 |
处理方法 |
|
0 |
没有指定要做任何处理 |
|
1 |
不处理，图形留在原处 |
|
2 |
显示图形的区域必须要恢复成背景颜色 |
|
3 |
恢复成以前显示的图形 |
|
4～7 |
(未定义) |
用户输入标志(User Input Flag)域表示在继续处理之前是否需要用户输入响应。在延时时间(Delay Time)和用户输入标志(User Input Flag)都设置为1的情况下，继续处理的开始时间取决于用户响应输入在前还是延时时间结束在前。
|
7 |
6 |
5 |
4 |
3 |
2 |
1 |
0 |
|
Reserved(保留) |
Disposal Method(处理方法) |
User Input Flag |
Transparent Color Flag |
||||
图6-12 图形控制扩展块的包装结构
(5) 透明(Transparency Flag)表示是否给出透明索引(transparency index)
(6) 延时时间(Delay Time)用来指定在图形显示之后继续处理数据流之前的等待时间，一百分之一秒为单位。
(7) 当且仅当透明标志位设置为1时，透明索引(Transparency Index)用来指示处理程序是否要修改显示设备上的相应象点。当且仅当透明标志位设置为1时，就要修改。
(8) 块结束符(Block Terminator)表示该图形控制扩展块(Graphic Control Extension)结束，它是由一个字节组成的数据块，该域的值是一个固定的值：0x00，因此称为零长度数据子块(zero-length Data Sub-block)。
8. 无格式文本扩展块
无格式文本扩展块(Plain Text Extension)包含文本数据和描绘文本所须的参数。文本数据用7位的ASCII字符编码并以图形形式显示。扩展块的结构如图6-13所示。
|
7 6 5 4 3 2 1 0 |
字节号 |
域的名称 |
数据类型 |
|
Extension Introducer (0x21) |
0 |
扩展导入符 |
Byte |
|
Plain Text Label (0x01) |
1 |
无格式文本标签 |
Byte |
|
Block Size |
0 |
块大小 |
Byte |
|
Text Grid Left Position |
1 |
文本网格左列位置 |
Unsigned |
|
2 |
|||
|
Text Grid Top Position |
3 |
文本网格顶行位置 |
Unsigned |
|
4 |
|||
|
Text Grid Width |
5 |
文本网格宽度 |
Unsigned |
|
6 |
|||
|
Text Grid Height |
7 |
文本网格高度 |
Unsigned |
|
8 |
|||
|
Character Cell Width |
9 |
字符单元宽度 |
Byte |
|
Character Cell Height |
10 |
字符单元高度 |
Byte |
|
Text Foreground Color Index |
11 |
文本颜色索引 |
Byte |
|
Text Background Color Index |
12 |
文本背景颜色索引 |
Byte |
|
Plain Text Data |
无格式文本数据 |
Data Sub-blocks |
|
图6-13 无格式文本扩展块结构
9. 注释扩展块
注释扩展块(Comment Extension)域的内容用来说明图形、作者或者其他任何非图形数据和控制信息的文本信息。
注释扩展块的结构如图6-14所示。其中的注释数据是序列数据子块(Data Sub-blocks)，每块最多255个字节，最少1个字节。
|
7 6 5 4 3 2 1 0 |
字节号 |
域的名称 |
数据类型 |
|
Extension Introducer (0x21) |
0 |
扩展导入符 |
Byte |
|
Comment Label (0xFE) |
1 |
注释标签 |
Byte |
|
Comment Data |
0 |
注释数据 |
|
|
Data Sub-blocks |
|||
|
… |
|||
|
N－1 |
|
Block Terminator |
块结束符 |
Byte |
图6-14 注释扩展块
10. 应用扩展块
应用扩展块(Application Extension)包含制作该图像文件的应用程序的相关信息，它的结构如图6-15所示。
|
7 6 5 4 3 2 1 0 |
字节号 |
域的名称 |
数据类型 |
|
Extension Introducer (0x21) |
0 |
扩展导入符 |
Byte |
|
Extension Label (0xFF) |
1 |
扩展标签 |
Byte |
|
Block Size |
0 |
块大小 |
Byte |
|
1 |
|||
|
2 |
|||
|
3 |
|||
|
Application Identifier |
4 |
应用程序标识符 |
8 Bytes |
|
5 |
(程序名称) |
||
|
6 |
|||
|
7 |
|||
|
8 |
|||
|
9 |
|||
|
Appl. Authentication Code |
10 |
应用程序识别码 |
3 Bytes |
|
11 |
|
Application Data |
应用数据 |
Data Sub-blocks |
|
|
Block Terminator |
0 |
Byte |
图6-15 应用扩展块
11. GIF文件结束块
结束块(GIF Trailer)表示GIF文件的结尾，它包含一个固定的数值：0x3B。它具有如图6-16所示的结构。
|
7 6 5 4 3 2 1 0 |
域的名称 |
数据类型 |
|
GIF Trailer = 0x3B |
GFI文件结束块 |
Byte |
图6-16 GIF文件结束块
6.2.4 速差表
表6-04 GIF文件格式
|
块的名称 |
需要 |
标签 |
扩展 |
版本号. |
|
Application Extension(应用扩展) |
Opt. (*) |
0xFF (255) |
yes |
89a |
|
Comment Extension(注释扩展) |
Opt. (*) |
0xFE (254) |
yes |
89a |
|
Global Color Table(全局彩色表) |
Opt. (1) |
none |
no |
87a |
|
Graphic Control Extension(图形控制扩展) |
Opt. (*) |
0xF9 (249) |
yes |
89a |
|
Header(文件头) |
Req. (1) |
none |
no |
N/A |
|
Image Descriptor(图像描述) |
Opt. (*) |
0x2C (044) |
no |
87a (89a) |
|
Local Color Table(局部彩色表) |
Opt. (*) |
none |
no |
87a |
|
Logical Screen Descriptor(逻辑屏幕描述块) |
Req. (1) |
none |
no |
87a (89a) |
|
Plain Text Extension(无格式文本扩展) |
Opt. (*) |
0x01 (001) |
yes |
89a |
|
Trailer(文件结束) |
Req. (1) |
0x3B (059) |
no |
87a |
Unlabeled Blocks(无标号块)
|
Header(文件头) |
Req. (1) |
none |
no |
N/A |
|
Logical Screen Descriptor(逻辑屏幕描述块) |
Req. (1) |
none |
no |
87a (89a) |
|
Global Color Table(全局彩色表) |
Opt. (1) |
none |
no |
87a |
|
Local Color Table(局部彩色表) |
Opt. (*) |
none |
no |
87a |
Graphic-Rendering Blocks(图像描绘块)
|
Plain Text Extension(无格式文本扩展) |
Opt. (*) |
0x01 (001) |
yes |
89a |
|
Image Descriptor(图像描述块) |
Opt. (*) |
0x2C (044) |
no |
87a (89a) |
Control Blocks(控制块)
|
Graphic Control Extension(图形控制扩展) |
Opt. (*) |
0xF9 (249) |
yes |
89a |
Special Purpose Blocks(专用块)
|
Trailer(结束) |
Req. (1) |
0x3B (059) |
no |
87a |
|
Comment Extension(注释扩展) |
Opt. (*) |
0xFE (254) |
yes |
89a |
|
Application Extension(应用程序扩展) |
Opt. (*) |
0xFF (255) |
yes |
89a |
表中：Req. (1) 表示最多出现一次
Opt. (*) 出现次数大于等于0
6.3.1 简介
微处理机中的存放顺序有正序(big endian)和逆序(little endian)之分。正序存放就是高字节存放在前低字节在后，而逆序存放就是低字节在前高字节在后。例如，十六进制数为A02B，正序存放就是A02B，逆序存放就是2BA0。摩托罗拉(Motorola)公司的微处理器使用正序存放，而英特尔(Intel)公司的微处理器使用逆序。JPEG文件中的字节是按照正序排列的。
JPEG委员会在制定JPEG标准时，定义了许多标记(marker)用来区分和识别图像数据及其相关信息，但笔者没有找到JPEG委员会对JPEG文件交换格式的明确定义。直到1998年12月从分析网上具体的JPG图像来看，使用比较广泛的还是JPEG文件交换格式(JPEG File Interchange Format，JFIF)版本号为1.02。这是1992年9月由在C-Cube Microsystems公司工作的Eric Hamilton提出的。此外还有TIFF JPEG等格式，但由于这种格式比较复杂，因此大多数应用程序都支持JFIF文件交换格式。
JPEG文件使用的颜色空间是CCIR 601推荐标准进行的彩色空间(参看第7章)。在这个彩色空间中，每个分量、每个像素的电平规定为255级，用8位代码表示。从RGB转换成YCbCr空间时，使用下面的精确的转换关系：
Y = 256 * E'y
Cb = 256 * [E'Cb] + 128
Cr = 256 * [E'Cr] + 128
其中亮度电平E'y和色差电平E'Cb和E'Cb分别是CCIR 601定义的参数。由于E'y的范围是0～1，E'Cb和E'Cb的范围是-0.5～+0.5，因此Y,Cb和Cr的最大值必须要箝到255。于是RGB和YCbCr之间的转换关系需要按照下面的方法计算。
(1) 从RGB转换成YCbCr
YCbCr(256级)分量可直接从用8位表示的RGB分量计算得到：
Y = 0.299R + 0.587G + 0.114B
Cb = - 0.1687R - 0.3313G + 0.5B + 128
Cr = 0.5R - 0.4187G - 0.0813B + 128
需要注意的是不是所有图像文件格式都按照R0，G0，B0，…… Rn，Gn，Bn的次序存储样本数据，因此在RGB文件转换成JFIF文件时需要首先验证RGB的次序。
(2) 从YCbCr转换成RGB
RGB分量可直接从YCbCr(256级)分量计算得到：
R = Y + 1.402(Cr-128)
G = Y - 0.34414(Cb-128) - 0.71414(Cr-128)
B = Y + 1.772(Cb-128)
在JFIF文件格式中，图像样本的存放顺序是从左到右和从上到下。这就是说JFIF文件中的第一个图像样本是图像左上角的样本。
6.3.2 文件结构
JFIF文件格式直接使用JPEG标准为应用程序定义的许多标记，因此JFIF格式成了事实上JPEG文件交换格式标准。JPEG的每个标记都是由2个字节组成，其前一个字节是固定值0xFF。每个标记之前还可以添加数目不限的0xFF填充字节(fill byte)。下面是其中的8个标记：
1.SOI 0xD8 图像开始
2.APP0 0xE0 JFIF应用数据块
3.APPn 0xE1 - 0xEF 其他的应用数据块(n, 1～15)
4.DQT 0xDB 量化表
5.SOF0 0xC0 帧开始
6.DHT 0xC4 霍夫曼(Huffman)表
7.SOS 0xDA 扫描线开始
8.EOI 0xD9 图像结束
为使读者对JPEG定义的标记一目了然，现将JPEG的标记码列于表6-05，并保留英文解释。
表6-05 JPEG定义的标记
|
Symbol(符号) |
Code Assignment(标记代码) |
Description(说明) |
|
Start Of Frame markers, non-hierarchical Huffman coding |
||
|
SOF0 |
0xFFC0 |
Baseline DCT |
|
SOF1 |
0xFFC1 |
Extended sequential DCT |
|
SOF2 |
0xFFC2 |
Progressive DCT |
|
SOF3 |
0xFFC3 |
Spatial (sequential) lossless |
|
Start Of Frame markers, hierarchical Huffman coding |
||
|
SOF5 |
0xFFC5 |
Differential sequential DCT |
|
SOF6 |
0xFFC6 |
Differential progressive DCT |
|
SOF7 |
0xFFC7 |
Differential spatial lossless |
|
Start Of Frame markers, non-hierarchical arithmetic coding |
||
|
JPG |
0xFFC8 |
Reserved for JPEG extensions |
|
SOF9 |
0xFFC9 |
Extended sequential DCT |
|
SOF10 |
0xFFCA |
Progressive DCT |
|
SOF11 |
0xFFCB |
Spatial (sequential) Lossless |
|
Start Of Frame markers, hierarchical arithmetic coding |
||
|
SOF13 |
0xFFCD |
Differential sequential DCT |
|
SOF14 |
0xFFCE |
Differential progressive DCT |
|
SOF15 |
0xFFCF |
Differential spatial Lossless |
|
Huffman table specification |
||
|
DHT |
0xFFC4 |
Define Huffman table(s) |
|
arithmetic coding conditioning specification |
||
|
DAC |
0xFFCC |
Define arithmetic conditioning table |
|
Restart interval termination |
||
|
RSTm |
0xFFD0～0xFFD7 |
Restart with modulo 8 counter m |
|
Other marker |
||
|
SOI |
0xFFD8 |
Start of image |
|
EOI |
0xFFD9 |
End of image |
|
SOS |
0xFFDA |
Start of scan |
|
DQT |
0xFFDB |
Define quantization table(s) |
|
DNL |
0xFFDC |
Define number of lines |
|
DRI |
0xFFDD |
Define restart interval |
|
DHP |
0xFFDE |
Define hierarchical progression |
|
EXP |
0xFFDF |
Expand reference image(s) |
|
APPn |
0xFFE0～0xFFEF |
Reserved for application use |
|
JPGn |
0xFFF0～0xFFFD |
Reserved for JPEG extension |
|
COM |
0xFFFE |
Comment |
|
Reserved markers |
||
|
TEM |
0xFF01 |
For temporary use in arithmetic coding |
|
RES |
0xFF02～0xFFBF |
Reserved |
JPEG文件由下面的8个部分组成：
(1) 图像开始SOI(Start of Image)标记
(2) APP0标记(Marker)
① APP0长度(length)
② 标识符(identifier)
③ 版本号(version)
④ X和Y的密度单位(units=0：无单位；units=1：点数/英寸；units=2：点数/厘米)
⑤ X方向像素密度(X density)
⑥ Y方向像素密度(Y density)
⑦ 缩略图水平像素数目(thumbnail horizontal pixels)
⑧ 缩略图垂直像素数目(thumbnail vertical pixels)
⑨ 缩略图RGB位图(thumbnail RGB bitmap)
(3) APPn标记(Markers)，其中n=1～15(任选)
① APPn长度(length)
② 由于详细信息(application specific information)
(4) 一个或者多个量化表DQT(difine quantization table)
① 量化表长度(quantization table length)
② 量化表数目(quantization table number)
③ 量化表(quantization table)
(5) 帧图像开始SOF0(Start of Frame)
① 帧开始长度(start of frame length)
② 精度(precision)，每个颜色分量每个像素的位数(bits per pixel per color component)
③ 图像高度(image height)
④ 图像宽度(image width)
⑤ 颜色分量数(number of color components)
⑥ 对每个颜色分量(for each component)
ID
垂直方向的样本因子(vertical sample factor)
水平方向的样本因子(horizontal sample factor)
量化表号(quantization table#)
(6) 一个或者多个霍夫曼表DHT(Difine Huffman Table)
① 霍夫曼表的长度(Huffman table length)
② 类型、AC或者DC(Type, AC or DC)
③ 索引(Index)
④ 位表(bits table)
⑤ 值表(value table)
(7) 扫描开始SOS(Start of Scan)
① 扫描开始长度(start of scan length)
② 颜色分量数(number of color components)
③ 每个颜色分量
ID
交流系数表号(AC table #)
直流系数表号(DC table #)
④ 压缩图像数据(compressed image data)
(8) 图像结束EOI(End of Image)
表6-06表示了APP0域的详细结构。有兴趣的读者可通过UltraEdit或者PC TOOLS等工具软件打开一个JPG图像文件，对APP0的结构进行分析和验证。
表6-06 JFIF格式中APP0域的详细结构
3n
< Thumbnail RGB bitmap>
缩略RGB位图(n为缩略图的像素数)
2 byte
0xFFD9
(EOI) end-of-file
图像文件结束标记
|
偏移 |
长度 |
内容 |
块的名称 |
说明 |
|
0 |
2 byte |
0xFFD8 |
(Start of Image,SOI) |
图像开始 |
|
2 |
2 byte |
0xFFE0 |
APP0(JFIF application segment) |
JFIF应用数据块 |
|
4 |
2 bytes |
length of APP0 block |
APP0块的长度 |
|
|
6 |
5 bytes |
"JFIF"+"0" |
识别APP0标记 |
|
|
11 |
1 byte |
<Major version> |
主要版本号(如版本1.02中的1) |
|
|
12 |
1 byte |
<Minor version> |
次要版本号(如版本1.02中的02) |
|
|
13 |
1 byte |
<Units for the X |
X和Y的密度单位 |
|
|
14 |
2 bytes |
<Xdensity> |
水平方向像素密度 |
|
|
16 |
2 bytes |
<Ydensity> |
垂直方向像素密度 |
|
|
18 |
1 byte |
<Xthumbnail> |
缩略图水平像素数目 |
|
|
19 |
1 byte |
<Ythumbnail> |
缩略图垂直像素数目 |
|
|
Optional JFIF extension APP0 marker segment(s) |
任选的JFIF扩展APP0标记段 |
|||
|
…… |
…… |
|||
6.4 PNG格式
6.4.1 简介
PNG是20世纪90年代中期开始开发的图像文件存储格式，其目的是企图替代GIF和TIFF文件格式，同时增加一些GIF文件格式所不具备的特性。流式网络图形格式(Portable Network Graphic Format，PNG)名称来源于非官方的“PNG's Not GIF”，是一种位图文件(bitmap file)存储格式，读成“ping”。PNG用来存储灰度图像时，灰度图像的深度可多到16位，存储彩色图像时，彩色图像的深度可多到48位，并且还可存储多到16位的α通道数据。PNG使用从LZ77派生的无损数据压缩算法。
PNG文件格式保留GIF文件格式的下列特性：
1.使用彩色查找表或者叫做调色板可支持256种颜色的彩色图像。
2.流式读/写性能(streamability)：图像文件格式允许连续读出和写入图像数据，这个特性很适合于在通信过程中生成和显示图像。
3.逐次逼近显示(progressive display)：这种特性可使在通信链路上传输图像文件的同时就在终端上显示图像，把整个轮廓显示出来之后逐步显示图像的细节，也就是先用低分辨率显示图像，然后逐步提高它的分辨率。
4.透明性(transparency)：这个性能可使图像中某些部分不显示出来，用来创建一些有特色的图像。
5.辅助信息(ancillary information)：这个特性可用来在图像文件中存储一些文本注释信息。
6.独立于计算机软硬件环境。
7.使用无损压缩。
PNG文件格式中要增加下列GIF文件格式所没有的特性：
1.每个像素为48位的真彩色图像。
2.每个像素为16位的灰度图像。
3.可为灰度图和真彩色图添加α通道。
4.添加图像的γ信息。
5.使用循环冗余码(cyclic redundancy code，CRC)检测损害的文件。
6.加快图像显示的逐次逼近显示方式。
7.标准的读/写工具包。
6.4.2 文件结构
PNG图像格式文件(或者称为数据流)由一个8字节的PNG文件署名(PNG file signature)域和按照特定结构组织的3个以上的数据块(chunk)组成。
PNG定义了两种类型的数据块，一种是称为关键数据块(critical chunk)，这是标准的数据块，另一种叫做辅助数据块(ancillary chunks)，这是可选的数据块。关键数据块定义了4个标准数据块，每个PNG文件都必须包含它们，PNG读写软件也都必须要支持这些数据块。虽然PNG文件规范没有要求PNG编译码器对可选数据块进行编码和译码，但规范提倡支持可选数据块。
(1) PNG文件署名域
8字节的PNG文件署名域用来识别该文件是不是PNG文件。该域的值是：
|
十进制数 |
137 |
80 |
78 |
71 |
13 |
10 |
26 |
10 |
|
十六进制数 |
89 |
50 |
4e |
47 |
0d |
0a |
1a |
0a |
(2) 数据块的结构
每个数据块都由表6-07所示的的4个域组成。
表6-07 PNG文件数据块的结构
|
名称 |
字节数 |
说明 |
|
Length(长度) |
4字节 |
指定数据块中数据域的长度，其长度不超过(231－1)字节 |
|
Chunk Type Code(数据块类型码) |
4字节 |
数据块类型码由ASCII字母(A-Z和a-z)组成 |
|
Chunk Data(数据块数据) |
可变长度 |
存储按照Chunk Type Code指定的数据 |
|
CRC(循环冗余检测) |
4字节 |
存储用来检测是否有错误的循环冗余码 |
在表6-07中，CRC(cyclic redundancy check)域中的值是对Chunk Type Code域和Chunk Data域中的数据进行计算得到的。CRC具体算法定义在ISO 3309和ITU-T V.42中，其值按下面的CRC码生成多项式进行计算：
x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1
6.4.3 数据块结构
1. 关键数据块
关键数据块中的4个标准数据块是：
(1) 文件头数据块IHDR(header chunk)：它包含有PNG文件中存储的图像数据的基本信息，并要作为第一个数据块出现在PNG数据流中，而且一个PNG数据流中只能有一个文件头数据块。
文件头数据块由13字节组成，它的格式如表6-08所示。
表6-08 PNG文件头键数据块的结构
|
域的名称 |
字节数 |
说明 |
|
Width |
4 bytes |
图像宽度，以像素为单位 |
|
Height |
4 bytes |
图像高度，以像素为单位 |
|
Bit depth |
1 byte |
图像深度： |
|
ColorType |
1 byte |
颜色类型： |
|
Compression method |
1 byte |
压缩方法(LZ77派生算法) |
|
Filter method |
1 byte |
滤波器方法 |
|
Interlace method |
1 byte |
隔行扫描方法： |
(2) 调色板数据块PLTE(palette chunk)：它包含有与索引彩色图像((indexed-color image))相关的彩色变换数据，它仅与索引彩色图像有关，而且要放在图像数据块(image data chunk)之前。真彩色的PNG数据流也可以有调色板数据块，目的是便于非真彩色显示程序用它来量化图像数据，从而显示该图像。调色板数据块结构如表6-09所示。
表6-09 调色板数据块结构
|
域的名称 |
字节数 |
说明 |
|
Red |
1 byte |
0 = 黑，255 = 红 |
|
Green |
1 byte |
0 = 黑，255 = 绿 |
|
Blue |
1 byte |
0 = 黑，255 = 蓝 |
调色板实际是一个彩色索引查找表，它的表项数目可以是1～256中的一个数，每个表项有3字节，因此调色板数据块所包含的最大字节数为768。
(3) 图像数据块IDAT(image data chunk)：它存储实际的数据，在数据流中可包含多个连续顺序的图像数据块。
(4) 图像结束数据IEND(image trailer chunk)：它用来标记PNG文件或者数据流已经结束，并且必须要放在文件的尾部。
除了表示数据块开始的IHDR必须放在最前面， 表示PNG文件结束的IEND数据块放在最后面之外，其他数据块的存放顺序没有限制。
2. 辅助数据块
PNG文件格式规范制定的10个辅助数据块是：
(1) 背景颜色数据块bKGD(background color)。
(2) 基色和白色度数据块cHRM(primary chromaticities and white point)。所谓白色度是指当R＝G＝B＝最大值时在显示器上产生的白色度。
(3) 图像γ数据块gAMA(image gamma)。
(4) 图像直方图数据块hIST(image histogram)。
(5) 物理像素尺寸数据块pHYs(physical pixel dimensions)。
(6) 样本有效位数据块sBIT(significant bits)。
(7) 文本信息数据块tEXt(textual data)。
(8) 图像最后修改时间数据块tIME (image last-modification time)。
(9) 图像透明数据块tRNS (transparency)。
(10) 压缩文本数据块zTXt (compressed textual data)。
3. 数据块摘要
关键数据块、辅助数据块和专用公共数据块(special-purpose public chunks)综合在表6-10中。
表6-10 PNG文件格式中的数据块
|
数据块符号 |
数据块名称 |
多数据块 |
可选否 |
位置限制 |
||
|
IHDR |
文件头数据块 |
否 |
否 |
第一块 |
||
|
cHRM |
基色和白色点数据块 |
否 |
是 |
在PLTE和IDAT之前 |
||
|
gAMA |
图像γ数据块 |
否 |
是 |
在PLTE和IDAT之前 |
||
|
sBIT |
样本有效位数据块 |
否 |
是 |
在PLTE和IDAT之前 |
||
|
PLTE |
调色板数据块 |
否 |
是 |
在IDAT之前 |
||
|
bKGD |
背景颜色数据块 |
否 |
是 |
在PLTE之后IDAT之前 |
||
|
hIST |
图像直方图数据块 |
否 |
是 |
在PLTE之后IDAT之前 |
||
|
tRNS |
图像透明数据块 |
否 |
是 |
在PLTE之后IDAT之前 |
||
|
oFFs |
(专用公共数据块) |
否 |
是 |
在IDAT之前 |
||
|
pHYs |
物理像素尺寸数据块 |
否 |
是 |
在IDAT之前 |
||
|
sCAL |
(专用公共数据块) |
否 |
是 |
在IDAT之前 |
||
|
IDAT |
图像数据块 |
是 |
否 |
与其他IDAT连续 |
||
|
tIME |
图像最后修改时间数据块 |
否 |
是 |
无限制 |
||
|
tEXt |
文本信息数据块 |
是 |
是 |
无限制 |
||
|
zTXt |
压缩文本数据块 |
是 |
是 |
无限制 |
||
|
fRAc |
(专用公共数据块) |
是 |
是 |
无限制 |
||
|
gIFg |
(专用公共数据块) |
是 |
是 |
无限制 |
||
|
gIFt |
(专用公共数据块) |
是 |
是 |
无限制 |
||
|
gIFx |
(专用公共数据块) |
是 |
是 |
无限制 |
||
|
IEND |
图像结束数据 |
否 |
否 |
最后一个数据块 |
||
tEXt<和zTXt数据块中的标准关键字：
Title 图像名称或者标题
Author 图像作者名
Description 图像说明
Copyright 版权声明
CreationTime 原图创作时间
Software 创作图像使用的软件
Disclaimer 弃权
Warning 图像内容警告
Source 创作图像使用的设备
Comment 各种注释
6.5 图像文件后缀一览表
文件格式是存储文本、图形或者图像数据的一种数据结构。在文字处理中，存储文本文件要使用文件格式。例如，使用微软公司的Word处理器编写的文件，可根据不同的应用环境用不同的格式存储。如果使用多信息文本格式(Rich Text Format，RTF)存储，这个文件就可在其他的平台(如Mac机)或者使用其他的字处理器进行处理。同样，存储图像也需要有存储格式，从20世纪70年代图像开始进入计算机以来，开发了许许多多的图像文件存储格式，而且互相不兼容，需要使用针对特定格式的处理软件。现在都意识到，不兼容的格式给用户造成很多的不便，因此有些格式也逐渐被淘汰。
在计算机中，有两种类型的图：矢量图(vector graphics)和位映象图(bitmapped graphics)。矢量图是用数学方法描述的一系列点、线、弧和其他几何形状，如图6-17(a)所示。因此存放这种图使用的格式称为矢量图格式，存储的数据主要是绘制图形的数学描述；位映象图(bitmapped graphics)也称光栅图(raster graphics)，这种图就像电视图像一样，由象点组成的，如图6-17(b)，因此存放这种图使用的格式称为位映象图格式，经常简称为位图格式，存储的数据是描述像素的数值。
图6-17 矢量图与位映象图
除了本章介绍的4种常用格式之外，在我们的工作中还会遇到其他图像格式。为方便查阅，现将部分图形与图像文件的后缀和名称列在表6-11@和表6-12@中。如果编写程序需要很专业的图像格式资源，包括一些源程序(source code)，可以访问站点：http://www.wotsit.org/，你可饱览多媒体世界中的各种媒体的存储格式。
表6-11@ 位映象图格式/光栅图光栅(bitmapped formats / raster graphics)
|
后缀 |
文件名称 |
后缀 |
文件名称 |
|
AG4 |
Access G4 document imaging |
JFF |
JPEG (JFIF) |
|
ATT |
AT&T Group IV |
JPG |
JPEG |
|
BMP |
Windows & OS/2 |
KFX |
Kofax Group IV |
|
CAL |
CALS Group IV |
MAC |
MacPaint |
|
CIT |
Intergraph scanned images |
MIL |
Same as GP4 extension |
|
CLP |
Windows Clipboard |
MSP |
Microsoft Paint |
|
CMP |
Photomatrix G3/G4 scanner format |
NIF |
Navy Image File |
|
CMP |
LEAD Technologies |
PBM |
Portable bitmap |
|
CPR |
Knowledge Access |
PCD |
PhotoCD |
|
CT |
Scitex Continuous Tone |
PCX |
PC Paintbrush |
|
CUT |
Dr. Halo |
PIX |
Inset Systems (HiJaak) |
|
DBX |
DATABEAM |
PNG |
Portable Network Graphics |
|
DX |
Autotrol document imaging |
PSD |
Photoshop native format |
|
ED6 |
EDMICS (U.S. DOD) |
RAS |
Sun |
|
EPS |
Encapsulated PostScript |
RGB |
SGI |
|
FAX |
Fax |
RIA |
Alpharel Group IV document imaging |
|
FMV |
FrameMaker |
RLC |
Image Systems |
|
GED |
Arts & Letters |
RLE |
Various RLE-compressed formats |
|
GDF |
IBM GDDM format |
RNL |
GTX Runlength |
|
GIF |
CompuServe |
SBP |
IBM StoryBoard |
|
GP4 |
CALS Group IV - ITU Group IV |
SGI |
Silicon Graphics RGB |
|
GX1 |
Show Partner |
SUN |
Sun |
|
GX2 |
Show Partner |
TGA |
Targa |
|
ICA |
IBM IOCA (see MO:DCA) |
TIF |
TIFF |
|
ICO |
Windows icon |
WPG |
WordPerfect image |
|
IFF |
Amiga ILBM |
XBM |
X Window bitmap |
|
IGF |
Inset Systems (HiJaak) |
XPM |
X Window pixelmap |
|
IMG |
GEM Paint |
XWD |
X Window dump |
表6-12@ 矢量图格式(vector graphics formats)
|
后缀 |
文件名称 |
后缀 |
文件名称 |
|
3DS |
3D Studio |
GEM |
GEM proprietary |
|
906 |
Calcomp plotter |
G4 |
GTX RasterCAD - scanned images into vectors for AutoCAD |
|
AI |
Adobe Illustrator |
IGF |
Inset Systems (HiJaak) |
|
CAL |
CALS subset of CGM |
IGS |
IGES |
|
CDR |
CorelDRAW |
MCS |
MathCAD |
|
CGM |
Computer Graphics Metafile |
MET |
OS/2 metafile |
|
CH3 |
Harvard Graphics chart |
MRK |
Informative Graphics markup file |
|
CLP |
Windows clipboard |
P10 |
Tektronix plotter (PLOT10) |
|
CMX |
Corel Metafile Exchange |
PCL |
HP LaserJet |
|
DG |
Autotrol |
PCT |
Macintosh PICT drawings |
|
DGN |
Intergraph drawing format |
PDW |
HiJaak |
|
DRW |
Micrografx Designer 2.x, 3.x |
PGL |
HP plotter |
|
DS4 |
Micrografx Designer 4.x |
PIC |
Variety of picture formats |
|
DSF |
Micrografx Designer 6.x |
PIX |
Inset Systems (HiJaak) |
|
DXF |
AutoCAD |
PLT |
HPGL Plot File (HPGL2 has raster format) |
|
DWG |
AutoCAD |
PS |
PostScript Level 2 |
|
EMF |
Enhanced metafile |
RLC |
Image Systems "CAD Overlay ESP" |
|
EPS |
Encapsulated PostScript |
SSK |
SmartSketch |
|
ESI |
Esri plot file (GIS mapping) |
WMF |
Windows Metafile |
|
FMV |
FrameMaker |
WPG |
WordPerfect graphics |
|
GCA |
IBM GOCA |
WRL |
VRML |
|
|
|
后缀 |
文件名称 |
练习与思考题
1.什么叫做α通道？它的作用是什么？
2.在计算机中找一幅像素深度为24的彩色图像，使用Office 97中的Microsoft Photo Editor或者其他图像处理软件显示该图像，然后用GIF格式存储，再显示GIF图像。观察图像有什么变化，并分析其原因。
3.PNG图像文件格式的主要特点是什么？
4.通过调查、试验和分析，把BMP，GIF，JFIF和PNG格式的一些特性填入下表。
|
图像格式名称 |
是不是有损压缩 |
支持的最大颜色数 |
是否支持α通道 |
BMP |
GIF |
JFIF |
PNG |
