读这3MF Project GIF和所有小节有你需要的所有步骤的例子,其余的是在spec文件。
现在的图像数据
流数据具有1个字节块大小开始,然后进入的比特流。最后是另一个块大小。当你绘制整个框架时,它停止,然后在最后一个加速块之后设置指针。
如果您发现块大小0
那么它意味着帧数据的结束。如果在终止符0x3b
之后则到达文件末尾。
本地颜色位将告诉您在启动时每个代码在流中有多少位。
我读取实际处理BYTE的LSB,然后将其右移,然后将代码右移并将此位添加为MSB。在达到索引处理所需的位数后,通过LZW解压缩,并将新代码添加到字典中。
如果字典交叉2 ^比特边界增加码比特并继续。不要忘了处理清楚,结束特殊代码...
所以,你必须:06 6b 40 86 70 48 2c 1a
06h
是初始位大小 - 1所以实位大小7
!
6bh
是以字节为单位的块大小
40h
是清楚代码(意味着存在64种颜色中color[]
表,和第一自由指数66)
86 70 48 2c 1a [hex]= |1 0000110|01 110000|010 01000|0010 1100|00011 010| [bin]
所以代码为:
|0000110|110000 1|01000 01|1100 010|010 0010| [bin]
|0000110|1100001 |0100001 |11000010|0100010 | [bin]
06,61,21,c2,22 [hex]
的61h
表明,在数据错误真的是这样开始的图像数据(或我犯了一个错误的地方)?代码可以只有一个大于字典中的最大索引。除了第一个字典以外,字典增加了每个代码,所以在处理61h
时字典的大小只有42h
。尝试在他们工作的链接页面中的示例...
您可能会研究一些现有的代码。以下是我今天使用过的一个:http://read.pudn.com/downloads3/sourcecode/graph/9721/DECODER.C__.htm解码表以已知状态开始并在每个新代码都更新时更新解码,与表格在编码时更新的方式相同。这是LZW的美丽。 – 2012-08-16 18:03:12
@MarkRansom感谢您的链接!我发现很多解码示例都过于优化,无法轻松读取。 – Eugene 2012-08-16 18:19:39
P.S.我在多年前发现了这个函数中的一个错误,不知道这个函数是否已经修复。这是一个脱节或类似的东西,并没有经常出现。 – 2012-08-16 19:12:40