mieki256's diary



2007/11/13(火) [n年前の日記]

#1 [iappli][cg_tools] パノラマ画像作成実験用素材写真を撮影してきた

自転車で、スポーツ公園脇の土手と、愛宕山公園まで。手持ちのデジカメ、Canon PowerShot A300(単焦点、広角(ぎみ)28mm)と、昨日購入した安物ダメ三脚、親父さんから借りた512MBのコンパクトフラッシュを持って、グルリと撮影。 *1 2時間半ほどかけて、200枚ちょっとの枚数に。

公園は、蚊柱が凄くて大変だった。親父さんや妹の話では、それは蚊じゃなくてユスリカだろうという話だったけど。何にしても顔の周りを覆われてもう大変。

撮影時の問題が見えてきたような。 :

帰宅後、PCに取り込んだ写真を眺めたり、パノラマ画像合成用ツール hugin で作業してるうちに、色々と問題が見えてきたような。

とにかく、大量に枚数を取らなきゃいけないのが面倒だなと。各画像を、縦、あるいは横方向に何度ずつずらして撮ればいいのか、事前に算出・実測して、なおかつ、三脚等にきっちり目盛りをつけて撮影していかないと、作業的にシンドイ。いきあたりばったりで撮ってたので、無駄な部分もあれば欠落してしまった部分もあって、よろしくなかったなと。

巷の撮影テクニック記事を読むと、カメラを縦にして撮影してる場合が多くて「なんでだろ」と思ってたけど。実際やってみたら、横方向(左右)にカメラを回転させていくより、縦方向(上下)に回転させていくほうが面倒だったので、おそらく巷のソレは、縦方向(上下方向)を極力一気に撮影しよう ―― 撮影画像の長辺と短辺では画角が違う・長辺のほうが角度が大きいので、カメラを縦にしたほうが、上下の風景は一気に収められる ―― ということかもしれないなと思った。…カメラを30度斜めにして撮影してる事例も見かけたけど、それは対角線上がもっとも画角が大きくなることを利用した撮影法らしい。ということで、撮影時のカメラの向きも気を配ったほうが、わずかでも楽になりそうだなと。もっともその場合、専用の雲台が必要になりそうではあるけど。

露出なのかホワイトバランスなのかシャッタースピードなのか判らないのだけど、画像の明るさ・コントラストがバラバラになってしまったのも致命的だった。hugin 上から Autopano-SIFT というプログラムを呼び出すことで、各画像の一致箇所・コントロールポイントなるものを自動で検索してくれるのだけど。今回撮ってきたソレは、画像の明るさ・コントラストがバラバラだったせいか、一致してるはずの部分をかなり見落とされてしまった。後から手作業で、「こことここは同じ」と大量に指定することに。…いや。もしかすると、手持ちの PowerShot A300 の場合、パノラマ画像撮影用のモードを使い続ければ、もしかすると露出等を固定して撮影できたのかもしれない。しかし、上下角度を変えるたびにモードから抜けて入り直してたので…それで明るさ等が違ってしまったのかも。A300のマニュアルを読み直さないと。

ノーダルポイントとやらも、やはり関係がありそうな予感。画像合成の際に、なんだかズレが出るというか…。
ズレが出るのは必然、の図。
雲台? マウンタ? を自作しないとダメだろうか。いや、安物コンパクトデジカメでそこまでするのもどうなんだという話が。そもそもゲームの背景素材としてのパノラマ画像が欲しいだけ・作品としてのパノラマ画像が欲しいわけでもないし。

風が強いと雲の形がどんどん変わっていって、後で合成しようにも形がマチマチ故に一致箇所を自動検索できなくなるのも厳しい。なるほど、魚眼レンズを使って、一発で撮影したくなるわけだなと…。とりあえず、地平線から取らずに、空→地平線→地面の順番で撮影したほうがいいのかもしれず。地面なんてのはそうそう動くものでもないし。変化があり得る空のほうから早目に撮影したほうが問題を回避しやすい、のかな。どうなんだろう。

合成にめちゃくちゃ時間がかかる。 :

enblendなるプログラムで実際の合成をするらしいのだけど。-l 29 をつけると最高品質で合成してくれるという記事を見かけて自分も指定したら、合成だけで2時間かかった…。

そもそも素材画像が大きすぎたのかもしれない。A300で撮影できる最高解像度、2048x1536 の画像で合成してたけど。角度を分けて撮影して、後で合成するなら、もっと小さいサイズのほうが現実的、なのかもしれず。試しに各画像を 640x480 に縮小してから合成作業をしたら、圧倒的に処理時間が短くて済んだ。

各画像が640x480でも、最終的に出力される画像はそれなりのサイズになる。ということは、ビデオカメラ等を使って動画で撮影してしまうやり方も、かなり有効・実用性があるのかもしれない。ブラー(?)が入らないようにする必要はありそうだけど。

一旦各画像を別途保存・enblendをDOS窓から呼んだほうがいいのかも。 :

enblend の実行時、正常に合成してくれないときがある。毎回 hugin から画像を生成するのも時間的に無駄なので、hugin では合成直前の画像を複数のtiffファイルで保存しておいて、別途 enblend を呼び出して試行錯誤したほうが、問題が起きた時の再試行が楽になるかもしれず。

呼び出し方は、
enblend -v -m 512 -w -a -l 29 -o OutputImage.tif InputImage*.tif
こんな感じだろうか。
-v
処理内容を逐一表示させる。
-m MemoryMB
処理に使うメモリを指定するらしい。「-m 512」なら、512MBを割り当てる、のかな? たぶん。
-w
左端と右端がループするように合成する。360度パノラマ画像を出力する際は、指定しないと話にならない。hugin が呼び出す際は、勝手に -w をつけてるらしい。
-a
画像を何枚か合成した後に、それら画像をさらに合成する、のだと思う。合成回数を少なくする=ちょっとは時間を節約してくれるのかも。品質のほうはどうなるか不明。
-l Level
合成時の品質レベルのようなものを指定するらしい? 「-l 29」といった感じで指定。最大値は29。値が大きいと、合成の不自然さは減るが、グーンと時間がかかる。てな話を見かけた。
-o 出力ファイル名
出力 tiff ファイル名を指定。
入力ファイル名
Input*.tif と指定すれば(ワイルドカード指定)、Input〜.tif という名前の全ファイルを元画像として使ってくれる。

これは確信が持てない話だけど。もしかすると、
  • hugin 上で、きりのいい出力画像サイズを指定すること。
  • hugin 上で、「クロップ(crop)」関連のオプションは無効にすること。
てな状態じゃないと、enblend での合成処理が失敗するような感じもした。何度試しても合成がまったくされずにハマってしまって、上記2つを弄ってたら上手く処理されたわけで。いや、もしかするとどこかのドキュメントに書いてあったりするのかもしれないけど、英語わからんです…。

*1: 手持ちのコンパクトフラッシュは128MBしかないので、70枚ちょっとしか撮れない。

以上、1 日分です。

過去ログ表示

Prev - 2007/11 - Next
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

カテゴリで表示

検索機能は Namazu for hns で提供されています。(詳細指定/ヘルプ


注意: 現在使用の日記自動生成システムは Version 2.19.6 です。
公開されている日記自動生成システムは Version 2.19.5 です。

Powered by hns-2.19.6, HyperNikkiSystem Project