Darkside（https対応しました）

　久しぶりに登場した、３Ｄカメラ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　だが、あれこれ手を広げ過ぎて手に負えなくなりつつあるのも確かだ。ここは、片付けられるものを１つずつ片付けよう。
　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 をサイズと型指定で用意しておかないといけない。

　numpy を cupy に書き直したが、不穏な警告が出る。

UserWarning: cuFFT plan cache is disabled on CUDA 11.1 due to a known bug, so performance may be degraded. The bug is fixed on CUDA 11.2+.
cache = get_plan_cache()

　をいをい、GPU 有効化した OpenCV は import 出来ずに苦しみまくり、ようやく少し古いバージョンの決め打ちで使えるようになったってのに！
　こともあろうか、CUDA 11.1 がバグでアウトだと！？

　最小二乗法の GPU 対応化がうまく行かず、その直前までの処理で実行時間を測ってみる。何と、正味の位相限定相関法だけで１．７５秒も掛かっている。cupy を使うことで、numpy より遅くなっている。もちろん OpenCV 関数との差は広がるばかり。これでは、最小二乗法を GPU 対応できたとしても無意味。
　新しい CUDA で OpenCV をビルドし直したら、速くなるのだろうか？
　それ以前の問題として、新しい CUDA でビルドし直した OpenCV は動くのだろうか？

　ひたすら前途多難である。なぜ CUDA に phaseCorrelate 関数が無いんだよ！
　現状は、phaseCorrelate 関数が余りに遅いので GPU を有効にしようと頑張ったけど、意味ありませんでした・・・である。いや、ここは冷静に考えてみよう。余りに酷い目に遭いまくってるせいでキレちゃったが、さすがにおかしい。位相限定相関法の正味の処理は、それほど長いコードではない。

img_f1 = np.fft.fft2(img_g1)
img_f2 = np.fft.fft2(img_g2).conjugate()
img_f = img_f1 * img_f2
img_n = img_f / np.abs(img_f)
img_p = np.fft.ifft2(img_n).real
img_p = np.fft.fftshift(img_p)

　この部分を cupy に置換したら実行時間が１倍半を超えるなんてのは、幾ら何でもおかし過ぎる。かなり大きな行列であり、GPU への転送オーバーヘッドを考慮しても変だ。ここは CUDA11.1 のバグをまずは疑うべきだ。
　CUDA11.7 を使用するよう（そこだけ）パラメーターを変えて OpenCV をビルドし直す。エラー無くインストールできた。cupy も 11.7 対応を入れ直す。結果は・・・１．４７秒に高速化された！
　駄目じゃん、まだ numpy より遅いじゃん。