Darkside(https対応しました)

<< 前のページ

2023年3月30日(木) 21:54

IBISハイレゾ

 キヤノンが EOS-R5 の大規模ファームアップデートで、IBIS を活用したピクセルシフトを実現するかもしれないと噂になっていたが、予想より早く実装された。残念ながら EOS-R5Cは IBIS を搭載していないので関係がない。
 しかしこれで EOS-R5 mkII にピクセルシフトが搭載されることも確実になった。

 現在、EOS R5/R5C に DUAL FISHEYE を組み合わせた場合の分解能は、約20PPD である。
 これは、ステッチ時の解像度が片目あたり約3684ドットと公式に発表されていて、自作ステッチソフトでもその値を採用している。180度で3684ピクセルだから、1度あたり20ピクセル強となる。
 肉眼は約60PPD とされているので、肉眼の3分の1の解像度しかないのだ。

 搭載された IBIS ハイレゾは3×3なので、分解能が3倍になる。つまり、ほぼ肉眼と同等の解像度が実現される!
 少なくとも静止画に関する限り、肉眼なみ分解能での VR180 3D 記録が遂に実現しそうなのだ。
 通常ピクセルシフトでは色情報も収集するので、実解像度が記録解像度に劣るというベイヤーセンサーの欠点も目立たなくなる。これはキヤノン、本気でVRニーズを取りに来たな!
 そう感じるファームアップだ。後継機で手持ちも可能になれば、大阪万博は肉眼解像度の VR180 3D で撮りまくれるかも・・・

 だが、ここまで書いて重要な問題に気付いた。肉眼に追い付くのはあくまで記録解像度であり、レンズの性能は追い付くのだろうか?
 DUAL FISHEYE のレンズとしての画質はLを名乗るのにふさわしいと評価しているものの、最高にカリカリの描写をするレンズではない。
 もっと客観的に、理論から考えてみよう。

 望遠鏡などでは、分解能は2点を見分ける最小の角度で定義する。60PPD の記録ならぬ実解像度を得たければ、1度の60分の1すなわち60秒角を見分けねばならない。
 天体望遠鏡のカタログスペックでは、分解能は(116÷口径ミリ)秒角で記載されている。例えば、口径200ミリならば 0.58 秒だ。
 分解能 60 秒以下を実現する場合、口径が1.93ミリより大きくなければならない。

 DUSL FISHEYE は焦点距離が5.2ミリなので、口径1.93ミリ以上を確保するにはF値が2.7未満でなければならない。現実の DUAL FISHEYE はF値が2.8〜16なので、足りていない!
 とは言え、F2.8 で撮影すれば「ほぼ足りている」とは言える。ピクセルシフトでは色情報も揃うことを考えれば、現在入手できる実写VR撮影機器で唯一、肉眼並の分解能で記録可能なものとなりそうだ。その場合、絞りは必ず開放にすること。
 どうせ三脚に据えて静止画でしか実現できないのであれば、スライダー上でカメラを左右に移動させて2回撮りできる状況下に限り、DUAL ではない通常の円周魚眼で撮影した方が画質は上がるだろう。ただ残念なことに、いま RF マウントの円周魚眼は発売されていない。

 この理論限界があるため、コンデジタイプのVR撮影機器で肉眼並の分解能を得るのは困難である。
 よくある1/2インチセンサーの場合、円周魚眼レンズの焦点距離は1.5ミリぐらいしかない。これで口径を1.93ミリより大きくしようとすれば、F値が1よりかなり小さくなる。通常のレンズではなく円周魚眼レンズの場合、そこまでF値を小さくすることは困難だ。コンデジタイプでも豪華版なら1インチセンサーを積んでいるが、それでもかなりキツい。

written by higashino [Virtual Reality] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2022年7月25日(月) 23:59

レガシー3Dビデオカメラ

 久しぶりに登場した、3Dカメラ。

 VR360 系やたまに VR180 3D を発売している KanDao の Qoocam EGO である。VRではないレガシー3Dのカメラはもう発売されないものと諦めていたのだが、クラウドファンディングで蘇った。3Dは徹底的に失敗している一方で、自分のような根強い支持者も確実に存在する。
 WEEVIEW を1〜2周り大きくした見た目だが、画角はまったく違う。

 WEEVIEW は VR110 という感じの製品で、110度ぐらいの視野角を持つ。スマホ用簡易VRゴーグル(ヘッドトラッキング無し)で鑑賞するのにベストな動画を記録する。1000円ぐらいで非常にリアルなVR映像を鑑賞できる。残念なことにコンセプトに性能が追い付いておらず、画質が余りにも酷い。だから、使わなくなった。
 青空を入れたら白トビして気分が壊れるし、スポットライトにも対応できず主要被写体真っ白。解像度もスペックを遥かに下回る実質。

 これに対し Qoocam EGO はかなりマシになっている。サイズなりの画質であって、R5C と比較するのは可哀そうである。だが、活躍の場はありそうだ。
 繰り返すが、Qoocam EGO はVRとは関係がない。10年ぶりに登場した、レガシー3Dカメラ。さすがに10年間の技術進歩は反映されていて、fullHD ×2を60p で記録できる。10年前は 30p や 60i はあったが、60p は無かった。これが、初めてだ。記録ビットレートも 60Mbps あるので、十分に高い。そして、長時間撮影してもファイルの保存に苦労しない程度には低い。
 ステレオベースが65ミリ確保されているのも、レガシー3Dビデオカメラでは極めて貴重。

 弱点としては、一部を除いてフルオートしかない。しかしダイナミックレンジが狭過ぎてフルオートが欠点にしかならなかった WEEVIEW と異なり、明暗差が大きく変化する長回しにおいて露出調整に苦労しなくていいメリットにもなる。
 R5C + DUAL FISHEYE はシャッター速度をオートにできないために、露出オートで対応可能な明暗差に限界がある。室内と屋外を行き来するような長回し撮影には対応困難なのだ。しかし Qoocam EGO なら気にせず撮れる。R5C はシネマEOS であり、シネマカメラに囚われている。シャッター速度をオートにできないというのは、場合によって極めて致命的な弱点になり得る。

 画質ではどう頑張っても R5C には遥かに及ばないので、メリットを生かせる状況として3Dブイログ的なものになる。

 軽量を生かして、ジンバル搭載で歩きながらの撮影がいい。
 R5C + DUAL FISHEYE をジンバルに搭載すると重量があり、歩きながらの長回しは辛い。しかし、Qoocam EGO なら負担にならず長回しできる。室内と室外を出入りしたり、日向と日陰を出入りしても、フルオート任せで良い。ファイルサイズも手頃。車載動画ならぬ街歩き動画。

 この街歩き動画も WEEVIEW でやりたかったが画質の酷さで断念したのだ。
 Qoocam EGO も画質は悪いが、ドライブレコーダーならぬウォーキングレコーダーとしてなら許容範囲である。

 実は Qoocam EGO はAFではない。何段階かのフォーカス距離から手動選択する。これも、ウォーキングレコーダーの場合なら障害ではない。

 3Dと言えば立体感が問題にされがちだが、立体感が弱くなる5メートルや10メートルでも十分に意味はある。肉眼は距離情報を両眼視差にかなり依存していて、立体感が弱くても3Dの方が圧倒的に現実感が上になるのだ。
 街歩きの長回し撮影映像なんて、2Dで鑑賞してもつまらない。3Dならでは現実感が極めて貴重である。

 しかし3Dは高画質撮影できる機材が無いし、高画質鑑賞できる再生装置も無い。だから記録映像として、2Dで済む場合は2D撮影を優先させざるを得ない。ここが3D最大の難点だ。被写体を選ぶことになる。
 それほど高画質でなくても良い、なら3D優先で撮りたい。

written by higashino [Virtual Reality] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2022年7月22日(金) 21:01

ままならない

 どうも、やらかしたらしい。
 1日中インターネット固定回線がやたら遅くて使い物にならなかったのだが、たぶんモデムの熱暴走。
 ネット接続用モデムってやたら熱くなる。埋もれてしまうと熱暴走し易い。ただでさえ暑い季節は要注意だ。モデムの周囲は整理しておかないとマズい。
 だけどモデムの発熱が多過ぎる。消費電力が多いという意味でもある。ムーアの法則が死んだ近年は、各種電子機器の消費電力が低下しなくなって困ったものだ。

 さて、位相限定相関法を GPU により高速化する試みは、ひとまず断念することにした。労力が膨大過ぎてペイできそうにない。
 収束の繰り返しを最大3回に限定することで処理時間を短くし、妥協することにした。繰り返しを更に増やしても、効果が怪しい。phaseCorrelate() がサブピクセルの計算をどうやって行っているのか不明だが、本来1ピクセル単位でしか分からないものを最小二乗法などで推測しているのだとすれば、0.1ピクセル未満まで煮詰める意味がどこまであるのか分からない。実際の動画に適用しても、見分けが付かない。

 試行錯誤した結果として、速度は大雑把に
CUDA > OpenCV > cupy > numpy
だと判明している。
 OpenCV の関数に対応する関数が CUDA に存在する場合は、CUDA で高速化できる。
 numpy は cupy で高速化できるが、それでも OpenCV より遅いので意味がない。OpenCV で記述できず numpy で書くしかない場合のみ、cupy の意味がある。
 将来の CUDA に phaseCorrelate() が登場するまでは、OpenCV を使うのが最速。
 回転不変位相限定相関法の場合は、更に warpPolar() も CUDA 対応になるまで GPU はお預けだ。

 GPU に関しては結論が出たので、手ぶれ補正の検証を進める。
 収束3回限定の3軸手ぶれ補正は、念のためスカイツリー動画で効果を確認する。見た目で変わらないなら、計算時間を節約できるということで本採用。
 それとは別に、本来なら三脚を使いたい固定位置での手持ち撮影映像に対する3軸手ぶれ補正プログラムの修正だ。これは、基準フレームを先頭フレームに固定するもので、最大3回までの収束を行う方式の効果を確認してみる。動きの少ない部分を切り出しての2軸手ぶれ補正は効果大だと判明している。計算時間を余分に使用しての3軸手ぶれ補正にすると効果がどうまるか?だ。

 基準フレームを毎回更新すると、誤差が積み重なるので移動平均を取らねばならない。基準フレームを固定すると誤差は積み重ならないが、変化量が大きくなって推測精度が落ちる。そこに、収束3回繰り返しで精度を補ってやる。
 3軸補正は回転を加わるため、画面の広い範囲を対象にしないと判定が怪しい。2軸補正なら動きが小さく判定し易い一部だけを対象に判定することができる。だから、必ずしも3軸が常に有利というものではない。いろいろな状況の動画が蓄積されて来て、実験には不自由しない。
 計算時間が長いことだけが、障害だ。

 基準フレーム固定だと、判定ミスによる微振動が発生した。やはり3軸判定は基準フレームを毎回更新して移動平均を取るしかない。完全に画面を固定したい場合は、そうやって得た回転角補正だけを使い、残る2軸は慎重に選んだ画面の一部を対象にした2軸補正を使うのが良さそうだ。

written by higashino [Virtual Reality] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2022年7月21日(木) 21:30

工夫が足りぬ?

 ソフトウェア手ぶれ補正のクローズドループ打ち切りだが、最終的な鑑賞の結果として有意差を認めされなかった。
 計算時間の多さを考えると、収束計算は3回決め打ちで打ち切っても良い気がする。それが、性能とコストの良いバランスだと感じる。
 そしてその補正を行うと、慎重に歩きながら手持ち撮影した映像は何とか使用可能レベルに仕上げられそうだ。カメラのパンを最小限で済ませられる状況を選び、補正し易そうな映像内容を選ぶという条件は付くが、これはこれでかなり強力な武器になりそうだ。

 いっぽうアクションカメラとして使うのは無謀だとも判明。
 魚眼の画角が190度では、補正量が全く追い付かないのだ。どうにもならない。慎重ではなく普通に歩きながら手持ちで撮るとか、走りながら撮るとか、アクションカメラとして使うとか、そういう状況では手ぶれ補正のために数割の余裕が必要だと思われる。VR180 ならば、数度ではなく数十度の補正余地が必要だ。つまり、事実上ジンバルを使うしかない。
 R5C で 8K60p 撮影しようとすれば、外部電源が必要である。その場合、ジンバルに載せるのは実用にならない。映画スタジオで撮影するのなら別だが。ところが、ここに抜け穴がある。そもそも DUAL FISHEYE は絞りしか電子制御に対応していない。それ以外は基本的にMFレンズである。外部電源無しで 8K60p を撮ろうとすると、レンズの電子制御が全く効かなくなるが撮れないわけじゃないのだ。

 外部電源が無いと最小絞りになってしまうが、外部電源を取り付けて希望の絞り値に設定し、カメラの電源を落とさずに外部電源だけ外す。するとレンズは制御できなくなるが、絞りは動かない。これで、絞りを設定できる。後はそのままジンバルで撮れば良い。
 内蔵バッテリーでは短時間の撮影しかできないが、手持ちジンバルで長時間の撮影など、どうせ重量的にこれまた実用にならない。

 5D2 が登場した当初を思い出すが、制約だらけなら運用で何とかしようと工夫すれば良い。動画がオートでしか撮れなかった初期の 5D2 では、電子接点にセロテープを貼ったりしたものだ。DUAL FISHEYE も外部電源引き抜いたり、ソフトウェアで手ぶれ補正したり、工夫の余地はいろいろある。

 さて、ステッチの GPU 化だが、倍率色収差を補正できるようになった。だが、アンシャープマスクを忘れていたことに気付いた。これもまた GPU 化を頑張ったものの、うまく行かない。論理的にありえないことが起きていて、解決が見えない。
 アンシャープマスクを GPU で処理できたとしても時間短縮効果はそれほどでもなく、CPU 任せにすることにした。元動画ファイルを読んだり処理結果を書き込む I/O 時間が圧倒的に長いので、頑張って何とかしても労力に見合うような効果は恐らく得られない。

 アンシャープマスクは従来通り CPU で処理することにして、手ぶれ補正ありでのステッチは毎分53フレームぐらいまで速くなった。当初の3倍速を超えたので、妥協点だろう。速度のネックは I/O なので、ここから劇的に速くするには品質を犠牲にすることになる。

 こうなるといよいよ、位相限定相関法が GPU で著しく遅くなる問題だ。

written by higashino [Virtual Reality] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

2022年7月20日(水) 21:17

CUDA でレイヤー分離と結合

 アクションカメラっぽい使い方での撮影を試してみた。手ぶれが極端に激しい場合に、ソフトウェア手ぶれ補正がどこまで機能するかを確認するためである。
 あれこれ問題が噴出しているのに撮影を進めなくても良さそうだが、撮るものは撮れるときに撮っておかねばならない。特に天候は、ままならない。
 計算時間が掛かり過ぎるのは問題だが、短時間のクリップになら現状でも適用可能である。ならば、適用して改良するのもまた意味はある。

 手ぶれが激しい映像に適用すると、すぐに問題が発覚した。まっとうに収束せず繰り返しループ内で無茶苦茶な推測値が続出したのだ。

 その余りに無茶苦茶な数字を眺めているうちに、気づいた。そうだ、異常値の判定は簡単じゃないか?
 ズレ量を推測し、その推測した値だけフレームを逆変換する。推測値が正確なら、逆変換後のフレームとのズレ量はゼロになる。ゼロにならなかったら、差を前の推測値に加算することで推測値をより正確にできる。これが基本アイデアだ。だが、推測はあくまで推測であり、不適切な推測値が出ることは珍しくない。どのような条件で異常値だと判定するかは、悩ましい問題だった。
 だが、推測値をフィードバックしてのクローズドループで収束を狙う場合、簡単だ。収束している場合、通常はループを回すごとにズレ量は小さくなる。1回前のループよりもズレ量が大きくなったら、不適切な推測が行われたと判定すれば良い。

 回転や拡大に関しては、異常な値を拝んだことがない。ほぼ問題はX軸Y軸の推測値だけで発生している。
 そこで、XズレとYズレの2乗加算を取り、それが1回前より大きくなっていたらループを打ち切ることにした。そして、1回前までの加算結果を採用する。
 ベンチマークに使っているスカイツリーのクリップと、今回アクションカメラ的に激しく手ぶれしているクリップと、その両方で試してみる。
 相変わらず膨大な時間を要するので、今日中に結果は出ない。その重い処理をしていて、GPU 使用率が0%のままというのが悲しい。

 だが、あれこれ手を広げ過ぎて手に負えなくなりつつあるのも確かだ。ここは、片付けられるものを1つずつ片付けよう。
 GPU 関係でいま最も解決に近いのが、ステッチである。位相限定相関法も極座標変換も登場せず、既に GPU により一部が高速化できている。numpy はなぜか遅いが、OpenCV は GPU 化で速くなっている。ステッチで残っているのは、倍率色収差低減部分の GPU 化である。RGB 配列の違いがあるので、うっかりすると別の色を補正してしまう。また、プログラムの記述自体も少し特殊らしい。
 完成一歩手前まで来ているが、慎重に作業せねばならない。

 静止画のステッチを使って動作確認し、これは何とか成功した。重要部分だけ↓

g_src = cv2.cuda_GpuMat()
g_dst = cv2.cuda_GpuMat()
im_bgr = cv2.cuda_GpuMat()
img_red = cv2.cuda_GpuMat((4096,5464), cv2.CV_8UC1)
im_dst = cv2.cuda_GpuMat((4096,5464), cv2.CV_8UC3)
 ・・・
g_src.upload(img_right)
im_bgr = cv2.cuda.split(g_src)
M = cv2.getRotationMatrix2D((CRX, CRY), 0, MAG_RED)
img_red = cv2.cuda.warpAffine(im_bgr[1], M, (int(width/2), height), flags=WARP_FLAGS)
cv2.cuda.merge([im_bgr[0], img_red, im_bgr[2]], im_dst)
g_dst = cv2.cuda.remap(im_dst, cuxmapR, cuymapR, interpolation=WARP_FLAGS)
right = g_dst.download()

 ややこしいのはレイヤーごとの分割と合体である。特に merge は格納先 im_dst をサイズと型指定で用意しておかないといけない。

written by higashino [Virtual Reality] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

<< 前のページ

Darkside(https対応しました)

Generated by MySketch GE 1.4.1

Remodelling origin is MySketch 2.7.4