我正在编写一个C库,将SDL_Surfaces导出为各种格式作为练习, 到目前为止,我得到了BMP,TGA和PCX格式。现在我正在研究GIF 格式,我觉得我非常接近它的工作。我的实施是一个 修改后的this one。
我目前的问题是编写GIF LZW压缩图像数据子块。一切顺利,直到 第一个子块中的位置208。原始文件中的三个字节是(从位置207开始): 十六进制的“B8 29 B2”,我的是“B8 41 B2”。之后,字节“同步”了 再次。在压缩流的下游,我可能会发现类似的差异 由第一个错误引起的。我的文件也比原文件短。
我应该注意到我将lzw_entry结构的类型从uint16_t更改为int以允许 -1表示“空”条目,因为0是有效条目。它并没有真正有所作为 但是在压缩流中。原始实现使用未初始化的数据 改为标记空条目。
我认为我正在错误地阅读我的字典值,这就是为什么我得到的位置208的另一个代码比预期的要多。否则,我的bitpacking不正确。
我添加了压缩代码的精简版本。可能是什么问题?另外,我怎么样 使我的“字典”数据结构更好或使比特流写得更快?
最后,我也知道我可以在这里和那里优化一些代码:)
static Uint8 bit_count = 0;
static Uint8 block_pos = 0;
int LZW_PackBits(SDL_RWops *dst, Uint8 *block, int code, Uint8 bits) {
Uint8 out = 0;
while (out != bits) {
if (bit_count == 8) {
bit_count = 0;
if (block_pos == 254) { // Thus 254 * 8 + 8 == 2040 -> 2040 / 8 = 255 -> buffer full
++block_pos;
SDL_RWwrite(dst, &block_pos, 1, 1);
SDL_RWwrite(dst, &block[0], 1, block_pos);
memset(block, 0, block_pos);
block_pos = 0;
} else
++block_pos;
}
block[block_pos] |= (code >> out & 0x1) << bit_count;
++bit_count; ++out;
}
return 1;
}
#define LZW_MAX_BITS 12
#define LZW_START_BITS 9
#define LZW_CLEAR_CODE 256
#define LZW_END_CODE 257
#define LZW_ALPHABET_SIZE 256
typedef struct {
int next[LZW_ALPHABET_SIZE]; // int so that -1 is allowed
} lzw_entry;
int table_size = 1 << LZW_MAX_BITS; // 2^12 = 4096
lzw_entry *lzw_table = (lzw_entry*)malloc(sizeof(lzw_entry) * table_size);
for (i = 0; i < table_size; ++i)
memset(&lzw_table[i].next[0], -1, sizeof(int) * LZW_ALPHABET_SIZE);
Uint8 block[255];
memset(&block[0], 0, 255);
Uint16 next_entry = LZW_END_CODE + 1;
Uint8 out_len = LZW_START_BITS;
Uint8 next_byte = 0;
int input = 0;
int nc = 0;
LZW_PackBits(dst, block, clear_code, out_len);
Uint8 *pos = ... // Start of image data
Uint8 *end = ... // End of image data
input = *pos++;
while (pos < end) {
next_byte = *pos++;
nc = lzw_table[input].next[next_byte];
if (nc >= 0) {
input = nc;
continue;
} else {
LZW_PackBits(dst, block, input, out_len);
nc = lzw_table[input].next[next_byte] = next_entry++;
input = next_byte;
}
if (next_entry == (1 << out_len)) { // Next code requires more bits
++out_len;
if (out_len > LZW_MAX_BITS) {
// Reset table
LZW_PackBits(dst, block, clear_code, out_len - 1);
out_len = LZW_START_BITS;
next_entry = LZW_END_CODE + 1;
for (i = 0; i < table_size; ++i)
memset(&lzw_table[i].next[0], -1, sizeof(int) * LZW_ALPHABET_SIZE);
}
}
}
// Write remaining stuff including current code (not shown)
LZW_PackBits(dst, block, end_code, out_len);
++block_pos;
SDL_RWwrite(dst, &block[0], 1, block_pos);
SDL_RWwrite(dst, &zero_byte, 1, 1);
const Uint8 trailer = 0x3b; // ';'
SDL_RWwrite(dst, &trailer, 1, 1);
更新:我已经做了一些测试,并实施了Aki Suihkonen建议的位打包算法。没有明显的区别告诉我,我在lzw_table结构中错误地查找/存储代码,并且错误是在主循环中。
答案 0 :(得分:2)
这不是问题的原因,但是有时需要写字符255吗?
SDL_RWwrite(dst, &block_pos, 1, 1);
第一个指针如何使写入速度更快:
void bitpacker(int what, int howmany)
{
static unsigned int bit_reservoir=0;
static int bits_left = 0;
static unsigned char *my_block = start_of_block;
bit_reservoir|=what<<bits_left; // you can optionally mask: (what & ((1<<howmany)-1))
bits_left+=howmany;
while (bits_left >= 8) {
*myblock++ = bit_reservoir;
bits_left-=8;
bit_reservoir>>=8; // EDIT: added, even though it's so obvious :)
if (myblock==end_of_block) { my_block=start_of_block;
write(my_block,1,block_size, outputfile);
}
}
// and while we are here, why not reserve a few kilobytes at least for myblock?
}
字典的4MB内存很多(特别是与1987年开发标准时相比),但可能没有那么多来证明编写更复杂的哈希表。但基本单位可能很短。如果只是将代码+ 1写入表中(并将其读作表[a] .next [b] -1),也可以将其初始化为零。
可以优化表清除。保留了4MB内存但使用的条目少于4k。
int *clear_table[MAX_CODES];
...
{
// memorize the address that is changed...
int *tmp = clear_table[next_entry] = &lzw_table[input].next[next_byte];
nc = *tmp = next_entry++;
}
if (need_to_clear) { for (int i=258;i<MAX_CODE;i++) *(clear_table[i]) = 0;