データの構造にモノ申すっ･･･

･･･X3Fファイルのハナシ。


データ展開のカギとなる値を含むのは、選りにも選って、ファイルの先頭部分と末端部分に分かれている。
ツマり、画像やEXIFを適宜読み取るには、一旦全てのファイルをメモリへ読み込む必要性に迫られる。

エクスプローラで情報を表示するだけでも時間を要すると云う構造だ。
そもそも、EXIFをWindowsに提供する機能すら持たないフォーマットなので、
過去紹介したような、サムネイル表示プラグインツールが必要となる。

むしろ、それらで運用するだけなら、問題を認識することは無かったと思う。
そんな折、支障があるコトが判ったのは、VBScriptでEXIF抜きを試行した際だ。

データの先頭位置を記録しているのが、ファイルの末端部分だったってのが、致命的で、
先頭の1kB程度を読むだけで得られる撮影情報の先頭位置すらも、ココに記録されているのだ。
それら情報を適切に、全て見えるカタチにする為には、ファイルを最後まで取り込んで、
末端部分も確保する必要があるのだ。


　　　ナニ云ってるカナ？　ADODBStreamで、スキップ読みすればイイだけだろ？


･･･と思うよね、やっぱり(´ﾍ｀；)
確かに その処理も、ローカルドライブで扱うには、そう大きな支障はないんだが、
ネットワークを介する場合、困ったことが起こる。

以前のログでも述べた通り、ADODBStreamでネットワークドライブ上のファイルを扱う場合、
その意図が無くとも、一旦ローカルのテンポラリフォルダへ全容量確保された後、処理に利用されるのだ。
･･･X3Fファイルのサイズは そう小さくない、縦しんば、GigabitEthernetを利用していたとしても、
大量のファイルから一気にEXIFを抜く、などと云った処理の場合、膨大な時間を要してしまう･･･
ファイルの数次第では、ローカルで処理しても同様の問題を抱えてしまい、実用性に掛ける結果に見舞われた。


　　　だったら、FileSystemObjectのTextStreamで、一部分抜粋読み出しで解決～


･･･とも考えるよな～　でも実際は、コレもダメだった。
部分読みには成功するのだが、文字コードとして処理できない部分が、強制的に置き換えられてしまい、
元の情報として機能しない破損データとなってしまうのだ。･･･なんか前置き長かったね(^_^;)　ナニが云いたいのかってぇと、"X3Fデータの形式を改めろ" ってコト。


X3Fファイルの構造概略


　　1.Headder
　　2.JPEG FullSize 2640×1760
　　3.CAMP -Unknowns-
　　4.Property for EXIF Data
　　5.RAW Data
　　6.JPEG for Preview
　　7.Directory
　　8.Offset Directory


つー資料掲載のサイトがあった。
撮影後、本体内で出来たデータの順でファイルを書き込んでるのがロコツに判る、
しかしSD14からのデータを覗くに、かなり変えてある可能性が高い。が、1と7と8は、あの位置で間違いがナイ。

ツマり、8を読まないと、各データの先頭位置の情報を含む場所(7)も判らないし、
そのアト、7を読んで、ようやく各データの先頭位置が確保できる･･･　なんて毛唐な文法･･･(-_-;)


pdfのX3Fファイル仕様書によると、もっと大雑把なのがあったw


　　1.Extended Header
　　2.Data
　　3.Directory 
　　4.Directory Pointer 


･･･(´ﾍ｀；)　やはりココは日本人らしく、使いやすい順序に並べ替えるべきだ!


　　4.Directory Pointer 
　　3.Directory 
　　1.Extended Header
　　2.Data


コレなら、ファイルの必要な部分にのみ適宜アクセスする処理を容易に構築できる。
3を固定長にすれば、4は不要になり、肝心の 2 の中身も、


　　1.JPEG for Preview
　　2.JPEG FullSize 2640×1760
　　3.RAW Data


コレならPhotoPRO等でのサムネイル表示も、不要な部分を読み込む必要から開放され、高速化が可能になる。
1の記録破損問題さえ解決できればな～Ψ(｀∀´)Ψ


しかし、管理の利便性を向上させる為にも、一考の価値、あると思うのだがねぇ･･･(´ﾍ｀；)