GIF |
|
圖形交換格式說明書 |
|
CompuServe 公司, 1987
保留所有權利
|
'GIF' (tm)是CompuServe用以界定廣義彩色點陣影像的標準。 為允許高品質及高解析的圖像在多種電腦硬體中交換及顯示的機制。 此文件解釋影像格式以支援現在及未來的影像科技為CompuServe影像產品增加服務。
此份文件主要著重於提供必要的技術資訊給程式設計師去執行GIF的編碼及解碼。 也假定對繪圖及寫程式是有意義的術語解說。
此份文件的第一部份是描述GIF資料格式、構成要素及其對所有GIF解碼之應用,無論是獨立的電腦程式或是轉換套件的一部份。 附錄B是描寫轉換軟體套件如何進出GIF模式及回應協定請求。 附錄A的詞彙表解釋了在此文件中被使用到的術語;附錄C詳細說明了如何將影像影像成一系列的資料位元組。
+-----------------------+ | +-------------------+ | | | GIF 識別 | | | +-------------------+ | | +-------------------+ | | | 顯示框描述 | | | +-------------------+ | | +-------------------+ | | | 全體色彩映圖 | | | +-------------------+ | . . . . . . | +-------------------+ | ---+ | | 圖形描述 | | | | +-------------------+ | | | +-------------------+ | | | | 局部色彩映圖 | | |- 重覆一到多次 | +-------------------+ | | | +-------------------+ | | | | 點陣資料 | | | | +-------------------+ | ---+ . . . . . . |- GIF 終止指示 -| +-----------------------+
以下的GIF識別確認接下來的資料是一個合法的GIF影像流,其包含下面六個字母:
G I F 8 7 a
最後三個字母'87a'對於特定的GIF解釋也許會被視為版本數字,在GIF格式定義視為文件的一項參考,就像是加註的版本附屬物。
顯示框描述敘述了下列GIF圖形的整體參數,其定義了圖形各維度的大小,或邏輯螢幕需求,色彩繪圖資訊,顯示框背景顏色及顏色解析度資訊。 這些資訊被貯在下述8位元的位元組的系列中。
bits 7 6 5 4 3 2 1 0 Byte # +---------------+ | | 1 +- 顯示框寬度 -+ (最小值位元優先) | | 2 +---------------+ | | 3 +- 顯示框高度 -+ (最小值位元優先) | | 4 +-+-----+-+-----+ M = 1, 隨後描述全體色彩映圖 |M| cr |0| 像素| 5 cr值+1=顏色的解析度由幾個bits代表 +-+-----+-+-----+ 像素值+1=每像素由幾個bits代表 | 背景色色碼 | 6 =顯示框背景色的色碼 +---------------+ (依全體色彩映圖或預設映圖指示) |0 0 0 0 0 0 0 0| 7 +---------------+
邏輯螢幕(顯示框)寬度及高度會比實際顯示器大得多。如何操作比實際顯示器大的影像,取決於實際硬體的特色。(例如:麥金塔捲動視窗) 此外,影像在顯示器的角落會被省略一部分。
像素的值定義了影像中色彩的最大數目。像素值的範圍自0至7,也就是每像素由1至8個位元來代表。換算起來為2(黑白)至256色的範圍。 第5個byte的第3位元是保留給未來定義的,一定是零。
全體色彩映圖雖非必須但建議使用,它能精確描述顏色。 如果顯示框描述的第5byte的M欄被設為1,它就存在。 色彩映圖也可以在GIF檔的稍後才加以描述。 可是當前的硬體設備在正常情況下會使用全體色彩映圖。 個別圖形描述時M欄通常被設為0。 如果全體色彩映圖設為存在,它會緊跟在顯示框描述之後。 色彩映圖項目的總數是2的n次方,n是顯示框描述中代表每像素的bit數; 而每個項目內含三個值,分別代表紅綠藍的強度。 色彩映圖區的結構如下:
bits 7 6 5 4 3 2 1 0 Byte # +---------------+ | 紅強度 | 1 第0色的紅強度 +---------------+ | 綠強度 | 2 第0色的綠強度 +---------------+ | 藍強度 | 3 第0色的藍強度 +---------------+ | 紅強度 | 4 第1色的紅強度 +---------------+ | 綠強度 | 5 第1色的綠強度 +---------------+ | 藍強度 | 6 第1色的藍強度 +---------------+ : : (繼續剩下的顏色)
每一像素皆以這色彩映圖為基礎,顯示出其最接近及可用的顏色。每種色彩成份以0到255表示強度。 白色就以(255,255,255)來表示,黑色就是(0,0,0),還有中黃色就是(180,180,0)。 如果顯示設備,一色彩成份少於8位元, 每一種成份色就使用較高的位元。 GIF色彩映圖項目的支援硬體少於8位元,硬體的成份值應會被轉換成8位元形式,如同下方計算:
<色彩映圖值> = <原成分值>*255/(2**<原bit數> -1)
這確保了所有顯示器顏色的明確解譯。 在這樣的情況下,從硬體要建立一個GIF圖形而無可用的調色盤,依照硬體可用的顯示色彩可以建立出一修改過的調色盤。 如果未設定全體色彩映圖,就會依硬體的色彩索引為模,去產生內部預設的色彩映圖區,其項目數同於硬體的顏色數目。
圖形描述定義在顯示區中影像的實際定位及寬度,還定義了局部色彩映圖旗標,也定義了像素的顯示序列。 每一組圖形描述皆由圖形分隔符號前導。圖形分隔符號的角色以相同的符號來前導圖形描述。 如果GIF檔案一次包含了一個以上的圖形,這樣使用分隔符號就很有用。 這個符號設定為0x2C hex(即逗號',')。當碰到了這個符號時,圖形描述就會立即更新。
所有前一個圖結尾到圖形分隔符號之間的字元都會被忽略。這樣的安排有助於與日後更新GIF檔案格式相容。
bits 7 6 5 4 3 2 1 0 Byte # +---------------+ |0 0 1 0 1 1 0 0| 1 ',' - 圖形分隔符號 +---------------+ | | 2 圖形在顯示區左側開始的像素 +-圖形左側位置 -+ (最小值位元優先) | | 3 +---------------+ | | 4 +-圖形上側位置 -+ 圖形在顯示區上側開始的像素 | | 5 (最小值位元優先) +---------------+ | | 6 +- 圖形寬度 -+ (最小值位元優先) | | 7 +---------------+ | | 8 +- 圖形高度 -+ (最小值位元優先) | | 9 +-+-+-+-+-+-----+ M=0 - 使用全體色彩映圖,忽略像素欄的指示 |M|I|0|0|0|pixel| 10 M=1 - 隨後會有局部色彩映圖,使用'像素欄' +-+-+-+-+-+-----+ I=0 - 圖形格式為連續式 I=1 - 圖形格式為交錯式 像素值+1=每像素由幾個bits代表
圖形的位置和大小必須比顯示區小。當然圖形不必一定要填滿顯示區。
局部色彩映圖是非必須且為了未來而設計的。 如果圖形描述第10byte的M欄設為1,就會有專屬於此圖形的色彩映圖跟在圖形描述之後。 而此圖形結束後,色彩映圖就回復到顯示框描述所指示的色彩映圖狀態。 注意,只有局部色彩映圖指示設立時,第10byte的像素欄才有作用。 像素欄不只決定了圖形像素的大小,也決定了局部色彩映圖有多少項目。 當圖形結束時,每像素由幾個bits代表也回復到顯示框描述所指示的值。
在繪圖時實體圖形被定義成一串的像素色碼值,像素由左至右構成列,預設由上而下排列圖形列。 圖形描述的第10byte的'I'欄設為1時,圖列的顯示是交錯的。交錯顯示是按四行程法將圖顯示於較廣的空列。 每一個行程周期顯示八列,第一行程顯示八列中的首列,第二行程顯示八列中的第五列,第三行程顯示每四列中的第三列,第四行程顯示其他列,即每兩列中的第二列。 整個繪圖過程如下圖:
Image Row Pass 1 Pass 2 Pass 3 Pass 4 Result --------------------------------------------------- 0 **1a** **1a** 1 **4a** **4a** 2 **3a** **3a** 3 **4b** **4b** 4 **2a** **2a** 5 **4c** **4c** 6 **3b** **3b** 7 **4d** **4d** 8 **1b** **1b** 9 **4e** **4e** 10 **3c** **3c** 11 **4f** **4f** 12 **2b** **2b** . . .
各像素之值是一串色碼,此色碼對映到現行色彩映圖中某色。而像素數目等於圖寬×圖長。 每像素一值成串排列,壓縮及包裹則依附錄C的LZW壓縮演算法版本。
為了統一結束GIF諸圖檔,使用0x3B hex(即';')置於圖檔的最後。 解碼軟體碰到此字元時會停止解碼並等待使用者下新的指示,可能是按Enter或按滑鼠。 繪圖解碼軟體通常會退出繪圖模式並繼續使用者之前的工作。
為了擴充GIF的定義,需要有包裹和延伸GIF資料串的機制。 CompuServe提供了指定GIF擴充定義的方法。
GIF延伸區塊的包裹方法有點像非壓縮的點陣資料,其基本結構如下:
7 6 5 4 3 2 1 0 Byte # +---------------+ |0 0 1 0 0 0 0 1| 1 '!' - GIF 延伸區塊前導符號 +---------------+ | 功能碼 | 2 擴充功能碼 (0 to 255) +---------------+ ---+ | byte 數 | | +---------------+ | : : +-- 需要時可重覆很多次 |func data bytes| | : : | +---------------+ ---+ . . . . . . +---------------+ |0 0 0 0 0 0 0 0| zero byte count (結束區塊) +---------------+
GIF延伸區塊可能作用於GIF終止指示前的任何過程中。
所有的GIF解碼軟體應該要能辨識GIF延伸區塊及其處理功能代碼。 這樣才能確保較舊的解碼軟體也能處理未來的GIF圖檔而不必附加功能。
附錄 A
此演算法也用於 ARC 檔案壓縮。CompuServe對GIF使用LZW的說明請看附錄C。
附錄 B
以下的流程定義是用來控制互動通訊中GIF的傳送和接收。 但並不適用於下載靜態的GIF檔案且不考慮部份的GIF檔案。
GCE(GIF能力查詢)流程是由伺服器回應GIF解碼器互動請求的回應訊息。 這包含了以下的回覆資訊:可用的螢幕尺寸、每色以多少位元代表、色彩總數、色彩細節。 GCE以逸出序列定義如下:
ESC [ > 0 g (g 小寫,為求清楚各字元間插入空白) (0x1B 0x5B 0x3E 0x30 0x67)
GCR(GIF能力回應)是由GIF解碼器提供的互動訊息用以表示軟體在各種圖形模式下的顯示能力。 注意:這同時包含了印表機和螢幕。通常格式如下:
#版本;協定{;設備,寬,高,每色由幾位元代表,顏色的解析度}... <CR> '#' - GCR 識別字元(數字簽章) 版本 - GIF 格式版本;以'87a'為始 協定='0' - 非點對點協定,由解碼器提供,直接譯為8位元的資料流 協定='1' - 使用可以校正錯誤的協定,由主機對螢幕直接進行互動顯示 設備 = '0' - 接著設定螢幕 設備 = '1' - 接著設定印表機 寬 - 寬的最大圖素 高 - 高的最大圖素 每色由幾位元代表 - 每圖素由幾位元代表。可支援的總色數是2的n次方,n是每圖素由幾位元代表。 顏色的解析度 - 在硬體調色盤上,每一色彩成分由幾位元來支援。如果顏色的解析度是'0',就無可用的硬體調色盤
注意:GCR的值是以ASCII十進位數回傳,且訊息是以「Carriage Return」為終止。
以下的GCR訊息描述了三種非列印機的EGA組態;GIF資料流使用可校正錯誤的協定:
#87a;1 ;0,320,200,4,0 ;0,640,200,2,2 ;0,640,350,4,2<CR>
互動的GIF解碼器使用兩個動作定義。此二者唯一不同的是選用不同的輸出媒體,此二流程是:
ESC [ > 1 g 顯示GIF圖形到螢幕 (0x1B 0x5B 0x3E 0x31 0x67) ESC [ > 2 g 繪製圖形到外加的列印設備,圖形也選擇性的顯示在螢幕上。 (0x1B 0x5B 0x3E 0x32 0x67)
注意:每一流程的結束字元'g'是小寫
在互動式的應用中,通常假定GIF影像資料傳送環境是一個自主機到微電腦的全8位元的資料流。所有256個字元碼必須可被轉譯。 通常主機應用程式將建立一個8位元通訊路徑。而且接收端的通訊程式必須支援GIF對所有256個的8位元碼能「接收及傳送」給GIF譯碼軟體。
附錄 C
點陣資料流在輸出影像時可被表述為:
7 6 5 4 3 2 1 0 +---------------+ | 壓縮碼大小 | +---------------+ ---+ | 資料塊含幾byte| | +---------------+ | : : +-- 如果需要可重覆多次 | 放資料的諸 | | : bytes : | +---------------+ ---+ . . . . . . +---------------+ |0 0 0 0 0 0 0 0| 0 byte (結束圖形資料流) +---------------+
將像素值編為字元串涉及幾個步驟,簡述如下:
首byte指示點陣資料流中代表每像素的位元數(code size)。通常就是代表色碼的位元數。 由於某些演算法的限制,黑白圖雖然以1bit代表色碼,但卻必須將code size定為2。 這也意味著壓縮碼必須比1bit更長。
LZW演算法將一串值轉為一串碼,這些碼可能代表列值或代表一串值。 看起來很像文件字元,即由字元組成的字串。
GIF使用的LZW演算法和標準的LZW演算法有以下不同:
+1 bits,最大到每一碼 12 bits 。
其最大值為4095(hex FFF)。總之 LZW 碼長將大於目前的碼長並且碼長會加1。
當包裹/解包裹時這些碼會自動修改碼長以反應事實。
由於在GIF的LZW壓縮使用3到12bit的可用壓縮碼長度,其中任何一種都必須轉成8-bit的位元組才能實際被貯存和傳送。 這些壓縮碼被由左向右排列宛如長流,並被一次切出8 bit送出。 假設一串8bit的字元陣列其中含5 bit碼,其包裹方式如下:
byte n byte 5 byte 4 byte 3 byte 2 byte 1 +-.....-----+--------+--------+--------+--------+--------+ | and so on |hhhhhggg|ggfffffe|eeeedddd|dcccccbb|bbbaaaaa| +-.....-----+--------+--------+--------+--------+--------+
每次將壓縮碼打包成諸byte,byte數將介於0-255,並且置於前導的計數位元組。 而0byte將用來結束一張圖形的點陣資料流。
附錄C
這樣的格式安排可以幫助解碼程式為了效能也可以只讀取資料區塊的計數位元組而跳過其後的資料塊。
附錄D
自始GIF就能在一檔案中包含多張圖形。 圖形描述中允許將圖形放入顯示框中,圖形可能放不滿顯示框也可以放滿顯示框。 操作多圖形的指引如下:
GIF (tm) Graphics Interchange Format (tm)
圖形交換格式:儲存及傳輸點陣圖資訊的機制
(c) CompuServe 公司, 1987
保留所有權利
授權此文件在電腦軟體中可使用,免付授權費
GIF 及圖形交換格式是CompuServe公司的商標
an H&R Block公司
阿靈頓中心林蔭大道5000號
俄亥俄州哥倫布市 43220
(614) 457-8600