Nature | Photography | Music | Art -35ページ目

Nature | Photography | Music | Art

日々好奇心の趣くまま

サイト内の写真の使用ならびに無断転用を禁じます。

GWに沖縄の群青の海に包まれたのに端を発したのか、このところ「蒼いモノが撮りたくて仕方ない」病が高じています。

丹沢山塊は山の形が地味とかテント禁止とかヤマビル攻撃とかのマイナス要因があって、比較的近い割にはほとんど足が向くことがありません。
そんな中、丹沢に信じがたいほど蒼い水があると聞いて機材一式を背負って行ってきました。

ユーシン渓谷…比較的マイナーなコースで、ずっと林道歩きなので登山的には少々物足りないのですが、新緑と紅葉の名所ということでこの時期のんびり歩くにはいいかも。

このコース、真っ暗な隧道体験などいろいろ見所があるのですがそのあたりは他所に任せて、以下は本題の蒼い水のところだけ厳選して。

蒼い水が見られるところは結局のところダムによって堰きとめられたもので、上高地の大正池と同様に半分は人工的な景観ですが、とりあえず邪魔な人工物をフレームアウトさせています。決して南の島の海岸ではありません…








実際の見た目は実はこれほどまで蒼くはなく、なぜか写真に撮ると異常に蒼く写るのです。水中の粒子とCPLフィルターの相互作用なのか、人間の目とカメラセンサーの特性の違いが原因なのか、非常に不思議。

もちろん水中も。







以下チラ裏ですが…

このところずっと追求している川や湖沼の水中風景、ほとんどの場合は海のように面白い地形やフォトジェニックな生き物で溢れているわけではないので作品になる構図の選択肢があまりないという結論から抜け出せずにいます。

ほとんどの場所は水中だけを撮ってもあまり面白くなく、水上と水中の風景に加えて上下から見た2通りの水面の4つの要素をどうやって面白く配分するかということに落ち着いてしまう。
しかしながらこれらの4つの要素をすべて一枚に収めるのは物理的に不可能で、結局のところ最大3要素の組み合わせということになる。

なにやらピカソがキュビズムを始めた理由が妙に理解できる今日この頃です。
以下の写真、ペトラでもアンコールワットでもなく、群馬にある「知る人ぞ知る」石切場跡です。

場所は分かりにくいが一応観光地になっていて、現状のところはかなり自由に探検できます。

少々危険な場所も立ち入れるので、すぐに管理者責任を問う日本の厄介な風潮ゆえ、今後有名になって訪問者が増えればいろいろトラブルを起こしてそのうち立ち入り制限などされるのではないかと思っています。

駐車スペースに停めて何の変哲もない山道を5分ほど歩くといきなり前方に巨大な建造物が現れる。



内部に入っても魚眼でなければ太刀打ちできない巨大さ。







太陽のフレアなど入れると果てしなくどこかの遺跡っぽい。





で、実はこれは本題ではなく…

折角ダイナミックレンジの大きい被写体なので、ここでブラケット撮影した写真をネタにOpenCV 3.0から実装されたHDR機能を試してみようというのが本題。

実は上の写真もすべてOpenCVのHDR機能を使って合成したものです。
HDRとは何ぞや…についてはここを参照。

OpenCV3.0のHDRの概要に関しては以下参照。紹介されている参考文献がとても勉強になる。

http://docs.opencv.org/master/d3/db7/tutorial_hdr_imaging.html

http://docs.opencv.org/3.0-beta/modules/photo/doc/hdr_imaging.html

市販のPhotomatixなどのソフトと比べると「いかにもHDR」というようなド派手な仕上がりにはならないが、適度に品良く合成してくれるという印象で、実戦でも十分使用できるのではないでしょうか。
しかもその気になればソースも公開されているので自分でカスタマイズなどもできてしまう。

通常、HDRはPhotomatixやHDR Proなどの専用ソフトで原理を知らなくても合成できてしまうので、動作原理の理解などはすっ飛ばしてしまうのだが、今回少しばかりHDR合成の理解を深めるよい機会となりました。

そもそも一般的にHDR写真と言われているものは厳密に言うと実はHDRではなく(現在のいかなる表示手段でもHDRをそのまま表示することはできない)合成されたHDRからモニターや印刷物で見られるようにLDR(Low Dynamic Range)に変換されたものであることも今回改めて知りました。
以下混乱のないように、表示できるように変換した画像をLDRと書きます。

その筋の専門家ではないので、誤って理解しているものもあるかも知れませんが…

大きく分けてメジャーなHDR合成手法は

・Tonemap
・Exposure Fusion

の2つに分かれるらしい。(たしかにPhotomatixでもこの2つの設定がある)
それぞれの手順は

Tonemapの場合

1. ブラケット撮影されたイメージシーケンスとそのcamera response function (CRF)を用意する。
CRFとは、通常ピクセル値と実際の照度(irradiance)は非線形なため、合成に適する線形に補正するためのLUTのようなもの。
CRFは通常カメラメーカーからは公開されていないので、OpenCVでは撮影されたイメージシーケンスとそのそれぞれのシャッタースピード(絞り・ISOは固定として)からCRFを推定する手法を採用しています。

2. 上のデータを元にHDR画像を合成する。ここで合成されたHDRは浮動小数点で表現されていてダイナミックレンジが非常に大きく、モニターなどで全貌を見ることはできない。

3. ここが一番肝の部分。出来上がったHDR画像から表示することが出来るLDR画像を合成する。これがTonemappingと呼ばれるもので、現在進行形でいろいろな手法が考案されつつある(らしい)。OpenCVでもDrago,Durand,Mantiuk,Reinhardの4つのアルゴリズムが組み込まれている。
要はHDR画像をそのまま線形にダイナミックレンジを狭くしてもコントラストのない実用的でない画像になってしまうため、コントラストを維持したままダイナミックレンジを256階調(16bitの場合は65536か…)に収める手法の総称がTonemappingと呼ばれている。(たぶん)

Exposure Fusionの場合

1. Tonemapとは異なり、HDR画像やCRFを介さずにイメージシーケンスから直接LDR画像を合成する。
与えられたイメージシーケンスのコントラスト・彩度・適正露出の3つのパラメータ+αの情報から判断してイメージシーケンスのうちの1枚から最適な部分を取り出しモンタージュして一枚のLDR画像を合成する。

以下、本家サイトのサンプルをベースに一連のアルゴリズムの合成結果を比較できるプログラムを作ってみました。

https://github.com/delphinus1024/opencv30hdr.git

Windowsでは何故かassertionエラーで不正終了してしまうので、Linux(Ubuntu)のみで動作確認しています。
使用したバージョンはOpenCV 3.0 RC1

準備として

1. exiv2 (画像ファイルのEXIF情報を取得・操作するオープンソースなソフト)をインストールしておく。

2. pkg-configをインストールしておく。

3. もちろんOpenCV 3.0をインストール。

4. ブラケット撮影されたイメージシーケンス。今回は1Ev刻みでブラケット撮影したものを使用。



ビルド方法は

上記すべてのファイルを同じディレクトリに置いて

make

で実行ファイルhdrができる。

実行方法は

1. まずイメージシーケンスとシャッタースピードの一覧を記述したlist.txtを作成する。
もちろん各イメージファイルにシャッタースピードのEXIF情報が含まれている必要がある。
イメージファイルの拡張子は.tifを想定。

python make_list.py [イメージシーケンスのあるディレクトリ名] >list.txt

でlist.txtが出来上がる。
list.txtの中身は以下のような感じで、ファイル名とシャッタースピード値が羅列されている。




7S4A9876.tif 1579.223836
7S4A9877.tif 789.611918
7S4A9878.tif 394.805959
7S4A9879.tif 197.402980
7S4A9880.tif 98.701490
7S4A9881.tif 49.350745
7S4A9882.tif 24.675372
7S4A9883.tif 12.337686
7S4A9884.tif 6.168843
7S4A9885.tif 3.084422
7S4A9886.tif 1.681793
7S4A9887.tif 0.771105
7S4A9888.tif 0.385553
7S4A9889.tif 0.192776





2. list.txtをイメージシーケンスと同じディレクトリに置く。

3. 以下のコマンドで起動

./hdr [イメージシーケンスのあるディレクトリ名]

処理が終わると各アルゴリズムで処理されたLDR画像(png)が生成される。

生成された画像はそのままではコントラストが低いので、適宜レベル調整してやると見られる画像になる。
それぞれのレベル調整後の結果は以下。

Tonemap系のアルゴリズムはすべてデフォルト設定で処理したのだが、比べて見てみるとコントラスト情報とそれ以外の情報を分離して処理しているDurandが細部まで綺麗に合成されていてコントラストも色もいい感じに保持されているように感じる。パラメータを変えてみるとまた異なる結果になるのかもしれないが、このあたりは未確認。
もちろんHDRはアート系以外に科学的・医学的にも使われる技術なので、美的判断だけがすべてではないのかも。

Mantiuk


Durand


Drago


Reinhard


Exposure Fusionは4種類の設定で出してみた。
デフォルト値の contrast_weight=1.0f, saturation_weight=1.0f, exposure_weight=0.0fで出したものが一番コントラストも彩度も派手に合成されるみたい。

(1.0, 1.0, 1.0)


(0.0, 1.0, 1.0)


(1.0, 0.0, 1.0)


(1.0, 1.0, 0.0)


いずれにしても、市販ソフトよりも自然な絵を出してくれる上に自分で詳細を弄れるので結構気に入りました。タダだし…
ただし、Photomatix系の派手派手な絵が好きな人には物足りないかもしれません。
GW前に書いたこの記事の続編です。

http://ameblo.jp/delphinus1024/entry-12018016756.html

念のため重複になりますが、gphoto2とは多くの民生カメラをUSB制御できるオープンソースのLinux(Mac)ソフトウェアで、libgphoto2というのはその心臓部を司るライブラリ。

うまく使いこなせればカメラの自動制御などが可能になって表現の幅が広がる(かも)。

gphoto2でもかなりのことができるのですが、それでも機能的・パフォーマンス的に不足な場合はgphoto2を介さずにlibghoto2を直接制御することになります。
それが今回のテーマです。

カメラマンでここまで必要とする人はいないのか、Web上にまとまったわかりやすい情報がほとんどありません。

断片的な情報を寄せ集めてなんとか使えるところまで来ましたので、個人的な備忘録を兼ねて。

以下参考にされる方は自己責任・No Question・No Supportでお願いします。

ここでは前回の記事と同じこと(マニュアル露光にしてブラケット3枚を20秒毎に3回繰り返す)をC++のプログラムからlibgphoto2を直接叩いて実行してみます。

以下ビルドするには前回書いた環境構築が正常に行われている必要があり、gccが使用できる環境である必要があります。

プログラムの内容はかなりボリュームがありますが、とりあえず動作することを目的にしたので、最適化していないため冗長な箇所やデバッグ時のゴミも多いです。Webの情報をかき集めて作ったので、コーディングスタイルも各所まちまちなのもご了承ください。

C++のテンプレートなどを使えば半分以下の分量になるかもしれませんが、サンプルなのでそのままにしています。

仕様変更の多いライブラリなので、将来のバージョンでは動作しなくなる可能性もあるかと思います。カメラの種類によっても挙動が異なるかも知れず、あくまでも参考程度だと思ってください。

下の環境で動作確認しています。

・gphoto2 2.5.6
・libgphoto2 2.5.7
・libgphoto2_port 0.12.0
・5D2 & 5D3
・VMWare+Ubuntu13.04(少々古いが…)

ダウンロードは

https://github.com/delphinus1024/gp_bracket

ビルド方法はreadmeに詳しく書いてあるが、コンソール上で

make

をすれば実行ファイルbracketが出来上がります。

実行方法はまず、EOSをUSB接続・電源ON
lsusbでEOSが見えていることを確認後、

./bracket

と入力。

正常動作すれば、EOSが3x3=合計9回シャッターを切った後にプログラム終了するはずです。
暗い場所などフォーカスが会わない時は動作破綻するので、マニュアルフォーカスに切り替えておいた方が問題が起こりにくい。

プログラムの大筋は処理の内容と照らし合わせればだいたい想像がつくかと思いますが、理解のキーとなる点をいくつか。

・gp_の接頭語がつく関数がlibghoto2が提供するAPI。

・Config Valuesの箇所で主要なパラメータの一覧を宣言してある(ISO,シャッタースピード,絞り…etc)。サンプルでは使用していないものもとりあえず入れてある。
set_xxx, get_xxx関数(xxxは設定対象名)でそれらの値の取得・変更を行う。ここでは5D2,5D3を想定していますが、カメラが変わったら宣言の変更が必要になるかも。

・set_xxx, get_xxx内部で"widget"とつくlibgphoto2関数を操作しているが、widget = 設定値(config value)名と考えてよいみたい。前回に書いたようにConfig ValueはTree状になっているためwidgetと呼んでいるみたい。

・main関数の最初でGPContextを取得しているが、このcontextというのがlibgphoto2の「総元締め」のような役割を果たすみたい。これ以降のlibgphoto2のAPIの多くはこのcontextを渡す必要がある。contextは(カメラが複数あっても)プログラム内で一個取得すれば十分。

・カメラは複数個接続/制御できる。このプログラム内ではすべての接続されたカメラをOpen(open_camera関数参照)して、以降の操作は最初のカメラのみに行っている。プログラム終了時にOpenしたカメラはExit(gp_camera_exit)する必要がある。プログラムを書き換えれば複数のカメラを平行して制御することも可能。

・portやabilitiesという名前のついた関数をOpen前に呼んでいるが、これらはとりあえずオマジナイと思っておいても支障はないみたい。

・プログラムでは撮影したデータはCFカードに残す設定にしているが(set_capture_target関数参照)、#define GET_FILEをアンコメントするとホスト側にも同じデータをUSB経由で取得するようになる。

・撮影を行うのがgp_camera_capture関数。この関数は撮影が終了してCFカードにデータが格納されるまで制御を返さない。複数のカメラをパラレルで撮影するときなどは撮影開始後に制御をすぐ返すcp_camera_trigger_captureを使用した方が便利かもしれない。(#define DO_TETHER_CAPTUREをアンコメントするとその部分が有効になる) この際、撮影終了を判断するにはカメラからGP_EVENT_FILE_ADDEDイベントが帰ってくるのを待つ必要がある。これに関してはcamera_tether関数内を参照。

・エラーや情報通知用のコールバック関数を設定するのが、gp_context_set_error_funcとgp_context_set_status_func。何か起こればコールバックが起こる。必要があれば処理する。

・その他、実践で流用できるようにLiveViewやFocus関連などサンプルで使用していない関数なども入れてあります。いろいろ実験してみるといろいろ発見があるかもしれません。
GWに北アルプス栂池で撮影した映像が完成しました。



その時の詳細は以下で。

http://ameblo.jp/delphinus1024/entry-12024523963.html

満月に照らされた雪山は生で体感している限りは、それはそれは神秘的な雰囲気に包まれる別世界なのですが、いざそれを映像にしようとするといろいろ困難に直面します。

星がほとんど写らなかったり(特に月をフレームインした時)、その結果昼間の絵と変わらなかったり(なので後から色温度とかを弄るしかない)、毎回毎回後処理に苦労します。





それはさておき、付随音楽についてですが、実はこのところ音楽方面でかなりスランプに陥っておりまして…どう作っても、どう弾いても面白くない。
それは前向きに考えて、自分の耳が進化しつつある証拠だと思いたいのですが…





そんな状況下ではありますが、無理やり奮起しつつ、いつもながらのピアノの即興で。

その際、脳に少々刺激と渇を与えるべく、苦手な#多い系のキー克服を兼ねてC#mのキーで貫いてみました。これ以上#が増えると即興では弾けません…

縺れまくっているのはそのあたりに(も)原因があるので、どうかご了承ください。

新緑+水辺シリーズが続きます。

群馬の北限のドンツキにあるダム湖。

人造湖ながら景観に配慮して建築したらしく天然湖のようなフォトジェニックな湖です。
特筆すべきは、下流にある四万湖もそうだが、ここは摩周湖かと思うほど透き通った蒼すぎる水の色です。

おそらく鉱物系の色だと思われますが。

ここで多くのカメラマンが撮る写真が湖に一列に生えた木を入れたこんな構図。ここだけでもおそらく時間帯や季節によって色合いが変わって飽きなさそう。



しかしながら、もちろんこれだけでは満足できないので、水辺に下りてみます。

この湖、立ち入り禁止柵のあるダム保守用ルートと写真的にあまり面白くなさそうな水辺公園を除けば、摩周湖と同じでほぼ全周崖に囲まれているので湖面に下りるのは困難に見える。
が、実は何箇所か下りることができるルートがあることを事前に下見して確認しています。

まずは先ほどの一列木の正面。三角点の保守用に不明瞭なトレースができているのでそれに沿って下りる。湖畔に植生が多くて写りこんでしまうが、やは蒼い。





もう一箇所、ひっそりとした入り江の奥。個人的にはこちらの場所の方がフォトジェニックなのでお気に入り。

近くで見ると尚更尋常ではない蒼さと透明度が分かる。



水の蒼さと新緑を絡めて。





紅葉の時期に来てもよいかもしれません。