|
|

- >
- Yahoo!サービス
- >
- Yahoo!ブログ
- >
- 練習用
こんにちは、ゲストさん
|
Dcrawを使って、rawファイルの中身を見るためには、まず、dcrawのソース(dcraw.c)をコンパイルできる必要がある。
「Compile with "gcc -o dcraw -O4 dcraw.c -lm -ljasper -ljpeg -llcms" or "gcc -o dcraw -O4 dcraw.c -lm -DNODEPS". 」
GCCはLinuxの標準C, C++コンパイラだが、Windowsでも動くものがフリーで入手できる。
私が使っているのは、MingWである。
これが必要な場合は、HP(http://sourceforge.net/projects/mingw/files/)に行き、「Looking for the latest version? Download mingw-get-inst-日付.exe」という行をクリックし、インストーラをdownloadしてインストールする。
インストールするとMingWの他に、Windows上にLinuxライクな環境を作って、MingWを使いやすくするため(無くても良いが、環境変数とかを自分で設定する必要が出てくる)のMsysというtool集もインストールされ、デスクトップにMsysのアイコン、ハードデスク上にMsysというディレクトリができる。
このMsysディレクトリの中のHomeというディレクトリの中に、自分のlogin名(Administratorとか)のディレクトリができており、そこがMsysを立ち上げてGCCを使う場合の作業ディレクトリとなる。
そこに、dcrawのソースファイルdcraw.cをdownload(あるいはコピー)しておくと良い。
Msysのアイコンをクリックして立ち上げるとコマンドプロンプト(というかlinuxのコンソールウインドウ)のようなものが立ち上がる。
すでに作業用ディレクトリにいるので(pwdと打つとどこにいるかわかる)、今回はいきなり、
gcc -o dcraw -O4 dcraw.c -lm -ljasper -ljpeg -llcms
とか
gcc -o dcraw -O4 dcraw.c -lm -DNODEPS
とか打ってみた。
両者とも、warningコメントが出て、エラーでとまるが、後者はwarningも短く、性質がよさそうだったので、じっくり読んでみたところ、どうも、ntohs、htons、ntohl、htonlという四つの関数がわからないらしい。
いろいろ調べたが、どれも下記のような簡単な関数なので、ソースに書き込んでしまうことにした。
unsigned short htons(unsigned short n)
{
return ((n & 0xFF) << 8) | ((n & 0xFF00) >> 8);
}
unsigned short ntohs(unsigned short n)
{
return ((n & 0xFF) << 8) | ((n & 0xFF00) >> 8);
}
unsigned long htonl(unsigned long n)
{
return ((n & 0xFF) << 24) | ((n & 0xFF00) << 8) | ((n & 0xFF0000) >> 8) | ((n & 0xFF000000) >> 24);
}
unsigned long ntohl(unsigned long n)
{
return ((n & 0xFF) << 24) | ((n & 0xFF00) << 8) | ((n & 0xFF0000) >> 8) | ((n & 0xFF000000) >> 24);
}
ソースを書き直すには、まず、エクスプロラーで作業ディレクトリを開き、dcraw.cをノートパッドなどで書き直せばよい。ただ、downloadしたdcraw.cをいきなりノートパッドで開けると、ノートパッドが改行を認識しないので、非常に見ずらい。
最初はワードパッドで開け、すぐに上書き保存して改行をwindowsタイプにしておくと、その後はノートパッドでも改行されるので見やすくなる。
上記の関数は、一応、マクロ定義(#define)が終わったあたり、実際の関数定義が始まるあたりに挿入した。
で、
gcc -o dcraw -O4 dcraw.c -lm -DNODEPS
と、やってみたところ、
あっさり、コンパイルできてしまい、作業ディレクトリにはdcraw.exeというファイルができてしまった。
さて、rawファイルのxx.RW2を作業ディレクトリにコピーし、
dcraw xx.RW2
とすると
xx.ppmという、48Mバイトもあるファイルが作成される。
これが、Partable Pixelmapという古い完全無圧縮のファイル形式のもので、1600万ピクセルに対応し、1ピクセルあたり3バイト(3色分)だから、16Mx3=48Mという大きさのものになるわけだ。
IrfanView(http://www.irfanview.com/)などで開けることができて、すこし、眠くて色がおかしいものの、ちゃんと現像できている。
dcraw
SILKYPIX ディフォルトでdcrawを使うとこうなるのらしい。
もっとも、多様なオプション設定ができるようなので、がんばればSILKYPIXのような絵を出すことも可能だろう。
どうやら、自分でコンパイルしたdcrawでrawファイルの現像ができたようだ。
<つづく>
|
|
Rawファイルについて、いろいろ解析する前から奇妙に思っていたことがある。
それは大きさだ。
G3の撮像素子は約1600万画素で1画素あたり12ビットの諧調を記録できる。
となると、rawファイルは、少なくとも、(1600万x12ビット=19200万ビット/8ビット=2400万バイト=)24Mバイトの大きさであるべきなのだが、大体、19M前後の大きさに収まっている。
Exif情報を読み出そうと、いろいろrawファイルの構造を調べたが、サムネイル用のJpegが入っているので、本来の情報を格納している大きさは19Mバイトより小さく、Exif情報やサムネイル部分を除くと10.8Mバイトになる。
本来必要な24Mの半分以下に圧縮されているようなのである。
SILKYPIXは、rawファイルから情報を取り出すことができるが、さすがにどう圧縮されているかまではわからない。
中身を見てみたいものだなあ、と思って、いろいろフリーの現像ソフトウエアなどを当たっていたら、すごいものにぶち当たった。
その名は、dcraw(http://www.cybercom.net/~dcoffin/dcraw/)。
ANCI Cで書いてあるrawファイル現像ソフトで、ソースが公開、しかも、474種類のカメラのrawファイルに対応という優れものである。
出力が、Partable Pixelmap(ppm)という古い完全無圧縮のファイル形式とTiffだけ、さらに、出力された画像が暗く(特に16ビットで出力された場合)、やや眠い感じで色もおかしい、という欠点があるが、rawファイルのなぞにせまるには、最高のフリーソフトだ。
rawファイルの読み出し部分は、多くの商用ソフト・フリーソフトで2次利用されているよう(HP情報によると、PhotoshopやPicasaなども使っているらしい?)で、使ってみることにした。
<つづく>
|
|
レンズをとっ変えひっ変えして、撮影したjpegなどを整理していて、気がついたことがある。
カメラで直接作ったjpegにはレンズ情報ががあるのに、rawファイルから付属のSILKYPIXをつかって現像したjpegファイルには、レンズ情報が無いのだ。
使用していた画像整理ソフトはPhotoStagePro(http://www.rjtt.jp/sufirico/)という優れもののフリーソフトで、デジカメ画像の撮影情報などが書かれているExif情報は、しっかり抽出して表示してくれているはずなのだが、rawからは、レンズ情報なし。
他のソフトも2,3当たったが、rawファイルからレンズ情報を読み取ることができなかった。
まさか、rawファイルにはレンズ情報は記録されていないのか?と気になって、バイナリエディタBz (http://www.vcraft.jp/)で、rawファイルをのぞいて見たところ...ちゃんとありました。
結局、レンズ情報はファイルの中のどこかに確実にある。しかし、rawファイルからExif情報を読み出してくれるソフトウエアが、SILKYPIXはじめ、レンズ情報には対応していない、という有様のようだ。
ひとつ自分で、rawファイルからレンズ情報を読み取るrubyスクリプトでも書いてみようかと考えた。
いろいろHPなどをのぞいてみた結果、Exif情報はTIFF形式のエントリーとしてrawファイルの最初の部分に書かれていることがわかりました、TIFF形式のエントリーというのは、12バイトで、タグ2バイト+タイプ2バイト+カウント4バイト+値または値の場所4バイト、という構成になっています。これがいくつか集まってInformation Directory(IFD)というものを作っていて、画像情報以外のほとんどすべての情報がIFDとして格納されている。
G3のrawファイル(拡張子.RW2)は5つのIFDを持っていて、一番先頭のTIFF-like-header直後のIFD(IFD0)のエントリーを順番に読んでいくと、芋ずる式に他のIFDの始まりの位置がわかるようになっている。
相互関係はこんな感じ:
TIFF-like-header → Information Directory0(IFD0) → IFD1
↓
APP1 IFD
↓
Exif IFD
↓
Maker Note IFD
ファイルの先頭からの、実際の並びはこんな感じ:
TIFF-like-header
IFD0
(実際の値:IFD0用)
IFD1
(実際の値:IFD1用)
(わけのわからないbinaryデータ)
APP1 IFD
(Print IMとかいうもの)
Exif IFD
(実際の値:Exif IFD用)
Maker Note IFD
(実際の値:Maker note IFD用:広い顔認識用データ領域など??)
Thumb nail 1 (Jpeg形式)
Thumb nail 2 (Jpeg形式)
本当のRAW data
で、各IFDの各エントリーのタグが何を意味するのかがわかれば、実際のExif情報の中身がわかるはず。
そこで、Exif Tags(http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html)といったサイトを参照しつつ勉強した結果、レンズ情報はMaker noteIFDといわれている各メーカーが勝手に使っていい部分に含まれていることがわかった。
Maker noteIFDは各メーカーが自由にタグを定義して使えるため、汎用のソフトウエアはいちいちそこまで情報を得ようとしない部分のようだ。
上記の Exif Tagsには、各主要メーカーのMaker noteのエントリータグが何を意味しているかの情報もあるので大いに助かった。
まあ、rubyスクリプトは一応書いて、レンズ情報もその他の情報も取り出せるようになったものの、正直よくわからないタグも多く、とても使い勝手の良いものとは言いにくい。
面白かったのは、Jpegファイルを2つ含んでいるのがわかったことだ。大きいほう(Thumbnail2)はPhotoStageProなどでrawファイルを表示するとき使われているもののようで、小さい方は、そのサムネイルのようだ。
|
[ すべて表示 ]
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 |
登録されていません
[PR]お得情報