??xml version="1.0" encoding="utf-8" standalone="yes"?>亚洲欧洲美洲无码精品VA,亚洲熟女乱综合一区二区 ,国产自偷亚洲精品页65页http://www.tkk7.com/cxc014/category/6426.html真正的生z，应该是不断的向前Q?/description>zh-cnTue, 21 Sep 2010 12:33:01 GMTTue, 21 Sep 2010 12:33:01 GMT60Gif文g格式http://www.tkk7.com/cxc014/articles/26879.html生活Q在l箋……勿要停Q?/dc:creator>生活Q在l箋……勿要停Q?/author>Fri, 06 Jan 2006 06:38:00 GMThttp://www.tkk7.com/cxc014/articles/26879.htmlhttp://www.tkk7.com/cxc014/comments/26879.htmlhttp://www.tkk7.com/cxc014/articles/26879.html#Feedback0http://www.tkk7.com/cxc014/comments/commentRss/26879.htmlhttp://www.tkk7.com/cxc014/services/trackbacks/26879.html

　

　


 

1.概述
~~~~~~~~

　　GIF(Graphics Interchange FormatQ图形交换格?文g是由 CompuServe公司开发的囑Ş文g格式Q版权所有，M商业目的使用均须 CompuServe公司授权?/SMALL>
　　GIF图象是基于颜色列表的Q存储的数据是该点的颜色对应于颜色列表的索引|(j)Q最多只支持8位（256Ԍ(j)。GIF文g内部分成许多存储块，用来存储多幅图象或者是军_图象表现行ؓ(f)的控制块Q用以实现动d交互式应用。GIF文gq通过LZW压羃法压羃图象数据来减图象尺寸（关于LZW法和GIF数据压羃>>...Q?/SMALL>

2.GIF文g存储l构
~~~~~~~~~~~~~~~~~~~

　　GIF文g内部是按块划分的Q包括控制块Q?Control Block Q和数据块（Data Sub-blocksQ两U。控制块是控制数据块行ؓ(f)的，Ҏ(gu)不同的控制块包含一些不同的控制参数Q?A name=数据?数据?/A>只包含一?-bit的字W流Q由它前面的控制块来军_它的功能Q每个数据块大小??55个字节，数据块的W一个字节指个数据块大小Q字节数Q，计算数据块的大小时不包括q个字节Q所以一个空的数据块有一个字节，那就是数据块的大?x00。下表是一个数据块的结构：(x)

BYTE 7 6 5 4 3 2 1 0 BIT
0

块大?/SMALL>

 Block Size - 块大，不包括这个这个字节（不计块大小自nQ?/SMALL>
1 Data Values - 块数据，8-bit的字W串
2
...
254
255

　　一个GIF文g的结构可分ؓ(f)文g?File Header)、GIF数据?GIF Data Stream)和文件终l器(Trailer)三个部分。文件头包含GIF文g|名(Signature)和版本号(Version)QGIF数据由控制标识W、图象块(Image Block)和其他的一些扩展块l成Q文件终l器只有一个gؓ(f)0x3B的字W（';'Q表C文件结束。下表显CZ一个GIF文g的组成结构：(x)

GIF|名 文g?/SMALL>
版本?/SMALL>
逻辑屏幕标识W?/SMALL> GIF数据?/SMALL>
全局颜色列表
...
图象标识W?/SMALL> 图象?/SMALL> 　　　　                  　　　　　　　
图象局部颜色列表图
　　                  　　　　　　　 Z颜色列表的图象数?/SMALL>
...
GIFl尾 文gl尾

　　下面具体介l各个部?

文g头部?Header)
~~~~~~~~~~~~~~~~~

GIF|名(Signature)和版本号(Version)
~~~~~~~~~~~~~~~~~~~~~~~~~~~
GIF|名用来认一个文件是否是GIF格式的文Ӟq一部分׃个字W组成：(x)"GIF";文g版本号也是由三个字节l成,可以?87a"?89a".具体描述见下?

BYTE 7 6 5 4 3 2 1 0 BIT
1 'G' GIF文g标识
2 'I'
3 'F'
4 '8' GIF文g版本P(x)87a - 1987q??/SMALL>
　　　　　　　 89a - 1989q??/SMALL>
5 '7'?9'
6 'a'

GIF数据部?GIF Data Stream)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

逻辑屏幕标识W?Logical Screen Descriptor)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
q一部分?个字节组成，定义了GIF图象的大?Logical Screen Width & Height)、颜色深?Color Bits)、背景色(Blackground Color Index)以及(qing)有无全局颜色列表(Global Color Table)和颜色列表的索引?Index Count)Q具体描q见下表Q?/SMALL>

BYTE 7 6 5 4 3 2 1 0 BIT
1 逻辑屏幕宽度 像素敎ͼ定义GIF图象的宽?/SMALL>
2
3 逻辑屏幕高度 像素敎ͼ定义GIF图象的高?/SMALL>
4
5 m cr s pixel 具体描述见下...
6 背景?/SMALL> 背景颜色(在全局颜色列表中的索引Q如果没有全局颜色列表Q该值没有意?
7 像素宽高?/SMALL> 像素宽高?Pixel Aspect Radio)

m - 全局颜色列表标志(Global Color Table Flag)Q当|位时表C有全局颜色列表Qpixel值有意义.
cr - 颜色深度(Color ResoluTion)Qcr+1定图象的颜色深?
s - 分类标志(Sort Flag)Q如果置位表C全局颜色列表分类排列.
pixel - 全局颜色列表大小Qpixel+1定颜色列表的烦(ch)引数Q?的pixel+1ơ方Q?/SMALL>.

全局颜色列表(Global Color Table)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
全局颜色列表必须紧跟在逻辑屏幕标识W后面，每个颜色列表索引条目׃个字节组成，按R、G、B的顺序排列?/SMALL>

BYTE 7 6 5 4 3 2 1 0 BIT
1 索引1的红色?/SMALL>
2 索引1的绿色?/SMALL>
3 索引1的蓝色?/SMALL>
4 索引2的红色?/SMALL>
5 索引2的绿色?/SMALL>
6 索引2的蓝色?/SMALL>
7 ... 　　　                  　　　　　　　

图象标识W?Image Descriptor)
~~~~~~~~~~~~~~~~~~~~~~~~~
一个GIF文g内可以包含多q图象，一q图象结束之后紧接着下是一q图象的标识W，图象标识W以0x2C(',')字符开始，定义紧接着它的图象的性质Q包括图象相对于逻辑屏幕边界的偏U量、图象大以?qing)有无局部颜色列表和颜色列表大小Q由10个字节组成：(x)

BYTE 7 6 5 4 3 2 1 0 BIT
1 0 0 1 0 1 1 0 0 图象标识W开始，固定gؓ(f)','
2 X方向偏移?/SMALL> 必须限定在逻辑屏幕寸范围?/SMALL>
3
4 Y方向偏移?/SMALL>
5
6 图象宽度
7
8 图象高度
9
10 m i s r pixel m - 局部颜色列表标?Local Color Table Flag)
|位时标识紧接在图象标识W之后有一个局部颜色列表，供紧跟在它之后的一q图象用；值否时用全局颜色列表Q忽略pixel倹{?/SMALL>
i - 交织标志(Interlace Flag)Q置位时图象数据使用交织方式排列Q?A HREF="/cxc014/admin/EditArticles.aspx#q箋的和交织?>详细描述...Q，否则使用序排列?/SMALL>
s - 分类标志(Sort Flag)Q如果置位表C紧跟着的局部颜色列表分cL?
r - 保留Q必d始化?.
pixel - 局部颜色列表大?Size of Local Color Table)Qpixel+1׃ؓ(f)颜色列表的位?/SMALL>

局部颜色列?Local Color Table)
~~~~~~~~~~~~~~~~~~~~~~~~~~
如果上面的局部颜色列表标志置位的话，则需要在q里Q紧跟在图象标识W之后）(j)定义一个局部颜色列表以供紧接着它的图象使用Q注意用前应线保存原来的颜色列表，使用l束之后回复原来保存的全局颜色列表。如果一个GIF文gx有提供全局颜色列表Q也没有提供局部颜色列表，可以自己创徏一个颜色列表，或用系l的颜色列表。局部颜色列表的排列方式和全局颜色列表一P(x)RGBRGB......

Z颜色列表的图象数?Table-Based Image Data)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
׃部分l成QLZW~码长度(LZW Minimum Code Size)和图象数?Image Data)?/SMALL>

BYTE 7 6 5 4 3 2 1 0 BIT
1 LZW~码长度 LZW~码初始码表大小的位敎ͼ详细描述见LZW~码...
　

　
...
 图象数据Q由一个或几个数据?『LZW法和GIF数据压羃?/A>Q，大大减小了图象数据的大小。图象数据在压羃前有两种排列格式Q?A name=q箋的和交织?q箋的和交织?/A>(由图象标识符?A HREF="/cxc014/admin/EditArticles.aspx#交织标志">交织标志控制)。连l方式按从左到右、从上到下的序排列图象的光栅数据；交织图象按下面的Ҏ(gu)处理光栅数据Q?/SMALL>

创徏四个通道(pass)保存数据Q每个通道提取不同行的数据Q?/SMALL>
W一通道(Pass 1)提取从第0行开始每?行的数据Q?/SMALL>
W二通道(Pass 2)提取从第4行开始每?行的数据Q?/SMALL>
W三通道(Pass 3)提取从第2行开始每?行的数据Q?/SMALL>
W四通道(Pass 4)提取从第1行开始每?行的数据Q?/SMALL>

下面的例子演CZ提取交织图象数据的顺序：(x)

?/SMALL> 　通道1　 　通道2　 　通道3　 　通道4　
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
20 -------------------------------------------------------- 2

　

囑Ş控制扩展(Graphic Control Extension)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
q一部分是可选的Q需?9a版本Q，可以攑֜一个图象块(图象标识W?或文本扩展块的前面，用来控制跟在它后面的W一个图象（或文本）(j)的渲?Render)形式Q组成结构如下：(x)

BYTE 7 6 5 4 3 2 1 0 BIT
1 扩展块标?/SMALL> Extension Introducer - 标识q是一个扩展块Q固定?x21
2 囑Ş控制扩展标签 Graphic Control Label - 标识q是一个图形控制扩展块Q固定?xF9
3 块大?/SMALL> Block Size - 不包括块l结器，固定?
4 保留 处置Ҏ(gu)

i

t

 i - 用户输入标志Qt - 透明色标志?A HREF="/cxc014/admin/EditArticles.aspx#处置Ҏ(gu)">详细描述见下...
5 延迟旉 Delay Time - 单位1/100U，如果g?Q表C暂停规定的旉后再l箋往下处理数据流
6
7 透明色烦(ch)?/SMALL> Transparent Color Index - 透明色烦(ch)引?/SMALL>
8 块终l器 Block Terminator - 标识块终l，固定?

处置Ҏ(gu)(Disposal Method)Q指出处|图形的Ҏ(gu)Q当gؓ(f)Q?/SMALL>
                        0 - 不用处|方?/SMALL>
                        1 - 不处|图形，把图形从当前位置Ud
                        2 - 回复到背景色
                        3 - 回复到先前状?/SMALL>
                      4-7 - 自定?/SMALL>
用户输入标志(Use Input Flag)Q指出是否期待用h输入之后才l进行下去，|位表示期待Q值否表示不期待。用戯入可以是按回车键、鼠标点ȝQ可以和延迟旉一起用，在设|的延迟旉内用h输入则马上l进行，或者没有输入直到gq时间到达而l?/SMALL>
透明颜色标志(Transparent Color Flag)Q置位表CZ用透明颜色

注释扩展(Comment Extension)
~~~~~~~~~~~~~~~~~~~~~~~~~~~
q一部分是可选的Q需?9a版本Q，可以用来记录囑Ş、版权、描q等M的非囑Ş和控制的U文本数?7-bit ASCII字符)Q注释扩展ƈ不媄(jing)响对图象数据的处理Q解码器完全可以忽略它。存放位|可以是数据的M地方Q最好不要妨控制和数据块，推荐攑֜数据的开始或l尾。具体组成：(x)

BYTE 7 6 5 4 3 2 1 0 BIT
1 扩展块标?/SMALL> Extension Introducer - 标识q是一个扩展块Q固定?x21
2 注释块标{?/SMALL> Comment Label - 标识q是一个注释块Q固定?xFE

...
 Comment Data - 一个或多个数据?
BYTE 7 6 5 4 3 2 1 0 BIT
1 扩展块标?/SMALL> Extension Introducer - 标识q是一个扩展块Q固定?x21
2 囑Ş控制扩展标签 Plain Text Label - 标识q是一个图形文本扩展块Q固定?x01
3 块大?/SMALL> Block Size - 块大，固定?2
4 文本框左边界位置 Text Glid Left Posotion - 像素|文本框离逻辑屏幕的左边界距离
5
6 文本框上边界位置 Text Glid Top Posotion - 像素|文本框离逻辑屏幕的上边界距离
7
8 文本框高?/SMALL> Text Glid Width -像素?/SMALL>
9
10 文本框高?/SMALL> Text Glid Height - 像素?/SMALL>
11
12 字符单元格宽?/SMALL> Character Cell Width - 像素|单个单元格宽?/SMALL>
13 字符单元格高?/SMALL> Character Cell Height- 像素|单个单元格高?/SMALL>
14 文本前景色烦(ch)?/SMALL> Text Foreground Color Index - 前景色在全局颜色列表中的索引
15 文本背景色烦(ch)?/SMALL> Text Blackground Color Index - 背景色在全局颜色列表中的索引
N
...
 Plain Text Data - 一个或多个数据?
BYTE 7 6 5 4 3 2 1 0 BIT
1 扩展块标?/SMALL> Extension Introducer - 标识q是一个扩展块Q固定?x21
2 囑Ş控制扩展标签 Application Extension Label - 标识q是一个应用程序扩展块Q固定?xFF
3 块大?/SMALL> Block Size - 块大，固定?1
4 应用E序标识W?/SMALL> Application Identifier - 用来鉴别应用E序自n的标?8个连lASCII字符)
5
6
7
8
9
10
11
12 应用E序鉴别?/SMALL> Application Authentication Code - 应用E序定义的特D标识码(3个连lASCII字符)
13
14
N
...
 应用E序自定义数据块 - 一个或多个数据?
BYTE 7 6 5 4 3 2 1 0
1

文gl结

 GIF Trailer - 标识GIF文gl束Q固定?x3B

2.LZW法和GIF数据压羃
~~~~~~~~~~~~~~~~~~~~~~~~~~~

　　GIF文g的图象数据用了可变长度~码的LZW压羃法(Variable-Length_Code LZW Compression)Q这是从LZW(Lempel Ziv Compression)压羃法演变q来的，通过压羃原始数据的重复部分来辑ֈ减少文g大小的目的?/SMALL>

标准的LZW压羃原理Q?/SMALL>
~~~~~~~~~~~~~~~~~~
先来解释一下几个基本概念：(x)
　　LZW压羃有三个重要的对象Q数据流(CharStream)、编码流(CodeStream)和编译表(String Table)。在~码Ӟ数据是输入对象Q图象的光栅数据序列Q，~码就是输出对象（l过压羃q算的编码数据）(j)Q在解码Ӟ~码则是输入对象，数据是输出对象Q而编译表是在~码和解码时都须要用借助的对象?/SMALL>

字符(Character)Q最基础的数据元素，在文本文件中是一个字节，在光栅数据中是一个像素的颜色在指定的颜色列表中的索引?/SMALL>Q?BR>字符?/STRONG>(String)Q由几个q箋的字W组成；
前缀(Prefix)Q也是一个字W串Q不q通常用在另一个字W的前面Q而且它的长度可以?Q?/SMALL>
?/STRONG>(Root)Q单个长度的字符Ԍ
~码(Code)Q一个数字，按照固定长度Q编码长度）(j)从编码流中取出，~译表的映射|
图案Q一个字W串Q按不定长度从数据流中读?映射到编译表条目.

　　LZW压羃的原理：(x)提取原始图象数据中的不同图案Q基于这些图案创Z个编译表Q然后用~译表中的图案烦(ch)引来替代原始光栅数据中的相应图案Q减原始数据大。看h和调色板图象的实现原理差不多Q但是应该注意到的是Q我们这里的~译表不是事先创建好的，而是Ҏ(gu)原始图象数据动态创建的Q解码时q要从已~码的数据中q原出原来的~译表（GIF文g中是不携带编译表信息的）(j)Qؓ(f)了更好理解编解码原理Q我们来看看具体的处理过E：(x)

~码?Compressor)
~~~~~~~~~~~~~~~~

　　~码数据Q第一步，初始化一个编译表Q假设这个编译表的大是12位的Q也是最多有4096个单位，另外假设我们?2个不同的字符Q也可以认ؓ(f)图象的每个像素最多有32U颜Ԍ(j)Q表CZؓ(f)aQbQcQdQe...Q初始化~译表：(x)W?ؓ(f)aQ第1ؓ(f)bQ第2ؓ(f)c...一直到W?1，我们把这32就UCؓ(f)栏V?/SMALL>
　　开始编译，先定义一个前~对象Current PrefixQ记为[.c.]Q现在它是空的，然后定义一个当前字W串Current StringQ标Cؓ(f)[.c.]kQ[.c.]׃ؓ(f)Current PrefixQk׃ؓ(f)当前d字符。现在来d数据的W一个字W，假如为pQ那么Current Stringq于[.c.]pQ由于[.c.]为空Q实际上值就{于pQ，现在在编译表中查找有没有Current String的|׃p是一个根字符Q我们已l初始了32个根索引Q当然可以找刎ͼ把p设ؓ(f)Current Prefix的|不做M事l读取下一个字W，假设为qQCurrent Stringq于[.c.]qQ也是pqQ，看看在编译表中有没有该|当然。没有，q时我们要做下面的事情：(x)Current String的|也就是pqQ添加到~译表的W?2，把Current Prefix的|也就是pQ在~译表中的烦(ch)引输出到~码，修改Current Prefix为当前读取的字符Q也是qQ。l往下读Q如果在~译表中可以查找到Current String的?[.c.]k)Q则把Current String的?[.c.]k)赋予Current PrefixQ如果查找不刎ͼ则添加Current String的?[.c.]k)到编译表Q把Current Prefix的?[.c.])在编译表中所对应的烦(ch)引输出到~码，同时修改Current Prefix为k Q这样一直@环下ȝ到数据流l束。伪代码看v来就像下面这P(x)

~码器伪代码

Initialize String Table;
[.c.] = Empty;
[.c.]k = First Character in CharStream;
while ([.c.]k != EOF )
{
　　if ( [.c.]k is in the StringTable)
　　{
　　　　[.c.] = [.c.]k;
　　}
　　else
　　{
　　　　add [.c.]k to the StringTable;
　　　　Output the Index of [.c.] in the StringTable to the CodeStream;
　　　　[.c.] = k;
　　}
　　[.c.]k = Next Character in CharStream;
}
Output the Index of [.c.] in the StringTable to the CodeStream;

来看一个具体的例子,我们有一个字母表aQbQcQd.有一个输入的字符abacaba。现在来初始化编译表Q?0=a,#1=b,#2=c,#3=d.现在开始读取第一个字WaQ[.c.]a=aQ可以在在编译表中找刎ͼ修改[.c.]=a;不做M事l读取第二个字符bQ[.c.]b=abQ在~译表中不能找，那么d[.c.]b到编译表Q?4=abQ同时输出[.c.]Q也是aQ的索引#0到编码流Q修改[.c.]=bQ读下一个字WaQ[.c.]a=baQ在~译表中不能扑ֈQ添加编译表#5=baQ输出[.c.]的烦(ch)?1到编码流Q修改[.c.]=aQ读下一个字WcQ[.c.]c=acQ在~译表中不能扑ֈQ添加编译表#6=acQ输出[.c.]的烦(ch)?0到编码流Q修改[.c.]=cQ读下一个字WaQ[.c.]c=caQ在~译表中不能扑ֈQ添加编译表#7=caQ输出[.c.]的烦(ch)?2到编码流Q修改[.c.]=aQ读下一个字WbQ[.c.]b=abQ编译表?4=abQ修改[.c.]=abQ读取最后一个字WaQ[.c.]a=abaQ在~译表中不能扑ֈQ添加编译表#8=abaQ输出[.c.]的烦(ch)?4到编码流Q修改[.c.]=aQ好了，现在没有数据了，输出[.c.]的值a的烦(ch)?0到编码流Q这h后的输出l果是Q?0#1#0#2#4#0.

解码?Decompressor)
~~~~~~~~~~~~~~~~~~

　　好了Q现在来看看解码数据。数据的解码Q其实就是数据编码的逆向q程Q要从已l编译的数据Q编码流Q中扑և~译表，然后对照~译表还原图象的光栅数据?/SMALL>
　　首先Q还是要初始化编译表。GIF文g的图象数据的W一个字节存储的是LZW~码的编码大（一般等于图象的位数Q，Ҏ(gu)~码大小Q初始化~译表的Ҏ(gu)目（??的编码大次方）(j)Q然后定义一个当前编码Current CodeQ记作[code]Q定义一个Old CodeQ记作[old]。读取第一个编码到[code]Q这是一个根~码Q在~译表中可以扑ֈQ把该编码所对应的字W输出到数据，[old]=[code]Q读取下一个编码到[code]Q这有两种情况Q在~译表中有或没有该编码，我们先来看第一U情况：(x)先输出当前编码[code]所对应的字W串到数据流Q然后把[old]所对应的字W（Ԍ(j)当成前缀prefix [...]Q当前编码[code]所对应的字W串的第一个字W当成kQ组合v来当前字W串Current String׃ؓ(f)[...]kQ把[...]kd到编译表Q修改[old]=[code]Q读下一个编码；我们来看看在~译表中找不到该~码的情况，回想一下编码情况：(x)如果数据中有一个p[...]p[...]pqq样的字W串Qp[...]在编译表中而p[...]p不在Q编译器输出p[...]的烦(ch)引而添加p[...]p到编译表Q下一个字W串p[...]p可以在~译表中扑ֈ了，而p[...]pq不在~译表中Q同样将输出p[...]p的烦(ch)引D添加p[...]pq到编译表Q这L(fng)来，解码器L~码?STRONG>?/STRONG>慢一步』，当我们遇到p[...]p所对应的烦(ch)引时Q我们不知到该烦(ch)引对应的字符Ԍ在解码器的编译表中还没有该烦(ch)引，事实上，q个索引在下一步添加）(j)Q这旉要用猜测法：(x)现在假设上面的p[...]所对应的烦(ch)引值是#58Q那么上面的字符串经q编译之后是#58#59Q我们在解码器中d#59Ӟ~译表的最大烦(ch)引只?58Q?59所对应的字W串q?58所对应的字W串(也就是p[...])加上q个字符串的W一个字W?也就是p)Q也是p[...]p。事实上Q这U猜法是很准确Q有点不好理解，仔细想一惛_Q。上面的解码q程用伪代码表示像下面q样Q?/SMALL>

解码器伪代码

Initialize String Table;
[code] = First Code in the CodeStream;
Output the String for [code] to the CharStream;
[old] = [code];
[code] = Next Code in the CodeStream;
while ([code] != EOF )
{
　　if ( [code] is in the StringTable)
　　{
　　　　Output the String for [code] to the CharStream; // 输出[code]所对应的字W串
　　　　[...] = translation for [old]; // [old]所对应的字W串
　　　　k = first character of translation for [code]; // [code]所对应的字W串的第一个字W?/SMALL>
　　　　add [...]k to the StringTable;
　　　　[old] = [code];
　　}
　　else
　　{
　　　　[...] = translation for [old];
　　　　k = first character of [...];
　　　　Output [...]k to CharStream;
　　　　add [...]k to the StringTable;
　　　　[old] = [code];
　　}
　　[code] = Next Code in the CodeStream;
}

GIF数据压羃
~~~~~~~~~~~

下面是GIF文g的图象数据结构：(x)

BYTE 7 6 5 4 3 2 1 0 BIT
1

~码长度

 LZW Code Size - LZW压羃的编码长度，也就是要压羃的数据的位数
... 数据?/SMALL>
块大?/SMALL> 数据块，如果需要可重复多次
~码数据
... 数据?/SMALL>
块终l器 一个图象的数据~码l束Q固定?

把光栅数据序列（数据）(j)压羃成GIF文g的图象数据（字符）(j)可以按下面的步骤q行Q?/SMALL>
1.定义~码长度
GIF图象数据的第一个字节就是编码长?Code Size)Q这个值是指要表现一个像素所需要的最位敎ͼ通常q于图象的色深Q?/SMALL>
2.压羃数据
通过LZW压羃法图象的光栅数据压~成GIF的编码数据流。这里用的LZW压羃法是从标准的LZW压羃法演变q来的，它们之间有如下的差别Q?/SMALL>
　　[1]GIF文g定义了一个编码大?Clear Code)Q这个值等?的『编码长度』次方，在从新开始一个编译表Q编译表溢出Q时均须输出该|解码器遇到该值时意味着要从新初始化一个编译表Q?/SMALL>
　　[2]在一个图象的~码数据l束之前Q也是在块l结器的前面Q，需要输Z个Clear Code+1的|解码器在遇到该值时意味着GIF文g的一个图象数据流的结束；
　　[3]W一个可用到的编译表索引值是Clear Code+2Q从0到Clear Code-1是根索引Q再上去两个不可使用Q新的烦(ch)引从Clare Code+2开始添加）(j)Q?/SMALL>
　　[4]GIF输出的编码流是不定长的，每个~码的大从Code Size + 1位到12?/SMALL>Q?SMALL>~码的最大值就?095Q编译表需要定义的索引数就?096Q，当编码所ȝ位数过当前的位数时把当前位数?Q这需要在~码或解码时注意到编码长度的改变?/SMALL>
3.~译成字节序?/SMALL>
因ؓ(f)GIF输出的编码流是不定长的，q就需要把它们~译成固定的8-bit长度的字W流Q编译顺序是从右往左。下面是一个具体例子：(x)~译5位长度编码到8位字W?/SMALL>

0 b b b a a a a a
1 d c c c c c b b
2 e e e e d d d d
3 g g f f f f f e
4 h h h h h g g g
...
N

　
4.打包
　　前面讲过Q一个GIF的数据块的大从0?55个字节，W一个字节是q个数据块的大小Q字节数Q，q就需要将~译~后的码数据打包成一个或几个大小不大?55个字节的数据包。然后写入图象数据块中?/SMALL>

　

 　

〈完?/P>



]]>png格式囄详解http://www.tkk7.com/cxc014/articles/25775.html生活Q在l箋……勿要停Q?/dc:creator>生活Q在l箋……勿要停Q?/author>Wed, 28 Dec 2005 11:58:00 GMThttp://www.tkk7.com/cxc014/articles/25775.htmlhttp://www.tkk7.com/cxc014/comments/25775.htmlhttp://www.tkk7.com/cxc014/articles/25775.html#Feedback0http://www.tkk7.com/cxc014/comments/commentRss/25775.htmlhttp://www.tkk7.com/cxc014/services/trackbacks/25775.html阅读全文

]]> վ֩ģ壺 Ƶվ| | պӰ߹ۿƵ| ˳WWW| պػɫƬƵ| ѹվ߹ۿ| ȫӳѹۿ߿| AVרAV鶹Ѿ| ޾Ƶ| ޾Ʒ| ɫһ| AŮAVۺϾþþ| һһһƵѿ| ѿƵ| ޲Ƶ| Ƶ߹ۿƵ| ߹ۿվ| 88avѹۿ| ѳ˼Ƶ| aëƬƵ| 91ۿ| ƵƷ2| avƬ߿| ޸רƵ| պaƵ| avպavӰƬƷ| ձ| ߲޾Ʒ| ޷츾| +ɫ++| 㽶þۺӰ| պĻһ| hairyëpicsȫ| 鴤һһgifƵ| 99Ʒ| ޹Ʒһ| ޻ɫƵ| ɫþƷƵ| ߹ۿwwwձվ| ͵͵޸պ| С˵ɫͼ|