はじめに
先日、下記のくだりを X で呟いたところ、思いのほかのプチバズり状態となり驚きました。
動き探索などが良い例で、1フレームで100ピクセル移動されると、100x100で10000ピクセルの範囲を検索しないといけないが、フレームレートを100倍にすると、1フレームに1ピクセルしか移動しないので 3x3 の 9 ピクセルの範囲を100回探索すればよく、900ピクセル分の計算で済む。
— Ryuji Fuchikami (@Ryuz88) 2024年11月1日
内容自体はもちろん私が最初に発見したわけではなく、少なくとも東京大学の石川グループ研究室さんなどでは遥か昔から主張しておられた内容かと存じています(なお、ツイートで「100ピクセル動くなら探索範囲は 201x201 では？」というツッコミはその通りの私のポカですｗ)。
とはいえ、恥ずかしながら、私は高速度カメラとかを扱いつつも、しばらくこの分野で非常に有名な石川研究室さんを知らないまま開発をやっておりましたので、モグリと言われてもまあ仕方がないかなと思っております。
一方で、私の名前が入っている特許とか論文とか眺めて頂くと、リアルタイム・ハイスピードビジョン的な事もいろいろやっていた人間というのはなんとなくわかって頂けるのではないかと思います。
そこで転職したのを機に、少し 公知の内容 と 技術一般論 で語れる範囲で少し触れてみたいと思います (なお、LUT-Network は過去も今もお仕事とは無関係な私の趣味の産物なので、こっちは自由に語ります)。
私の方はあくまで 計算機科学 に軸足を置いて、リアルタイムコンピューティングの観点から画像処理応用でこの領域に踏み込んでおりますので、少し違った視点からお話しできる点もあるのではないかと思います。
ダイナミクスに対して十分なサンプリングレートにすると起こること
まずはツイート含めて一般論(というか先人の成果)の復習です。
上の動き探索の例などがまあいい例と思いますが、例えば OpenCV の cv::matchTemplateなどで SADやSSDなどである意味力業で行う探索において、上の理屈は非常によく当てはまります。
また、X に書いている通り、移動量が1ピクセル以下程度になってくると、例えば OpenCV の オプティカルフロー とか、例えば Lucas-Kanade法 などを使うものなどが 画像ピラミッドなど作らずにそのまま機能するようになっていく事が想像頂けるのではないかと思います。 マッチングによる探索が微分という計算に変わる瞬間で、これは時間方向に十分情報密度が出てきて、時間方向に十分連続性をもった信号として取り扱えるようになったために起こる現象です。
現実世界では、自動車でも、ドローンでも、固定監視カメラでも、何でもよいですが、「車は急に止まれない」という話の通り、撮像対象やカメラ自身に起こりうる最大の加速度に対して起こりうる変化量を限定して考えることが出来るケースは多々ありますので、「一定制約下で移動量が1ピクセル以下になるまでフレームレートを上げれば別のアルゴリズムが適用できる」などということは十分に実用的に設定可能な条件です。
また、ここで、「移動量が1ピクセル以下」と書いたのは例でしかなく、実際には 予測不可能な変化量 が一定範囲に収まるようにすることが重要です。
（しばしデモでは誰にでもわかるように速さを見せびらかす構成になるのですが、本来見るべきは予測できない変化に対する応答性です。これは技術有識者がデモ見るときに見ているポイントの違いです。石川研究室の動画も当然のごとく両者に考慮した構成になってるものが多く、さすがだなと思います)。
物体追跡の場合は、物体はニュートン力学に従って、物理モデルでを作って予測することができますので、予期できない外乱加速度 の最大値がわかれば、カメラに求められる性能が逆算可能になります。
また、この際のモデルの更新もサンプリングレートを上げていくと容易になります。⊿t が小さくなりますので、早い話、テイラー展開したときに１次の項しか計算しないなどの簡略化を行っても十分高い精度が出たりします。
多くの場合、ここで運動方程式を、状態空間モデルにして計算していくと思いますが、この計算が簡単になるわけです。
なお、画像処理の場合、照明変動とか、ノイズとか、ローリングシャッターかグローバルシャッターかといういろいろな要因も入ってきますし、ストロボ照明のようなもの制御なども混ぜてアクティブセンシングを始めるといろいろ複雑化したりとかはあるのですが、まあ、こういった世界観があるわけです。
計算機として決まったサンプリングレートでの入力と計算と出力をするという事
ここで話を計算機に持っていくと、計算機には
- 決まったらレートで必ず入力すること
- 決まった時間内で必ず計算を終わらせること
- 決まったらレートで必ず出力すること
- 上記の一連のレイレンシも可能な限り短くしたい
などが求められてきます。
既存のPC(パソコン)などではこれが案外難しいです。 入力データの帯域自体は 画像サイズ×フレームレートでしかありませんので、昨今の高速なインターフェースを用いれば理屈上は可能でしょう。
しかし、一般的なPCでは、例えば USBカメラは同じUSBチャネル上に居る別のデバイスに帯域を取られることもありますし、画像入力が終わった後もCPUは別の仕事をしているかもしれません。急にネットワーク負荷がかかるなど様々な要因で「PCの動作が急に一瞬遅くなった」などは誰でも経験しているところです。ゲームなどでのフレームレートもしばし変動するのを御存じの方も多いでしょう。
CPU を占有できる場合でも、データ依存で計算時間が揺らぐことはしばしあり、これらはリアルタイムOSなどを用いて最悪実行時間保証を考えていくような分野になります。その場合は入力完了の割り込みに対する不感時間や最悪実行時間などシステム設計を吟味することになり、外部にもさまざま仕組みを持ったハードウェアを準備することになります。
出力にもしばし課題があります。例えば、ディスプレイの 60Hz の周期などは、カメラ撮影とは同期していませんので、「カメラ画像をディスプレイに表示する」という簡単な話であっても、PCの場合は内部のフレームバッファに一度バッファリングされ、同じフレームが2回出たり、フレームが1枚スキップされたりと言ったことが簡単に起こります。
このような問題に対して、非ノイマン型のプロセッサである FPGA は極めて有効であり、例えば以前に書いた下記のブログに繋がってきたりするわけです。
(なお、余談ですが筆者はRTOS分野でもいろいろやっております)
イメージセンサの話(余談)
高速度撮影をすると、シャッター速度が短くなるので、「絵が暗くなって使い物にならないのではないか？」とおっしゃる方も良くおられます。
それはその通りで、短時間露光画像の１枚だけを見ると、S/N比が極めて悪くなります。基本的に暗い画像になるので、アナログゲインをあげるなどするわけですが、ノイズも一緒に増幅されるのでザラザラした画像になります。
しかしながら情報量として何か欠落しているかと言うと決してそんなことはありません。
例えばシャッター速度 1/1000秒(1ms) で 100枚 撮影した画像を加算すると、シャッター速度 1/10(100ms) で撮影したのと同じことになります。
加えて、この時、１枚づつは画素飽和(白飛び)が起こりにくいですので、ダイナミックレンジは逆に広がります。ダイナミックレンジが広がって白飛びしにくいので強い照明を焚くことも可能です。
また動きについても 100ms だとブレブレになる画像も少なくとも動きブラーは殆ど発生しません。代わりにショットノイズなどのノイズ成分強く表れてくるわけですが、これも過去のフレームをうまく使う事でノイズ除去の可能性が出てきます。
このあたりのノイズの仕組みなどイメージセンサの中の構造を勉強するといろいろな事が分かってきて面白いのですが、まあその話は今日は一旦置いておいておきます。
何が言いたいかと言うと、「データ帯域が増える」というのを甘受する代わりに、情報自体を小分けにして受け取ってるだけだという事です。 （もっと身もふたもない事を言うと、人間の目もイメージセンサも飛んでくる光子を確率的に光電変換して認識しているだけで、積分すると確率的な揺らぎがなだらかになってるだけだけなのですよね。光子の単位でセンシングできるSPADセンサーが最強ではないかと思う次第です）
また、データ帯域の観点でも、同じデータ帯域でも画像サイズを 1/4(縦横半分)、1/16 (縦横1/4)と小さくしてよければ同じ帯域で、4倍、16倍とフレームレートを上げることが出来ます。
これは、1/2ピクセルとか、1/4ピクセルとかのサブピクセル精度で計測精度が出れば、許容できることを意味します。このあたりが先に上げた「微分で扱える」部分と関連してきます。
リアルタイムに計算するという事とAIと
リアルタイムに計算するという事は、これまでの入力データに最新の入力データを加えて、素早く今できる最善の出力を行う事です。
これは計算に必要な情報が揃った端から出力を更新していく事に他なりません。この時出力には予測と言う名の推論が含まれていても良く、とにもかくにも今できる 最善の出力 を刻々と変化するリアルな時間の中で行い続ける事です。
ここまでの条件を今の GPGPU などの AI の環境で行う事が難しいというのはなんとなく想像していただけるのではなないかと思います。
ですので、これを何とかする AI を作れないかと言うのが、前回の下記の記事で紹介している LUT-Network であったりするわけです。
おわりに
リアルタイムビジョンを語り始めるといくらでも書くことはあるのですが、キリがなくなりそうなので今日はこのぐらいにしておきます（後日また加筆するかもしれませんが）
なお、私が連名になっている論文を見て頂ければわかるように、早稲田大学の池永研究室 と連携させて頂いておりました。
先生とは転職後も個人的にはお付き合いさせて頂いており、LUT-Network を研究テーマに考えてくださっている学生さんもいらっしゃるようですので、今後、FPGA上でリアルタイム保証のできる LUT-Network がこの分野でもう少し面白い成果が生れてくるかもしれません。
計算機の観点から見てもリアルタイムビジョンの世界はとても興味深いものですの、この分野に興味を持ってくれる方が増えるととても嬉しく思う次第です。
余談
なお最後に余談ですが、タイトルのうち、リアルタイムビジョン と ハイスピードビジョン はそれぞれ異なるもので、高速度カメラの画像を処理するだけなら 十分バッファを持ったキャプチャカードで GPGPU で処理すればいいのですが、「固定時間(それも低レイテンシ)でリアルタイムフィードバックしなさい 」という話になると途端に難易度が上がります。
両方を複合して、「リアルタイムかつハイスピードで、しかもフィードバックによって現実世界に起こる作用まで考えて新しいアルゴリズムと計算機アーキテクチャを考えなさい」となると、非常に新規性の高い研究が生まれやすいフィールドが出来るわけです。 テーマに困っている学生さん、FPGA覚えるだけで周りに差が付けられますよｗ と誘惑してみます。
