画像ファイルのメモリ要件を理解する

9

240x400解像度のディスプレイに表示される画像リソースファイルのメモリ要件を理解したい。

ディスプレイには次の仕様があります。

最大18ビットの色深度をサポートし、ILI9327ディスプレイドライバーを使用します。

サイズがそれぞれ10 mm X 10 mmの50個の異なるアイコンを表示する必要があると仮定すると、必要なストレージスペースはどれくらいですか？

これが私の計算です：

mm /ピクセル= 400 / 61.2 = 6.536

1つの画像のピクセル数= 65.36 x 65.36 = 4272ピクセル

各ピクセルには18ビットX 3（R、G、B用）= 54ビットが必要です

必要な総ビット数= 4272 x 54 = 230688ビット= 28.16キロバイト

50枚の画像の場合、1.375メガバイトのストレージが必要になります。

私の計算は正しいですか？

display

— ウイスキージャック
ソース

2

上位レベルのストレージ要件を計算しています。通常、画像は圧縮されており、非圧縮ファイルから余分なバイトを読み取るよりも、その場で（SDカードなどから）読み取りと解凍を行う方が高速です。これは多くの場合、デバイスのI / Oがボトルネックであるためです。

— キングスレー

17

mm /ピクセル= 400 / 61.2 = 6.536

うん。

1つの画像のピクセル数= 65.36 x 65.36 = 4272ピクセル

まあ、あなたはアイコンあたりのピクセルを意味します。ただし、それでも小数のピクセルを生成することはできないため、数値は65 x 65または66 x 66のいずれかである必要があります。これにより、さらに単純化されます。アイコンを64 x 64にしてみませんか？これにより、メモリのアドレス計算が簡略化され、約2％の「収縮」しか生じません。そして、私を信じて、このサイズで誰も気づかないでしょう。アイコンのサイズは4096ピクセルになります。

各ピクセルには18ビットX 3（R、G、B用）= 54ビットが必要です

いいえ。jmsがちょうど答えたように、それは合計でピクセルあたり18ビット、または色あたり6ビットです。繰り返しますが、ビットレベルについてはそれほど心配しないでください。色の値を部分的なバイト（バイトごとに6ビット）として、色ごとに個別のバイトとして保存します。これにより、メモリが33％増加しますが、メモリから画面に転送する際の処理負荷が大幅に軽減されます。

必要な総ビット数= 4272 x 54 = 230688ビット= 28.16キロバイト

合計ビットは、4096 x 24、または98304ビット、または12288バイトです。

50枚の画像の場合、1.375メガバイトのストレージが必要になります。

12288に50を掛けると、614400バイトになります。

— WhatRoughBeast
ソース

1

しかし、確かに永続ストレージについて話している場合は、アイコンをPNGまたはJPEGとして圧縮して保存しますか？または、フレームバッファについて話している場合、それは単なる(display_width * display_height * bpp) / 8バイトですか？

— aroth

@aroth-これにより、トレードオフの領域にまっすぐに行くことができます。より重要なのは、メモリサイズまたは処理要求ですか。圧縮されていない画像を使用すると、大きなファイルを犠牲にして、画面に転送するのに本質的に苦痛はありません。大きな単語からカラーデータをアンパックする必要がないため、さらに簡単です。圧縮された画像を解凍したり、カラーテーブルを適用したりすると、データファイルをはるかに小さくすることができますが、初心者にとっては処理に手間がかかります。それはすべて優先順位と好みの問題です。

— WhatRoughBeast

11

アイコンを64×64ピクセルにして、自分の生活をシンプルにしましょう。それらを大きく見せたい場合は、それらの周りに境界を描きます。

16ビットのカラーフォーマットでは、アイコンごとに8 kB、または50のセットの場合は400 kBしか必要ありません。

単純な圧縮形式の1つは、すべてのピクセルの色を直接格納するのではなく、カラーテーブルを使用することです。アイコンには16色で十分です。特に、クリエイティブなディザリングを適用する場合は特にそうです。これにより、アイコンごとに2 kBに加えて、カラーテーブル用に32バイトにストレージが削減されます。すべてのアイコンに独自のカラーテーブルがある場合、合計ストレージは101 kBを少し超えます。

自分の好奇心を満たすために、私は次の「最悪の場合」の画像を取得しました（ここから）：

このImageMagickコマンドライン

convert image.jpg -crop 267x267+66+0 -resize 64x64 -colors 16 final.png

これに変えました：

悪くはありません。もちろん、色の範囲がより限定されたソース画像がさらに良くなります。たとえば、同じ方法で処理されたOlinは次のとおりです。

— デイブ・ツイード
ソース

2

キーワード：インデックス付きの色。たとえば、ビットマップあたり16色では不十分な場合は、アイコンをいくつかの小さなビットマップに分割し、それぞれに異なるパレットを使用できます。ディザーを適用することも役立ちます。

— jms

9

色深度の詳細

デイブツイードの答えを拡張すると、彼が示したものよりもさらに上手くいくことができます。

これは、彼が使用したのと同じ大きなサイズのオリジナルです。

正方形に切り取られ、64 x 64ピクセルに縮小されますが、フル（赤、grn、bluごとに8ビット）カラーを使用すると、次のようになります。

チャネルごとに8ビットから6ビットにカラー情報を丸めると、次のようになります。

これは、18ビットの色深度をサポートしていると言うので、ディスプレイで実行できることです。

色情報をさらに赤の5ビット、緑の6ビット、青の5ビットに丸め、合計で16ビット/ピクセルになります。

これは本当にアイコンとしては十分なはずです。

圧縮を行わなくても、このフォーマットのアイコンは64 x 64 x 2 = 8192バイトしかかかりません。このような画像が50個ある場合、409,600バイトが必要になります。

— オリン・ラスロップ
ソース

2

画像は4ビット/ピクセル（16色）に圧縮されています-アイコンあたり2kバイト、さらに32バイトのルックアップテーブル。限られた色のセットでのディザリングがどのように見えるかを示したかったのです。

— Dave Tweed

さまざまな色深度を比較しているので、8ビットのカラーマップを追加することに注意してください。これは、既に存在する4ビットと16ビットのバリアントの中間（対数）になります。

— ilkkachu

@Dave：答えからははっきりしませんでしたが、それはディザリングアーティファクトを説明しています。

— Olin Lathrop

8

各ピクセルには18ビットX 3（R、G、B用）= 54ビットが必要です

見積もりが間違っています。「18ビット」の値は、色ごとではなくピクセルごとです。赤、緑、青の各チャネルの最大ビット深度は6ビット（64の異なる値）、合計18ビットです。
このディスプレイコントローラーは16ビットモードもサポートします（ピクセルデータは赤の場合は5ビット、緑の場合は6ビット、青の場合は5ビットのみ）。これにより、各ピクセルを2バイトに簡単にパックできます。これにより、ビットマップを効率的に保存しやすくなり、1秒あたりのディスプレイに書き込むことができるピクセル数が増加します。

1つの画像のピクセル数= 65.36 x 65.36 = 4272ピクセル

小数ピクセルを実際に格納することはできないため、実際のビットマップ（画像/スプライト/文字/その他）はおそらく65 ² = 4225ピクセルになります。

簡単な方法（16ビットR5G6B5ピクセル形式）を使用すると、4225 * 16ビットはビットマップあたり67600ビット、つまりビットマップあたり8450バイトになります。50枚の画像には423 kBが必要です（圧縮なし）。

フルカラー深度が本当に必要な場合は、ピクセルあたり2バイト以上が必要です。その段階で、（WhatRoughBeastが示唆するように）各色に1バイトを割り当てることもできます。これにより、ストレージ要件が3/2（50の65x65ビットマップに対して634 kB）だけさらに膨らみます。

また、ビットを浪費することなく、18ビットピクセルを互いに隣接してメモリ内にパックすることもできます（サブピクセルビットはバイト境界に揃えられていません）。50個の65x65 18ビットビットマップに必要なのは476 kBだけですが、プログラミングが面倒で処理が遅くなります。

— jms
ソース