私の主なプロジェクトの 1 つは、マイクロコントローラー用のディスプレイ ライブラリです。その一部として、フォント (ビットマップ) とアイコン (アルファ チャネル) のコレクションがあります。
マイクロコントローラではリソース (フラッシュ メモリと RAM) が限られているため、これらのフォントとアイコンのデータを保存するより良い方法を検討しています。
私は、データに分離平面配置を使用することに傾いています (Amiga で使用されている ILBM のように)。つまり、各ピクセルのすべてのビットを一緒に保存する代わりに、画像全体の最初のすべてのビットを一緒に保存し、その後にこれは、2 の累乗ではない画像深度を扱う場合により効率的になります (3 ビット データを 8 ビット データ ストリームにパックしようとしましたか?)。
また、これらの各ビットプレーンを圧縮したいと思います。RLE が最も賢明なようです。しかし、私は現在、整数ではなくビットのストリームを扱っているので、RLE を実装する最善の方法は何かと考えています。
8 のブロックでビットを処理し、繰り返されるバイトを探すという従来の方法に固執することもできます (2 つ以上の同じもの、2 つの同じものに置き換え、続いて実行中の数のカウント)。 1 つのビットプレーンを構成するビット単位のデータに関しては、これは非常に優れています。(ちなみに、ILBM はこのバイト単位のさまざまな方法を使用します。つまり、データを純粋にバイトとして扱い、必要に応じてそれらを繰り返し、次のバイトの処理方法を定義する「ヘッダー」バイトを使用します)。
別の方法は、交互ビットカウント方式を使用することです。つまり、ビットが 0 であると仮定して開始し、実行中のそのビットの数を記録します。次に、1 に切り替えて、実行中の 1 ビットの数を記録します。次に、再び 0 に切り替えて、ビット数を記録します。等。
繰り返しますが、同じビットが長く続く場合は素晴らしいですが、ビットが急速に変化するとすぐに、使用されるスペースが大幅に増加します (たとえば01010101、8 ビットは の 8 バイトになる可能性があります[1,1,1,1,1,1,1,1])。
ここでの主な注意点は、圧縮を解除するための CPU と、解凍中に作業バッファーを保持するためのメモリの両方で、効率的でなければならないということです。そのため、他の方法ではなく RLE を考えています。
だから、私が見逃していたアイデアを探していると思います。単一ビットのストリームを圧縮し、その圧縮データをバイト中心のシステムで表現するための最良の実装は何でしょうか?
グリフの例 (10 進数):
00 00 02 14 03 00 00 00
00 00 09 13 10 00 00 00
00 00 13 05 13 00 00 00
00 05 12 00 12 06 00 00
00 11 15 15 15 11 00 00
00 14 02 00 01 14 00 00
08 12 00 00 00 12 08 00
11 07 00 00 00 07 12 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
したがって、ビットプレーン 0 ～ 3 は
0 1 2 3
00001000 00111000 00010000 00010000
00111000 00001000 00010000 00111000
00111000 00000000 00111000 00101000
01000000 00000100 01101100 00101000
01111100 01111100 00111000 01111100
00001000 01100100 01000100 01000100
00000000 00000000 01000100 11000110
11000100 11000100 01000110 10000010
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
ただし、このサイズのグリフを圧縮しようとすることさえありそうにありません。意味がないくらい小さいです。ただし、ビットプレーンの階層化と、ビットストリームが元のデータに関連してどのように見えるかを示しています。