・・・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の記録破損問題さえ解決できればな~Ψ(`∀´)Ψ
しかし、管理の利便性を向上させる為にも、一考の価値、あると思うのだがねぇ・・・(´ヘ`;)
2010/02/22
データの構造にモノ申すっ・・・
Label:
SD14,
SD15,
SIGMA,
Technology,
X3F,
おきつねさまのこうしょう,
おきつねさまのていげん
2010/01/03
アレ対応版・・・
前の版で困難だった、ネットワークドライブ/フォルダ上のファイルアクセスも容易にする為、
対象ファイル読み込み処理だけ、ADODB.Streamから FileSystemObject.OpenTextFileに差し替えました。
以前のログにも記述した通り、ADODB.Streamでは、どう処理の順序を変えても、
ネットワーク先からローカルドライブへ、無条件にテンポラリってしまい、
大量のファイルを連続処理するのはおろか、1つのファイルだけでも多大な時間を要していたのです。
で、今朝・・・ つーか深夜だけどw 夜通しでFSO版を試作してみて、その問題の解消に至りました。
やっぱり餅は餅屋、ファイルアクセスなら、DB向けオブジェクト使うより、FSOってコトですかね・・・(^_^;)
って、書き込みとかはADOのままですケドww以下はアーカイブです。
|
とは云え まだまだ、
アクマで暫定版デスから。結局こんなん出ました~w
< ファイルの一部へのみアクセスするなら、FileSystemObject(FSO) >
2009/12/30
またかいっ・・・
先の おでかけ撮影のトキにもヤられた、SD14の撮影データ破損。
今朝の就寝前定点撮影データも完全ロスト・・・ もう勘弁して(-_-;)
CFメーカー/商品問わず こんな症状出るようなら、新たにCFを買い足すとしても躊躇する罠・・・(´ヘ`;)
取り敢えずChkDskで回復させたが、確保できた.chkファイルの拡張子をX3F変え、
そのままSIGMA PhotoProで現像を試みたトコロで、余程 運が良くない限り、現像は出来ない。
しかし、面白いコトがついさっき判った。
前ログ公開のスクリプトで、正常なファイルと同様に撮影情報が取得できたのだワw
確かに、元々から、完全に全ての情報を取得できないスクリプトだったワケだが、
Header破損しているファイルからも、正常なファイルからのモノと変わらないデータを抜き出せたコトに驚いている。
・・・でも、現像は出来ないんだよなぁ(;_;)
RAW内のメインデータの範囲を取得する手段があれば復元できそうだが、
その情報を格納しているハズのFooterも死んでるコトが多いし、
当然ファイル内で一番規模の大きいメインデータの破損も考えられるワケだから、
結局安直には解決できん・・・(´ヘ`;)
ま、撮影のログだけでも簡単に確保できたので、ヨシとするしかナイ罠・・・
Label:
Developments,
SD14,
SIGMA,
Trouble,
VBScript,
X3F,
おきつねさまのすくりぷと
なんだか・・・
・・・またまた遅延。 真に おきつねさまくおりてぃww
って アレ、まだ完成はしていない。
・・・先のを うpしたアトに気付いたコトなのだが、今回、スクリプトの対象としているトコロのX3Fファイルってのは、
どうやらカメラ側の設定次第で、付随するデータの開始位置も変ってしまうようで、
文字列として抽出する範囲固定で処理しているようなブツでは、うまく対応できないと云う罠(-_-;)
また、撮影日時の値も、秒で構成された小数点以下の値を使わない整数で表されている上、
基準日時が通常端末とは異なる1970/01/01と云う仕様。
・・・Longで表されるシリアル値で、且つ 1900/01/01を基準として動作するVBScriptの日付関数では、
単純に そのまま代入して使うと云うワケには逝かなかった。
今回は、それらの点への対応と、オブジェクトの再利用など、処理の流れを大幅に見直し効率化を図り、且つ
暫定ではあるが、複数ファイルドロップも可能にした。
・・・ただ、カメラの設定項目で、SIGMA PhotoProでも抽出でき、撮影データと深く関わりのある、
露出補正/コントラスト/彩度/シャープネス は、あれらテキストとは、独立したBitで記録されているらしく、
今回の版でも取り出せてない。
そのヘン、X3Fファイルのデータ形式について物色したら、意外に単純でない項目があって、
仕様の通りの処理していては、ファイルの全領域を読み込む必要性に迫られてしまう・・・
コレは、ネットワークドライブを多用している おきつねさま的には、非常~にヨロしくない(´ヘ`;)
なので、実機サンプル撮影後のデータを比較解析し、詳細が判明し次第、スクリプトに反映させるコトとした。
ま、今回のでも、前の版よりは、全然マシではあるモノの、以下は やっぱり、
まだまだ アクマでサンプルですから・・・m(_ _)mスクリプトは、散々コソコソ差し替えつつも、何気にメドイさんだったんで
アーカイブせずに放置していたのだが、取り敢えず、うpしますたm(_ _)m
|
登録:
投稿 (Atom)