2017-02-15 5 views
0

私の主なプロジェクトの1つは、マイクロコントローラ用のディスプレイライブラリです。その一部として、フォント(ビットマップ)とアイコン(アルファチャンネル)のコレクションがあります。ビット単位のデータに対する効率的なRLEアイディア

マイクロコントローラではリソース(フラッシュメモリとRAM)が制限されているため、これらのフォントとアイコンのデータを保存するためのより良い方法を検討しています。

私は、アミーガのILBMのように、データの分離された平面配置を使うことに傾いています。つまり、各ピクセルのすべてのビットを一緒に保存するのではなく、イメージ全体のすべての最初のビットをまとめて格納します2番目のビットが続きます。これは、2の累乗ではない画像深度で作業する方が効率的になります(3ビットデータを8ビットデータストリームにパックしてみましたか?)。

また、これらのビットプレーンのそれぞれを圧縮したいと思います。 RLEが最も賢明であるようです。しかし、私は整数の数ではなくビットの流れを扱っているので、RLEを実装する最良の方法は何だろうと思っています。

私は、8のブロックでビットを扱い、繰り返しバイト(2つ以上同じ、2つの同じものに続けて同じくらい多くの数をカウントしたもの)を探している従来の方法に固執することができましたが、 1つの単一のビットプレーンを構成するビット単位のデータについては、それほど優れていることは理解できません。 (ちなみに、ILBMはデータを純粋にバイトとして扱い、必要に応じて次のバイトの処理方法を定義する "header"バイトで繰り返す、このバイトワイズメソッドのさまざまな方法を使用します。

代わりに、交互ビットカウント方式を使用することもできます。つまり、ビットが0であると仮定して、そのビットの数を実行に記録します。次に、1に切り替えて、実行中に1ビットの数を記録します。その後、再び0に戻り、ビット数を記録します。など

同じビットの長い実行がある場合は素晴らしいですが、すぐにビットの急速な変更を取得すると、スペースの大幅な増加に終わる(8ビット、たとえば01010101、終了可能性があります8バイトの[1,1,1,1,1,1,1,1]として上書き)。

ここでの主な注意点は、効率的でなければならないことです。CPUで圧縮解除する必要があり、圧縮解除中に作業バッファを保持するメモリが必要です。そういうわけで私はRLEを他の方法よりも考えているのです。

私は逃したアイデアを探していると思います。単一ビットのストリームを圧縮し、その圧縮データをバイト中心のシステムで表現するための最良の実装は何でしょうか?


例グリフ(10進数):ビットプレーン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 

しかしグリフこのサイズは私もしようとしそうにないことになる

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

ビットマップイメージの圧縮の問題は何十年もの研究課題でしたので、JBIG2の結果をそのまま使用することができます。あなたはオープンソースのJBIG2コードのためにgoogleすることができます。

+0

JBIG2は、同じデータブロックのパターン(ページ上の文字など)を繰り返し、単一の1ビットビットマップに最適化されていると効率的です。マルチビットプレーンイメージでは、特にイメージがフォント内の単一のグリフ、アイコンなどのような繰り返しパターンを多く取得する傾向はありません。ここでは、おそらく数千のピクセルのビットプレーンを話しています(48x48はビットプレーンあたり2304ビットになります)。私はそれがたくさん聞こえないことを知っていますが、あなたはそれらのうちの数百、そして数百kBの記憶容量しか持たないときは、サイズが重要です。 – Majenko

+0

グレースケールイメージをプレーンに分割するのは、JBIG2の使用方法です。それはあなたが短時間で調理しようとするものよりも、あなたのデータ上で優れたパフォーマンスを発揮するでしょう。 –

関連する問題