Darkside(https対応しました)

<< 前のページ

2022年6月24日(金) 21:13

必要リソース過大

 いろいろいじくって、分かった話。

■魚眼のピント
 円周魚眼より更に短焦点な DUAL FISHEYE をF8.0 あたりまで絞ればもうパンフォーカスも良いところ。近距離人物を撮るなら別だが、1〜2メートルにピントを合わせておけば無限遠までピント合ってるでしょ・・・と思い込んでいたがそれほど甘くない。実際の DUAL FISHEYE はガチピンの範囲が想像より遥かに狭い。
 更にVRの現状として、近景は解像度不足を感じ難く、遠景になるほど解像度不足を感じる。よって、拡大表示とピーキングを駆使して遠景にガチピンを合わせるべきだ。
 解像度が足りないVRでは、解像度が既に充分である通常の写真とは、ピントの考え方を変えねばならない。

■シャープネス
 モニター鑑賞の場合はシャープネス不要と思うければ、VRゴーグルは事情が異なる。肉眼に対して解像度が悲惨なまでに不足しているため、何でもかんでもピンボケて見える。そのため、アンシャープマスクはほぼ必須。ノイズが多い絵では回避した方が良いけど、原則としては常にアンシャープマスクでいい。印刷する場合と同様。
 もちろん、アンシャープマスクは画像処理の最後に掛ける。自作ステッチソフトに、アンシャープマスクを組み込んだ。

■ソフトウェア手ぶれ補正
 歩きながら撮った映像でも、回転まで判定する3軸手ぶれ補正は意外に効く。これは、適当な映像を撮っての比較動画を作りたい。通常の動画でソフトウェア手ぶれ補正の効果をデモする比較動画は見掛けるが、それをVR動画でやるのだ。魚眼レンズで撮影する場合に電子式手ぶれ補正は使えないと思い込んでいる者(カメラメーカーも)が多いので、面白いかもしれない。
 撮影後の映像のみで処理するため、効果は映像次第で異なる。処理しようがない映像もある。

■SKYBOX
 Quest 2 でVR動画を観る場合に、SKYBOX を愛用している。しかし、性能を引き出すのに設定が重要だ。
 全体設定メニューの解像度スケールを、必ず2に設定すること。

 この2〜3ヶ月あれこれ頑張ってVR動画を仕上げたが、ギリギリで仮想現実を味わえるという品質に達したと感じている。Youtube VR の画質は論外だが、6Kエンコードして Quest 2 で楽しむならば、ほぼ撮影当時の臨場感を再び味わえるようになった。そのために DUAL FISHEYE ほどの機材を必要とし、ゲーミングパソコンと呼ばれるレベルのパソコンを長時間駆使し、それでも「画質に不満は残るがギリギリ及第点か?」という所にしか到達できない。
 必死で残した映像の価値は認めるけれど、一般に実写VRが普及するかと言えば思い切り疑問である。さっさと VR180 3D に見切りを付けた Google は酷いと感じつつ、なぜ駄目なのかも分かっているんだろうなとは思う。

 必要リソースが同じ VR360 が大丈夫なのは、3D ではないために従来の2D鑑賞環境でも活かせるからだ。従来の2D鑑賞環境であれば、解像度不足が問題にならない。

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

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

2022年6月20日(月) 21:23

Python クリーンインストール

 OpenCV で GPU を使う魅力は強烈なので諦め切れず、Python 仮想環境にインストールしてみることにした。すべての環境において OpenCV で GPU を使いたかったので仮想環境は使わなかったが、仮想環境に入れればインストール失敗しても通常環境では OpenCV が使える(GPU 非対応だが)。
 失敗時に再インストールしなくて済むのはメリットだ。

 しかし仮想環境に入れようとしても、全く同じエラーにより GPU 対応版 OpenCV は動かなかった。


 頑として、このエラーは消えない。そればかりか、通常環境の OpenCV まで同じエラーが出るようになって動かない。

 そこで Windows において、手早く Python + OpenCV の環境(GPU使わない)を復活させる手順をまとめておく。慣れれば5分で復活できるので、インストールが失敗して OpenCV が動かなくなっても、すぐ動く状態に戻せる。そうなると、GPU対応 OpenCV のビルドにもダメ元で挑戦し易くなる。
 ひとまず断念するが、仮に将来これまで試したのと別パターンの方法が引っ掛かれば、試してみたい。何と言っても、OpenCV が GPU を使わないのは酷過ぎる。それでも静止画 VR180 3D のステッチぐらいであれば軽いので、10年前のパソコンでも快適に動作する。これはこれで、かなり重宝する。

 基本手順は、金子邦彦研究室のサイトに従う。
1)コントロールパネル→プログラムの機能、から Python をアンインストール。
2)Python ディレクトリを削除。
3)Windows installer (64-bit) にて Python をインストール。
4)numpy あたりまで関連パッケージをインストール。

 仕上げに、OpenCV を入れ直す
5)Python 用 opencv-python のインストール(これだけ)。

 GPU 対応版 OpenCV をインストールしようとすれば、仮にエラーが出ずすんなり終わる場合でさえ、数多くの手順を経た上で何時間もコンパイルすることになる。
 それに対し GPU 非対応の OpenCV は、

python -m pip install -U opencv-python

と、たった1行打ち込むだけで全てが完了するのだ!
 使える GPU があればそれを使い、無ければ GPU を使わない。そんな OpenCV が公開されていて1行打ち込めばインストールが終わる世界線に生きていたかった・・・
 何日も時間を溶かして、得た物は何も無かった。

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

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

2022年6月19日(日) 21:29

やり直しは可能

 エラーメッセージを手がかりにネットで前例を探すが、やはりというか問題は解消しない。
 そこで cmake の GUI 版を使い、Visual Studio プロジェクト生成からの 2022 起動してリビルド。これには何時間も掛かるのだが、その甲斐もなくエラーは解消しない。

 DLL の依存関係を調べてくれるツール Dependencies を使ってみる。ところが、実行可能ファイルを指定せねばならない。Python スクリプト中の import cv2 で発生している DLL を調べるには、どうすれば良いんだ?
 かなり悩んだが、site-packages/cv2/python-3.10/cv2.cp310-win_amd64.pyd を指定すると解析してくれた。しかし、関連する DLL は想像より遥かに多い。何百というか下手すると4桁じゃないのか?
 しかも使用する DLL を調べてくれるが、欠落している DLL はリストアップしてくれないようだ。膨大なリストをいちいち開かないといけない。開いたその一覧内に存在しない DLL があれば、指摘してくれる。開くまでは、指摘してくれない。こういう膨大な関連 DLL がある場合は、恐ろしく使いにくい。

 だが少なくとも、欠落している DLL が実際に存在することが明確になった。別途検索してみたが、ディスク上の、どこにも無い。
 ならば次は、この DLL はどうすればインストールされるのか?ということ。だが、どうしても分からない。残念ながら、ネットにも情報はない。

 Visual Studio の再配布可能パッケージは怪しいが、とっくに一揃い入れてある。

 試しに、VS2022 のオプションを変更し、余分に入れてみる。これまた、かなりの時間が掛かる。パソコンのトラブルは、際限なく時間を溶かしやがる。
 やはり、症状から解決策を提示してくれる人工知能が欲しい。使い物になるエキスパートシステムが欲しい。
 その後も試行錯誤したが、どうやっても import cv2 できない。

 諦めて、OpenCV ではなく Python から再インストールし直す。ちゃんとアンインストールから始める。すると、無事に復活した。もちろん GPU は使用されないが。ともあれ、最悪の事態は避けられたし、Python からやり直すのも GPU を諦めれば短時間で可能。こうなると、リトライもアリだ。
 OpenCV を入れ直してもエラーが解消しなかったが、Python から入れ直せば解消した。ということは、Python さえ入れ直せばネット情報の手順で GPU 対応 OpenCV を正常にインストールできる可能性はある。

 Ubuntu はOSと Python が不可分であるので、Python から入れ直すというのはOSのクリーンインストールを意味する。Python だけいじくっても状況が悪化するばかりで、どうにもならない。
 しかし Windows はOSと Python が独立なので、OSの再インストールなどしなくても Python だけ入れ直せば大丈夫。これは、Ubuntu に比べて比較にならないほど楽だ。

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

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

2022年6月18日(土) 21:43

最悪だ

 OpenCV + CUDA をインストールして GPU が活用されるようになった、と思い込んでいたのだが、タスクマネジャーの表示で GPU が使われていないことに気付いた。
 DaVinci Resolve では、ちゃんと GPU が使われていると確認できる。

 単に CUDA を入れただけでは駄目で、GPU を有効化した OpenCV をビルドしないといけないのかもしれない。
 方法は Jetson Nano だと簡単に見つかるが、Windows でやる例は少な目だ。
 こういう時に頼りになるのが、金子邦彦研究室のサイト。Jetson Nano でもかなりお世話になっている。他のサイトに比べると、手順通りにやったのにエラーが出る頻度は少ない。ただし今回は、エラーが出る。

-S /usr/local/src/opencv -B /usr/local/src/opencv/build

という感じに cmake のオプションを追加し、ソースの path とビルドの path を明示的に指定する必要がある。
 こうして無事に OpenCV のビルドとインストールが終了したものの、いざ Python を実行すると import cv2 でエラーが出る。正常にインストールできていない!
 そればかりではなく、cv2 を使うプログラムが動かなくなった。最悪の場合、ビルドせず OpenCV をインストールすることで GPU が使えない版に復活させることはできるが・・・

 仕方なく、Python のインストールから全部やり直すことにした。
 ○○が無い、という類のエラーが出て実行できない場合、無いと言う○○を入れてエラーを解消させようとしてもまず無理である。Linux 系では嫌というほど実感させられている。OpenCV のソースコンパイルなんてのは Windows であっても完全に Linux の世界と同じで、エラーを消そうと格闘するよりクリーンにやり直す方が速いに決まってる。
 ところが作業途中でふと気付くと、知らない間に勝手に DaVinci Resolve が終了してやがる!

 20時間近く掛かりそうなエンコードの最中だったのに!

 膨大な時間が掛かるエンコードは本当に困りもので、その途中のトラブルでいつ止まるかも分からない。
 エンコードだけさせて裏で何もできない、などという時間を20時間も確保できるほど暇じゃないんだよ!
 いや、そこに文句を言う前に、いつまで経っても DaVinci Resolve は不安定過ぎる。エラーも出さず「ただ突然終了する」のは止めてくれ!

 もっと前の話をすれば、OpenCV がデフォルトで GPU を活用してくれれば何も問題無い。なぜ大変な苦労をしてソースコンパイルしないと GPU を使ってくれないのか?
 そこが、諸悪の根源だったりする。

 ところが、諦めて GPU を使わない普通の OpenCV をインストールし直しても、エラーが解消されない。
 うわっこれまさに Linux で散々起きたパターンやん。環境が壊れると、延々とエラーが居座り続ける。

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

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

2022年6月16日(木) 21:24

実は別窓でも同じ

 DaVinci Resolve とコマンドプロンプトを裏で2並列、ぐらいがリソースを活用するのに良い感じである。余り干渉することもなく、それほど遅くなることもなく、動いてくれる。うまくタスクを割り振ると、効率的にエンコードやステッチができる。
 だが、物理ディスクの同時アクセスはマズい。著しく性能が低下する。こういう場合に均等に遅くなるのではなく、犠牲になるタスクが集中する。Windows のマルチタスクは、ディスクI/Oの均等化は行ってくれないようだ。

 ところが、そのうちにエラーダイアログが画面中央に浮いていることに気付いた。DaVinci Resolve が出しているようで、キャプチャーがタイムアウトした?
 ビデオキャプチャーなんて、実行していないのだが?

 ダイアログを消しても、立て続けにキャプチャーエラーが出る。こうなると、キャプチャーではなくエンコードだがドロップアウト発生の可能性がある。止むを得ず、エンコードを打ち切って DaVinci Resolve を終了させてみる。
 すると、異様に実行が遅くなっていた裏の Python が、快速で動き出した。この Python が DaVinci Resolve と同じディレクトリの連番 png を読み込んでいて、ディスクI/O が極端に遅くなっていたと思われる。

 多窓実行は概して機能するが、ディスクI/O が重複しないようにだけは注意が必要なようだ。ディスクI/O が競合するタスクは1つを残して終了させ、フルスピードでディスクアクセスできるようにする方が、結局は速い。まさに、急がば回れ。
 別窓でも時間が経つとこの現象が発生するということは、マルチタスクが失敗した理由も共通だと思われる。png 書き込みが遅いからと並列処理したら、複数タスクがディスクI/O を奪い合って激遅になった。ディスク書き込みに要する時間より png 圧縮の方に時間が掛かるので、それなりにディスクI/O は分散すると期待したがそうなってくれない。

 だったらSSD使えば?と言いたくなるだろうが、8TB×2でも不安があるほど容量使うのに、SSDはコスト的にも寿命的にも無理がある。寿命が長いが揮発性というメモリーが安く手に入ればいいのだが、昔存在したシリコンディスクは今やほぼ無い。揮発性メモリーの方が高価という、厄介なことになっている。

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