2022年7月20日(水) 21:17
アクションカメラっぽい使い方での撮影を試してみた。手ぶれが極端に激しい場合に、ソフトウェア手ぶれ補正がどこまで機能するかを確認するためである。
あれこれ問題が噴出しているのに撮影を進めなくても良さそうだが、撮るものは撮れるときに撮っておかねばならない。特に天候は、ままならない。
計算時間が掛かり過ぎるのは問題だが、短時間のクリップになら現状でも適用可能である。ならば、適用して改良するのもまた意味はある。
手ぶれが激しい映像に適用すると、すぐに問題が発覚した。まっとうに収束せず繰り返しループ内で無茶苦茶な推測値が続出したのだ。
その余りに無茶苦茶な数字を眺めているうちに、気づいた。そうだ、異常値の判定は簡単じゃないか?
ズレ量を推測し、その推測した値だけフレームを逆変換する。推測値が正確なら、逆変換後のフレームとのズレ量はゼロになる。ゼロにならなかったら、差を前の推測値に加算することで推測値をより正確にできる。これが基本アイデアだ。だが、推測はあくまで推測であり、不適切な推測値が出ることは珍しくない。どのような条件で異常値だと判定するかは、悩ましい問題だった。
だが、推測値をフィードバックしてのクローズドループで収束を狙う場合、簡単だ。収束している場合、通常はループを回すごとにズレ量は小さくなる。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)]
Generated by MySketch GE 1.4.1
Remodelling origin is MySketch 2.7.4