第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 |
兩字節的內容用來識別位圖的類型: |
0002h |
File Size |
1 dword |
用字節表示的整個文件的大小 |
|
000Ah |
Bitmap Data Offset |
1 dword |
從文件開始到位圖數據開始之間的數據(bitmap data)之間的偏移量 |
|
0012h |
Width |
1 dword |
位圖的寬度,以像素爲單位 |
|
0016h |
Height |
1 dword |
位圖的高度,以像素爲單位 |
|
001Ah |
Planes |
1 word |
位圖的位面數 |
|
|
001Ch |
Bits Per Pixel |
1 word |
每個像素的位數 |
001Eh |
Compression |
1 dword |
壓縮說明: |
|
0022h |
Bitmap Data Size |
1 dword |
用字節數表示的位圖數據的大小。該數必須是4的倍數 |
|
0032h |
Important Colors |
1 dword |
指定重要的顏色數。當該域的值等於顏色數時,表示所有顏色都一樣重要 |
|
調色板數據 |
0036h |
Palette |
N * 4 byte |
調色板規範。對於調色板中的每個表項,這4個字節用下述方法來描述RGB的值: |
圖像數據 |
0436h |
Bitmap Data |
x bytes |
該域的大小取決於壓縮方法,它包含所有的位圖數據字節,這些數據實際就是彩色調色板的索引號 |
002Eh |
Colors |
1 dword |
位圖使用的顏色數。如8-位/像素表示爲100h或者 256. |
002Ah |
VResolution |
1 dword |
用像素/米表示的垂直分辨率 |
0026h |
HResolution |
1 dword |
用像素/米表示的水平分辨率 |
000Eh |
Bitmap Header Size |
1 dword |
位圖信息頭(Bitmap Info Header)的長度,用來描述位圖的顏色、壓縮方法等。下面的長度表示: |
0006h |
Reserved |
1 dword |
保留,設置爲0 |
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 表示位圖最多有224=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域的詳細結構
偏移 |
長度 |
內容 |
塊的名稱 |
說明 |
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標記段 |
|||
…… |
…… |
|||
2 byte |
0xFFD9 |
(EOI) end-of-file |
圖像文件結束標記 |
3n |
< Thumbnail RGB bitmap> |
縮略RGB位圖(n爲縮略圖的像素數) |
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.標準的讀/寫工具包。
8.可在一個文件中存儲多幅圖像。
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 |
偏移量
域的名稱
大小
內容