360度カメラの残念な現状

冬のスノーボードのために動画撮影用のカメラを買おうと思っている。今の所、GoProの次のモデルが発表されたら買うのを検討しようかと思っているのだが、360度カメラという選択肢も出てきた。しかし調べたところ、360度カメラの現状はあまりよろしくない。

360度カメラではカメラを中心に全周囲を撮影できる。これによって追い撮りするときに撮影対象を収めそこねたという問題を回避できるし、自分も周囲も同時に撮影できる。私の目的は思い出を記録しておくことだから、360度カメラはとてもいい選択肢のように思える。

360度カメラは2つ以上のレンズを使って撮影した複数の映像をつなぎ合わせることで実現されている。一般的な製品では半球レンズを2つ使って2つの動画を撮影してつなぎ合わせている。

撮影した生の映像は、半球レンズによって著しく歪んだ2つの動画にすぎない。このままでは見るに耐えないので、視点を固定し、その視点に合わせた現実的な狭い視野を模した動画の一部のみを再生することになる。そのための処理として、製品ごとに異なる独自のプロプライエタリなソフトウェアが必要になる。

まずstitchingを行う。撮影した複数の動画は境目となる部分を単に重ねただけでは継ぎ目が明らかになってしまう。撮影部分がオーバーラップしたり、撮影方向の違いによって当たる光の関係で映像の色温度が変わってくる。これをごまかすために、オーバーラップ部分を認識したり、継ぎ目をぼかしたり、色温度を調整したりといった処理が必要になる。複数の独立したカメラを使って手動で360度動画を作るならこれはすべて手動でやらなければならない。360度カメラのようにあらかじめカメラ特性が分かっているのであれば自動化も可能になる。そのためのソフトウェアはカメラベンダーが提供するプロプライエタリなソフトウェアとなる。GoPro MAXではstitchingはカメラ内で撮影時に行われる。

次にprojectionが必要になる。我々の視野は360度ではない。そのため視聴環境に合わせて動画を変形させなければならない。視聴環境が平面ディスプレイせよ、VRディスプレイにせよ、必要だ。この処理も事前にカメラ特性がわかっていれば自動化できるが、そのためのソフトウェアもカメラベンダーが提供するプロプライエタリなものになる。

360度動画に必要なものは規格化であるように思われる。stitchingはカメラ内で行えるが、projectionは処理量的にカメラ内ではやりにくい。その方法もまだ発展段階にあり混沌としている。projectionを規格化することによってカメラベンダーごとのプロプライエタリなソフトウェアの必要をなくしてほしい。

なぜこれを問題視しているかと言うと、プロプライエタリなソフトウェアが10年後に動作する保証はどこにもないからだ。しかも360度動画のprojection処理はGPUを使うのでなおさらだ。

LinuxカーネルにおけるGPLコンドーム問題への対処パッチ

最近、Linuxカーネルで話題になっていることに、GPLコンドーム問題がある。

Kernel Developers Work To Block NVIDIA "GPL Condom" Effort Around New NetGPU Code - Phoronix

発端はNetGPUと呼ばれる機能をLinuxカーネルへ追加するパッチだ。これはNICとGPUの間のデータ転送にDMA zero-copyにしてNICとGPUが直接やり取りできるようにしつつ、プロトコル処理自体はCPUに処理させるという機能で、GPGPUがますます汎用化してくるなかでGPUから直接ネットワーク越しにデータを転送する事ができるようになる。

ところが、NetGPUをNVIDIAドライバーに対応させるパッチとやら出てきて物議を醸している。NVIDIAのドライバーはプロプライエタリであり、LinuxカーネルのGPLシンボルを使うことができない。そこでLinuxカーネルとNVIDIAのプロプライエタリドライバーをつなぐ目的のためだけの薄いshimコードをGPLと称する手口が流行っている。これがGPLコンドームと呼ばれる問題だ。NetGPUがプロプライエタリなNVIDIAだけを利するものであれば、そもそもLinux上流に取り入れる意味がない。

その流れを受けて、GPLコンドーム問題に対処するパッチが出てきた。

Linux 5.9 Brings Safeguard Following NVIDIA's Recent "GPL Condom" Incident - Phoronix

これはGPLを称しながらプロプライエタリなシンボルを使うカーネルモジュールに対してもTAINT_PROPRIETARY_MODULE taintを付加するものだ。

GDBがeBPFのデバッグをサポートした

GDBがeBPFのデバッグをサポートした。

GNU Debugger Adding eBPF Debugging Support - Phoronix

eBPFというのはLinuxカーネル内の仮想マシンだ。

もともと、BPF(Barkley Packet Filter)という仮想マシンがあった。これはネットワークのパケットフィルタリングをするための仮想マシンで、レジスターベースのRISCプロセッサーを模した命令セットになっている。

カーネル内で安全にユーザーコードを実行するというのは需要があるので、BPFをより汎用的に使いたいという声は多かったのだが、何分BPFは設計が古い。レジスタは2個で32bit、命令セットはatomic compare exchangeのようなモダンなプロセッサーに搭載されている命令がない。

そのためeBPF(extended BPF)が設計された。レジスタは10個で64bit、命令セットもモダンなプロセッサーにマッピングできるように見直された。

キャスターボード

かねてから気になっていたキャスターボードを買った。今回買ったのはRipStik Air Proだ。

キャスターボードは一見するとスケートボードに似ているが、スケートボードではない。スケートボードは板の下に二輪ずつのウィールが前後に付いているものをいう。キャスターボードは、前後に1輪づつしかついていない。しかもウィールはキャスターにつながっていて、回転する。このキャスターは水平に対して30度ほど傾けて取り付けてある。

キャスターボードの元祖は韓国で発売されたEssBoardであるといわれている。その後、アメリカでRazorがRipStikという製品を出してから有名になった。オリジナルのRipStikは板が2枚あり、その間をトーションバーでつないでいる。その後、一枚の板でトーションもきく製品が発売された。今回買ったRipStik Air Proは1枚板の製品だ。

さっそく乗ってみたが、意外と簡単だった。スノーボードの経験が効いているものと見える。筋肉の疲労具合もスノーボードと似ている。スノーボードのオフシーズンのトレーニングに丁度いい。

キャスターボードはトーションをきかせつつ前後の足を互い違いに動かすことで進むことができる。また、腰のツイスト運動で進むこともできる。どちらもひねり運動の一部を前進運動に変換しているようで、スケートボードのキックターンと同じだ。ただ、ひねり運動から前進運動への変換には極めて低い上限があるらしく、ある速度を超えるとひねり運動が過剰になるだけで前進速度は少しも上がらなくなる。

運動負荷も高い。私は片足スクワットができる上に9kmのジョギングもできるし毎日6kmほどキックスクーターで移動している。それでもキャスターボードでは数百メートルも進むと後ろ足がパンプする。キャスターボードを始めてから一ヶ月ほどすると、筋持久力は上がってきたのだが、今度はヒザに違和感が出てきた。痛みと言うほどではないがかゆみがある。そのためヒザの調子を見つつトレーニングしている。できれば週に2回はトレーニングしたいのだが、ヒザの回復を待つために週に1回ぐらいしかできていない。

キャスターボードの構造上、スイッチができない。動画ではウイリーやオーリー、360といったトリックができるようだが、とてもできるようには思えない。

最近は板から降りずにレギュラーとグーフィーの両方で1km進むことができるようになった。

キャスターボードは後輪ウィールの消耗が激しい。RipStick Air Proには76mmのウィールがついているようで、インラインスケート用のウィールと同じものなので硬度の高いウィールを注文した。ベアリングも安いものを注文したが、いずれスケートボード用のオイルベアリングを試してみてもいいかも知れない。