プロ用フリー素材のクリエイティブマーケット: 3D・HDRI

はじめまして
トラックバックならびにご紹介、有り難うございました。
すでに、完璧なパノラマですね。
これからも時々寄らせて頂きます。
今後ともよろしくお願いします。

keijiさん、コメントありがとうございます。
keijiさんのようにネット上に情報を公開していただいているので、比較的スムーズにできました。ありがとうございます。今後ともよろしくお願いいたします。

> 通常スフィリカルマップを使う場合、【撮影→パノラマ化→Cubeに分割→レタッチ→再パノラマ化】という手順をとることになるので、HDRIにする場合この工程を最低3回は繰り返す必要がある。

　撮影の直後に（スティッチする前に）HDRI化しておけば、その後の工程は一回ですみます。

> さらに、三脚を消すレタッチの工程をどうするかも考えなければならない。

　単純に下方向の画像を合成するだけなら、それもHDRI化しておいてマスクで切って重ねれば終わりです。ビットマップレベルでレタッチする場合は、HDRI化した直後に（スティッチする前に）レタッチしておくのが楽でしょう（平面だしデータサイズが小さいので）。

> 1. +2/0/-2段階でRAW撮影
> 2. RAWデータを16bit TIFFに変換
> 3. 元にPTguiで3枚のパノラマを作成。
> 4. それを元にPhotoshopでHDRI化

> 理論上は、16bitが3枚なので、48bit分のダイナミクスがあるので、32bitのHDRは作成できる

　それは大間違いです。16bit画像を3枚重ねても48bitにはなりません。多少ノイズは減りますが、ダイナミックレンジは16bitのままです。

---ビットについて---　
　例えば、あるデジタルカメラで「ASA1600、F1.4、1sec（星の明るさ）」で撮影した時の16bit画像が「1-16bit」までの情報を持っていると仮定した場合（10進数で言うと0から65,535）、32bit目に相当する明るさの情報を記録するには露出を16bit分（65,536倍）絞らなければなりません。

　これは「ASA100、F8、1/125sec（日陰の明るさ）」に相当します。この時記録されるデータは「17-32」の16bitですが、「1-16bit」のデータに不都合が生じます。というのは、最初に撮影した「1-16bit」のデータは「17-32bit」が全て0の時の「1-16bit」の値であって、それ以外の場合には無意味なのです。

　32bitは、確かに情報量としては16bitの2倍なのですが、組み合わせの数としては「65,536倍」に相当します。つまり、16bitの撮影を65,536回繰り返して合成しないと32bitの画像にはならない、ということです。もしやらなければ、65,535の次の値が65,536ではなく2倍の131,072になります。まあこれでも実用にはなるんですけどね。

　また、48bit目の明るさを記録するためにはさらに16bit分絞る必要があり、これは「ASA100、F32、1/8000sec、ND6（太陽表面の明るさ）」に相当し、既にNDフィルタ無しでは撮影できない領域になってしまいます。現実問題として撮影は困難ですし、する必要もないでしょう。

　このように、もしカメラの露出を32段分変えて3枚の16bit画像を撮影したとしても、そこから有効な48bit画像を作ることはできません。これができるかのように仕様の中で述べているカメラメーカーもありますが、それは自分が無知だということを宣伝しているようなものです。

　最後に、カメラのAEB機能を使って3枚の画像を撮影する場合、変えられる露出の範囲はたかだか+-2EVに過ぎません。これはつまり+-2bitということです。したがって、もし露出を変えた3枚の16bit画像を適切に合成して32bit画像を作った場合は、最大20bit範囲の画像が得られることになります。ただし、上に述べたような理由により明るい部分では値がとびとびになるので、完全に有効な20bitではありません。また、もちろん有効な32bit画像ではありません。

---センサのダイナミックレンジについて---
　一般的に、現在使われている光、熱センサの精度は8〜12bitです。理由は「熱」によってノイズが発生するため、これ以上感度を上げても意味がないからです。これは物理的な制約なので、技術の進歩では改善できません。したがって、これ以上の精度が必要なセンサは全て液体窒素や液体ヘリウムで冷却して使います。

　デジタルカメラのセンサも12bitでセンシングし、AD変換するように作られています。したがって、情報の精度は最大で12bitです。それを16bitフォーマットに変換したからといって精度が16bitになるわけではありません。4bit分は何の意味もない無駄なデータです。

　例えて言えば、1Lのジョッキに入っていた1Lのビールを2Lのジョッキに入れてもビールが増えるわけではありません。無駄なスペースが増えるだけです。

---ノイズについて---
　一般的に、全ての情報にはノイズが含まれています。「ノイズ」というのは自然界でランダムに発生する無意味な情報で、これによって意味のある情報が汚されたり、かき消されたりします。技術の進歩により、多くの場合には信号とノイズを区別してノイズだけを選択的に除去できるようになりましたが、写真の場合はうまく除去できません。

　理由は簡単で、写真では「自然界に存在するノイズを被写体にすることが多い」からです。写真からノイズを強力に消すと、雲もさざ波も砂浜も全部消えますが、これでは写真になりません。ノイズは被写体の中とセンサの中の両方に存在するが、被写体の中のノイズは残してセンサの中のノイズは除去したい、というわけです。

　しかしそれらのノイズが一度混ざってしまえば、センサで生じたノイズだけを選択的に除去するのは不可能です。ノイズを除去するアルゴリズムには、どのノイズに写真的価値があり、どのノイズにないかまでは判別できないからです。つまり、センサで発生するノイズを抑えることが非常に重要になります。ところが、上記のようにノイズの絶対値を減らすことは困難です。それで、「ノイズに比べて信号を大きくし、ノイズが混ざった信号は潔く捨てる」という形で、「相対的」にノイズを減らすわけです。

　ついでに言うと、「信号を大きくする」というのは、つまり「露出を増やす」ということです。しかし露出を増やすと「明るい部分が白く飛ぶ」という別の問題が発生します。この相反する二つの問題を解決するために生まれたのが、「露出を変えて複数の画像を撮影し、後で合成する」というHDRIの考え方です。HDRIの原点には「1枚の画像が記録できる情報量（明るさのダイナミックレンジ）は少ない」という「暗黙の了解」があります。

---値の有効性について---
　それでは、1枚の画像が記録できる情報量はどのぐらいか、という問題に移ります。これはつまり、どこまでを「（センサでの）ノイズを含まない信号」と呼べるか、という問題でもあります。

　ノイズはその大きさもランダムなので、「ここまではノイズがあり、ここからはない」というような明確な区別はできません。言えるのは、大きな（明るい）信号は相対的にノイズが少なく、小さな（暗い）信号にはノイズが多い、ということだけです。具体的に言えば、イメージセンサがセンシングした情報の12bit目はノイズが最も少なく、1bit目は最もノイズが多いということになります。
　
　つまり、「情報を明るい方から順に採用する」という点には疑問の余地がありません。しかし暗い方をどこまで採用するか、つまりどこまでを「ノイズがない（許容範囲内）情報」とするかは、撮影者が絵を見て「主観」で決めることになります。

　ノイズの程度は、レンズキャップをしたままデジタルカメラのシャッターを切り（つまり黒い画像を撮影する）、撮影した画像を16bitで出力してPhotoshopで開き、レベル補正で入力レベルの上限を255から下げていくことで簡単に確認できます。

　ディスプレイの表示能力は8bitなので、レベル補正する前に見えているのは明るい方から8bit分、つまり「9 - 16bit」に相当します。そしてもし最初から画面にノイズが見えていたら、そのデジタルカメラには8bit目に既にノイズがある、ということになります。実際多くのコンパクトデジカメは7bit目からノイズが乗ります。また、私が使っている一眼レフデジタルカメラ（Canon EOS kiss DN）でも8bit目にわずかにノイズが乗ります。

　入力レベルの値を255から127、63、31、15と順に半分にしていくと、より下のビットのノイズが見えてきます。入力レベルを15にすると、センサの限界である12bitの一番暗いビットをチェックできます。この時画像の中には相当のノイズが見えているはずですが、「私の写真はRAWで撮っているからきれいだ」と言うのは、この画像を「きれいな黒だ」というのと同じです。

　少なくとも私はこれを「きれいな黒」だとは思いません。私がきれいな黒だと思えるのは、甘く見て上から8bit目、厳しく見ると7bit目までです。これはレベル補正で出力レベルの上限を127にした時の画像に相当します。このような理由から、私はRAWは使わずASAを100にしてJPEGで保存しています。

　ASAを100にしてJPEGで保存した場合、センシングされた12bitの情報のうち上から8bitが記録されます。逆に、ASAを1600にしてJPEGで保存すると下から8bitが記録されます。したがって、「私の写真はRAWで撮っているからきれいだ」と言うのは、「ASA1600で撮った画像はきれいだ」というのと同じだとも言えます。RAWで保存した場合12bit全ての情報が記録されますが、私の場合下の4bitを使う可能性はないので、記録するだけ無駄だと思っています。

　誤解のないように書いておきますが、センシングされた12bitの情報のうち一番暗いビットにも情報はあります。ですからよく言われる「JPEG（8bit）よりRAW（12bit）の方が情報が多い」というのは事実です。しかしながら、増えた情報の大半はノイズで、それを除去する方法はありません。

　例えて言えば、ジョッキに入ったビールの上から1/3が「泡」であった場合、それをビールと認めるかどうか、ということです。

　もし他に方法が無いのならば、私もRAWで撮影して被写体に含まれるノイズが消えるのを覚悟の上でノイズを消すとか、諦めてノイズだらけの画像を使うなどの方法を取るでしょう。実際2004年から2005年にかけて、初期のVR作成システムでは私もそのように撮影していました。

　しかしパノラマの場合、もともと「シーンが変化しない」というお約束の上でスティッチングを行っているわけであり、容易にHDRIに拡張できます。なぜなら、パノラマもHDRIも「複数の画像を1枚に合成する」という原理は同じで、そこで発生する問題も解決するための方法も同じだからです。つまり、「パノラマが作れるならHDRIも作れるはず」なのです。そしてRAWをいじくるより、HDRI化した方がずっといい結果が得られます。

---結論---
　ここで、最初の「理論上は、16bitが3枚なので、48bit分のダイナミクスがある」という話に戻りますが、EOS kiss DXでAEBを使って撮影した3枚の16bit画像を合成して得られる画像の有効なダイナミックレンジは、おそらく10から12bitぐらいです。間違っても32bitにはなりません。

　HDRIの論文を読むと、「1EVおきに20枚撮影して合成したが、まだ32bitには足りない」というような記述がよくあります。実際厳密に値の有効性を議論するなら、32bitの精度を保証する画像を生成するのは非常に困難だと思いますし、またそんな画像が必要になるケースもほとんどないでしょう。
　
　私の経験によれば、3DCGを作ったりWebに風景のパノラマを載せるのが目的なら、32bitはおろか16bitの精度も要りません。にもかかわらず、「このカメラは（画像は）何bitだからいい」というような議論がなされるのは、結局「bit（情報）」の考え方を理解していないことの現れであり、むなしいなあと感じます。

言われてからちゃんと調べたら、bit数の扱いは二乗されていくわけですから、32bitになるはずないですね。完全に勘違いしていました。

実際テストでHDRIを作って、簡単なシーンをレンダリングしたところ、それなりの効果は得られました。ここで疑問が出てきたのですが、+/-2EVで撮影された3枚のRAW画像からHDRを作成した場合、10～12bitのダイナミクスしかないいうことですよね。ということは、ステッチや画像レタッチなどは16bitで作業して最終的に、HDRで保存しても結果は変わらないということなんでしょうか。

一番困っているのが、現状HDRの状態でステッチできるソフトが、冨士さんが作成したC4Dのシーンファイルしかないことです。あのシーンファイルを使ってみましたが、カメラが違い画像サイズが違うので（1800x1800ピクセルでのクリップのサイズが違うはず）、どうもうまくいかず、また歪曲補正のXpressoの数式の意味がよくわからないため、使っていません。

しかし、16bitでステッチできるソフトは、使っているPTguiを含めそれなりにあるので、そうなると作業が格段に楽になります。

冨士さんは8bitの複数の画像からどのように12bitのデータを作成しているのでしょうか。

> 言われてからちゃんと調べたら、bit数の扱いは二乗されていくわけですから、32bitになるはずないですね。完全に勘違いしていました。

　えーとですね。「16bitの値を二つ足すと32bitになる」というのは「操作」としては正しいのです。例えば、32bitのデータを上半分と下半分に分けて2個の16bitデータにし、それをどこか遠くに転送し、転送先でつなげて32bitに戻す、ということはそこら中で行われています。

　しかし、「16bitの精度で測定ができる機械で取った値を2個足すと32bit精度のデータになる」というのは大間違いなのです。

　例えば10進数で「78」という二桁の数字を考えます。これを上下に分割して「7」と「8」の二つの一桁データにし、後で78に戻すのは簡単なことです。ここで上の桁は70/100で下の桁は8/10を意味しています

　次に、「78」が床の上に描かれた線の長さ78cmだったとして、これを10cmの長さの物差しで測る場合を考えます。何回測定する必要があるでしょうか。答えは「8回」です。値が得られるのは1回だけですが、そのためには7回の「空振り」をする必要があるのです。

　16bit精度の測定器で32bitの値を測定する場合も同じ問題が発生します。得られる結果の大きさは2倍ですが、その値を得るために最大で65535回の「空振り測定」が発生しうるのです。

> 実際テストでHDRIを作って、簡単なシーンをレンダリングしたところ、それなりの効果は得られました。ここで疑問が出てきたのですが、+/-2EVで撮影された3枚のRAW画像からHDRを作成した場合、10～12bitのダイナミクスしかないいうことですよね。ということは、ステッチや画像レタッチなどは16bitで作業して最終的に、HDRで保存しても結果は変わらないということなんでしょうか。

　RAWは12bitです。+-2EVで撮影すると上下に2bit分値が増えるので、合計で16bitになります。したがって、確実に言えるのは「16bit以上のダイナミックレンジは絶対に発生しない」ということです。

　次に、上から4bit分のデータの中にはHDRI合成時に「欠落」が生じます。これは12bitのデータを16bitにマップするために発生するもので、Photoshopのレベル補正で画像を明るくすると櫛の歯が抜けたようなグラフができるのと同じです。

　最後に、下から4〜5bit分はノイズが目立つので私は使いません。

　このような理由から、「使えるデータ（意味のあるデータ）」としては10〜12bit程度だと考えているのです。

---

　フォーマットに関しては普通の16bit（PSDやB3D）で十分です。HDRI（32bit）を使っても結果は変わりません。ただし、HDRIは100%以上の明るさをネイティブで持てるので、作業は楽になります。

　例えば16bitのB3Dを使う場合、全ての明るさを100%以内に収める必要があり、作業中「非常に暗い絵」を使わなければなりません。

　このような理由から、OpenEXRでは32bit以外に「16bitのHDRI」を持てるようになっていて、ILMの現場では必要十分な16bitの方がよく使われているそうです。ところがCINEMA 4Dは16bitのOpenEXRをサポートしていません。これだけを見てもMAXONが「現場のニーズ」を調べずにソフトを開発していることがよく分かります。

> 一番困っているのが、現状HDRの状態でステッチできるソフトが、冨士さんが作成したC4Dのシーンファイルしかないことです。あのシーンファイルを使ってみましたが、カメラが違い画像サイズが違うので（1800x1800ピクセルでのクリップのサイズが違うはず）、どうもうまくいかず、また歪曲補正のXpressoの数式の意味がよくわからないため、使っていません。

　現実的な方法としては、元データの精度が16bit以下なので、16bitでレタッチまでやって最後に32bitに変換する、というのでいいと思います。32bitに変換する理由は、上記のように100%以上の値を持てる、ということだけです。

　ただし、素人はデータの精度なんか理解できないので、単純に16bitより32bitの方がいいと勘違いし、32bitにしたデータの方をありがたがる、という「販売上の効果」はあるでしょう。まあ、ちゃんと説明しても理解できないわけで、「詐欺」にはならないと思います。

　デジカメの12bitRAWも全く同じです。現在のRAWはコンパクトデジカメと一眼デジカメを区別するためだけに設定されているもので、プロであればこそRAWの下4bitを使ってはいけないのです。

---

　私のWebで公開されているシーンファイルはかなり古いので使い勝手は悪いでしょうね。ただレンズと撮影方向は同じなんで、画像のクリップ範囲を変えて何回かトライすればXpressoをいじらなくても合うと思います。EOS kissDNとDXの解像度の差から推測すると2025*2025pixelぐらいでちょうど合うはずです。

　それから、宮田さんのハードでは無理かもしれませんが、26枚用のシーンファイルも公開しておきました（末尾参照）。今回のはアイデンティファイに売った機械のマニュアルを兼ねているので、かなり詳しく説明してあります。

---

　あの数式を普通に書くと以下のようになります。「多項式近似」と呼ばれる手法で、理系の大学1年で習います。

　Fr= ar^6+br^4+cr^2

Fr=　レンズの歪み
r=　半径（メッシュの中心から各ポイントまでの距離）
a, b, c= 係数（絵を見ながら適当に合わせる）

　また、あのシーンファイルで実際に計算をやっているのはXPressoではなく「数式デフォーマ」です。数式デフォーマの中では「^」が使えないので、あのように見苦しくなっています。現在は全部XPressoでやっているので、a、b、cの値を直接属性マネージャから指定できます。

> しかし、16bitでステッチできるソフトは、使っているPTguiを含めそれなりにあるので、そうなると作業が格段に楽になります。

　上記のように16bitで十分です。

　ただし、一般的な16bit画像を処理するソフトは（CINEMA 4Dを含めて）100%以上の値を持てないので、作業中全てのピクセルの値が100%を越えないようにしなければなりません。100%を越えた値は全て100%でサチッてしまいます。

　つまり、「元データを非常に暗い画像のまま編集する必要がある」ということです。CINEMA 4Dではシェーダで100%以上の明るさを乗算できるので、作業上の問題はありません。Photoshpも調整レイヤを使えば同じことができます。PTGUIで同じことができるかどうかは知りませんが、可能ならそれでいいと思います。

> 冨士さんは8bitの複数の画像からどのように12bitのデータを作成しているのでしょうか。

　CINEMA 4Dのレイヤシェーダの中にいろんなシェーダを入れて作っています。下記アドレスにシーンファイルがあるので調べて下さい。

http://www.11moon.com/QuickTimeVR/VRcam2/manual/index.html

> 一番困っているのが、現状HDRの状態でステッチできるソフトが、冨士さんが作成したC4Dのシーンファイルしかないことです。あのシーンファイルを使ってみましたが、カメラが違い画像サイズが違うので（1800x1800ピクセルでのクリップのサイズが違うはず）、どうもうまくいかず、また歪曲補正のXpressoの数式の意味がよくわからないため、使っていません。

　一応6方向の画像をつなぐためのシーンファイルの最終版をアップロードしておきました。

http://www.11moon.com/QuickTimeVR/making/index.html

　既に1年半も前のもので、今見ると使いにくく感じますが、それでもこのファイルで1200ポイントぐらいQuickTimeVRを作ったので、実用的ではあると思います。
　
　例の数式の部分は、中に「3個の数字」が含まれているので、必要に応じてそれを変えて下さい。もしくは、宮田さんが撮った補正しやすい画像を送ってくれればこちらで補正してもいいです。
　
　おそらくこの先8mmレンズを使うことはないので、残念ながらこのシーンファイルがこれ以上洗練されることはありません。私は現在15mmレンズで78枚撮ってつなぐ方法を使っていますが、いろいろ改良した結果、1日で50枚ぐらい作れるようになったので、8mmレンズを使うメリットが無くなってしまったのです。

　また、クライアントからの要望も「より高精細に」というのが多く、8mmでは仕事になりません。15mmでも余裕がない状況です。したがって、次に作るVRcam3では105mmレンズを使って480枚ほどつなぐ予定です。

　480枚というと手動はきついので、モーターで回します。画像サイズは64000*16000pixelぐらいになります。もちろん合成はCINEMA 4Dで全自動です。撮影枚数が増えれば増えるほど「2Dソフトを使った力づくのスティッチング」という技法との差が開いていきます。