Darkside（https対応しました）

　ソフトウェアIBIS は、残念ながら手元の動画では逆効果だった。魚眼という特殊な歪み画像では、的確な手ぶれ成分の認識が困難と思われる。

　更に、問題が他にもいろいろ発覚している。
　スカイツリーの近くで撮ったのだが、非常に異常がわかり易かった。スカイツリーの先端が左右にズレていて、つまりは無限遠じゃない。左右映像の間隔はしっかり確認済みだが、切り出し座標が不適切だったようだ。改めて、左右魚眼それぞれの中心座標を調査し計算し直す。

　次に OpenCV で Cineform を読むとき、YUV10bit だとフルスケール出力が正常に認識されない。ビデオレベルとみなされるようで黒潰れ白飛びになってしまう。おかしい。YUV10bit でも正常にフルスケールが読めていたはずなのに、どうなった？
　データーは膨れるが、RGB16bit で出力すれば問題ない。CineForm に限らず、over 8bit によるRGB出力すれば、フルスケールとビデオスケールが取り違えられることは無さそうだ。

　更に、OpenCV の png 書き込みが、異常に遅い。情報量の多い画だと、以前の測定値の何倍も時間を食う。無圧縮形式の画像なら高速に書き込めるが、それだと Davinci Resolve で読めない。
 pillow を試したが、更に遅くなっただけ。
　圧縮率を最低にすると、ファイルサイズはそれほど変わらずに相対的に速くなる。それでも充分に遅いが。
　元はと言えばステッチが遅過ぎるので OpenCV + CUDA で高速化を図ったのだが、それが成功したら結果的に画像処理系ではなく単なる画像の書き込み時が遥かに遅いというオチに。

　ただし、OpenCV に任せたことにより、左右映像の合体なども済ませておけるようになった。最終的に DaVinci Resolve では左右映像と音声の合体を行って最終エンコしていたが、今後は映像と音声の合体を行って最終エンコってことになる。合体処理が不要になったことで、DaVinci Resolve の消費リソースも減るはずだ。最終エンコばかりはタイムラインを８Ｋにせざるを得ないので、リソース不足で落ちる可能性を減らすことは重要だ。

　でもどうせなら、最終エンコまで OpenCV で出来ないだろうか？
　そうすれば、なぜか超絶に遅い png 書き込みが不要になる。
　OpenCV で mp4 をまっとうな画質で出力することが出来ていなかったが、FFmpeg をパイプラインで使うという記事を発見。
　これならば、単体の FFmpeg さえ動作する環境なら最終エンコが出来る！
　・・・いや、音声どうするかって問題が残っているのだが。

　しかし試したところ、scikit-video の時の症状

とそっくりな出力となり、失敗に終わった。