JPEG再考

年末に3つのデコーダの記事を書いて、3つのデコーダを担当するタスクは同時に走ることはないので、スタックを含むRAM空間を共有できることを説明しました。この記事を書いて、自分でももう一度確認してみようと思い立った事があります。それが、アルバム画像の表示についてです。MP3再生では、WMPがダウンロードしてくれた画像データを表示していますが、昨年の実装の際にはJPEG画像の表示にはメモリが必要となりそうなので、これを断念していったんBMPに変換したものを表示する仕様としていました。しかし、良く考えてみれば楽曲の再生中に画像表示が必要なわけではなく、アルバム画像を表示してから再生を開始しているので、デコーダが使うメモリ領域は画像表示に利用できます。つまり、JPEG展開に要するメモリ量がMP3再生に要するメモリ量と大差なければ実装可能なわけです。

さっそくJPEG展開に必要なメモリ量を確認してみました。今回は、libjpegの最新版であるrelease 7を使うことにします。まずはドキュメントの確認です。libjpeg.txtにはMemory usageという節があり、それによるとまずは静的におよそ24Kバイトを必要とし、それに加えて画像の幅に比例したバッファ領域を必要とするようです。おぉ、24KBというサイズは、ほぼMP3のデコーダが必要とするメモリ領域と同等です。あとは画像の幅に比例したバッファ領域ですが、アルバム画像は幅80ピクセル程度ですからこれも大して喰わないはずです。これならなんとかなりそうじゃないですか。

libjpeg.txtのメモリ必要量の記述はv6bの頃の数字のようですし、画像幅に応じたメモリ量を確認するためにも、実際に使ってみて消費されるメモリ量を確認してみました。まずはLinux上での確認です。djpegのソースとメモリ管理するjmemnobs.cにちょっとprintf追加してみました。



矢印の左側の数字が追加獲得したメモリ量、右側は合計量です。jpeg_start_decompressで、画像幅に応じた領域まで割り当てられているようですが、アルバム画像ファイル程度の大きさなら30KBもあれば充分なようです。それじゃ、ちょっと画像ファイルを大きくしてみましょう。



今度↑はVGA(640x480)のファイルですが、確かにメモリ使用量増えてます。さすがに64KBのうちの半分以上を使われるのはツライ。せめて半分の32KB以下に抑えたいところです。そこで....



LCDはQVGAですのでVGAの画像はそのままでは表示できません。そこで、展開時にスケーリングして半分にしています。縮小することでメモリ消費量も抑えられるのですが、アルバム画像の時と同量のメモリしか割り当てられていません。この理由については調べていませんが、元のJPEG画像のカラーモデルに違いがあったりするのかもしれません。それじゃ、さらに大きい元画像を試してみましょう。



djpegで指定できるスケーリングはn/8となっていますので、この大きさになると1/8にしないとLCDに収まりません。結果、表示画像サイズは200x150となり、QVGAを下回ります。その影響もあってか、メモリ使用量も減ってます。

大雑把に見て30KB～32KBのメモリ・プールを用意しておけば、アルバム画像だけでなく、デジカメ画像の表示もできそうです。こうなったら、簡易フォトフレーム機能も追加するしかないですね。