GIF文件结构与解码器

1、1. 前记 一直以来,blog对我来说, 与其说是写给别人看,不如说是给自己看得. 一些只有笨蛋才会返的错误,白痴才不知道的原理, 就让笨蛋白痴写下来给自己看吧. 你看, 前面至少已经有一个错字了:) 直到最近写一个东西时, 突然需要某一个gif, 还希望透明. 要我去装photoshop? 哦,算了吧. 好像挺简单的, 于是我放下手边的进程,开始投入gif,我以为是2天搞定, 后来,写完后觉得, 既然实现gif透明了, 为何不把效果展示给用户看? 要我用gdi+ ? com 组件?前者我很喜欢,后者我很头大. 可是想到一个gif透明工具, 里面的解码器竟然是调用gdi+这些第三方的, 嗯, 一个字形容,不爽:) (我是笨蛋) 其中遇到的一些问题, 网络上一般语焉不详, 所以斗胆写了, 嗯, 写了这篇狗屎.2. 文件结构 巴尔扎克说过类似的话: 第二个形容女人如花的是一个蠢货. 作为笨蛋我不希望是蠢货, 所以我不费时费力,把外面到处都有的东西再花时间写一遍, 我喜欢偷懒, 所以我来引用, 各位可以看看下面的链接:http:/local.wasp.uwa.edu.au/pbourke/d

2、ataformats/gif/ 这是一个英文文档, 写的很好,很详细http:/ 这是那个英文文档的翻译, 写的很好, 很详细. 可是缺少一些解释,有些东西也有纰漏, 这正是我等一下要说的. 纵观整个Gif结构, 我们看到两种快结构( Block Struct ) , 一种是定长,一种是那个. 定长: 1. Gif头 2. Gif 画布描述头, 英文叫逻辑屏幕标识符(Logical Screen Descriptor) . 3.Gif帧描述头 英文叫图象标识符(Image Descriptor) 4.Gif扩展控制头 英文叫图形控制扩展(Graphic Control Extension) 5. Gif 结束块(一个字节3B) 不定长: 颜色表(包括全局和局部), 数据块. (还有一些什么注释块, 应用程序扩展块,图像文字扩展块) 在英文文档中,有一些名词是我们迷惑我们的, 比如什么叫逻辑屏幕? 为什么我的GIF会和屏幕有关系,还是逻辑的? 哦,不,我大脑要不逻辑了. 其实所谓屏幕,其实是指Gif的图像的总大小. 我称之为Gif的画布描述. 然后说说Gif帧描述头(图像标识符-Imag

3、e Descriptor),对于拥有n帧Gif(即动画), 我们会有n帧描述头, (当然,官方叫它图像标识符,我觉得这名字起的很牛屎) , Gif有一个特点: 每一帧可以只在画布的某一区域绘画 , 比如在一片草地上,一只猪在原地跑, Gif可以只在第一帧画一幅背景, 以后的每一帧只在猪的地方画上猪.汗 所以我们才看到Gif图像标识符会有一个 left, top ,width, depth 的结构. 这也是我叫他 帧描述头的原因,他只是画布(整个Gif)的一部分. 再说说Gif扩展控制头, 他不是必需的, 但是如果有了它,可以实现透明,还可以决定绘画上下帧时对于两者没有重叠的地方的取舍. ( 可以保留, 或者用背景色覆盖 ) 有一个问题, 我们知道Gif协议有87a和89a两种, 我建议大家不用在乎两者的区别. 您知道,87a的协议中没有Gif扩展控制头, 可是我亲眼看到一个87a的Gif 有扩展控制块. 另一个问题, 尽管Gif协议看上去许多块没有顺序的要求,特别是注释块,应用程序扩展块,这种无足轻重的块可以出现在任何位置. 但是其他一些重要块还是有内定的顺序. 一般是：Gif头-画布

4、描述-全局颜色表(如果画布描述头说有全局表的话)-Gif扩展控制头(可能没有)-Gif帧描述头-局部颜色表(如果Gif帧描述头说有局部颜色表)-数据块-重复(Gif控制,描述,局部颜色,数据)-结束块. 颜色表和数据块的结构参看那两文档 2. 的第一段. 什么注释块,程序扩展块, 图像文字扩展块,文档说的有点模糊. 实际上他们的结构是相似的, 都是一个头+数据. 而数据的结构和颜色表,压缩数据块的排布是一模一样的, 都是 1个字节表示长度.一个字节表示长度.最后0,表示后面的数据长度是0,没有数据了 基本上在结构方面我也就这些要补充, 如果还有疑问,可以提问,我会添加.3.解码器 巴尔扎克说过类似的话: 如果你是蠢货,就赞美女人如花吧! 废话少说,上文档: http:/ 其中包含了编码和解码. 您必须看懂编码,就能圆满理解解码. 理解了就不难了, 比起编码,解码实在太容易了. 当然细节处这篇文章没有涉及. 问题一: 在解码的解说时,原文说: 第一步，取第一个和第二个数据，是（A，B），不认得，令6（A，B） , 在实际解码中您完全不必要去考虑,取得的两个数据是在过去是不是出现, 看看编

5、码的时候,你就会知道, 每个数据组合在解码时都是全新的Code, 你只需另Code+1即可. 问题二: 在实际的解码中, 第一个数据往往就是CLEAN标志, 这是为了算法而优化的设计,这样我们能直接进入解码循环,而不必在循环外部初始化. 问题三: 在实际编码中, 一个Code最大长度是12bit, 能表示最大数为4095. Gif协议说, 在4095以后会使用CLEAN标志归零. 这里就有一个问题, 也许这里说不明白,但是您亲自动手写一写,就会明白了. 我用程序说话: /下面这段程序是读取数据时,确定数据长度的. /wCurCode是当前编码 /byBitWidth是当前数据长度 /注释中byOriBitWidth是指初始时的数据长度,也就是所谓的:LZW code size while( wCurCode (112 ) byBitWidth = 12;问题就是,你还没有遇到CLEAN, byBitWidth 就要超过12,变成13了, 这不是不符合要求了吗? 没错, 很奇怪的地方, 解决的办法就是继续用 12bit, 而不是13bit. 幸运的是, 其实这个时候,读取的数据就是CLE

6、AN标志. 这个问题困扰我很久.真该死. 好了,下面我给出一个算法, 这是一个非常不安全的算法,它假设调用者给予它的内存,能够放下所有图像数据, 因为我不想因为旁枝末节的东西,影响您的阅读,我删除了所有检查,把一些功能以函数的方式分解, 尽管,这样解码速度会有影响,当然,这对您有好处,不是吗? BOOL _UncompressGifFrame(PBYTE pGifImageData, PBYTE pOutput) /* 1. 把pGifImageData指向的数据,转换成纯粹的图像压缩数据,便于处理 DWORD dwCompressDataSize = 0; /扫描指针pTmp,计算实际数据大小(即不包含每一个块的第一个字节) PBYTE pTmp = pGifImageData+1;/第一个字节是 LZW Mini Code while( pTmp0!=0 ) dwCompressDataSize+=pTmp0; pTmp+=pTmp0+1;/ +1 表示算上自己本身 /创建压缩数据数组 PBYTE npImgData = new BYTE dwCompressDataSize ;

7、:memset( npImgData, 0, dwCompressDataSize ); pTmp = pGifImageData + 1;/第一个字节是 LZW Mini Code for( DWORD i = 0; pTmp0!=0 ; i+=pTmp0,pTmp+=pTmp0+1) :memcpy( npImgData+i, pTmp+1,pTmp0); /* 2. 解压缩数据 BYTE byOriBitWidth = pGifImageData0; BYTE byCurBitWidth = byOriBitWidth + 1; WORD GIF_CLEAN = 1byOriBitWidth;/得到CLEAN标志 WORD GIF_END = GIF_CLEAN+1;/得到END标志 WORD wCurCode = GIF_END+1;/当前Code BYTE byBitI = 0; /用于定位当前的数据,详细见GETCURDATA() DWORD dwByteI = 0; /前缀后缀记录器 WORD arrPrefix4097=0; WORD arrPostfix4097=0; /输出前缀堆栈数组 WORD arrStack4098 = 0;/每当一个输出一个前缀的时候, 为了正确表示这个前缀所代表的数据, 配合arrPrefix,arrPostfix,输出到arrStack /再从arrStack的最末端,输出到输出数组pOutput; DWORD dwOutputI = 0;/输出数组计数器 DWORD wPrefix = GETCURDATA(); DWORD wPostfix = 0; for( ;dwByteIdwCompressDataSize;) if( wPrefix = GIF_END ) break; if( wPrefix = GIF_CLEAN ) wCurCode = GIF_END+1; byCurBitWidth = byOriBitWidth; :wmemset( (PWSTR)arrPrefix, 0 , sizeof(arrPrefix)/sizeof(WORD

《GIF文件结构与解码器》由会员卷****络分享，可在线阅读，更多相关《GIF文件结构与解码器》请在金锄头文库上搜索。