- 浏览: 382912 次
- 性别:
- 来自: 上海
-
文章分类
最新评论
-
周仁明:
xin911 写道周仁明 写道js的借用了,谢谢!java的版 ...
人民币金额数字转中文大写程序多种编程语言汇总2011版 -
xin911:
周仁明 写道js的借用了,谢谢!java的版本必然是不对的问题 ...
人民币金额数字转中文大写程序多种编程语言汇总2011版 -
周仁明:
js的借用了,谢谢!java的版本必然是不对的问题很多。
人民币金额数字转中文大写程序多种编程语言汇总2011版 -
zhangzhj85:
...
公开几个移动互联产品设计大神的观点 -
white_crucifix:
嗯,不过网络诊断功能能帮上忙的次数的确微乎其微
戏说windows 7 中的优秀设计
GIF文件格式详解
GIF是图像交换格式(Graphics Interchange Format)的简称,它是由美国CompuServe公司在1987年所提出的图像文件格式,它最初的目的是希望每个BBS的使用者能够通过GIF图像 文件轻易存储并交换图像数据,这也就是它为什么被称为图像交换格式的原因了。
GIF文件格式采用了一种经过改进的LZW压缩算法,通常我们称 之为GIF-LZW算法。这是一种无损的压缩算法,压缩效率也比较高,并且GIF支持在一幅GIF文件中存放多幅彩色图像,并且可以按照一定的顺序和时间 间隔将多幅图像依次读出并显示在屏幕上,这样就可以形成一种简单的动画效果。
GIF图像文件是以块的形式来存储图像信息,其中的块又称为区域结构。按照其中 块的特征又可以将所有的块分成三大类,分别是:
控制块(Control Block)、
图像描述块(Graphic Rendering Block)和
特殊用途块(Special Purpose Block)。
控制块:包含了控制数据流的处理以及硬件参数的设置,其成员主要包括:
文件头信息、
逻辑屏幕描述块、
图像控制扩充块和
文件结尾块。
图像描述块:包含了在显示设备上描述图像所需的信息,其成员包括:
图像描述块、
全局调色板、
局部调色板、
图像压缩数据和
图像说明扩充块。
特殊用途块:包含了与图像数据处理无直接关系的信息,其成员包括:
图像注释扩充块和
应用程序扩充块。
下面详细介绍每一个块的详细结构。
1. 文件头信息(Header)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Signature 3 Bytes
+- -+
1 | |
+- -+
2 | |
+---------------+
3 | | Version 3 Bytes
+- -+
4 | |
+- -+
5 | |
+---------------+
GIF的文件头只有六个字节,其结构定义如下:
typedef struct gifheader
{
BYTE bySignature[3]; //GIF文件标示码,其固定值为“GIF”
BYTE byVersion[3]; //GIF文件的版本信息。其取值固定为“87a”和“89a”
} GIFHEADER;
其中:
bySignature:为GIF文件标示码,其固定值为“GIF”,使用者可以通过该域来判断一个图像文件是否是GIF图像格式的文件。
byVersion:表明GIF文件的版本信息。其取值固定为“87a”和“89a”。分别表示GIF文件的版本为GIF87a或GIF89a。这两个版本有一些不同:
GIF87a公布的时间为1987年,该版本不支持动画和一些扩展属性。
GIF89a是1989年确定的一个版本标准,只有89a版本才支持动画、注释扩展和文本扩展。
2. 逻辑屏幕描述块(Logical Screen Descriptor)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Logical Screen Width Unsigned
+- -+
1 | |
+---------------+
2 | | Logical Screen Height Unsigned
+- -+
3 | |
+---------------+
4 | | | | | See below
+---------------+
5 | | Background Color Index Byte
+---------------+
6 | | Pixel Aspect Ratio Byte
+---------------+
逻辑屏幕(Logical Screen)是一个虚拟屏幕(Virtual Screen),它相当于画布,所有的操作都是在它的基础上进行的,同时它也决定了图像的长度和宽度。逻辑屏幕描述块共占有七个字节,其具体结构定义如下:
typedef struct gifscrdesc
{
WORD wWidth; //逻辑屏幕的宽度
WORD wDepth; //逻辑屏幕的高度
struct globalflag //Packed Fields
{
BYTE PalBits : 3; //全局调色板的位数
BYTE SortFlag : 1; //全局调色板中的RGB颜色值是否按照使用率进行从高到底的次序排序的
BYTE ColorRes : 3; //图像的色彩分辨率
BYTE GlobalPal : 1; //指明GIF文件中是否具有全局调色板,其值取1表示有全局调色板,为0表示没有全局调色板
} GlobalFlag;
BYTE byBackground; //逻辑屏幕的背景颜色,也就相当于是画布的颜色
BYTE byAspect; //逻辑屏幕的像素的长宽比例
} GIFSCRDESC;
其中,
wWidth: 用来指定逻辑屏幕的宽度,
wDepth: 用来指定逻辑屏幕的高度,
glaobalflag: 为全域性数据,它的总长度为一个字节,其中:
前三位(第0位到第2位)指定全局调色板的位数,可以通过该值来计算全局调色板的大小。
第3位表明全局调色板中的RGB颜色值是否按照使用率进行从高到底的次序排序的。
第4到第6位指定图像的色彩分辨率。
第7位指明GIF文件中是否具有全局调色板,其值取1表示有全局调色板,为0表示没有全局调色板。
一个 GIF文件可以有全局调色板也可以没有全局调色板,如果定义了全局调色板并且没有定义某一幅图像的局部调色板,则本幅图像采用全局调色板;
如果某一幅图像定义的自己的局部调色板,则该幅图像使用自己的局部调色板。
如果没有定义全局调色板,则GIF文件中的每一幅图像都必须定义自己的局部调色板。
Global Color Table 全局调色板
7 6 5 4 3 2 1 0 Field Name Type
+===============+
0 | | Red 0 Byte
+- -+
1 | | Green 0 Byte
+- -+
2 | | Blue 0 Byte
+- -+
3 | | Red 1 Byte
+- -+
| | Green 1 Byte
+- -+
up | |
+- . . . . -+ ...
to | |
+- -+
| | Green 255 Byte
+- -+
767 | | Blue 255 Byte
+===============+
全局调色板必须紧跟在逻辑屏幕描述块的后面,其大小由GlobalFlag.PalBits决定,其最大长度为768(3*256)字节。
全局调色板的数据是按照 RGBRGB…..RGB的方式存储的。
byBackground: 用来指定逻辑屏幕的背景颜色,也就相当于是画布的颜色。当图像长宽小于逻辑屏幕的大小时,未被图像覆盖部分的颜色值由该值对应的全局调色板中的索引颜色值确定。如果没有全局调色板,该值无效,默认背景颜色为黑色。
byAspect: 用来指定 逻辑屏幕的像素的长宽比例。
3. 图像描述块(Image Descriptor)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Image Separator Byte
+---------------+
1 | | Image Left Position Unsigned
+- -+
2 | |
+---------------+
3 | | Image Top Position Unsigned
+- -+
4 | |
+---------------+
5 | | Image Width Unsigned
+- -+
6 | |
+---------------+
7 | | Image Height Unsigned
+- -+
8 | |
+---------------+
9 | | | | | | See below
+---------------+
一幅GIF图像文件中可以存储多幅图像,并且这些图像没有固定的存放次序。为了区分两幅图像,GIF采用了一个字节的识别码(Image Separator)来判断下面的数据是否是图像描述块。
图像描述块以0x2C开始,定义紧接着它的图像的性质,包括图像相对于逻辑屏幕边界的偏移量、图 像大小以及有无局部调色板和调色板的大小。图像描述块由10个字节组成:
typedef struct gifimage //图像描述块以0x2C开始(Image Separator: 0x2C)
{
WORD wLeft; //指定图像相对逻辑屏幕左上角的X坐标,以象素为单位
WORD wTop; //用来指定图像相对逻辑屏幕左上角的Y坐标
WORD wWidth; //图像的宽度
WORD wDepth; //图像的宽高度
struct localflag //区域性数据(Packed Fields)
{
BYTE PalBits : 3; //局部调色板的位数
BYTE Reserved : 2; //保留位,没有使用,其值固定为0
BYTE SortFlag : 1; //指明局部调色板中的RGB颜色值是否经过排序
BYTE Interlace : 1; //图像是否以交错方式存储
BYTE LocalPal : 1; //图像是否含有局部调色板
} LocalFlag;
} GIFIMAGE;
其中,
wLeft用来指定图像相对逻辑屏幕左上角的X坐标,以象素为单位。
wTop用来指定图像相对逻辑屏幕左上角的Y坐标。
wWdith和 wDepth分别用来指定图像的宽度和高度。
LocalFlag用来指定区域性数据,也就是具体一幅图像的属性。LocalFlag的总长度为一个字节, 其中:
前三位用来指定局部调色板的位数,可以根据该值来计算局部调色板的大小。
第4位到第5位为保留位,没有使用,其值固定为0。
第6位指明局部调色板中的RGB颜色值是否经过排序,其值为1表示调色板中的RGB颜色值是按照其使用率从高到底的次序进行排序。
第7位表示GIF图像是否以交错方式存储,其取值为1表示以交错的方式进行存储。
当图像是按照交错方式存储时,其图像数据的处理可以分为4个阶段:
第一阶段从第0行开始,每次间隔8行进行处理;
第二阶 段从第4行开始,每次间隔8行进行处理;
第三阶段从第2行开始,每次间隔4行进行处理;
第四阶段从第1行开始,每次间隔2行进行处理,
这样 当完成第一阶段时就可以看到图像的概貌,
当处理完第二阶段时,图像会变得清晰一些;
当处理完第三阶段时,图像处理完成一半,清晰效果也进一步增强,
当完成第四阶段,图像 处理完毕,显示出完整清晰的整幅图像。
以交错方式存储是GIF文件格式的一个重要的特点,也是GIF文件格式的一个重要的优点。
以交错方式存储的图像的好处就是无需将整个图像文件解压完成就可以看到图像的概貌,这样可以减少用户的等待时间。
第8位指明GIF图像是否含有局部调色板,如果含有局部调色板,则局部调色板的内容应当紧跟在图像描述块的后面。
局部调色板(Local Color Table)
7 6 5 4 3 2 1 0 Field Name Type
+===============+
0 | | Red 0 Byte
+- -+
1 | | Green 0 Byte
+- -+
2 | | Blue 0 Byte
+- -+
3 | | Red 1 Byte
+- -+
| | Green 1 Byte
+- -+
up | |
+- . . . . -+ ...
to | |
+- -+
| | Green 255 Byte
+- -+
767 | | Blue 255 Byte
+===============+
4. 图像压缩数据(Table Based Image Data)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
| | LZW Minimum Code Size Byte
+---------------+
+===============+
| |
/ / Image Data Data Sub-blocks
| |
+===============+
图像压缩数据是按照GIF-LZW压缩编码后存储于图像压缩数据块中的。
GIF-LZW编码是一种经过改良的LZW编码方式,它是一种无损压缩的编码方法。GIF-LZW编码方法是将原始数据中的重复字符串建立一个字符串表,然后用该重复字符串在字符串表中的索引来替代原始数据以达到压缩的目的。
由于GIF-LZW压缩编码的需要,必须首先存储GIF-LZW的最小编码 长度以供解码程序使用,然后再存储编码后的图像数据。
编码后的图像数据是一个个数据子块的方式存储的,每个数据子块的最大长度为256字节。数据子块的第一个字节指定该数据子块的长度,接下来的数据为数据子块的内容。
如果某个数据子块的第一个字节数值为0,即该数据子块中没有包含任何有用数据,则该子块称为块终结符,用来标识数据子块到此结束。
5. 图像控制扩充块(Graphic Control Extension)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Graphic Control Label Byte
+---------------+
+---------------+
0 | | Block Size Byte
+---------------+
1 | | | | | See below
+---------------+
2 | | Delay Time Unsigned
+- -+
3 | |
+---------------+
4 | | Transparent Color Index Byte
+---------------+
+---------------+
0 | | Block Terminator Byte
+---------------+
图像控制扩充块是可选的,只应用于89a版本,它描述了与图像控制相关的参数。
一般情况下,图像控制扩充块位于一个图像块(包括图像标识符、局部颜色列表和图像数据)或文本扩展块的前面,用来控制跟在它后面的第一个图像(或 文本)的渲染(Render)形式,This field contains the fixed value 0x21 ,组成结构如下:
typedef struct gifcontrol //图像控制扩充块以0x21开始(Extension Introducer: 0x21)
{
BYTE byBlockSize; //用来指定该图像控制扩充块的长度,其取值固定为4
struct flag //用来描述图像控制相关数据,它的长度为1个字节
{
BYTE Transparency : 1; //指定图像中是否具有透明性的颜色
BYTE UserInput : 1; //判断在显示一幅图像后,是否需要用户输入后再进行下一个动作
BYTE DisposalMethod : 3; //指定图像 显示后的处理方式
BYTE Reserved : 3; //保留位,没有任何含义,固定为0
} Flag;
WORD wDelayTime; //指定应用程序进行下一步操作之前延迟的时间,单位为0.01秒
BYTE byTransparencyIndex; //图像中透明色的颜色索引,指定的透明色将不在显示设备上显示
BYTE byTerminator; //块终结符,其值固定为0
} GIFCONTROL;
其中,
byBlockSize用来指定该图像控制扩充块的长度,其取值固定为4。
Flag用来描述图像控制相关数据,它的长度为1个字节。其中:
第0位用来指定图像中是否具有透明性的颜色,
如果该位为1,这表明图像中某种颜色具有透明性,该颜色由参数byTransparencyIndex指定。
第一位用来判断在显示一幅图像后,是否需要用户输入后再进行下一个动作。
如果该位为1,则表示应用程序在进行下一个动作之前需要用户输入。
第2-4位用来指定图像 显示后的处理方式,
当该值为0时,表示没有指定任何处理方式;
当该值为1时,表明不进行任何处理动作;
当该值为2时,表明图像显示后以背景色擦去;
当该值为3时,表明图像显示后恢复原先的背景图像。
第5-7位为保留位,没有任何含义,固定为0。
wDelayTime用来指定应用程序进行下一步操作之前延迟的时间,单位为0.01秒。
如果Flag.UserInput和wDelayTime都设定了,则以先发者为主,
如果没有到指定的延迟时间即有用户输入, 则应用程序直接进行下一步操作。
如果到达延迟时间后还没有用户输入,应用程序也直接进入下一步操作。
byTransparenceIndex用来指定图像中透明色的颜色索引,指定的透明色将不在显示设备上显示。
byTerminator为块终结符,其值固定为0。
6. 图像说明扩充块(Plain Text Extension)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Plain Text Label Byte
+---------------+
+---------------+
0 | | Block Size Byte
+---------------+
1 | | Text Grid Left Position Unsigned
+- -+
2 | |
+---------------+
3 | | Text Grid Top Position Unsigned
+- -+
4 | |
+---------------+
5 | | Text Grid Width Unsigned
+- -+
6 | |
+---------------+
7 | | Text Grid Height Unsigned
+- -+
8 | |
+---------------+
9 | | Character Cell Width Byte
+---------------+
10 | | Character Cell Height Byte
+---------------+
11 | | Text Foreground Color Index Byte
+---------------+
12 | | Text Background Color Index Byte
+---------------+
+===============+
| |
N | | Plain Text Data Data Sub-blocks
| |
+===============+
+---------------+
0 | | Block Terminator Byte
+---------------+
图像说明扩充块又可以称为图像文本扩展块,它用来绘制一个简单的文本图像,这一部分由用来绘制的纯文本数据(7位的 ASCII字符)和控制绘制的参数等组成。
绘制文本借助于一个文本框(Text Grid)来定义边界,在文本框中划分多个单元格,每个字符占用一个单元,绘制时按从左到右、从上到下的顺序依次进行,直到最后一个字符或者占满整个文本框(之后的字符将被忽略,因此定义文本框的大小时应该注意到是否可以容纳整个文本)。
绘制文本的颜色使用全局颜色列表,没有则可以使用一个已经保存的前一 个颜色列表。
另外,图形文本扩展块也属于图形块(Graphic Rendering Block),可以在它前面定义图形控制扩展对它的表现形式进一步修改。
图像说明扩充块的组成:
typedef struct gifplaintext //图像说明扩充块以0x21开始(Extension Introducer: 0x21)
{
BYTE byBlockSize; //指定该图像扩充块的长度
WORD wTextGridLeft; //指定文字显示方格相对于逻辑屏幕左上角的 X坐标(以像素为单位)
WORD wTextGridTop; //指定文字显示方格相对于逻辑屏幕左上角的Y坐标
WORD wTextGridWidth; //指定文字显示方 格的宽度
WORD wTextGridDepth; //用来指定文字显示方格的高度
BYTE byCharCellWidth; //用来指定字符的宽度
BYTE byCharCellDepth; //用来指定字符的高度
BYTE byForeColorIndex; //用来指定字符的前景色
BYTE byBackColorIndex; //用来指定字符的背景色
} GIFPLAINTEXT;
其中,
byBlockSize用来指定该图像扩充块的长度,其取值固定为13。
wTextGridLeft用来指定文字显示方格相对于逻辑屏幕左上角的 X坐标(以像素为单位)。
wTextGridTop用来指定文字显示方格相对于逻辑屏幕左上角的Y坐标。
wTextGridWidth用来指定文字显示方 格的宽度。
wTextGridDepth用来指定文字显示方格的高度。
byCharCellWidth用来指定字符的宽度,
byCharCellDepth用来指定字符的高度。
byForeColorIndex用来指定字符的前景色,
byBackColorIndex用来指定字符的背景色。
7. 图像注释扩充块(Comment Extension)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Comment Label Byte
+---------------+
+===============+
| |
N | | Comment Data Data Sub-blocks
| |
+===============+
+---------------+
0 | | Block Terminator Byte
+---------------+
图像注释扩充块以0x21开始(Extension Introducer: 0x21)
图像注释扩充块包含了图像的文字注释说明,可以用来记录图形、版权、描述等任何的非图形和控制的纯文本数据(7位的ASCII字符)。
注释扩展并不影响对图象数据流的处理,解码器完全可以忽略它。
存放位置可以是数据流的任何地方,最好不要妨碍控制和数据块,推荐放在数据流的开始或结尾。
在GIF中用识别码0xFE来判断一个扩充块是否为图像注释扩充块。
图像注释扩充块中的数据子块个数不限,必须通过块终结符来判断该扩充块是否结束。
8. 应用程序扩充块(Application Extension)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Extension Label Byte
+---------------+
+---------------+
0 | | Block Size Byte
+---------------+
1 | |
+- -+
2 | |
+- -+
3 | | Application Identifier 8 Bytes
+- -+
4 | |
+- -+
5 | |
+- -+
6 | |
+- -+
7 | |
+- -+
8 | |
+---------------+
9 | |
+- -+
10 | | Appl. Authentication Code 3 Bytes
+- -+
11 | |
+---------------+
+===============+
| |
| | Application Data Data Sub-blocks
| |
| |
+===============+
+---------------+
0 | | Block Terminator Byte
+---------------+
应用程序扩充块包含了制作该GIF图像文件的应用程序的信息,GIF中用识别码0xFF来判断一个扩充块是否为应用程序扩充块。它的结构定义如下:
typedef struct gifapplication 应用程序扩充块以0x21开始(Extension Introducer: 0x21)
{
BYTE byBlockSize; //指定该应用程序扩充块的长度,其取值固定为12
BYTE byIdentifier[8]; //用来指定应用程序名称
BYTE byAuthentication[3]; //用来指定应用程序的识别码
} GIFAPPLICATION;
其中:
byBlockSize用来指定该应用程序扩充块的长度,其取值固定为12。
byIdentifier用来指定应用程序名称。
byAuthentication用来指定应用程序的识别码。
9. 文件结尾块(Trailer)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | GIF Trailer Byte
+---------------+
文件结尾块为GIF图像文件的最后一个字节,其取值固定为0x3B。
Appendix
A. Quick Reference Table.
Block Name Required Label Ext. Vers.
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
legend: (1) if present, at most one occurrence
(*) zero or more occurrences
(+) one or more occurrences
Notes : The Header is not subject to Version Numbers.
(89a) The Logical Screen Descriptor and the Image Descriptor retained their
syntax from version 87a to version 89a, but some fields reserved under version
87a are used under version 89a.
Appendix
B. GIF Grammar.
A Grammar is a form of notation to represent the sequence in which certain
objects form larger objects. A grammar is also used to represent the number of
objects that can occur at a given position. The grammar given here represents
the sequence of blocks that form the GIF Data Stream. A grammar is given by
listing its rules. Each rule consists of the left-hand side, followed by some
form of equals sign, followed by the right-hand side. In a rule, the
right-hand side describes how the left-hand side is defined. The right-hand
side consists of a sequence of entities, with the possible presence of special
symbols. The following legend defines the symbols used in this grammar for GIF.
Legend: <> grammar word
::= defines symbol
* zero or more occurrences
+ one or more occurrences
| alternate element
[] optional element
Example:
::= Header * Trailer
This rule defines the entity as follows. It must begin with a
Header. The Header is followed by an entity called Logical Screen, which is
defined below by another rule. The Logical Screen is followed by the entity
Data, which is also defined below by another rule. Finally, the entity Data is
followed by the Trailer. Since there is no rule defining the Header or the
Trailer, this means that these blocks are defined in the document. The entity
Data has a special symbol (*) following it which means that, at this position,
the entity Data may be repeated any number of times, including 0 times. For
further reading on this subject, refer to a standard text on Programming
Languages.
The Grammar.
::= Header * Trailer
::= Logical Screen Descriptor [Global Color Table]
::= |
::= [Graphic Control Extension]
::= |
Plain Text Extension
::= Image Descriptor [Local Color Table] Image Data
::= Application Extension |
Comment Extension
NOTE : The grammar indicates that it is possible for a GIF Data Stream to
contain the Header, the Logical Screen Descriptor, a Global Color Table and the
GIF Trailer. This special case is used to load a GIF decoder with a Global
Color Table, in preparation for subsequent Data Streams without color tables at
all.
注:此文稿为英文翻译稿,主要是能给需要用的朋友一个快速参考。
不过有些地方还是不太明白,如果有代码例子研究下就更帅了。
简单:PHP直接打开文件,用pack操作二进制数据即可。
不过有些地方还是不太明白,如果有代码例子研究下就更帅了。
翻得很认真~
楼主能否提供vc生成gif的源码给我参考
不好意思,我目前只用PHP。
翻得很认真~
楼主能否提供vc生成gif的源码给我参考
GIF是图像交换格式(Graphics Interchange Format)的简称,它是由美国CompuServe公司在1987年所提出的图像文件格式,它最初的目的是希望每个BBS的使用者能够通过GIF图像 文件轻易存储并交换图像数据,这也就是它为什么被称为图像交换格式的原因了。
GIF文件格式采用了一种经过改进的LZW压缩算法,通常我们称 之为GIF-LZW算法。这是一种无损的压缩算法,压缩效率也比较高,并且GIF支持在一幅GIF文件中存放多幅彩色图像,并且可以按照一定的顺序和时间 间隔将多幅图像依次读出并显示在屏幕上,这样就可以形成一种简单的动画效果。
GIF图像文件是以块的形式来存储图像信息,其中的块又称为区域结构。按照其中 块的特征又可以将所有的块分成三大类,分别是:
控制块(Control Block)、
图像描述块(Graphic Rendering Block)和
特殊用途块(Special Purpose Block)。
控制块:包含了控制数据流的处理以及硬件参数的设置,其成员主要包括:
文件头信息、
逻辑屏幕描述块、
图像控制扩充块和
文件结尾块。
图像描述块:包含了在显示设备上描述图像所需的信息,其成员包括:
图像描述块、
全局调色板、
局部调色板、
图像压缩数据和
图像说明扩充块。
特殊用途块:包含了与图像数据处理无直接关系的信息,其成员包括:
图像注释扩充块和
应用程序扩充块。
下面详细介绍每一个块的详细结构。
1. 文件头信息(Header)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Signature 3 Bytes
+- -+
1 | |
+- -+
2 | |
+---------------+
3 | | Version 3 Bytes
+- -+
4 | |
+- -+
5 | |
+---------------+
GIF的文件头只有六个字节,其结构定义如下:
typedef struct gifheader
{
BYTE bySignature[3]; //GIF文件标示码,其固定值为“GIF”
BYTE byVersion[3]; //GIF文件的版本信息。其取值固定为“87a”和“89a”
} GIFHEADER;
其中:
bySignature:为GIF文件标示码,其固定值为“GIF”,使用者可以通过该域来判断一个图像文件是否是GIF图像格式的文件。
byVersion:表明GIF文件的版本信息。其取值固定为“87a”和“89a”。分别表示GIF文件的版本为GIF87a或GIF89a。这两个版本有一些不同:
GIF87a公布的时间为1987年,该版本不支持动画和一些扩展属性。
GIF89a是1989年确定的一个版本标准,只有89a版本才支持动画、注释扩展和文本扩展。
2. 逻辑屏幕描述块(Logical Screen Descriptor)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Logical Screen Width Unsigned
+- -+
1 | |
+---------------+
2 | | Logical Screen Height Unsigned
+- -+
3 | |
+---------------+
4 | | | | | See below
+---------------+
5 | | Background Color Index Byte
+---------------+
6 | | Pixel Aspect Ratio Byte
+---------------+
逻辑屏幕(Logical Screen)是一个虚拟屏幕(Virtual Screen),它相当于画布,所有的操作都是在它的基础上进行的,同时它也决定了图像的长度和宽度。逻辑屏幕描述块共占有七个字节,其具体结构定义如下:
typedef struct gifscrdesc
{
WORD wWidth; //逻辑屏幕的宽度
WORD wDepth; //逻辑屏幕的高度
struct globalflag //Packed Fields
{
BYTE PalBits : 3; //全局调色板的位数
BYTE SortFlag : 1; //全局调色板中的RGB颜色值是否按照使用率进行从高到底的次序排序的
BYTE ColorRes : 3; //图像的色彩分辨率
BYTE GlobalPal : 1; //指明GIF文件中是否具有全局调色板,其值取1表示有全局调色板,为0表示没有全局调色板
} GlobalFlag;
BYTE byBackground; //逻辑屏幕的背景颜色,也就相当于是画布的颜色
BYTE byAspect; //逻辑屏幕的像素的长宽比例
} GIFSCRDESC;
其中,
wWidth: 用来指定逻辑屏幕的宽度,
wDepth: 用来指定逻辑屏幕的高度,
glaobalflag: 为全域性数据,它的总长度为一个字节,其中:
前三位(第0位到第2位)指定全局调色板的位数,可以通过该值来计算全局调色板的大小。
第3位表明全局调色板中的RGB颜色值是否按照使用率进行从高到底的次序排序的。
第4到第6位指定图像的色彩分辨率。
第7位指明GIF文件中是否具有全局调色板,其值取1表示有全局调色板,为0表示没有全局调色板。
一个 GIF文件可以有全局调色板也可以没有全局调色板,如果定义了全局调色板并且没有定义某一幅图像的局部调色板,则本幅图像采用全局调色板;
如果某一幅图像定义的自己的局部调色板,则该幅图像使用自己的局部调色板。
如果没有定义全局调色板,则GIF文件中的每一幅图像都必须定义自己的局部调色板。
Global Color Table 全局调色板
7 6 5 4 3 2 1 0 Field Name Type
+===============+
0 | | Red 0 Byte
+- -+
1 | | Green 0 Byte
+- -+
2 | | Blue 0 Byte
+- -+
3 | | Red 1 Byte
+- -+
| | Green 1 Byte
+- -+
up | |
+- . . . . -+ ...
to | |
+- -+
| | Green 255 Byte
+- -+
767 | | Blue 255 Byte
+===============+
全局调色板必须紧跟在逻辑屏幕描述块的后面,其大小由GlobalFlag.PalBits决定,其最大长度为768(3*256)字节。
全局调色板的数据是按照 RGBRGB…..RGB的方式存储的。
byBackground: 用来指定逻辑屏幕的背景颜色,也就相当于是画布的颜色。当图像长宽小于逻辑屏幕的大小时,未被图像覆盖部分的颜色值由该值对应的全局调色板中的索引颜色值确定。如果没有全局调色板,该值无效,默认背景颜色为黑色。
byAspect: 用来指定 逻辑屏幕的像素的长宽比例。
3. 图像描述块(Image Descriptor)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Image Separator Byte
+---------------+
1 | | Image Left Position Unsigned
+- -+
2 | |
+---------------+
3 | | Image Top Position Unsigned
+- -+
4 | |
+---------------+
5 | | Image Width Unsigned
+- -+
6 | |
+---------------+
7 | | Image Height Unsigned
+- -+
8 | |
+---------------+
9 | | | | | | See below
+---------------+
一幅GIF图像文件中可以存储多幅图像,并且这些图像没有固定的存放次序。为了区分两幅图像,GIF采用了一个字节的识别码(Image Separator)来判断下面的数据是否是图像描述块。
图像描述块以0x2C开始,定义紧接着它的图像的性质,包括图像相对于逻辑屏幕边界的偏移量、图 像大小以及有无局部调色板和调色板的大小。图像描述块由10个字节组成:
typedef struct gifimage //图像描述块以0x2C开始(Image Separator: 0x2C)
{
WORD wLeft; //指定图像相对逻辑屏幕左上角的X坐标,以象素为单位
WORD wTop; //用来指定图像相对逻辑屏幕左上角的Y坐标
WORD wWidth; //图像的宽度
WORD wDepth; //图像的宽高度
struct localflag //区域性数据(Packed Fields)
{
BYTE PalBits : 3; //局部调色板的位数
BYTE Reserved : 2; //保留位,没有使用,其值固定为0
BYTE SortFlag : 1; //指明局部调色板中的RGB颜色值是否经过排序
BYTE Interlace : 1; //图像是否以交错方式存储
BYTE LocalPal : 1; //图像是否含有局部调色板
} LocalFlag;
} GIFIMAGE;
其中,
wLeft用来指定图像相对逻辑屏幕左上角的X坐标,以象素为单位。
wTop用来指定图像相对逻辑屏幕左上角的Y坐标。
wWdith和 wDepth分别用来指定图像的宽度和高度。
LocalFlag用来指定区域性数据,也就是具体一幅图像的属性。LocalFlag的总长度为一个字节, 其中:
前三位用来指定局部调色板的位数,可以根据该值来计算局部调色板的大小。
第4位到第5位为保留位,没有使用,其值固定为0。
第6位指明局部调色板中的RGB颜色值是否经过排序,其值为1表示调色板中的RGB颜色值是按照其使用率从高到底的次序进行排序。
第7位表示GIF图像是否以交错方式存储,其取值为1表示以交错的方式进行存储。
当图像是按照交错方式存储时,其图像数据的处理可以分为4个阶段:
第一阶段从第0行开始,每次间隔8行进行处理;
第二阶 段从第4行开始,每次间隔8行进行处理;
第三阶段从第2行开始,每次间隔4行进行处理;
第四阶段从第1行开始,每次间隔2行进行处理,
这样 当完成第一阶段时就可以看到图像的概貌,
当处理完第二阶段时,图像会变得清晰一些;
当处理完第三阶段时,图像处理完成一半,清晰效果也进一步增强,
当完成第四阶段,图像 处理完毕,显示出完整清晰的整幅图像。
以交错方式存储是GIF文件格式的一个重要的特点,也是GIF文件格式的一个重要的优点。
以交错方式存储的图像的好处就是无需将整个图像文件解压完成就可以看到图像的概貌,这样可以减少用户的等待时间。
第8位指明GIF图像是否含有局部调色板,如果含有局部调色板,则局部调色板的内容应当紧跟在图像描述块的后面。
局部调色板(Local Color Table)
7 6 5 4 3 2 1 0 Field Name Type
+===============+
0 | | Red 0 Byte
+- -+
1 | | Green 0 Byte
+- -+
2 | | Blue 0 Byte
+- -+
3 | | Red 1 Byte
+- -+
| | Green 1 Byte
+- -+
up | |
+- . . . . -+ ...
to | |
+- -+
| | Green 255 Byte
+- -+
767 | | Blue 255 Byte
+===============+
4. 图像压缩数据(Table Based Image Data)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
| | LZW Minimum Code Size Byte
+---------------+
+===============+
| |
/ / Image Data Data Sub-blocks
| |
+===============+
图像压缩数据是按照GIF-LZW压缩编码后存储于图像压缩数据块中的。
GIF-LZW编码是一种经过改良的LZW编码方式,它是一种无损压缩的编码方法。GIF-LZW编码方法是将原始数据中的重复字符串建立一个字符串表,然后用该重复字符串在字符串表中的索引来替代原始数据以达到压缩的目的。
由于GIF-LZW压缩编码的需要,必须首先存储GIF-LZW的最小编码 长度以供解码程序使用,然后再存储编码后的图像数据。
编码后的图像数据是一个个数据子块的方式存储的,每个数据子块的最大长度为256字节。数据子块的第一个字节指定该数据子块的长度,接下来的数据为数据子块的内容。
如果某个数据子块的第一个字节数值为0,即该数据子块中没有包含任何有用数据,则该子块称为块终结符,用来标识数据子块到此结束。
5. 图像控制扩充块(Graphic Control Extension)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Graphic Control Label Byte
+---------------+
+---------------+
0 | | Block Size Byte
+---------------+
1 | | | | | See below
+---------------+
2 | | Delay Time Unsigned
+- -+
3 | |
+---------------+
4 | | Transparent Color Index Byte
+---------------+
+---------------+
0 | | Block Terminator Byte
+---------------+
图像控制扩充块是可选的,只应用于89a版本,它描述了与图像控制相关的参数。
一般情况下,图像控制扩充块位于一个图像块(包括图像标识符、局部颜色列表和图像数据)或文本扩展块的前面,用来控制跟在它后面的第一个图像(或 文本)的渲染(Render)形式,This field contains the fixed value 0x21 ,组成结构如下:
typedef struct gifcontrol //图像控制扩充块以0x21开始(Extension Introducer: 0x21)
{
BYTE byBlockSize; //用来指定该图像控制扩充块的长度,其取值固定为4
struct flag //用来描述图像控制相关数据,它的长度为1个字节
{
BYTE Transparency : 1; //指定图像中是否具有透明性的颜色
BYTE UserInput : 1; //判断在显示一幅图像后,是否需要用户输入后再进行下一个动作
BYTE DisposalMethod : 3; //指定图像 显示后的处理方式
BYTE Reserved : 3; //保留位,没有任何含义,固定为0
} Flag;
WORD wDelayTime; //指定应用程序进行下一步操作之前延迟的时间,单位为0.01秒
BYTE byTransparencyIndex; //图像中透明色的颜色索引,指定的透明色将不在显示设备上显示
BYTE byTerminator; //块终结符,其值固定为0
} GIFCONTROL;
其中,
byBlockSize用来指定该图像控制扩充块的长度,其取值固定为4。
Flag用来描述图像控制相关数据,它的长度为1个字节。其中:
第0位用来指定图像中是否具有透明性的颜色,
如果该位为1,这表明图像中某种颜色具有透明性,该颜色由参数byTransparencyIndex指定。
第一位用来判断在显示一幅图像后,是否需要用户输入后再进行下一个动作。
如果该位为1,则表示应用程序在进行下一个动作之前需要用户输入。
第2-4位用来指定图像 显示后的处理方式,
当该值为0时,表示没有指定任何处理方式;
当该值为1时,表明不进行任何处理动作;
当该值为2时,表明图像显示后以背景色擦去;
当该值为3时,表明图像显示后恢复原先的背景图像。
第5-7位为保留位,没有任何含义,固定为0。
wDelayTime用来指定应用程序进行下一步操作之前延迟的时间,单位为0.01秒。
如果Flag.UserInput和wDelayTime都设定了,则以先发者为主,
如果没有到指定的延迟时间即有用户输入, 则应用程序直接进行下一步操作。
如果到达延迟时间后还没有用户输入,应用程序也直接进入下一步操作。
byTransparenceIndex用来指定图像中透明色的颜色索引,指定的透明色将不在显示设备上显示。
byTerminator为块终结符,其值固定为0。
6. 图像说明扩充块(Plain Text Extension)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Plain Text Label Byte
+---------------+
+---------------+
0 | | Block Size Byte
+---------------+
1 | | Text Grid Left Position Unsigned
+- -+
2 | |
+---------------+
3 | | Text Grid Top Position Unsigned
+- -+
4 | |
+---------------+
5 | | Text Grid Width Unsigned
+- -+
6 | |
+---------------+
7 | | Text Grid Height Unsigned
+- -+
8 | |
+---------------+
9 | | Character Cell Width Byte
+---------------+
10 | | Character Cell Height Byte
+---------------+
11 | | Text Foreground Color Index Byte
+---------------+
12 | | Text Background Color Index Byte
+---------------+
+===============+
| |
N | | Plain Text Data Data Sub-blocks
| |
+===============+
+---------------+
0 | | Block Terminator Byte
+---------------+
图像说明扩充块又可以称为图像文本扩展块,它用来绘制一个简单的文本图像,这一部分由用来绘制的纯文本数据(7位的 ASCII字符)和控制绘制的参数等组成。
绘制文本借助于一个文本框(Text Grid)来定义边界,在文本框中划分多个单元格,每个字符占用一个单元,绘制时按从左到右、从上到下的顺序依次进行,直到最后一个字符或者占满整个文本框(之后的字符将被忽略,因此定义文本框的大小时应该注意到是否可以容纳整个文本)。
绘制文本的颜色使用全局颜色列表,没有则可以使用一个已经保存的前一 个颜色列表。
另外,图形文本扩展块也属于图形块(Graphic Rendering Block),可以在它前面定义图形控制扩展对它的表现形式进一步修改。
图像说明扩充块的组成:
typedef struct gifplaintext //图像说明扩充块以0x21开始(Extension Introducer: 0x21)
{
BYTE byBlockSize; //指定该图像扩充块的长度
WORD wTextGridLeft; //指定文字显示方格相对于逻辑屏幕左上角的 X坐标(以像素为单位)
WORD wTextGridTop; //指定文字显示方格相对于逻辑屏幕左上角的Y坐标
WORD wTextGridWidth; //指定文字显示方 格的宽度
WORD wTextGridDepth; //用来指定文字显示方格的高度
BYTE byCharCellWidth; //用来指定字符的宽度
BYTE byCharCellDepth; //用来指定字符的高度
BYTE byForeColorIndex; //用来指定字符的前景色
BYTE byBackColorIndex; //用来指定字符的背景色
} GIFPLAINTEXT;
其中,
byBlockSize用来指定该图像扩充块的长度,其取值固定为13。
wTextGridLeft用来指定文字显示方格相对于逻辑屏幕左上角的 X坐标(以像素为单位)。
wTextGridTop用来指定文字显示方格相对于逻辑屏幕左上角的Y坐标。
wTextGridWidth用来指定文字显示方 格的宽度。
wTextGridDepth用来指定文字显示方格的高度。
byCharCellWidth用来指定字符的宽度,
byCharCellDepth用来指定字符的高度。
byForeColorIndex用来指定字符的前景色,
byBackColorIndex用来指定字符的背景色。
7. 图像注释扩充块(Comment Extension)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Comment Label Byte
+---------------+
+===============+
| |
N | | Comment Data Data Sub-blocks
| |
+===============+
+---------------+
0 | | Block Terminator Byte
+---------------+
图像注释扩充块以0x21开始(Extension Introducer: 0x21)
图像注释扩充块包含了图像的文字注释说明,可以用来记录图形、版权、描述等任何的非图形和控制的纯文本数据(7位的ASCII字符)。
注释扩展并不影响对图象数据流的处理,解码器完全可以忽略它。
存放位置可以是数据流的任何地方,最好不要妨碍控制和数据块,推荐放在数据流的开始或结尾。
在GIF中用识别码0xFE来判断一个扩充块是否为图像注释扩充块。
图像注释扩充块中的数据子块个数不限,必须通过块终结符来判断该扩充块是否结束。
8. 应用程序扩充块(Application Extension)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | Extension Introducer Byte
+---------------+
1 | | Extension Label Byte
+---------------+
+---------------+
0 | | Block Size Byte
+---------------+
1 | |
+- -+
2 | |
+- -+
3 | | Application Identifier 8 Bytes
+- -+
4 | |
+- -+
5 | |
+- -+
6 | |
+- -+
7 | |
+- -+
8 | |
+---------------+
9 | |
+- -+
10 | | Appl. Authentication Code 3 Bytes
+- -+
11 | |
+---------------+
+===============+
| |
| | Application Data Data Sub-blocks
| |
| |
+===============+
+---------------+
0 | | Block Terminator Byte
+---------------+
应用程序扩充块包含了制作该GIF图像文件的应用程序的信息,GIF中用识别码0xFF来判断一个扩充块是否为应用程序扩充块。它的结构定义如下:
typedef struct gifapplication 应用程序扩充块以0x21开始(Extension Introducer: 0x21)
{
BYTE byBlockSize; //指定该应用程序扩充块的长度,其取值固定为12
BYTE byIdentifier[8]; //用来指定应用程序名称
BYTE byAuthentication[3]; //用来指定应用程序的识别码
} GIFAPPLICATION;
其中:
byBlockSize用来指定该应用程序扩充块的长度,其取值固定为12。
byIdentifier用来指定应用程序名称。
byAuthentication用来指定应用程序的识别码。
9. 文件结尾块(Trailer)
7 6 5 4 3 2 1 0 Field Name Type
+---------------+
0 | | GIF Trailer Byte
+---------------+
文件结尾块为GIF图像文件的最后一个字节,其取值固定为0x3B。
Appendix
A. Quick Reference Table.
Block Name Required Label Ext. Vers.
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
legend: (1) if present, at most one occurrence
(*) zero or more occurrences
(+) one or more occurrences
Notes : The Header is not subject to Version Numbers.
(89a) The Logical Screen Descriptor and the Image Descriptor retained their
syntax from version 87a to version 89a, but some fields reserved under version
87a are used under version 89a.
Appendix
B. GIF Grammar.
A Grammar is a form of notation to represent the sequence in which certain
objects form larger objects. A grammar is also used to represent the number of
objects that can occur at a given position. The grammar given here represents
the sequence of blocks that form the GIF Data Stream. A grammar is given by
listing its rules. Each rule consists of the left-hand side, followed by some
form of equals sign, followed by the right-hand side. In a rule, the
right-hand side describes how the left-hand side is defined. The right-hand
side consists of a sequence of entities, with the possible presence of special
symbols. The following legend defines the symbols used in this grammar for GIF.
Legend: <> grammar word
::= defines symbol
* zero or more occurrences
+ one or more occurrences
| alternate element
[] optional element
Example:
::= Header * Trailer
This rule defines the entity as follows. It must begin with a
Header. The Header is followed by an entity called Logical Screen, which is
defined below by another rule. The Logical Screen is followed by the entity
Data, which is also defined below by another rule. Finally, the entity Data is
followed by the Trailer. Since there is no rule defining the Header or the
Trailer, this means that these blocks are defined in the document. The entity
Data has a special symbol (*) following it which means that, at this position,
the entity Data may be repeated any number of times, including 0 times. For
further reading on this subject, refer to a standard text on Programming
Languages.
The Grammar.
::= Header * Trailer
::= Logical Screen Descriptor [Global Color Table]
::= |
::= [Graphic Control Extension]
::= |
Plain Text Extension
::= Image Descriptor [Local Color Table] Image Data
::= Application Extension |
Comment Extension
NOTE : The grammar indicates that it is possible for a GIF Data Stream to
contain the Header, the Logical Screen Descriptor, a Global Color Table and the
GIF Trailer. This special case is used to load a GIF decoder with a Global
Color Table, in preparation for subsequent Data Streams without color tables at
all.
注:此文稿为英文翻译稿,主要是能给需要用的朋友一个快速参考。
评论
4 楼
bardo
2011-01-13
enefry 写道

简单:PHP直接打开文件,用pack操作二进制数据即可。
3 楼
enefry
2011-01-12

2 楼
bardo
2010-06-08
diaodiaowen1987 写道

楼主能否提供vc生成gif的源码给我参考

不好意思,我目前只用PHP。
1 楼
diaodiaowen1987
2010-05-17

楼主能否提供vc生成gif的源码给我参考

相关推荐
内容概要:本文详细介绍了基于MATLAB GUI界面和卷积神经网络(CNN)的模糊车牌识别系统。该系统旨在解决现实中车牌因模糊不清导致识别困难的问题。文中阐述了整个流程的关键步骤,包括图像的模糊还原、灰度化、阈值化、边缘检测、孔洞填充、形态学操作、滤波操作、车牌定位、字符分割以及最终的字符识别。通过使用维纳滤波或最小二乘法约束滤波进行模糊还原,再利用CNN的强大特征提取能力完成字符分类。此外,还特别强调了MATLAB GUI界面的设计,使得用户能直观便捷地操作整个系统。 适合人群:对图像处理和深度学习感兴趣的科研人员、高校学生及从事相关领域的工程师。 使用场景及目标:适用于交通管理、智能停车场等领域,用于提升车牌识别的准确性和效率,特别是在面对模糊车牌时的表现。 其他说明:文中提供了部分关键代码片段作为参考,并对实验结果进行了详细的分析,展示了系统在不同环境下的表现情况及其潜在的应用前景。
嵌入式八股文面试题库资料知识宝典-计算机专业试题.zip
嵌入式八股文面试题库资料知识宝典-C and C++ normal interview_3.zip
内容概要:本文深入探讨了一款额定功率为4kW的开关磁阻电机,详细介绍了其性能参数如额定功率、转速、效率、输出转矩和脉动率等。同时,文章还展示了利用RMxprt、Maxwell 2D和3D模型对该电机进行仿真的方法和技术,通过外电路分析进一步研究其电气性能和动态响应特性。最后,文章提供了基于RMxprt模型的MATLAB仿真代码示例,帮助读者理解电机的工作原理及其性能特点。 适合人群:从事电机设计、工业自动化领域的工程师和技术人员,尤其是对开关磁阻电机感兴趣的科研工作者。 使用场景及目标:适用于希望深入了解开关磁阻电机特性和建模技术的研究人员,在新产品开发或现有产品改进时作为参考资料。 其他说明:文中提供的代码示例仅用于演示目的,实际操作时需根据所用软件的具体情况进行适当修改。
少儿编程scratch项目源代码文件案例素材-剑客冲刺.zip
少儿编程scratch项目源代码文件案例素材-几何冲刺 转瞬即逝.zip
内容概要:本文详细介绍了基于PID控制器的四象限直流电机速度驱动控制系统仿真模型及其永磁直流电机(PMDC)转速控制模型。首先阐述了PID控制器的工作原理,即通过对系统误差的比例、积分和微分运算来调整电机的驱动信号,从而实现转速的精确控制。接着讨论了如何利用PID控制器使有刷PMDC电机在四个象限中精确跟踪参考速度,并展示了仿真模型在应对快速负载扰动时的有效性和稳定性。最后,提供了Simulink仿真模型和详细的Word模型说明文档,帮助读者理解和调整PID控制器参数,以达到最佳控制效果。 适合人群:从事电力电子与电机控制领域的研究人员和技术人员,尤其是对四象限直流电机速度驱动控制系统感兴趣的读者。 使用场景及目标:适用于需要深入了解和掌握四象限直流电机速度驱动控制系统设计与实现的研究人员和技术人员。目标是在实际项目中能够运用PID控制器实现电机转速的精确控制,并提高系统的稳定性和抗干扰能力。 其他说明:文中引用了多篇相关领域的权威文献,确保了理论依据的可靠性和实用性。此外,提供的Simulink模型和Word文档有助于读者更好地理解和实践所介绍的内容。
嵌入式八股文面试题库资料知识宝典-2013年海康威视校园招聘嵌入式开发笔试题.zip
少儿编程scratch项目源代码文件案例素材-驾驶通关.zip
小区开放对周边道路通行能力影响的研究.pdf
内容概要:本文探讨了冷链物流车辆路径优化问题,特别是如何通过NSGA-2遗传算法和软硬时间窗策略来实现高效、环保和高客户满意度的路径规划。文中介绍了冷链物流的特点及其重要性,提出了软时间窗概念,允许一定的配送时间弹性,同时考虑碳排放成本,以达到绿色物流的目的。此外,还讨论了如何将客户满意度作为路径优化的重要评价标准之一。最后,通过一段简化的Python代码展示了遗传算法的应用。 适合人群:从事物流管理、冷链物流运营的专业人士,以及对遗传算法和路径优化感兴趣的科研人员和技术开发者。 使用场景及目标:适用于冷链物流企业,旨在优化配送路线,降低运营成本,减少碳排放,提升客户满意度。目标是帮助企业实现绿色、高效的物流配送系统。 其他说明:文中提供的代码仅为示意,实际应用需根据具体情况调整参数设置和模型构建。
少儿编程scratch项目源代码文件案例素材-恐怖矿井.zip
内容概要:本文详细介绍了基于STM32F030的无刷电机控制方案,重点在于高压FOC(磁场定向控制)技术和滑膜无感FOC的应用。该方案实现了过载、过欠压、堵转等多种保护机制,并提供了完整的源码、原理图和PCB设计。文中展示了关键代码片段,如滑膜观测器和电流环处理,以及保护机制的具体实现方法。此外,还提到了方案的移植要点和实际测试效果,确保系统的稳定性和高效性。 适合人群:嵌入式系统开发者、电机控制系统工程师、硬件工程师。 使用场景及目标:适用于需要高性能无刷电机控制的应用场景,如工业自动化设备、无人机、电动工具等。目标是提供一种成熟的、经过验证的无刷电机控制方案,帮助开发者快速实现并优化电机控制性能。 其他说明:提供的资料包括详细的原理图、PCB设计文件、源码及测试视频,方便开发者进行学习和应用。
基于有限体积法Godunov格式的管道泄漏检测模型研究.pdf
嵌入式八股文面试题库资料知识宝典-CC++笔试题-深圳有为(2019.2.28)1.zip
少儿编程scratch项目源代码文件案例素材-几何冲刺 V1.5.zip
Android系统开发_Linux内核配置_USB-HID设备模拟_通过root权限将Android设备转换为全功能USB键盘的项目实现_该项目需要内核支持configFS文件系统
C# WPF - LiveCharts Project
少儿编程scratch项目源代码文件案例素材-恐怖叉子 动画.zip
嵌入式八股文面试题库资料知识宝典-嵌⼊式⼯程师⾯试⾼频问题.zip