すべてのデジタル画像は、最終的には0〜255のピクセル値ではありませんか？

私は画像についていくつかの信じられないほど基本的な（愚かな？）質問があります。具体的には、画像形式とピクセル値。

許してください、私は写真家ではありません。私は画像を扱うただの人であり、私にとっては、それらは単なる数字の行と列です。

私の質問は：

コアで、写真がピクセル値[0、255] X RBGの3チャネルだけである場合、どのように2つの画像フォーマットに違いがあるのでしょうか？つまり、RAWとTIFFの違いは何ですか？これらはすべて、0〜255の値に制限されているわけではありませんか？数字は数字です-可能なセット形式は1つだけではありませんか？または、同じ高さと幅の2つの画像を同じファイルサイズにロックしないでください。

さらに、数値の観点から、16ビット画像のようなものが32ビット画像と異なるのはなぜですか？繰り返しますが、イメージは0〜255の整数値を持つ単なる配列です。

コンピューターのファイルシステム上の画像は、0から255の間の整数の3チャネル配列にすぎないというこの見方を続けると、画像を圧縮して、たとえばJPGのような非可逆形式にするポイントは何ですか？圧縮アルゴリズムが、いくつかのピクセル値を254から255またはその他の値に変更するとします。そう？それはどのようにファイルサイズの節約を提供し、視覚的な品質に影響を与えますか？

画像データを保存する方法はたくさんあることを知っています。しかし、私は基本的な3チャンネルRBCイメージ以外については何も尋ねていません。私が知っているのは、誰かがこれらのいずれかを私に渡せば、私は今、数字の配列を持っているということです。ある数値の配列が他の0〜255の数値の配列と異なる可能性がある理由を知る理由はありません。これが理にかなっていることを願っています。この質問はRAW形式に限定されません！むしろ、ピクセル値の配列についてです

申し訳ありませんが、基本的な前提は間違っています。画像は、値ごとに8ビットのRBGピクセルの配列としてエンコードできますが、他にも多くの方法があります。

• 1ビット/チャネル（純粋な白黒）を持つ1つのチャネル、
• xビット/チャンネルの1つのチャンネル（グレースケール形式、xは通常8または16で、256または65536の値を与える）、
• さまざまなパレットベースの形式（cf.GIF）
• （少なくとも理論上）必要なビット深度で必要な数のチャネルを備えたフルカラー。

そして、それは編集/表示中にコンピューターのRAMに保存された画像です。存在するさまざまなRAW画像形式を無視しています（こことこの投稿の残りの部分）。

写真の場合、最も一般的なのは、8、16、または32ビット/チャネルの3チャネル（通常は整数ですが、少なくとも一部のプログラムは32ビット浮動小数点数で内部的に動作します）です。プログラムがレイヤーの使用を許可している場合は特に、4番目のチャンネル（アルファ）がしばしばあります。そしてどこかで、画像配列の次元を保存する必要があります。

これらの異なる形式にはさまざまな理由があります。インメモリ形式の場合、重要な考慮事項は、データのサイズと速度（4つの32ビットチャネルよりも1つの8ビットチャネルを操作する方がはるかに高速）でした。これらは最近ではそれほど重要ではありませんが、さまざまな色空間で完全な色管理が可能になりました。それらの一部（プロフォトRGBなど）は、目に見えるバンディングを回避するのに十分なほど隣接する色の違いを小さく保つために、少なくとも16ビット/チャネルを必要とします。また、処理が複雑になると、32ビット浮動小数点数を使用する利点があります（色は0.0〜1.0の値でエンコードされ、処理ではこの範囲外の中間値が許可されます）。

画像をファイルに保存し、同じメモリ内データに再読み込みできるようにするには、少なくともチャネルごとにim-memory形式と同じ数のビットを使用する必要があります。また、画像の寸法、ビット深度、色空間。

これらの画像のユーザーは、画像に関する追加情報（キャプション、タイトル、画像の撮影者など）の保存も好みます。この情報を保存するさまざまな方法。

次に、ファイルストレージ用に画像データを圧縮するさまざまな方法があります。より単純なものの1つはRLE（Run Length Encoding）で、繰り返しピクセル値が検出されるたびにカウントとピクセル値を保存します。jpegなどのその他のものは、はるかに複雑ですが、圧縮率も高くなります。たとえば、jpegはコサイン変換を使用し、（目に見えない）高周波情報を破棄し、情報の損失を犠牲にして高い圧縮率を提供します（さらに多くのことがありますが、これは長すぎます）。

これはすでにディスクに情報を保存する多くの方法を提供しますが、どのような方法を選んだとしても、イメージの読み込み時に正しい解釈を可能にするためにフォーマットを適切に指定する必要があります。

その後、既存の形式では常に処理できないロスレス圧縮技術などの絶え間ない開発があります。

したがって、保存された情報の忠実度、占有ディスク容量、読み取り、書き込み、送信の速度の間のさまざまなトレードオフを伴うさまざまなファイル形式になります（非圧縮TIFFのサイズと適切な品質のjpgを比較してください） 。

メモリ内イメージを処理する場合、1つ以上の配列の形式になります。その時点で、元のファイル形式はもはや役割を果たさないはずです。8ビット/チャネルでデータを処理すると仮定します。

ただし、処理済みのイメージか生のイメージかを知る必要があります。それらには2つの重要な違いがあります。

• 生画像は通常、ピクセルごとに1色を持ち、ピクセルは通常、4ピクセルの正方形ごとに2つの緑、1つの赤、および1つの青のピクセルを持つベイヤー配列に配置されます。値はシーンの強度に比例します（非常に低い値と非常に高い値を除く）。
• 処理された画像は、3つの数値を含むレコードの2D配列として、またはカラープレーン（3つの2D配列、R、G、Bのそれぞれに1つずつ）として配置できます。また、通常、値はシーンの強度に比例しません。さらに悪いことに、ピクセル値とシーンの強度の正確な関係は、画像の処理に依存します。また、人間の目の反応に対応するように色のバランスが調整されています（ホワイトバランス、赤と青は緑に対して増幅されます）。

したがって、ピクセルごとに3つのカラー値を持つ生の画像を取得する場合、その生の画像にはすでに何らかの処理が行われています（少なくともデモザイキング、または4つの生のピクセルから1つの画像ピクセルへの単純なビニング）。それが受け入れられるかどうかは、アプリケーションによって異なります。

コアの場合、写真はピクセル値[0、255] X RBGの3チャンネルのみであり、

しかし、写真は「コアで」さえ「ピクセル値の3つのチャンネル」ではありません。通常、コンピューター画面はRGBピクセルの配列で構成されているため、コンピューター画面に画像を表示する場合は、ある時点で、持っている画像データをRGBピクセルの配列にマッピングする必要がありますが、そのデータは画像データの特定のレンダリング。画像内のデータは、ピクセル値のストリームで構成されていない場合があります。画像からピクセル値を取得するには、データのフォーマット方法を知っている必要があります。

それでは、どのように2つの画像形式に違いがあるのでしょうか？つまり、RAWとTIFFの違いは何ですか？これらはすべて、0〜255の値に制限されているわけではありませんか？

これらの2つの形式のいずれも、必ずしもRGB値の長方形配列を保持しないため、これらは2つの良い例です。

RAWは単一の形式ではありません。イメージセンサーから直接記録されたデータを含むファイルの一種のキャッチオール名です。そのため、RAWファイルには、さまざまなセンサーサイトから読み取られた電圧を表す一連の値が含まれている場合があります。これらのサイトは画像ピクセルのようなものですが、RGBピクセルではありません。RAWファイルからRGBピクセルを取得するには、センサーに関する情報、その時点でのカメラ設定などのコンテキストでそのデータを解釈する必要があります。つまり、16進エディターでRAWファイルを開くことができます必要なすべてを探しますが、単一のRGB値は見つかりません。

TIFFはタグ付き画像ファイル形式の略で、画像のさまざまな表現を含めることができるため、非常に興味深い形式です。1つのTIFFファイルには、サムネイル、画面解像度画像、印刷解像度画像など、いくつかのサイズの「同じ」画像を含めることができます。また、カラーバージョンとグレースケールバージョンがある場合もあります。ファックス機は通常、データをTIFFファイルとして送信することをご存知ですか？TIFFファイルからRGBピクセルを取得するには、TIFF形式だけでなく、そのファイル内の特定の画像表現の形式も理解する必要があります。

数字は数字です-可能なセット形式は1つだけではありませんか？

いいえ。人々はそれぞれ異なるニーズのセットを提供しているため、さまざまな画像フォーマットがたくさんあります。JPEGの非可逆圧縮は、非常に小さな画像ファイルを取得するのに最適ですが、数回編集する必要がある画像には適していません。一部の形式ではインターレースが使用されているため、いくつかの異なる解像度で非常に高速に画像を読み取ることができます。など...各形式には、それぞれの利点と妥協点があります。

または、同じ高さと幅の2つの画像を同じファイルサイズにロックしないでください。

いいえ、それはひどいでしょう。すべての画像ファイルのサイズを本質的にwidth * height * 3（24ビットカラーを想定）する必要がある場合、大量のストレージスペースを無駄にします。ほとんどの写真には多くの冗長性が含まれています。つまり、同じ色が何度も繰り返される領域です。ストレージスペースを節約するために、多くの場合、その冗長な情報を排除することが理にかなっています。これを行う1つの方法は、たとえば、ランレングスエンコーディングです、またはRLE。たとえば、4195個の連続するピクセルの領域がすべて白の場合、単に多くの白いピクセルを格納するのではなく、「次の4195ピクセルはすべて{255、255、255}」としてエンコードする方がはるかに効率的です。ファイル。実際、RLEは一部の画像形式で使用されていますが、多くの形式にははるかに洗練されたスキームがあり、スペースを大幅に節約できます。つまり、ハードドライブまたはメモリカードにさらに多くの画像を保存できます。また、画像を他の人に送信するのがはるかに速くなります。

コンピューターのファイルシステム上の画像は、0から255の間の整数の3チャネル配列にすぎないというこの見方を続けると、画像を圧縮して、たとえばJPGのような非可逆形式にするポイントは何ですか？

重要なのは、ファイルがはるかに小さくなることです。JPEG圧縮では、ファイルのサイズが10倍以上に縮小されることがよくあります。つまり、特定のストレージデバイスにより多くの画像を収めることができ、それらをより速くコピーし、より速く開くことができ、より速くアップロードおよびダウンロードすることができます。同じイメージ（または非常に近いもの）をはるかに小さなスペースに保存すると、リソースがより効率的に使用されるため、コストが削減されます。大規模に考えてみてください。インターネットで利用可能な情報の非常に大きな割合が画像と映画で構成されている可能性が高く、圧縮しないと、より多くのまたはより大きなデータセンターが必要になり、より多くのエネルギーを消費します。

圧縮アルゴリズムが、いくつかのピクセル値を254から255またはその他の値に変更するとします。そう？それはどのようにファイルサイズの節約を提供し、視覚的な品質に影響を与えますか？

上記の私のRLEの例を考えてください。大きな空白の壁が含まれている写真があるとしましょう。写真の大きな領域はすべて同じ色ですが、画像にわずかに目立つほどのわずかに暗いピクセルが散らばっています。これらのピクセルは、圧縮の有効性を低下させます。「次の500,000ピクセルはすべて{243、251、227}」と言うだけでなく、はるかに小さいチャンクを長さエンコードする必要があります。圧縮アルゴリズムに小さな変更を加え、おそらくピクセルを1％または2％だけ変更することを許可すると、画像を知覚的に変更することなく、はるかに高い圧縮率を得ることができます。それはトレードオフです：あなた ' ファイルサイズの大幅な削減と引き換えに、元の画像の少量の情報をあきらめます。その線を描画する正確な場所は変わる可能性があるため、JPEGなどの損失の多い形式では、ユーザーは圧縮レベルを選択できます。

加えて、@のレムコの幻想的な答えは、私は（大体）同じ目的のために別のコーデックがある理由を追加します。

コーデックは次の目的で設計されています。

• ロスレスvsロスリー
• 高速なエンコード対ファイルサイズを減らします
• 非対称対対称エン/デコード
• ソフトウェアと互換性がある
• さまざまな圧縮レベル/状況で知覚的にほぼ無損失であること
• 以下を含む、他のコーデックでは提供されない機能があります。
  • ロイヤリティフリー
  • レイヤーのサポート
  • アルファチャンネル（RGBAなど）/透明度のサポート
  • 高速なWebビューを提供
  • 高（より）ビット深度をサポート
  • 複数の色空間をサポート（RGB / CMYK）
  • メタデータのサポート/バージョン管理/ ...

それらのいくつかは相互に排他的です。そのため、多数のコーデックが残っています。

いくつかの例

注：コーデックのリストは完全ではなく、すべての機能（またはその欠如）も記載されていません。この回答が誰かにとって有用であることが判明した場合、さらに情報を追加することができます（そして、もう少し正確になります）。

おそらく最もよく知られている形式はJPEGです。非常に広くサポートされていますが、古い形式です。DCT（離散コサイン変換）を使用するため、最高品質の設定で非常に優れた品質を提供しますが、低い設定ではブロッキングが発生します。

その後、JPEG 2000は、JPEGを置き換えるために登場しました。Wavelet-Transformationに基づいているため、高品質設定ではJPEGとほぼ同じ品質を提供しますが、低品質設定でははるかに優れた品質を提供します（ブロックは少しぼやけています） ）。また、JPEG 2000は、関心領域（画像の1つの領域で高品質、他のどこかで低品質）と16ビットのサポートを提供します。（また、他にもいくつかあります。）残念ながら（？）、JPEGよりも計算コストが高く、ライセンスに関する懸念があるため、JPEG 2000はJPEGほど広くサポートされていません。

PNGはもう 1つの広く知られている形式です。ロスレスであり、アルファチャネルをサポートしていますが、RGB以外の色空間（CMYKなど）のサポートは提供していません。したがって、これは「オンラインのみ」形式です。

次に、OpenEXRのようなVFX形式があります。それらはすべて品質と速度を中心に展開します。OpenEXRはロスレスで、最大64ビットをサポートし、高速でエンコード/デコードします。主にVFX業界で中間形式として使用されます。

TIFFは、写真家に非常に人気のある別のロスレス形式です。圧縮の場合、none / ZIP / RLE / LZW / JPEGを提供します。最大32ビットをサポートします。選択可能な圧縮により、非常に適応性がありますが、ロスレスであるため、よりオフライン形式です。

HEIFは最新の画像コーデックの1つです。HEVC / h.265と同じ圧縮を使用するため、JPEGよりも優れた圧縮率が期待されます。しかし、それは非常に新しく、それは特許の対象となるので、それはとして広くとしてサポートされていませんので、任意の上記の。

RAW画像^Seeも実際の画像ではありません。実際には、生の（したがって名前の）センサー読み出しデータのコンテナーです。データの解釈方法を知っているソフトウェアでのみ、画像を取得できます。また、Lightroom / Capture One / DarkTable / ...などのRAWコンバーターが、Canonの* .CR2などの既に指定されたコンテナーを使用する新しいカメラをサポートするために更新が必要な理由でもあります。また、同じRAWからエクスポートした32ビットTIFFよりも14ビットRAWが多くの編集オプションを提供する理由でもあります。

Intermisision：Lossless vs. Lossy

あなたが本当に何を求めているのかまだわかりません。ですから、ロスレスとロスレスの簡単な説明を加えても害はないと思いました。

ロスレス圧縮は、ランレングスエンコーディング（RLE） / ハフマンコーディング / ...を実行してデータを圧縮することで機能します。データ自体は変更されませんが、小さなパッケージに保存されます。たとえば、RLEを考えてみましょう：Rチャンネルビットストリーム（ピクセル0,0からピクセル0,11）があります255,255,255,255,255,215,215,235,100,000,000,000-RLEはこれをエンコードします52552215123511003000-これははるかに小さく、4桁のグループに保存され、最初の桁がカウンターで、最後の3桁が値である場合、完全なを再構築でき255,255,255,255,255,215,215,235,100,000,000,000ます。

一方、非可逆圧縮は、非可逆圧縮よりもさらに圧縮しようとします。これを行うために、損失の多いコーデックは通常、知覚が得られないものを削除しようとします。例えば、テイクYUV（YCbCr本当に）モデルJPEG（およびほぼすべてのビデオコーデック）を使用していますY = Luminance、Cb = Chrominance Blue、Cr = Chrominance Red。人間は4:2:0（すべてのピクセルに輝度値がありますが、色は2x2のブロックに交互に保存されます）と4:4:4（ピクセルごとに輝度と両方のカラーチャネルがある）エンコードされた画像の違いを確認できません。これは、目の生理学によるものです。色の違いも輝度の違いも見られません。

これはほとんどの場合うまく機能しますが、MP3ファイルと比較してください。ほとんどの人は192kbpsと320kbpsの違いを見つけることはできませんが、64kbpsを下回るとすぐに見苦しくなります。また、不要なアーティファクトが発生する可能性があるため、再エンコードにより品質がさらに低下します（たとえば、JPEGでは、高品質エンコーディングの小さなブロックは、さらなるエンコーディングの画像の詳細と見なされます）。

ボトムライン

画像形式やその機能を気にしないのであれば、どちらでも構いません。十分に高い品質設定では、それらの違いさえ見ない可能性があります。

ただし、特定の機能が必要な場合は、その機能を備えたコーデックが存在する可能性があります（ほぼ確実にそうなります）。

コアの場合、写真はピクセル値[0、255] X RBGの3チャネルのみです

それは深刻に壊れた仮定であり、あなたの質問の残りの部分は、それから脱却しない限り答えられないだけです。

つまり、RAWとTIFFの違いは何ですか？これらはすべて、0〜255の値に制限されているわけではありませんか？

「生」という用語は、「カメラの生」画像、またはヘッダーのない生の画像データを含むファイルという2つの異なるものを指す場合があります。

「カメラの未加工」画像は、センサーから出力される未加工のデータを保存します。最新のカメラセンサーのほとんどは8ビット以上のADCを備えていますが、各場所で1つの色成分の強度データのみを収集します。レンズによってジオメトリが歪む可能性があり、ADCからの強度値が強度の人間の知覚を反映する良い仕事をしない場合があり、色成分がモニターなどで使用されるものに正確にマッピングされない場合があります。

生のセンサーデータを高品質のRGB画像に変換するには、補間を含む複雑なマッピングプロセスが必要であり、適切な方法はありません。さらに、色成分を補間する必要があるため、RGB画像は生データよりも大きくなる場合があります。

変換はカメラで行うことができます（多くの場合、カメラで行われます）が、多くの写真家は、生データを保存して、事後処理を微調整できるようにしています。

Tiffは複雑なファイル形式で、さまざまなメタデータを含むさまざまな形式で画像を保存できます。ただし実際には、通常、非圧縮またはロスレス圧縮されたRGBまたはCMYK画像の保存に使用されます。

ヘッダーを持たない生の画像データを含むファイルは、それらを読み取る前にその形式と寸法を知っている必要があるため、めったに使用されません。ただし、一部の画像処理ツールはそれらをサポートしています。

さらに、数値の観点から、16ビット画像のようなものが32ビット画像と異なるのはなぜですか？

残念ながら、「nビット」は2つの異なることを意味します。これは、すべての色成分がビット番号に詰め込まれていることを意味します（たとえば、赤は5ビット、青は5ビット、緑は16ビットまたは8ビットの赤、緑は8ビット、緑は8ビット、青は8ビット、8ビットは32ビットのアルファ）またはatは、各色成分が各ピクセル位置にnビットの情報を持つことを意味します。

コンピューターのファイルシステム上のイメージは、0〜255の整数の3チャネル配列にすぎないというこの観点を続ける

繰り返しますが、この見方はまったく間違っています。

ファイルは一連のバイトですが、それらのバイトは「0〜255の整数の3チャネル配列」ではありません

そのような画像を保存できます。一部のツールは、このようなファイルの読み取りと書き込みもサポートしていますが、問題は、ファイルを読み取る前にそのファイルについて知っておく必要があることです。サイズが3000バイトのファイルがあったとします。1000個の24ビットRGBピクセルがありますか？3000 8ビットグレースケールピクセル？パレットから3000 8ビットピクセル？色成分はどのような順序になっていますか？画像はどのような形ですか？色成分はRGBまたはBGRの順序ですか？これらの質問に対する答えがわからなければ、そのようなファイルを有意義に読むことはできません。

したがって、実用的な画像フォーマットは通常、ファイルの種類、画像のサイズ、実際の画像データの保存方法を識別する1つ以上のヘッダーで始まります。オプションのメタデータも含まれる場合があります。

画像をJPGなどの損失の多い形式に圧縮するポイントは何ですか？圧縮アルゴリズムが、いくつかのピクセル値を254から255またはその他の値に変更するとします。そう？それはどのようにファイルサイズの節約を提供し、視覚的な品質に影響を与えますか？

圧縮アルゴリズムは単に「値を変更する」だけでなく、まったく異なる方法で情報をエンコードします。たとえば、JPEGはおおよそ次のように説明できます。

• RGBからYUVにデータを変換します
• （オプション）クロマチャンネルの解像度を1次元または両方の次元で2倍に削減
• 各チャネルのデータを8x8ブロックに分割します。
• 離散コサイン変換を使用してブロックを周波数領域に変換します
• 結果を定量化し、高周波数情報の精度を下げながら低周波数情報を保存します。
• 可変長エンコードスキーム（ハフマンコーディングまたは算術コーディング）を使用して、結果の数値をバイトシーケンスとしてエンコードします。
• これらのバイトを適切なヘッダーとともにファイルに保存します。

一方、可逆圧縮形式は、多くの場合、汎用のデータ圧縮アルゴリズムに基づいて構築されますが、PNGのように画像固有の前処理を追加することもあります。

• データをサポートされている形式のいずれかに変換します（たとえば、赤、緑、青の順にそれぞれ1ビットずつ）
• 画像の各行に対して「フィルタリング」プロセスを実行します。サーバーフィルタリングオプション（フィルタリングなしを含む）がありますが、一般的な目的は、ピクセルが隣接ピクセルに類似している可能性が高い画像固有の情報を取得してエンコードすることです「デフレート」が処理できる方法で。
• 「deflate」汎用圧縮アルゴリズムを使用して、フィルタリングされたデータを圧縮します。
• これらのバイトを適切なヘッダーとともにファイルに保存します。

この仮定が間違っているのにはいくつかの理由があり、それらはすべて1つになります。

実際に使用している尺度は何ですか？

そして、それはもう少し細分化することができます：

255とは何ですか？

「色」は物理的な宇宙の特性ではありません。それは心に生じる感覚です。そして、これには「青」、「緑」、「赤」などが含まれます。「青なし」を意味する0から「すべて青！」を意味する255までのスケール。実際には、255 が青のプラトニックな理想を表すことはできません。なぜなら、現実の世界にはそのような完璧なものはないからです。だから、それはどういう意味ですか：

• あなたの目の前のデバイスで作ることができる最も青い種類のもの？
• ほとんどの画面とプリンタ/インク/紙の組み合わせで表現できない場合でも、人間の視覚システムの観点から見た純粋な青に理想的に近いですか？
• さまざまなデバイスで合理的に表現される可能性が高いかなり良い青ですか？
• 人間の視覚の範囲外の青ですが、RGBトリプルが範囲内のほとんどの色をカバーできるのはどれですか？

サウンドは不自然ですか？いや！これらは実際の実例です。各選択肢のこれらの表現をご覧ください。湾曲した領域は、人間の視覚の色空間の2Dスライスであり、三角形は、赤、緑、または青の特定の選択肢が与えられて表現できる領域を示しています。

まず、ここに私のラップトップ画面のプロファイルを示します。これは、現在のミッドレンジデバイスのかなり代表的なものです。

さて、ここにAdobe RGBスペースがあります。これが私の画面に表示できるものよりもはるかに大きいことに注意してください！

したがって、ここにsRGBがあります。これは、何も指定されていない場合に通常想定される事実上の標準およびデフォルトのスペースです。ほとんどの状況で「十分」であることを意味します。

最後に、人間の視覚のほとんどすべてに適合するように三角形を大きくするために、原色として想像上の色を使用するProPhoto RGB 。

次に、光自体の色と色順応、つまり環境に対する知覚を調整する人間の視覚システムの能力を投入します。実際、能力だけでなく、あなたが望むかどうかにかかわらず起こること。「純粋な青」とは、この白熱灯の下でおそらく青く見えることを意味しますか？日光の代わりに写真を撮る場合、価値はどうあるべきでしょうか？

したがって、「255」はさまざまな意味を持ちます。

0とは何ですか？

これは非常に簡単です-0になるにはどのくらい黒が必要ですか？それはベンタブラック黒？シーン内の実際のシェードのすべてがそれほど極端でない場合、シーン内にないダイナミックレンジの潜在的な値の束を「無駄」にしたいですか？アクセスできるデバイスやプリンターに代表されることさえありませんか？

あなたの曲線は？

それでは、エンドポイントを取得したら、どのようにしてエンドポイントを取得しますか？人間の明るさの知覚は明らかに非線形です。0から255のスケールで、100は50の2倍の明るさである必要がありますか？たとえば、3と4の知覚的な違いは、203と204の違いと同じでしょうか？

ログストレージシステムを使用することにした場合、その曲線を人間の視覚に合わせて最適化する必要がありますか？

多くの異なるニーズのために、多くの可能性があります。

圧縮について

あなたが尋ねる。

圧縮アルゴリズムが、いくつかのピクセル値を254から255またはその他の値に変更するとします。そう？それはどのようにファイルサイズの節約を提供し、視覚的な品質に影響を与えますか？

最新の圧縮アルゴリズムはこれよりも複雑ですが、これは良い例です。FF255 FEを表し、254 を表すために16進数を使用し、圧縮の形式としてランレングスエンコーディングを使用していることを想像します。また、簡単にするために、色ではなく白黒を想定してみましょう。これで、次のようなデータ行がある場合：

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

それを非常にシンプルに圧縮できます

16×FF 

...これはかなり明らかな節約です。基本的に16バイトを2つ（カウント用に1つ、データ用に2つ）に格納できます。しかし、私たちが持っているとしましょう：

FF FF FE FF FE FF FF FF FF FF FE FE FE FF FE FE

さて、ランレングスエンコーディングは次を提供します：

2×FF 1×FE 1×FF 1×FE 5×FF 3×FE 1×FF 2×FE

...これはまったく節約ではなく、実際にはファイルサイズが大きくなる可能性があります。しかし、すべてのFE値をに丸めるFFと、最初のケースに戻り、サイズが大幅に縮小され、ファイル品質への影響は小さくてもおそらく気づきにくいものになります。

もちろん、それは些細な、不自然な例だが、すべての非可逆圧縮アルゴリズムは、この基本的な形質を共有する：データの損失は、それが簡単で、よりコンパクトなストレージ・フォーマットを使用することができ、うまくいけば、あまりないの知覚の変化を。

ビット深度

さらに、数値の観点から、16ビット画像のようなものが32ビット画像と異なるのはなぜですか？繰り返しますが、イメージは0〜255の整数値を持つ単なる配列です。

そのため、0〜255の整数値の配列は8ビット配列です。（2⁸=256。）3チャネルの場合、これは24ビット画像です。一部の形式には、32ビットの透明度（「アルファ」）チャネルもあります。また、チャネルごとに高い値を使用することもできます。これは通常、「16ビット深度」と言うときの意味です。つまり、配列は0〜255ではなく、0〜65535（2¹⁶= 65536）になります。通常、このようなスキームでは、これは基本的に単なる乗数であり、最高値は各スケールで同じものを表しますが、ビット深度が高いほどニュアンスが大きくなります。（詳細については、この回答を参照してください。）値に整数の代わりに64ビット浮動小数点（！）を使用する特殊なファイル形式、またはユースケースに応じて他のデータ型もありますが、基本的な概念は同じです。

いいえ、画像は0〜255の範囲のRGB値だけではありません。ストレージ形式を無視しても、色を説明する方法はたくさんあります。ここではいくつかの例を示します。

• 赤、緑、青のコンポーネント（RGB）
• シアン、マゼンタ、イエロー、ブラックのコンポーネント（CMYK）
• 色相、彩度、明度/値（HSL / HSV）
• カメラのセンサーのグループに当たる光の量
• センサーに当たるときの光の量とその方向（ライトフィールドカメラ）

最初の2つは、モニターでの表示と印刷にそれぞれ最も一般的に使用されます。

さらに、画像はピクセルだけでなく、メタデータでもあります。ピクセル数の幅、印刷する場合の物理的な幅、サムネイル画像、または画像が撮影されたときのカメラの地理的位置などです。

あなたの前提は間違っていません：有限値のN次元配列を使用して任意の画像を表現できます。個人的には、マトリックスの代わりに離散ジオメトリを使用することを一般化しますが、本質は同じです。しかし、それはファイルではなくコンテンツです。

ただし、ファイル形式は異なります。基本的に、同じ画像を表すには、bmp、png、jpgなど、さまざまな方法があります。もちろん、それらをデコードすると、同じ画像の2つのロスレスエンコードバージョンが同じ行列になります。
zipで圧縮した.txtファイルと考えてください。ロスレスエンコーディングでは元のテキストとは異なるテキストが返されるという奇妙な点が追加されていますが、実際には、テキストのバカげたバージョンのようです。

テキストの類推にとどまり、.txt、.docx、.pdfなどとして保存された同じテキストがあるとします。コンテンツが同じ場合、すべてのファイルが正確に同じではないのはなぜですか？（OK、txtには書式がありませんが、他の書式にはあります）。

ちなみに、NetpbmエンコーディングがJPEGと実際にどのように異なるかを確認してください。

私が知る限り、RAWおよびTIFF形式の場合、答えは（他の人が言ったように）実際に常に同じ色空間を使用するとは限らないということです（たとえば、RAWファイルはより細かい色情報を保存できるようにピクセルあたりのビット数を増やす可能性があります） 。

しかし、あなたの質問の核心に到達するために-時には異なる形式で保存されている画像がありますが、それぞれは最終的には正確に同じ数の配列を表します。

この理由の良い例は、PNGファイルとTIFFファイルの圧縮の違いです。

PNGファイルは、1つの特定の圧縮アルゴリズムを使用します。つまり、画像は各ピクセルの大きな数字のリストとして保存されるだけではありません。簡単な例：「この10x10ピクセルのブロックでは、すべてのピクセルはカラーXYZです」という内容が格納されている場合があります。次に、その情報を100回以上保存する代わりに、1回保存し、それに加えて情報が適用される領域に関する情報を少し保存します。

問題は、元の数字の配列（色を表す）を取得することです。そのため、それを表示したり編集したりできますが、その圧縮情報を解釈する方法を知っているソフトウェアが必要です。

PNGファイルは常に同じ圧縮アルゴリズムを使用するため、ソフトウェアはすべての有効なPNGファイルを簡単にサポートできます。一方、一部の画像はPNGの圧縮アルゴリズムに適さない構造を持っているため、PNGファイルの一部が非常に大きくなる可能性があります。

一方、TIFFファイルは、さまざまな圧縮アルゴリズムをサポートしています。実際、画像のさまざまな部分を別々に圧縮して保存することもできます。また、「拡張子」をサポートしているため、独自の方法で画像を圧縮できます。したがって、画像の上半分はPNGと同様の方法で圧縮されますが、下半分はあまり圧縮されないため、下半分は別の方法で圧縮されます。

そのため、TIFFファイルはより柔軟です-より少ないバイトで正確に同じ数の配列を格納できる場合があります。しかし、画像をデコードするために必要なソフトウェアはより複雑になり、投げたすべてのTIFFファイルで一貫して動作しない場合があります。まだオリジナルで動作します。

だからあなたは尋ねる

しかし、私は基本的な3チャンネルRBCイメージ以外については何も尋ねていません。私が知っているのは、誰かがこれらのいずれかを私に渡せば、私は今、数字の配列を持っているということです。ある数値の配列が、他の0〜255の数値の配列と異なる可能性がある理由を知る理由はありません。

それをあなたに渡すために、誰かが画像がどのように保存され、それを数字の配列に変換する方法を知らなければなりませんでした。（またはおそらく、いくつかのソフトウェアがあなたに知らないあなたのためにその翻訳をしています）。

画像をPNGとして保存し、TIFFまたはGIFとして保存し、16進ビューアでそれを見て、それぞれが同じ数字の配列を異なって表す方法を確認できます。または、PNGファイルとTIFFファイルが内部でどのように表現されているかの詳細を読んで、同じ数字の配列を異なる方法で読み取るためにソフトウェアに組み込む必要があるものを考えてください。

ビットマップ

ビットマップ（BMP）は、本質的に説明するもので、ピクセルの色を表す数字の配列です。例えば

1、1、1、0、1、1、1、1、1、1、1、1

ロスレス圧縮

次に、圧縮スキームを定義しましょう。圧縮スキームでは、数値のペアの配列があります。例えば

3、1、1、0、7、1

さて、最初に指摘したいのは、この圧縮スキームが最初の配列と同じピクセルを表すということです。最初の配列には3つの1があり、その後に1つの0が続き、7つの1が続きます。そして、それが私たちがここで表現していることです。この形式は、2つの数字で複数のピクセルを表すため、短くなります。ビットマップ形式では、ピクセルごとに1つの数値を使用する必要があります。

明らかに、これはイメージの単純化されたビュー（たとえば、1行だけ）と圧縮スキームです。ただし、これにより、圧縮スキームが画像の形式をどのように変更するかを確認できます。これが、GIFとBMPの関係です。GIFは、この単純なスキームではなく、Lempel-Ziv-Welchと呼ばれる圧縮スキームを使用します。

ここで説明したのは、ロスレス圧縮方式です。ロスレス圧縮方式の問題は、入力によっては、エンコードされた形式が元の形式よりも長くなる可能性があることです。例えば

1、0、1、0、1

エンコーディングは

1、1、1、0、1、1、1、0、1、1

まあ、それは役に立たなかった。入力を2倍にしました。

別のロスレス圧縮

次に、別の圧縮スキームを考えてみましょう。この1つでは、イメージをオーバーレイされた円として表します。各円について、中心、半径、色を定義します。

最初のビットマップは次のようになります

5、5、1、3、0、0

これは、最初の圧縮方法と同じ長さです。

そして、私たちの2番目は

2、2、1、2、1、0、2、0、1

これは中央の要素を中心とする3つの円です（コンピューターのカウントでは0からカウントを開始するため、コンピューターのカウントでは2です）。1つの円には半径2と色1があります。次に、色0と半径1の円を追加します。最後に、色1と半径0の円があります。

1、1、1、1、1
1、0、0、0、1
1、0、1、0、1

または

2、2、1、1、0、0、3、0、0

これは同じ初期円ですが、2つの点の円で覆われています。ステップでは、それは

1、1、1、1、1
1、0、1、1、1
1、0、1、0、1

これらはどちらも、最初にエンコードされたバージョンよりも短いですが、元のバージョンよりも長くなっています。

なぜ範囲ではなく円について話しているのか疑問に思うかもしれません。主な理由は、円が実際の2次元画像が使用するものに近いためです。

非可逆圧縮

また、非可逆圧縮方式の概念もあります。これらのロスレス圧縮スキームは、元のビットマップ配列に戻すことができます。非可逆圧縮方式は可逆的ではない場合があります。

circlesメソッドの損失の多いバージョンを考えてみましょう。これでは、単純なルールを使用します。半径が1未満の円は保存しません。したがって、最後の2つのエンコードでは、代わりに

2、2、1、2、1、0

そして

2、2、1

再びピクセルに変換されるのは

1、0、0、0、1

そして

1、1、1、1、1

最初のバージョンは、元のバージョンより1つだけ長い要素です。2番目のバージョンは短くなっています。両方とも有効なので、アルゴリズムは両方を自由に開発し、短い方を選択します。

私たちは、より制限されたルールを持つ画像を低品質であると説明します。

円形の形状のオーバーレイされたコレクションとしてのこの画像の表現は、Joint Photographic Experts GroupまたはJPEG形式の仕組みに似ています。その形状は円ではなく楕円ですが、考え方は似ています。単純な方法ではなく、離散コサイン変換を使用して画像をエンコードします。

GIFとは異なり、JPEGは実際には画像を表現する異なる方法です。GIFはまだピクセルです。それらは異なる方法で保管されているだけです。JPEGは形状です。JPEGを表示するには、図形がピクセルに変換されるのは、それが画面の仕組みだからです。理論的には、この方法では機能しないスクリーンを開発できました。ピクセルの代わりに、JPEG形式によりよく一致する形状を作成できます。もちろん、その画面はビットマップを表示できません。BMPまたはGIFを表示するには、JPEGに変換する必要があります。

標準のGIF、たとえば300x300ピクセルを変換してJPEGに変換し、品質を下げると、使用する基本図形が表示されるはずです。多くのJPEGは、はるかに高い解像度の画像から開始することにより、これらのアーティファクトを回避します。

JPEGはピクセルではなく形状であるため、うまくスケーリングします。したがって、8000x8000の画像から始めてJPEGに変換し、300x300の画像として表示すると、失われた細部の多くはとにかく失われます。8000x8000ビットマップを最初に300x300ビットマップに変換してからJPEGに変換すると、多くの場合、結果の品質が低下します。

MPEG

静止画像について話してきました。動画専門家グループやMPEG形式はJPEGと圧縮の同じ種類を使用していますが、それはまた、他の何かを行います。ビデオを実行する簡単な方法は静止画像のシーケンスを送信することですが、MPEGは実際にフレームを送信し、その後、いくつかのフレームが変更をリストし、終了フレームで終了します。ほとんどのフレームは前のフレームに似ているため、変更のリストは多くの場合、2番目の画像よりも小さくなります。

通常、シーケンスはそれほど長くはありません（5フレームなど）。ただし、そうしないとストリームを小さくすることができます。

簡素化

私はたくさん無視しました。私の画像は2色（1ビット）のみで、8ビット画像の256色ではなく、32ビット画像の4,294,967,296色でもありません。8ビットの画像であっても、画像に異なるパレットを選択できることが多いことに注意してください。そのため、同じシーケンスを持つ2つの8ビットビットマップは、外観が異なる（同じ形状でも色が異なる）イメージを表す場合があります。

私の画像は二次元ではなく一列です。ほとんどの画像には特定の行サイズが保存され、配列が2次元になります。

私は実際のエンコーディングをまったく表現しようとしませんでした。それらは、私が使用した単純なものよりもはるかに複雑です。この投稿でエンコーディングを説明できるようにしたかったため、これを行いました。Lempel-Zivをもっと複雑なLempel-Ziv-Welchの改良よりも1つの答えで説明できるとは思いません。そして、私はフーリエ変換を十分に理解していないので、それらをいつでも説明できます。

これは、実際の画像処理の非常に単純化されたバージョンです。しかし、私は教訓的な目的のために、それは本質的なポイントにまだヒットしながら、より複雑な現実よりも理解しやすいと感じています。

すべてのピクセルがそれぞれ0〜255の範囲の3つの数字（赤、緑、青）だけであったことは事実だとしましょう。他の回答者は、その仮定に（正しく）挑戦することから始めましたが、簡単にするために、それが真実だと言ってみましょう。

私は言語学の教科書の漫画を思い出します（残念ながらオンラインで見つけることができません）：2人の古代エジプトの石彫り師は、非常に多くの行進図を彫った巨大な壁の底で疲れ果てて座っています。「ファラオには100,000人の兵士がいましたか？」と書くのは簡単です。その考えに留意してください。

ここで、画像の最初の行に1800個の黒ピクセルが含まれているとします。それはどのように表されますか？

0 0 0    0 0 0     0 0 0   ....

それでは、どれくらいのストレージスペースが必要でしょうか？各値はバイトです。1ピクセルあたり3バイト、1800ピクセルの行なので、すでに5400バイトの行です。そのため、サイズが1800 x 1200の画像は、1200倍のサイズを必要とし、これは6メガバイトを超えます。それでは、Google画像検索に行って、1800 x 1200の画像を2つダウンロードしましょう。1つの.png画像と1つの.jpg画像です。ファイルサイズを見てください：6 MBですか？まさか、通常はそれよりずっと小さいです。そして、それは望ましいことです。もちろん、スペースがすべて節約され、ダウンロード時間が短縮されます。

どうしたの？重要なのは、保存する数が多くても、表現する方法が異なることです。ファイル内のこれらの番号。私の答えには、2段落前の、より効率的な表現の例があります。「1800ブラックピクセル」という言葉を書きました。これは17文字であるため、17バイトを超える必要はありませんが、5400バイトが必要だと思ったのとまったく同じ情報を完全に記述しています。そして、英語を使用してこの情報をエンコードせずに、より特殊な目的の言語を使用した場合、17バイトよりも確かに良い（エンコード/デコードの実装に多大な労力を節約できます）。そのため、既に、複数の画像圧縮形式を用意しました。英語の単語を使用する形式と、それよりも効率的な形式です。これがどこに行くのか見てください？

OK、あなたは言う、それは隣接するピクセルの束全体が偶然同じ色を持っている場合に機能します。しかし、そうでない場合はどうなりますか？確かに、特定の画像の内容に依存します。冗長性が高いほど、情報を圧縮しやすくなります。冗長性とは、他の部分を既に知っている場合、画像の部分をかなりうまく予測できることを意味します。圧縮とは、情報を再構築するために最低限必要なものだけを書き留めることを意味します。すべての可能な画像に冗長性があるわけではありませんが、私の純粋な黒の例よりも複雑であるにもかかわらず、人間の目と脳にとって意味のある実際の画像には、かなり多くの冗長性がある傾向があります。また、圧縮にはさまざまな方法があります。一部の圧縮方法はロスレスです、つまり、私の黒い列の例のように、情報を元の情報と数学的に同一に再構成できることを意味します。ほとんどの.pngファイルはロスレス圧縮方式を使用しています。一部の方法は損失があります。再構成は完全ではありませんが、エラーは人間の目と脳がほとんど気付かないような方法で隠されています。ほとんどの.jpgファイルは非可逆です。

冗長性の複雑なパターンをどのように認識し、それらの効率的な圧縮記述をどのように記述するかの詳細は非常に数学的であり、自明ではありません。しかし、うまくいけば、原則が得られます。

上記のコメントのカップルは、あなたの誤解がどこで生じたのかについて合理的な推測をしました。あなたの質問では、圧縮は情報のレイアウトを変更せずに、ピクセル値を少しだけ変更するだけだと考えているようです（そして、確かに、損失のある圧縮方法は場所でそれを行いますが、望ましくない副作用としてのみ）。ファイルを開いて画像コンテンツを見るとき（たとえば、Matlabの数字の配列として、またはPhotoshopの画面上の画像として）、圧縮されたファイルコンテンツではなく、再構築を見る、元のレイアウトと同じレイアウトを使用します（レイアウトを正しく再作成しなかった場合、再構築はあまり行われません）。ファイルを開く手順により、ファイルの情報がメモリ内の完全な非圧縮表現に圧縮解除されました。2つの非圧縮再構成を比較する場合、実際には、元の2つの異なる画像形式を区別するものはありません（再構成エラーがある場合を除く）。

はい、しかしそれらの1と0に到達する方法は非常に異なります。

例を示しますが、それは偽物であり、正確である以上のことを説明するためのものです。すべてのデジタル画像は、あるレベルでバイナリで表されることに注意してください。

問題を複雑にするために、さまざまなチャネルがあります。CMYK、RGB、B＆W、ほんの一例を挙げると。私たちはそれに入るつもりはありません。キャプチャ、ストレージ、表示などのさまざまな段階もあります。これについても説明しますが、この例は正確ではないことを実証することになっています。正確な例が必要な場合は、大量の技術文書を検索する必要があります。

したがって、サンプルでは、​​白黒の画像を見ていきます。

00067000
00067000
00567800
04056090
40056009

数字は「黒」の強さを表しています。これは、カメラが画像をキャプチャする方法です。それはまともなカメラなので、画像を保存する方法でもあります。

これで画像がコンピューターに保存されますが、多くのスペースを占有するため、圧縮します。マッシュアップに加えて、ほとんどの人が1つの黒レベルの違いを検出できないことも知っているので、それをいくらか滑らかにします。

302730
302730
204820
*04056090
1420262019

これで、イメージをディスクに保存する方法ができました。スペースが少なくて済み、元の画像の多くを生成できます。

それでは、プリンターで印刷したいとしましょう。プリンターは1レベルの黒のみを印刷するため、コンピューターは保存された圧縮画像をプリンターの読み上げに変換します。

00011000
00011000
00111100
01011010
10011001

これにより、合理的な外観の画像が印刷されますが、例でも品質の極端な欠如がわかります。しかし、ちょっとそれはプリンターのせいです。

最後に、10レベルの黒で適切なプリンターで画像を印刷します。カメラと同じ。したがって、保存および圧縮されたイメージを使用します。

00077000
00077000
00888800
04056090
40066009

ご覧のとおり、画像は「優れています」が、元の画像から少し変更されています。

いつでも、それはすべてチャンネルの強さであるという正しいことです。そして、とにかく解凍しなければならない圧縮された画像以外は、それはかなり忠実です。

ただし、圧縮形式では多くの「情報」が失われます。その情報は重要ですか？まあ、それはアーティストと聴衆次第です。スペースの節約、処理時間、最終/保存画像の品質、およびニーズの間には、いくつかのトレードオフがあります。必要なのはそれだけなので、ほとんどのドキュメントを1色の黒でスキャンします。ただし、私の結婚式の写真は巨大なRAW形式です。これは、いつ素晴らしい再版が必要になるかわからないからです。つまり、それらをデジタル写真フレームに（写真）を転送するとき、スペースを節約するためにJPEGに変換します。異なるチャネル、異なるフィルター、異なる圧縮方法はすべて一連のトレードオフです。これは、プリンタの三角形のデジタルバージョンのようなものです。

ほとんどが動画像であるにも関わらず、画像センシングとエンコード/圧縮を扱ってきたので、少し補足的な情報を紹介します。

基本的な形では、特定の画面に表示される画像（任意の画像）は、実際には単なる数字の配列です。これらの番号はすべて0-255または0-65535または0-whatever-32-bits-is-I-forgot-go-google-itです。

しかし、情報を保存および転送する方法は非常に多く、それらの多くは、時間の霧によって失われた技術の産物にすぎません。

また、私がここで言及している他のペダルのどれも見ていない詳細の1つは、デジタルカメラからの真のRAWイメージセンサーデータは、バイエルパターンのRGrGbBまたは少なくとも少し処理する必要があるものである可能性があることですMk.1の人間の眼球に対する感覚。DSLRで保存されたRAW形式であっても、RGBまたはYUVピクセルの素敵なグリッドに変換するまでは役に立たないため、8、16、32、または深みのある数十ビットのビットに変換することはできません。

私が取り組んできたものは、何らかの理由で内部的にYUVを使用します。人間は色よりもはるかに高い感度で明るさを知覚するため、コーデックによってより簡単に処理されると思います。

就寝前の軽い読書については、「フレーム画像形式」セクションを参照してください：http : //focus.ti.com/lit/ug/sprufg8b/sprufg8b.pdf

とにかく... TIFF / RAW / IFF / PNGなどの非圧縮画像ファイルの違いに関する元の質問に戻ります。

一般に、これらが存在する理由は、多くの月前に、各コンピューター/ OS /プリンターのメーカーが、画像を保存/送信するための独自のわずかに異なる要件のセットを思いついたためです。

したがって、このスレッドで他の人が説明したように、RAWは、カメラのメーカーが将来持っているまたは将来持っている可能性のある機能に基づいて、カメラのメーカーが重要だと考えたデータの負荷を使用して、異なるデジタルカメラによって保存されたいくつかの異なるものの総称です。そのため、メインの画像データビットは非常に似ているかもしれませんが、画像とすべてのカメラ設定などを記述する「パッケージング」は、1つのファイルが別のメーカーに理解されないようにします。

伝統的にこれは彼らがあなた（または、おそらくプロの写真家）が独自の（そして時には高価な）ソフトウェアを使用してこれらの高品質の画像を処理できるようにするためです。そうでなければ、他の人の高価なソフトウェアを使い始めるかもしれません また、Adobe Photoshopはフォーマットをサポートしたいので、その情報にAdobe $$$を請求して、よりプロの写真家がPSを購入し、PSが現在サポートしているのでそのカメラを購入できるようにするかもしれません。居心地の良い！

RAWは、その特定のデータバンドルを人間が見ることができる画像に戻す方法に関する情報も保存します。データに必要なすべての調整を加えるだけで、画像が「正しく」見えるようになります。

TIFFは、グラフィックデータをプリンターに送信するために使用された初期のイメージ形式でした（グラフィック対応プリンターが手頃な価格になり始めたとき）。プリンタ内の小さな安価なマイクロプロセッサで処理するのは非常に基本的でとても簡単でした。

IFF（そうですね）は、Amigaコンピューターで使用されている類似の形式でした。Amigaコンピューターまたは人気のあるペイントパッケージによって発明されたと思います。ただし、ここでは例として使用していますが、これは他のビットマップ画像データを格納しますが、非圧縮またはRLEデータ、1ビットモノラルから8ビット256色までの可変ビット深度をサポートしているためです（ただし、各色から選択する3x8ビットRGBパレット）と、ハーフトーンおよびホールドアンドモディファイと呼ばれる特別なモードにより、他の時代のマシンが管理できるよりも多くの色を使用できます。ああ、アニメーションも（GIFのように）サポートしたので、IFFファイルはフレーム間の遅延が可変で、任意の数のフレームを保存でき、各フレームには独自のパレットがあります。したがって、IFFには、TIFFファイルなどと比較して、これをすべて処理するための追加データが含まれます。

PNGは別のロスレス画像形式であり、ビットマップデータを保存しますが、画像全体の透明度を変更する8ビットアルファチャネル（Webページで有用）などのファンキー機能をサポートしているため、画像データの「ペイロード」は非常によく似ていますただし、そのラッパーは異なり、ペイロードにはピクセルごとのRGBデータだけでなくRGBAが含まれる場合があります。

つまり、4つの異なる画像ファイル形式について説明します。猫のサンプルフルカラーHD画像を4つのいずれかに保存でき、同じように見えます。画面上のすべてのピクセルはまったく同じ値を持ち、NOはありません。 4 ...の品質の違い。ただし、4つのファイルはサイズ、レイアウトが異なる可能性が高く、ソフトウェアの読み込みと処理が容易または困難になります。

お役に立てば幸いです！

この質問への最初の回答に含まれているはずの情報をここに掲載すると思いました。

画像のピクセルはバイトに保存されません-画像がモノクロ、つまり白黒のみの場合を除きます。

トゥルーカラーイメージがある場合、各ピクセルは16ビット、つまり2バイトで1つの値として表されます。32ビットの画像がある場合、各ピクセルには32ビットまたは4バイトが必要です。これも単一の値です。

おもしろいことに、画像ファイルと音声ファイル、およびコンピューターの他のすべてのデータ型は、1と0のビットに要約されます。それらから意味が抽出されるのは、正しいサイズのチャンクで解釈することだけです。

たとえば、画像とワードドキュメントとmp3ファイルはすべて同じ基本データコンテンツ（大量のバイト）を持ち、それらはいずれも他のタイプの1つとして解釈できます-ワードdocをサウンドとして解釈できますファイルを作成すると何かが聞こえますが、音楽ではありません。サウンドファイルは間違いなくイメージとして解釈でき、何かを表示しますが、まとまりのあるイメージではありません。

要約すると、コンピューターはビットのみを認識します-ビットは1または0です。すべての画像、音声、ドキュメント、映画、ビデオ、録画、ゲーム、電話、テキストメッセージ、およびデジタルとしてラベル付けされたものはすべて同じですコンテンツ-1と0の束。1と0は、それらを読み取るコードがグループ内のこれらのビットを読み取り、それに応じて処理することを知っているため、画像、音声、ドキュメントなどになります。

だからこそ、16ビットと32ビットの画像、16ビットと24ビットのオーディオファイルなどがあります。ピクセルまたはサウンドサンプルに使用するビットが多いほど、表現力が増します。16ビットでは64kの一意の色しか定義できませんが、32ビットでは400万を超える一意の色を定義できます。モノクロ画像は、ピクセルあたり1ビットを使用します-オンまたはオフです。

オーディオファイルでは、サンプルごとに使用するビット数が多いほど、より詳細で微妙な録音が可能になります。

スレッド全体を読んだことはありませんが、ベクトル化された画像形式を忘れている人が多いようです。これらはピクセルの配列ではありません。ピクセルの概念はそのような形式にも存在しないためです。画面やその他のメディアで画像を生成する方法を理解するのはレンダラー次第です。

カラードメイン、圧縮、ビットサイズ、チャネル形式について言及しなくても、ピクセルマップとはまったく異なるファイル形式のセットがあります。さらに、ベクター形式は、特定の種類の画像を表現するのに非常に「優れています」。通常、カメラではなくコンピューターによって生成されます。

この質問は以前に非常に詳細に回答されました。しかし、答えには多くの理論が提示されていますが、通常はより明確な説明が必要なコンピュータープログラミングに関連するいくつかの基本的な主題があると感じています。私はソフトウェアエンジニアであると述べなければなりません。質問を読んだ後、この質問を生成した基本的なプログラミングデータ型の完全な誤解があることに気付きました。

最初の質問は次のとおりです。

さらに、数値の観点から、16ビット画像のようなものが32ビット画像と異なるのはなぜですか？繰り返しますが、イメージは0〜255の整数値を持つ単なる配列です。

前に示したように、そうではありません。 画像は、0〜255の整数値の配列だけではありません。実際には、0〜65535の値の単一または多次元配列、0〜4294967295の配列、またはビットの配列（ビットは0または1の値を保持できます）であることができます。さまざまなエンコード規則に従って整数値に画像ファイルを読み取ります。

これをさらに理解するには、前述のように、基本的なプログラミングデータ型に関する議論が必要だと思います。コンピュータファイルに整数値を格納することに関する問題を誰もが理解できるように、できるだけ簡単に説明しようとします。

コンピュータープログラミングでは、いくつかの基本的なプリミティブデータ型を使用して値をファイルに書き込み、ファイルからコンピューターメモリに読み取り、さまざまな特定のプログラミング言語データ型を使用してそれらの値を操作し、最終的にファイルに保存します。コンピュータプログラミングの整数は単なる整数ではありません。あらゆる種類の整数があり、使用しているプログラミング言語と、それぞれに必要なメモリ量によって異なります。通常、ほとんどのプログラミング言語には、次のデータ型（およびそれらを操作する方法）があります。

• BIT-0または1を保持
• UINT8-8ビット符号なし整数-[0〜255]の間隔で値を保持できます。
• INT8-8ビット符号付き整数-[-126〜127]の間隔で値を保持できます。
• UINT16-16ビット符号なし整数-[0〜65535]間隔の値を保持できます。
• INT16-16ビット符号なし整数-[-32768〜32767]間隔の値を保持できます。
• UINT32-32ビット符号なし整数-[0〜4294967295]間隔の値を保持できます。
• INT32-32ビット符号なし整数-[-2147483648〜2147483647]間隔の値を保持できます。
• または、これらすべてのデータ型をより複雑な形式で組み合わせたもの。たとえば、3つの異なる値を保持するUINT16（16 BIT）、0〜127の値を保持する最初の4 BIT、0または1を保持する次のBITなどです。

さらに、ファイルから整数データ型を読み書きする際にプログラマが対処しなければならないことがあります。エンディアンネス。エンディアンとは、メモリ（ファイル）に保存されるときに、バイト（表からのUINT8）がより大きな数値に配置される順序を指します。エンディアンネスは、2つの競合する互換性のない形式が一般的に使用されているため、コンピューターサイエンスで重要です。ビット）またはリトルエンド（最下位ビット）。簡単に言えば、この0000000011011111のような値を保存するか、この1101111100000000のような値、または選択したエンディアンの順序を格納できます。また、目的に合った順序を自由に選択できます。画像ファイル形式を設計するときに作成する規則は他にありません。

コンピュータのプログラミングでは、整数は値に応じて多少のスペースを使用していることに注意してください。255255255を書き込むためにより多くの紙が必要であるように、より大きな値を書き込むにはより多くのBITが必要です。その後、値を読み取るには、作成時に作成したルールを正確に把握する必要があります。あなただけ読むために私達の方法を理解するためにそれ以外の場合は不可能です0 -255の間の整数値を持つだけで、配列をそれらの番号が格納されており、これらの数字は、あなたが、（UINT8をBITを持っているので、多くの選択肢与え保存されているかどこが単に知らないので、 、UINT16、UINT32、またはこれらすべてのコンピューターデータタイプの組み合わせ）。そして、エンディアンネスを忘れないでください。データがビッグエンディアンまたはリトルエンディアンの順序を使用して書き込まれたことがわからない場合、適切な値を読み取ることができません。

このため、画像は0〜255の整数値を持つ単なる配列ではありません。UINT16（16ビット画像）の配列、UINT32（32ビット画像）の配列、またはUINT8（8ビット画像）の配列です。非常に創造的なコンピュータープログラマーの中には、INT8の配列、つまり-126から127の間の値の配列に対応する符号付きの型を使用することさえできます。

実際、画像ファイルを読み取るとき、最初に遭遇するデータの1つは通常、画像の幅と高さを表すいくつかのBITです。そして、それらは単なる0-255の値ではありません。これらは、プログラマーが選択したいくつかのデータ型でもあります。一部のプログラマーは、小さなボタンの画像を保持するためにゲームで使用される画像形式を設計しているため、16ビットは65535ピクセルの最大画像幅を保存するのに十分だと考えるでしょう。他のプログラマーはここで32ビット値を使用して、4294967295の幅と高さまで画像を保存できます。一部のクレイジーなNASAプログラマーは、18446744073709551615ピクセルまでの銀河の巨大な写真を保存するために64ビットを使用することさえあります。ルールがわからない場合、これらの「値」を呼び出すときに読み取ることができません。画像ファイルのどこから始まり、どこで終わるのかわからないからです。そのため、何も理解していない多くのBITになります。

宇宙が非常に多くの異なる画像形式でいっぱいである理由です。いくつかの整数値をファイルに書き込む標準的な解決策がないためです。作業中のマシンのエンディアネス、元のファイル形式の実装を設計するために使用しているプログラミング言語、および画像形式の目的のような他の多くの要素など、多くの要因に完全に基づいたプログラマーの選択ですその他の回答）。

4 x 2ピクセルの画像を表す単一の値166のみを保持する白黒画像の実用的なシンプルなファイル形式：

画像（1-黒ピクセル、0-白ピクセル）：

1010 
0110

このファイル形式は、単一の8ビット整数値166（10100110）として格納されているピクセルごとに1ビットを使用します。それで全部です。0〜255の値の配列は使用されませんが、8つの異なる0または1の値が値166として保存されます。

各ピクセルに0〜255の値の配列を使用した場合、RGBの3倍にすると、24倍大きい画像になります。このファイル形式は、このような画像を保存するのに必要なディスク容量の24倍、または高性能3Dゲームエンジンでこの画像を使用する場合にこの画像を読み取り、コンピューターのRAMに保存するために必要なコンピューターメモリの24倍少ない画面上に何かを描いてください（飛び回る何千もの塵粒子をテクスチャリングすることは良い候補です:)）