追跡精度は、何を見て判断するか

株式会社HULIX　守屋充雄｜約7分
連載「人の動きを追い、現場を変える」第5回／全7回

「追跡精度は何％ですか」。必要な質問ですが、数字一つでは現場で使えるか判断できません。

待ち時間を出したいのに、途中で同じ人のIDが変わる。二人の記録が一つにつながる。短い映像ではよく見えても、こうした失敗があると、分析する数字が変わります。

HULIXの評価記録を見返しても、改善につながっているのは、失敗した場面まで戻れる記録でした。

「見えている」と「補っている」を分ける

対象が隠れた間は、直前の位置や速度から移動を予測することがあります。それ自体は追跡に必要ですが、予測の位置を実際の観測と混ぜると、評価が難しくなります。

報告書の滞在時間が長いとき、本当に止まっていたのか。見失った後も、同じ場所にいると予測していたのか。この違いを調べられるようにします。

HULIXの評価設計でも、観測と補完、個別センサーのIDと統合後のIDを区別する記録を重視しています。画面では滑らかにつながっていても、その中身まで確かめるためです。

例えば、ほかの観測で位置を補っていた時間まで含めれば、追跡が続いている時間は長くなります。過去の評価でも、直接追跡できた時間と、補完を含めた時間を分けて集計しています。どちらか一方を都合よく選ぶと、同じシステムでも違う印象の数字になります。

おおよその位置を画面で案内する用途と、狭い区域へ入った時刻を測る用途では、補完に求める条件が違います。まず分母と分子を決め、見失った区間をどう扱ったかを添えます。「何％か」の前に「何を成功とした割合か」を合わせることが、評価の出発点です。

外れた映像を、一つずつ見た

過去のカメラ追跡の評価では、対象が重なった後に追う相手が入れ替わる場面がありました。検出枠の揺れや撮影方向、計算機側の処理条件も確認しています。

下の図は、対象とカメラの位置関係を変えて、追跡が外れた条件を見返した記録です。施設内の移動経路を描いた地図ではありません。

集計値が悪いからといって、全部を同じ原因にはできません。人物を検出できていないのか。検出はあるが、対応付けで別人を選んだのか。処理が間に合わず、時間が飛んだのか。修正する場所が違います。

失敗した時刻と、前後の映像・点群、元の検出、統合した軌跡がそろっていれば、原因を追えます。結果の軌跡だけを保存していると、もう一度現地で取り直すことにもなります。

失敗が起きる条件に偏りがないかも見ます。すれ違うときだけ外れるのか、センサーの境界で外れるのか。多く試した経路ほど失敗件数も増えるので、件数だけで原因を決めないようにします。過去の個別評価を、現在のHULIX製品すべてに当てはまる性能値としても扱いません。

評価メモに疑問符や「件数が少ない」という留保があるなら、そのまま残した方がよいと思います。観測した失敗と、原因についての仮説は、次に確かめることが違うからです。

評価表から、次に見る区間へ戻れるか

実装では、次の三つを分けて集計すると、修正先を絞りやすくなります。

HOTAのように検出と対応付けの両面を扱う指標も参考になります。ただし、ベンチマークの点数と、自分の現場で許容できる誤差は別に確かめます。HOTA原論文

例えば、全体の人数は合っていても、長く待った人だけ記録が切れていれば、待ち時間の評価は楽観的になります。合計人数だけでなく、重要な区間に偏って失敗していないかを見る必要があります。

評価対象の区間は、元の映像や点群へ戻れる形で残します。統合したIDから、その時刻に使ったセンサーの観測をたどれるか。表示を補完していたなら、最後に実際の観測が入ったのはいつか。こうした情報が、再現のための入口になります。

ただし、ログ上でIDの対応が変わったからといって、実際に人物が入れ替わったとは限りません。元のID自体が誤っていることもあります。人が確認した映像や注釈と照合し、正解側の判断も確かめる。ログの集計は、人が見る区間を絞る道具として使います。

正常時と、止まった後の両方を試す

追跡の評価には、いつもの動作だけでなく、停止や復旧も含めます。センサーが一台止まったとき、どの区域が観測できなくなったか。復帰後に同じ人を二重に数えていないか。通信が戻って過去のデータが届いたとき、現在の状態として表示されないかを見ます。

処理負荷にも時間の変化があります。起動直後は間に合っていても、長時間動かした後に遅れが増えるなら、利用者が多い場所の分析に影響します。CPUやGPUの使用率だけでなく、データを観測した時刻から画面や通知に出るまでの遅れを記録します。

HULIXで履歴と再生を重視しているのは、このような違いを同じ条件で見返したいからです。修正のたびに別の日のデータを持ってくると、改善したのが処理なのか、単に混み方が違ったのか分からなくなります。

調整したデータだけで、合格にしない

集計する単位にも注意します。一フレームごとの正しさを見る評価と、一人が入口から出口までつながったかを見る評価は、同じ割合にはなりません。長い区間ほど、一度も切れずにつなぐ条件は厳しくなります。比較する区間の長さまでそろえておきます。

待ち時間を作る用途なら、入口と出口がそろった記録の割合も確かめたいところです。途中までの移動は正しくても、出口が欠ければ待ち終わりが分かりません。平均の誤差だけでなく、そもそも待ち時間を計算できた人が、対象者のうち何人いたかを残します。

また、失敗した時刻だけを渡されても、原因を再現できないことがあります。前後の動き、使った処理の版、設定、センサーの状態を一緒に残す。別の担当者が同じ区間を再生して確認できれば、調整の引き継ぎも楽になります。

評価を依頼する側も、点数の一覧だけ受け取るより、代表的な失敗を数件見せてもらう方が判断しやすくなります。どの失敗が自分の業務に影響し、どれなら許容できるかを話せるからです。評価表と再生する記録の両方があると、技術側と運用側の話がつながります。

失敗した映像で設定を直す。その映像で良くなったことを確認する。ここまでは必要ですが、それだけでは別の日にも使えるか分かりません。

調整に使っていない時間帯や、混み方が違う区間でも確かめます。センサーや処理を止めた後に戻るか、長時間動かして遅れが増えないかも、現場で使うための評価です。

修正前後は、同じ元データと条件で比較します。集計ルールまで変えたなら、その変更を残す。そうしないと、追跡が良くなったのか、数え方が変わっただけなのか分からなくなります。

HULIXが履歴や再生の道具を持つのは、きれいな軌跡を見せるためだけではありません。外れた理由を確認し、直した結果を説明できるようにするためです。まず一つ、実際に外れた区間を、再現できる形で残すところから始めるのがよいと思います。