3

演習としてSDL_Surfacesをさまざまな形式にエクスポートするCライブラリを作成していますが、これまでのところ、BMP、TGA、およびPCX形式を使用していません。現在、私はGIF形式に取り組んでおり、それを機能させることに非常に近いと感じています。私の実装はこれの修正版です。

私の現在の問題は、GIFLZW圧縮画像データサブブロックの書き込みです。最初のサブブロックの位置208まで、すべてがスムーズに進みます。元のファイルの3バイトは（位置207から開始）：16進数の「B829 B2」であり、私のものは「B841B2」です。その後、バイトは再び「同期」します。圧縮されたストリームのさらに下流では、おそらく最初のエラーが原因で、同様の違いを見つけることができます。私のファイルも元のファイルよりも短いです。

0は有効なエントリであるため、lzw_entry構造体のタイプをuint16_tからintに変更して、-1を「空の」エントリとして許可することに注意してください。ただし、圧縮されたストリームには実際には違いはありませんでした。元の実装では、代わりに初期化されていないデータを使用して空のエントリをマークします。

辞書の値を誤って読み取っていると思います。そのため、位置208に予想よりも別のコードが表示されます。そうでなければ、私のビットパッキングは正しくありません。

圧縮コードの簡略版を追加しました。何が問題なのでしょう？また、「辞書」データ構造を改善する方法、またはビットストリーム書き込みを高速化する方法を教えてください。

最後に、私はあちこちでいくつかのコードを最適化できることも知っています:)

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);

更新：私はさらにいくつかのテストを行い、AkiSuihkonenが提案したビットパッキングアルゴリズムを実装しました。目立った違いはありませんでした。これは、lzw_table構造体でコードを誤って検索/保存していることと、エラーがメインループにあることを示しています。

4

1 に答える 1

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 年と比較すると)、おそらく、より複雑なハッシュ テーブルを作成することを正当化するにはそれほど多くはありません。ただし、基本単位は短くなる可能性があります。code+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;
于 2012-10-16T15:56:37.553 に答える