JPEGの半分がグレーになる理由

JPEGはどう組み立てられているか：まずルールブック、次にスキャン

JPEGは、ひとつのファイルを共有する2つの部分でできています。1つ目は短いヘッダーです——デコーダーが何かを描き始める前に必要とする ルールを運ぶ、マーカーの集まりです。フレームマーカー（SOF）は画像の寸法と 色成分の数を記録します。量子化テーブル（DQT）は、ファイルがどれだけ強く 圧縮されたかを示します。ハフマンテーブル（DHT）は、圧縮された値を展開する ためのコードブックです。これらを合わせたものがルールブックです。

2つ目の部分はエントロピー符号化されたスキャンです——実際の ピクセルデータの、ひとつの長く、ぎっしり詰まったストリームで、たいていは ファイルのほぼ全体を占めます。これは厳密な順序で、ブロックごとに、左上の隅 から右下へと読まれます。デコーダーは先へ飛ばすこともできず、途中から始める こともできません。各ブロックがその前のブロックの上に成り立っているからです。

2つのピースからなるJPEG：先頭に小さなルールブック、そのあとにルールが読み方を説明する、ピクセルの長いスキャン。

この分割が、以下のすべての症状を説明します。ルールブックを壊すと、すべての ピクセルが存在していても、デコーダーは始めることすらできません。スキャンを 途中で断ち切ると、デコーダーは描けるところまで描き、データが止まるところで 止まります。

3つの失敗のクラス、そしてそれぞれが意味するもの

破損した写真は、見分けのつく3つのクラスに分かれます。あなたの症状をその クラスに当てはめることが、修正に時間を費やす前に見通しを知る最速の方法です。

クラス1：まったく開かない

どのビューアもファイルを拒否するか、画像が壊れていることを示すプレース ホルダーを表示します。これはほぼ必ずヘッダーかマーカーの損傷です——先頭の ルールブックがめちゃくちゃになっていて、その後ろにあるスキャンを読み始める ことが何もできません。直感に反して、これは最も見込みの高い クラスです。画像データは、壊れた玄関の奥にたいてい無傷のまま置かれている からです。

クラス2：上部は正常、下部はグレーか滲み

写真は開き、上部は完璧に見え、それから急にのっぺりしたグレーか、最後の 正常な行が下へ引き伸ばされた滲みへと落ちます。これは切り詰め、あるいは スキャンの途中でのビットエラーです。断ち切りより上の部分だけが、なお存在 します。これは正真正銘の部分結果です——本物の上部は戻り、 その下のグレーは失われています。

クラス3：開くが、色がおかしい

画像全体は表示されますが、ポスタリゼーションがかかっていたり、色かぶりが あったり、色がずれていたりします。ここではスキャンは無傷で、それを操る テーブルのほうが誤っています——壊れたDQTやDHTが、間違ったルールで本物の ピクセルをデコードするのです。画像データが生き残っているため、テーブルを 修正したり置き換えたりすると、色がきれいに戻ることがよくあります。上記の 3つのクラスは、写真修復ツールがファイルを ローカルで読み取るときに仕分ける、まさにその区分です。

なぜ下部がグレーになり、そしてグレーのままなのか

JPEGは上から下へ、ブロックごとにデコードされ、各ブロックの明るさはその前の ブロックとの差分として保存されます。この連鎖する依存関係こそが、デコーダー が順番に進まなければならず、壊れたファイルを救うためにその末尾へ飛ぶことが できない理由です。スキャンが途中で終わると——切り詰められたダウンロード、 あるいは書き込みの途中で抜かれたカード——デコーダーには描くべきブロックが もう単純にありません。ほとんどのビューアは残りをニュートラルなグレーで 埋めます。中には最後に読んだ値を繰り返すものもあり、それは縦方向の滲みの ように見えます。

切り詰めを図にすると：ルールブックとスキャンの上部は生き残り、断ち切りより下の行はそもそもファイルに存在しなかった。

グレーの領域は、隠されているのでも、暗号化されているのでも、ロック解除を 待っているのでもありません。それはファイルに存在しない画像データなので、 どんなツールでも取り戻せません——それを復元するとはピクセルを捏造することで あり、ピクセルを捏造するのは修復ではありません。スキャンの途中で1ビットが 反転すると、同じ話の色ずれ版が生じます。それは圧縮されたストリームの同期を 狂わせ、その地点より後のすべてが、リスタートマーカー（RST）——カメラがそれ を書き込んでいればの話ですが——がデコーダーの回復を許すまで、ノイズとして デコードされます。多くのカメラはそれを書き込まず、だからこそ1つの不良バイト がフレームの下3分の2を台無しにしうるのです。

Photoshopのマーカーエラーを読み解く

そのファイルをPhotoshopで開いたことがあるなら、おそらく次のメッセージを 一字一句このまま目にしたはずです：

Could not complete your request because an unknown or invalid JPEG marker type is found.

Photoshopはその場で最も厳格なリーダーです。すべてのマーカーを検証し、ひとつ でも誤っていればファイル全体を拒否します。その厳格さは、実は診断に役立ち ます。まず同じファイルをブラウザかプレビューで開いてください。そこで写真が 表示されるなら、スキャンは無事で、損傷はマーカーに限られており——クラス1か クラス3、得られる最良の見込みです。Windowsのフォトは、同じ根っこの問題をIt looks like we don't support this file format. と言い表し、 Macのプレビューはそのファイルがmay be damagedだと言いがちです。 言い回しは違っても、その下にある問いは同じです——ルールブックが壊れて いるのか、それとも写真が失われたのか？

サルベージの戦術：ドナーヘッダーとEXIFサムネイル

損傷がヘッダーにあり、その後ろのスキャンが生き残っている場合、古典的な 手作業の修正がドナーヘッダーの移植です。同じカメラで同じ 設定で撮った正常な写真を用意し、そのヘッダーをコピーして、壊れたファイルの 親を失ったスキャンに移植します。同じカメラで同じ設定ということは、同じ量子化 テーブルとハフマンテーブル、そして同じフレームの寸法を意味するので、借りて きたルールブックが、いま記述しなければならないストリームに適合し、画像は 再びデコードされます。これは手作業による、バイト単位の骨の折れる作業です。 構造修復ツールは、まさにこの種の修正を自動化します。正直な注意点：これは スキャンが本当に無傷で、寸法が一致するときにのみ機能します。別の解像度や 別のカメラ機種のドナーは揃わず、無理に押し込めばゴミが生じます。

メインのスキャンそのものが失われている場合、残された選択肢はひとつです。 ほとんどのカメラやスマートフォンのJPEGは、小さなサムネイル——幅が数百ピクセルの、それ自体で完結した小さなJPEG——を、ファイル先頭の EXIFメタデータの中に埋め込んでいます。ヘッダーは生き残ったがメイン画像は そうでなかった場合、そのサムネイルこそが、あなたが取り出せる唯一の完全な 写真かもしれません。それは低解像度であり、復元ではなくサルベージですが、 それ以外は最初の数センチから下がグレーの写真にとっては、きれいな切手サイズ の一枚が、何もないよりましなことがあります。壊れた写真の多くは、データ復元 ソフトからこの形で届きます。カービングで取り出されたファイルは、スキャンが 一部しか残っていない一方で、ヘッダーとサムネイルはしばしば保っているのです。