有关GIF数据的长度可变LZW算法

余烬之中

据说在这个区必须@，否则几个月也难被注意到
@晴兰 @fux2 @taroxd @喵呜喵5 @VIPArcher

最近突然想在RGSS中实现播放gif文件，大概的思路是新建类GIF读取文件并解压成一串Bitmap，然后添加Sprite对GIF的支持，后面这个应该没什么问题，只是在GIF压缩算法上还有点疑问

搞了两个下午，标准的LZW算法倒是已经实现了：Github，应该没有问题

对GIF的数据结构分析也完成了（大部分），只剩下图像数据块和文本数据块并没有进行Bitmap的建立（也就是难在这里了），目前的进度：Github

希望是纯ruby实现

相关资料,链接

问题就是，ruby读取文件都是按字节读取，在这里就必须反编译为编码流，然后再应用长度可变LZW解压
另外长度可变LZW解压现在也暂时没有去实现，如果不能反编译的话实现了也没有什么意义

还有一个问题就是，读取出并解压了后，可以对照颜色表光栅数据什么的，应该如何建立Bitmap对象

另外还有这个，讲述解压缩的：链接

不太清楚四个通道指的是什么（具体操作）
当然 在解压缩之前 不管几个通道都是废话 所以还是要先专注在第一个问题

喵呜喵5

四个通道就是RGB以及Alpha吧？

fux2

某截图脚本以及柳之一的bitmap类marshal范例演示了如何将bitmap对象的data塞到RM的bitmap里面。

satgo1546

把GIF的每一个像素计算出来然后一个个像素地set_pixel……
话说有个gem叫做chunky_png
LZ是要做个chunky_gif的节奏……
反正我每次读这种二进制文件结构都是失败的我也不掺合了……
我注意到了这个帖子嗯。
还有LZ你不是离开了吗？难道某个时候已经到了？（如果是我记错了请无视

---

@余烬之中 也许我还需要科普一下……
为了让用户在浏览器里看图片的时候不是从上到下一行行看见图片，出现了交错的图像，这样的话像素的顺序就是第二段引用中的顺序了。
数据传输过程是先传通道1，然后通道2，……，然后通道4。
第0次收到数据：为数据开始符，切换到GIF处理器来接收数据。
第1次收到数据：为通道1，因为是第1次，计算出对应的行数为0。于是往图像中的第0行填色。
第2次收到数据：为通道1，因为是第2次，计算出对应的行数为8。于是往图像中的第8行填色。
第3次收到数据：为通道1，因为是第3次，计算出对应的行数为16。于是往图像中的第16行填色。
第4次收到数据：为通道2，因为是第1次收到通道2的数据，计算出对应的行数为4。于是往图像中的第4行填色。
第5次收到数据：为通道2，因为是第2次收到通道2的数据，计算出对应的行数为12。于是往图像中的第4行填色。
……
……
……
第20次收到数据：为通道4，因为是第9次收到通道4的数据，计算出对应的行数为17。于是往图像中的第17行填色。
第21次收到数据：为通道4，因为是第10次收到通道4的数据，计算出对应的行数为19。于是往图像中的第19行填色。
第22次收到数据：为数据终止符，此时图像已经完全被颜色充满，完成数据传输。
实际上并非一定传输23次，不过一般会将数据当作23次……