640x480 JPEGの最大サイズは?


25

数時間かけて夜空の特定の数の写真を撮るデータストレージデバイスを作成しています。写真はすべて撮影された直後にダウンロードされます。メモリカードは、すべての写真を一度に保存できる必要があります。

撮影されるJPEGは640x480ピクセルであり、100個すべてのメモリカードに十分なスペースがあることが不可欠です。それでは、640x480 JPEGの最大サイズは何ですか?

これを理解するためにいくつかのテスト写真を撮りました。

#1#2#3

  • 「stackoverflow」イメージのファイルサイズは73,774バイトです。
  • 白い画像のファイルサイズはわずか36,607バイトです。
  • ただし、市松模様の写真のファイルサイズは149,339バイトです。

複雑さとともにファイルサイズが増加すると想定しています。

100 640x480 JPEGに適合するようにメモリカードに十分なスペースをどのように構築できますか?これらのキャプチャデバイスの多くを作成している可能性があるため、余分なスペースを無駄にしたくありません。


画像プロデューサーに依存します。100品質のJPEGは、簡単にサイズを拡大できます。カメラとカメラの設定は何ですか?
ジョン・ドヴォルザーク

テストカメラはCanon Powershot A1100 ISです。詳細については、メタデータを確認してください。何を求めているのかわかりません。
ブルーアイス

1
difで夜空のサンプル写真を撮影しましたか。Q設定?テストとして?
カールB

2
これは何のためですか?jpegは正しい形式の選択です。
ジャックエイドリー

3
Jack Aidleysのコメントに背景を追加:JPEG圧縮により画像が変更されます。ファイルサイズを小さくするために、仮定を立てて情報を破棄します。(100%の品質に設定しない限り、この場合、非圧縮形式を使用することもできます。デジタルカメラには、多くの場合、この設定がTiffまたはRawでさえあります。星などの小さな点をすべて保持する場合は、これら)。これにより、画像のサイズも完全に予測可能になります。
ヘネス

回答:


22

ここでは、JPEGファイルサイズの上限を提案します。より一般的なjpegサイズの説明については、Ilmari Karonenの回答を参照してください。

640X480 32ビットビットマップイメージのピクセルストレージスペースは、次のように計算できます(この回答に基づいてますが、Ignacio Vazquez-Abramsのコメントとこの回答に基づいて修正されています)。

ファイルに圧縮が適用されていないと仮定すると、307,200ピクセルがあり、これは0.3MPです。便利なルックアップテーブル

各ピクセルに32ビットの情報が含まれている場合、

  1. 307,200 * 32 = 9,830,400ビットの情報
  2. 8ビットで除算してバイト値になります
  3. 9,830,400 / 8 = 1228800バイト(または1.17 Mb)

これは、圧縮されていないビットマップのサイズであり、jpegファイルサイズの上限である必要があります(実際には、JPEG形式は圧縮を使用するため、特に夜の写真を撮影している場合、画像ははるかに小さくなります空には多くの黒が含まれていると思います。質問の最大の画像例は0.14 MBだけです。

ただし、特定の問題に関しては、その上限を使用しても、100個の画像は117 MBしかありません。128MBという小さなメモリカードを見たのは久しぶりです。現在利用可能なメモリカードには、ニーズを満たすのに十分な容量があると思われます。

明らかに、最大のjpegファイルサイズの問題は、議論の対象です。このスタックオーバーフローの答えは、ピクセルあたり20.25バイト、または5.9 MBの理論上の最大サイズを示唆していますが、そのサイズの画像を生成するには、jpeg形式の圧縮スキームを意図的に誤用する必要があるため、このようなことはほとんどありませんカメラによって生成されたもの。


1
残念ながら、圧縮されていないビットマップ値でさえ、パッキングを前提としているため、ほんの少し低くなっています。展開されたビットマップは、ピクセルあたり32ビットを使用し(位置合わせの理由により)、ファイルサイズが33%増加します。
イグナシオバスケス-エイブラムス

@ IgnacioVazquez-Abramsに感謝します。それは、受け入れられた答えが正しいと仮定した場合に得られるものです。
ForeverWintr

1
@ IgnacioVazquez-Abrams-「Alignment」は、プロセッサ(ストレージメディアではなく)によって決定される属性であり、データが処理のためにRAMにある場合に便利です。ストレージの目的では、32ビットのワードアライメントは必要ではなく、確かに贅沢です。データをパックすることは、ストレージに書き込む前の一般的な操作で、特に25%の節約になります。生のフォーマットで各ピクセルを正確に3バイトで保存するデジタルカメラを見てきました。
おがくず

1
「...確かに贅沢。」最近。多くの月以前は、サイクル節約機能と考えられていました(どれだけ時間がかかるかを考えると、ロード時に調整する必要はありません)。
イグナシオバスケス-アブラムス

3
実際には、一部のシステムはRGB画像データをメモリ内のピクセルあたり4バイトとして保存する場合がありますが、ほとんどすべての画像ファイル形式は最大でピクセルあたり3バイトを使用します(実際のアルファチャネルが4バイト目に保存されていない限り)。以下の私の答えをご覧ください。
イルマリカロネン

35

確認するために、ForeverWintrの分析を実験的にテストさせてください。

JPEG圧縮のための入力画像の最悪の種類(または任意の圧縮、本当に)は、理論的に非圧縮性であり、ノイズ一様にランダムRGBあります。したがって、netpbmツールを使用していくつか生成します。

$ rawtoppm < /dev/urandom 640 480 > rnd.ppm
$ pnmtopng < rnd.ppm > rnd.png
$ du -b rnd.*
923772  rnd.png
921615  rnd.ppm

一様にランダムなRGBノイズ、ロスレスPNG形式
(均一にランダムなRGBノイズ、ロスレスPNG形式、903 kb)

注(2017年3月):この回答を最初に書いて2013年にアップロードしたとき、上記の画像はPNG形式であったと確信しています。ある時点で静かにJPEGに変換されたようで、ここでの視覚的な比較は役に立たない。

新しいPNGテスト画像を再アップロードしようとしましたが、どうやらそれはimgurで何らかの任意のPNGファイルサイズ制限に達し、JPEGに自動変換されます。この問題を回避する方法があるかどうかはわかりませんが、少なくともLinuxボックスにアクセスできる場合は、指定されたコマンドをいつでも再実行して独自のテストイメージを生成できます。いずれにせよ、圧縮品質の直接的な視覚的比較を防ぐことを除いて、これは以下の分析を決して無効にしません。

それで、非圧縮PPMファイルは640×480×3 = 921,600バイト長であり、予想どおり、最小PPMヘッダー用に15バイトです。PNG形式を使用してロスレス圧縮しようとすると、サイズが2157バイト増加します。これは、おそらくPNGヘッダーとメタデータが占めており、非圧縮データを圧縮しようとする圧縮アルゴリズムが若干非効率である可能性があります。

(はい、それはピクセルあたり3つのバイトではなく、4です。グラフィックファイル形式として、単純なよう程度であってもPPMフォーマットは、取得することができ、ディスク上のピクセルあたり役に立たない4番目のバイトを格納するためのダムは十分ではありませんあり。いくつかのこと特にアルファチャンネルも保存する必要がある場合、アライメントの理由でメモリ内で行うことの利点がありますが、イメージをファイルに書き込むときにこれらの理由は当てはまりません。

では、JPEGについてはどうでしょうか。最初に圧縮損失を最小化してみましょう(品質= 100、クロマサブサンプリングなし、浮動小数点DCT)。残念ながら、pnmtojpegマニュアルでは関連するすべてのオプションの設定方法が明確に説明されていません(具体的には、-sampleオプションは「libjpegドキュメントのファイルを参照するウィザードのオプション」セクションにリストされています)。代わりにGIMP。結果のファイルは次のようになります。

897249  rnd.jpg

JPEG圧縮RGBノイズ、品質= 100、クロマサブサンプリングなし
(JPEG圧縮RGBノイズ、品質= 100、クロマサブサンプリングなし、876 kb)

何、どうやって小さくできますか?純粋なノイズは非圧縮性だと言っていませんか?それは、最高の品質であっても、通常のJPEG圧縮は完全に無損失ではないということです。GIMPで画像を再度開き、元の画像と比較すると、一部のピクセルの色の値が1つまたは2つのステップ(256から)シフトされていることがわかります。これらは、JPEG圧縮アルゴリズムが「ごまかし」、ここでもう1つ捨てて、変更が目立たないと推定したピクセルです。実際、人間の肉眼では、結果は元のものとまったく区別できませんが、それらの破棄されたビットは、ヘッダーとエンコードのオーバーヘッドを考慮した後でも、ファイルサイズの測定可能な減少につながります。

それが最高の品質でした。pnmtojpegデフォルト(品質= 75、サブサンプリング有効)などのより一般的な設定はどうですか?試してみよう:

$ pnmtojpeg < rnd.ppm > rnd2.jpg
$ du -b rnd2.jpg
185128  rnd2.jpg

JPEG圧縮RGBノイズ、品質= 75、クロマサブサンプリング
(JPEG圧縮RGBノイズ、品質= 75、クロマサブサンプリング、184 kb)

すごい、901から184 kbまで!ただし、これはかなりアグレッシブな圧縮であり、画像を厳密に比較すると違いがはっきりとわかります。そのほとんどは、基本的に色(色相/彩度)データの75%を捨てるクロマサブサンプリングのためです。サブサンプリングを無効にしてGIMPで試してみると、350,618バイトのファイルが得られます。このファイルは、拡大しても元の画像に(少なくとも人間の目には)かなり近く見えます。

とにかく、このすべてのポイントは、それを実証することである、騒々しいあなたの夜空の写真があるかもしれないどんなに、あなたが選択する可能性がどのように高品質に関係なく、ただありません手立て 640×480 JPEGファイルには900を超える非常に大きい取得することができますkb。(まあ、カメラがマルチメガバイトのExifカラープロファイルまたはそれに同等の愚かさを付けていない限り) 。


4
理論的には、ロスレス圧縮の場合のみ圧縮可能ですよね?
ダニエルベック

1
@DanielBeck:そうです。明らかに、データの一部だけを破棄する場合は、必要なだけデータを圧縮できます。(これは基本的にJPEG圧縮が行うことであり、失われた部分が人間の目に見えないように、また残った部分をコンパクトにエンコードできるようにそれを実行しようとします。のみであっても非可逆圧縮アルゴリズムは、ノイズで行うことができますことは、それの一部を捨てている)。
イルマリKaronen

多分それは私だけかもしれませんが、2番目の画像は最初の画像よりも明るく見えます。
ボグダクツ

@Bogdacutu:するべきではありませんが、ブラウザが色の管理などでおかしなことをしている可能性は常にあります。グラフィックエディタで読み込み、色の値を比較してみてください。
イルマリカロネン

素敵な記事@Ilmari。
ForeverWintr
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.