事例集 デジタルカメラ画像のヘッダー修復例 Back


ここでは、デジタルカメラ画像のヘッダー(SOIからSOSまで)とイメージデータの先頭が無くなってしまった、言わば最悪な状態の修復例を説明します。

普通はJPEGヘッダーが壊れたり無くなってしまったりした場合、復元は出来ません。
しかし、条件付きですが何が写っているかまでは修復出来たケースが何件かあり、大事な写真画像なら試す価値は有るかと思います。


修復ファイルの条件=カメラが出力した未加工のファイル

もし、同じ時期に撮影した写真や、同じフォルダーにある写真など、破損したファイルと条件が同じファイルが複数有れば、それらをJpegAnalyzerで見比べて下さい。
以下の点が共通なら、それらのファイルのヘッダーを使って修復出来るかもしれません。

@汎用ハフマンテーブルを使用していること
A画像サイズ、サンプリング比が共通していること

Address Length Message
00000000 ****** SOI :Start Of Image ******
00000002 [3845] APP1 :Exchangeable image file format (Exif)
         00000014-0000009D 0th IFD        Tag = 11
         00000128-0000024D Exif IFD       Tag = 24
         00000382-0000039F Interoperability IFD Tag = 2
         00000324-00000371 1st IFD        Tag = 6
         00001000-0000242A Thumbnail

00003849 [00C5] DQT :Define Quantization Table 【汎用中間画質(IJG50,LEAD050)】
         0000384D QT0-8bit 汎用輝度(IJG50,LEAD050,ACD20-22)
         0000388E QT1-8bit 汎用色差(IJG50,LEAD050,ACD47-48)
         000038CF QT2-8bit 汎用色差(IJG50,LEAD050,ACD47-48)
00003910 [01A2] DHT :Define Huffman Table 【汎用ハフマンテーブル
@
         00003914 HT0-DC 汎用輝度HT-DC
         00003931 HT0-AC 汎用輝度HT-AC
         000039E4 HT1-DC 汎用色差HT-DC
         00003A01 HT1-AC 汎用色差HT-AC
00003AB4 [0011] SOF0 :Start Of Frame 0 - Baseline DCT
         2048[0] x 1536[0] pixel - 24bit color (YCbCr 4:2:2)
A
         ComponentID-01 Y 2x1 QT0
         ComponentID-02 Cb 1x1 QT1
         ComponentID-03 Cr 1x1 QT1
00003AC7 [000C] SOS :Start Of Scan 0-63[00]
         HT Selector[DC/AC] Y[0/0] Cb[1/1] Cr[1/1]
00003AD5 ****** Image Data ******
        Data Size 665,229 bytes
000A6162 ****** EOI :End Of Image ******




デジタルカメラから直接出力されたJPEGファイルは、全メーカー共通の固定ハフマンテーブルを使います。
画像に内蔵のテーブル(鍵)が無くても、固定ハフマンテーブル(合鍵)で復号出来ます。

しかし、加工ソフトで処理をした際にハフマンテーブルの最適化を行うと、画像固有のテーブルになります。
画像固有のハフマンテーブルが破損してしまうと鍵を紛失したのと同じく復元は不可能です。

また、デジタルカメラから出力されたJPEGファイルだと画像のサイズは僅か数パターンしか有りません。
サイズが判らなくても画像が表示されるか全パターン試す事が出来ます。

リサイズやトリミング処理したファイルは、画像サイズが判らなくなると気が遠くなりそうな数を試さなくてはならず、探すのは無理とは言わないまでもかなりの労力を要します。


修復ファイルの状態確認

解析パターンの確認

これから修復方法を説明するのは以下の2種類のどちらかのパターンの場合です。
メニューの
設定>マーカ・セグメント誤検出防止の下半分の設定を全てOFFで解析して下さい。

JPEGファイルの中間部分が残っている場合、このような表示になります。
Address Length Message
00000000     <=== 不明な領域 39,396 bytes

        ◆ JPEGファイルでは無さそうです ◆



JPEGファイルの後半部分が残っている場合、このような表示になります。
Address Length Message
00000000     <=== 不明な領域 42,632 bytes
0000A688 ****** EOI :End Of Image ******

        ◆ イメージデータの断片かもしれません ◆



以下のようにRSTが検出される場合はツールメニューのヘッダー修復機能を使って下さい。
Address Length Message
00000000     <=== 不明な領域 107 bytes
0000006B ****** RST3:Restart Interval Marker
         23,343個のRSTで挟まれた画像データ領域を検出
00428CE1 ****** EOI :End Of Image ******

        ◆ イメージデータの断片かもしれません ◆
        ◆ DRIセグメントが有りません ◆



イメージサイズ確認

該当するリストの場合、イメージデータのサイズ(ファイルサイズ)を確認して下さい。
余り少ないと修復してもまともな絵にはなりません。
人物が写った写真で足元しか残っていない写真なんて修復出来たとしてもいらないですよね?
同じ条件で撮った正常ファイルと比べて何割程度画像データが残っているか見積もって修復するかどうか決めて下さい。


データ確認

次に、データが本当にイメージデータかどうか判断して下さい。

JPEGイメージデータは圧縮されていますのでランダムなコードが並びます。
ダンプ表示をさせ、データの特徴を見ながら、スクロールしたりページ送りをしてファイル全体の状態を見て判断します。

Addr  + 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F Ascii Char
00022000 0D 73 36 8C 2D 60 1F 75 CE E2 73 8F 7A E9 A3 07 .s6.-`.uホ.s.z.」.
00022010 15 A9 2E 4A E4 61 84 D2 65 E4 DA 33 F2 83 D0 D5 .ゥ.J.a.メe.レ3..ミユ
00022020 BB 58 66 58 E4 58 D1 99 01 C8 38 ED 5D 57 B1 84 サXfX.Xム..ネ8.]Wア.
00022030 93 93 D0 8E D6 39 65 49 62 51 95 5E E6 92 36 63 ..ミ.ヨ9eIbQ.^..6c
00022040 70 C8 DF EA C1 E0 52 96 C4 47 46 6A 6A B7 11 3D pネ゚.チ.R.トGFjjキ.=
00022050 84 90 43 18 03 00 0F AE 7A D6 6B DB B5 C5 C4 4C ..C....ョzヨkロオナトL
00022060 B8 DF 1E 09 27 A5 4A 5A 58 D6 73 57 D0 BD 33 7D ク゚..'・JZXヨsWミス3}
00022070 B2 D8 AE 49 DC 49 56 26 B1 91 B7 30 0E 39 0D 83 イリョIワIV&ア.キ0.9..
00022080 56 95 91 9B 93 91 33 C1 31 B7 33 A2 7C 8B C6 4F V.....3チ1キ3「|.ニO
00022090 61 53 C4 AC D6 C6 4E 1A 38 CE 4E DA 89 A6 E2 F9 aSトャヨニN.8ホNレ.ヲ..
000220A0 46 D7 2B 57 3A 6B 37 D3 BC 83 24 6A 90 AC A0 6F Fラ+W:k7モシ.$j.ャo
000220B0 0C DC 75 AC A4 B5 DD 6B 3A 4D 2B B5 BB B7 C9 9E .ワuャ、オンk:M+オサキノ.
000220C0 03 0A E2 A3 7E A7 62 B3 46 3D B4 46 EE EB EC B0 ...」~ァbウF=エF...ー
000220D0 02 EE 09 08 3D AA C5 F5 BD E5 B5 98 79 15 80 0F ....=ェナ.ス.オ.y...
000220E0 B4 13 EA 3D 2B A9 CE 2D D9 98 A5 6B D8 90 DF B6 エ..=+ゥホ-ル.・kリ.゚カ
000220F0 CD 92 B1 64 75 CF 06 AA 59 5B EF DC 91 80 5C F2 ヘ.アduマ.ェY[.ワ..\.
00022100 07 4A D6 31 E5 32 94 EF A3 2C DB A1 88 18 64 C8 .Jヨ1.2..」,ロ。..dネ
00022110 23 27 34 6E 1E 64 71 46 31 C9 24 8A 24 94 A3 66 #'4n.dqF1ノ$.$.」f
00022120 66 B4 2C DC 4B 33 5B 7D 9C FE F0 2F DD 39 E9 EB fエ,ワK3[}.../ン9..
00022130 CD 51 6B 13 02 A4 CC
FF 00 24 7D 45 4C 69 A8 C7 ヘQk..、フ..$}ELiィヌ
00022140 43 4E 6E 6D C9 27 7D F2 B1 56 05 F0 0A ED E9 8A CNnmノ'}.アV......
00022150 7C BB BE D4 EA E8 70 10 13 C7 5A A8 BD 02 7A EC |サセヤ..p..ヌZィス.z.
00022160 24 F6 F1 1B 5F 31 19 94 B0 F9 47 AD 44 1B 60 3C $..._1..ー.GュD.`<
00022170 63 1D 29 EE C8 9A 48 2D 81 79 C2 B8 CA 8E 72 2A c.).ネ.H-.yツクハ.r*
00022180 CC 11 AB 3B F9 83 82 73 C9 A4 C2 29 EC 68 69 57 フ.ォ;...sノ、ツ).hiW
00022190 B6 90 C3 72 16 54 59 89 F9 64 71 F7 7A F0 2A C7 カ.テr.TY..dq.z.*ヌ
000221A0 88 05 BF F6 5A B4 C9 26 E6
FF 00 50 62 00 2E EE ..ソ.Zエノ&...Pb...
000221B0 2B CC 8A 92 AA D7 F5 B9 D6 9A E5 39 9B 5B AB 88 +フ..ェラ.ケヨ..9.[ォ.
000221C0 5B 60 3B 65 03 A8 A9 7C E9 1E 62 1C 92 A5 7A 93 [`;e.ィゥ|..b..・z.
000221D0 DE BD 3B 1C AD E9 60 F3 F6 2E DC E1 4F 06 A0 BE ゙ス;.ュ.`...ワ.O.セ

     <------------------ 16進表示部 ---------------> <--ASCII表示部-->

【16進表示部】
ポイント1:FF00の有無
イメージデータはファイルに記録される際、0x00から0xFEまではそのままですが、0xFFはマーカと間違わないように0xFF00に変換して記録されます。
そのためJPEGイメージデータでは他のバイナリーデータと比べ0xFF00というコードが頻発する特徴があります。

JPEG以外のバイナリーファイルでは
0xFF00(白文字)はダンプ画面1ページに1回有るか無いか程度の割合ですが、JPEGイメージデータの場合、1ページに10件前後記録されます。

ポイント2:マーカの有無
イメージデータの先頭には
SOS(0xFFDA)が、終わりにはEOI(0xFFD9)が記録されています。
リスタートインタバル処理されたイメージだと、
RST(0xFFD0〜0xFFD7)が間を置いて記録されます。
それ以外の
マーカ(赤文字の0xFF??)が記録されている場合、イメージデータではありません。

【ASCII表示部】
2〜3文字の単語なら偶然揃うことも有りますが、それより長い何か意味の有る文字が書かれている場合、イメージデータではありません。

修復作業

ヘッダーのコピー

作業を何度か繰り返す事になるので、JpegAnalyzerの多重起動機能を使い、2つ起動させると効率良く作業出来ます。

同じカメラから出力された正常なJPEGファイルからヘッダー部分をコピーします。
まずは正常なファイルを読み取り、
SOIからSOSまでを選択し、コピーを選びます。

次に破損ファイルを読み取り、先頭の"不明な領域"となっている行を選択し、
領域貼り付けを選びます。
この時点で解析エラーは出なくなると思いますが、エラーが表示されたらエラーの内容を調べて原因を除きます。
但し、"EOIがありません"というエラーはこの時点は支障無く無視してかまいません。


プレビュー画像の状態確認

プレビューボタンを押し、画像の状態を見て判断します。

写真の一部と判る画像

次のステップに進みます
砂嵐のような画像
ハフマンテーブルが合っていない可能性があります
TVのチュニングがずれたような画像

SOF(画像サイズやサンプリング比)が合っていない可能性があります
影や輪郭のような絵が出る

量子化テーブルが合っていない可能性があります

うまくいかない場合、以下の点を変えてやりなおして下さい。
・コピーするヘッダー用のファイルを変えてみる
・イメージデータの先頭を1バイト削除してみる


全体的に明るさや色がおかしくなっている場合

イメージデータのDC成分は先頭に直接の値、継続するデータは前のデータの差分となります。
先頭のデータが失われている為、差分データしか無い訳です。
本来その位置に記録されるDC成分の直接値と実際に記録されている差分値が一致すればいのですが、一致するのは偶然です。

後で加工ソフトを通す事になるのですが、加工ソフトで修正出来るものなら修正で直した方が確実です。
加工ソフトで修正出来そうも無い場合、まともな絵が出るまでイメージデータの先頭を1バイトづつ削除して下さい。

イメージデータの先頭を削除する方法は
解析リストの"***** Image Data *****"と表示された行から右クリックし、ダンプを選びます。
ダンプ画面のイメージデータの先頭が反転しますから、その部分にマウスを当てて右クリック"1byte削除"を選びます。
削除しますか?のメッセージにOKを返します。


どうやってもまともな画像が出ない場合

以下の点が考えられます。いずれも修復は無理ですので諦めて下さい。
・ハフマンコードが最適化されている
・イメージデータが間引き的に間欠状態で破損している
・JPEGのイメージデータではない


写真の一部と判る画像になったら

この画像の見えている状態を少し説明しておきます。

ファイルはバイト単位で記録されていますが、JPEGのイメージデータはビット単位に記録されています。
よって、イメージデータの先頭が欠けた状態では、ハフマンコードの途中のビットから始まる事になります。

ハフマンコードの同期が合わない状態が先頭データで何度か繰り返されるうちに偶然に同期が合い、その後はデータが破損していない限りデータの最後まで同期が合った状態が続くという感じになっています。

先頭のデータ数バイトは全く絵になっていないのですが、削除すると同期合わせのプロセスが変わり、絵の開始位置が変わってしまいます。

また、データが左端から始まるとは限りません。ずれていると、写真を縦半分に分けて右と左を逆にしたような絵になります。

これ以降はJpegAnalyzerで処理出来ません。
EOIが無ければEOIを付けて一旦保存し、画像加工ソフトでトリミングしたり左右を入れ替えたりして修復して下さい。
左右を入れ替える場合、右にくる画像がサンプリング比が4:2:2の場合8ドット、4:2:0の場合16ドット上にずれますので、下げて貼り合わせて下さい。

再圧縮することになりますが、その時点で正常なイメージデータになるので画像が劣化する分は諦めて下さい。

画像データ先頭に同期の合っていないビットデータがある為、ソフトによってはエラーになったり表示内容が変わったりする場合が有ります。
エラーデータの扱いはソフトにより異なるので、そう言った場合はソフトを変えて試して下さい。

最後に、始めて修復をされる場合、何をするにしても半信半疑だと思います。
一度正常な画像のヘッダー部分を含む先頭データをバイナリーエディターなどでをカットし、擬似破損ファイルを作って修復の練習をするといいでしょう。
実績が出来るので自信を持って処理を進められます。

Top