【问题标题】:Encoding error in GIF LZW compressed streamGIF LZW 压缩流中的编码错误
【发布时间】:2012-10-06 14:20:33
【问题描述】:

我正在编写一个 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 结构中以某种方式错误地查找/存储代码,并且错误在主循环中。

【问题讨论】:

    标签: c encoding sdl gif lzw


    【解决方案1】:

    不是问题的原因,而是需要时不时写255字符吗?
    SDL_RWwrite(dst, &amp;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 写入表格(并将其读取为 table[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;
    

    【讨论】:

    • 是的。 LZW 的 GIF 版本要求将压缩数据打包成子块。每个子块是一个字节(1-255),告诉您子块中有多少字节,然后是压缩数据的多少字节。因此,大多数块将包含 255 个块计数,可能最后一个除外。感谢您的比特打包器。我试着写一些类似的东西,但不知何故,我就是无法理解它。我也喜欢你的“代码+1”的想法。我可以制作一个哈希表,但我认为这个想法很容易开始。
    • 对。想不起来了。在 2012 年似乎已经过时了......一个人必须清除多少代码?约 3840 出 1M。为什么不将占用槽的地址存储到数组中呢? (无论如何,首要任务是让代码工作......)
    • 好吧。由于规范允许最大位长度为 12,因此您必须清除 4096 个代码(尽管使用此实现它不仅限于此)。我想我需要你再解释一下,但是是的,我同意:代码应该首先工作:)
    • 代码0..258实际上是保留的......所以我们可以减去2。
    • 假设 8bits/pixel(这是),那么是的,clearcode 和 end-of-information 代码是保留的。明码为2^8=256,意向书码为明码+1=257。然后第一个空闲代码是 258 并且没有保留。
    猜你喜欢
    • 1970-01-01
    • 2012-10-24
    • 2019-05-04
    • 1970-01-01
    • 2012-07-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-02-09
    相关资源
    最近更新 更多