インテル® NUCを活用したエッジAIカメラ「SCORER Traffic Counter Edge」の映像解析ノウハウを解説！

昨年１０月、交通量を自動計測するAIデバイス SCORER Traffic Counter Edgeをリリースしました。

弊社は映像解析のビジネスを専業で行っており、この製品には、これまでに培った交通量計測のノウハウを多数投入しています。本記事では、そのノウハウの一部を技術面から解説したいと思います。

1.製品の簡単な紹介
2.映像解析の流れ
　2-1.デコード
　2-2.物体検出
　2-3.トラッキング・検知線の通過判定
　2-4.二次解析
　2-5.集計・可視化

SCORER Traffic Counter Edgeは、カメラ映像の上に検知線（カウント線）を引いて、その線を通過する車両や歩行者を数える製品です。

＜カメラ映像の上に検知線を設定し、通過する車両をカウント＞

ハードウェアには、第１１世代の Intel NUC を採用しており、コンパクトな筐体（11cm x 11cm x 6cm）で、カメラ３台までの同時解析が可能です。交通量計測のためにインターネットへ接続する必要はないので、通信状況の厳しい環境であっても本製品を持ち込ん、完全スタンドアロンでの運用が可能です。お手持ちのカメラの近くに設置して「現場で計測、現場で結果を確認」できるポータブルな製品に仕上がっています。

もちろんインターネットに接続すれば、クラウド中心のユースケースにも対応できます。例えば、セーフィー株式会社様のクラウドカメラの映像を、オフィスに設置したTraffic Counter Edgeで受信して解析する。解析結果はクラウドにアップロードして集約する。といった使い方ができます。必ずしも現場に持ち込む必要はありません。

SCORER Traffic Counter Edgeは「コンパクトで扱いやすい、お客様専用の交通量計測AIデバイス」です。

Traffic Counter Edgeでは、実際どのようにカメラ映像を解析しているのでしょうか。

カメラ映像の解析とは、動画の解析です。動画は連続する多数の画像（フレームと呼びます）で構成されていて、H.264などの形式で圧縮されています。連続する画像をどのように圧縮しているかについては、興味のある方は、例えばこちらの解説が参考になるかもしれません。

本製品では、５つのステップで、カメラ映像を「時間あたりの車両／歩行者数」に変換します。

＜動画解析の流れ＞

1. 圧縮された動画データを、元の連続画像に分解して取り出す（デコード）。
   
2. 取り出した画像に写っている車両や歩行者を検知する（物体検知）。
   
3. 検知した車両や歩行者を連続する２枚のフレームで突き合わせ、同じものには同じIDを振る（トラッキング）。
   
4. これで１フレーム間の“動き”が分かるので、検知線を跨いだか判定する（検知線の通過判定）。
   
5. 検知線を跨いだ車両／歩行者の画像を切り出し、別の解析にかける（二次解析）。
   
6. 時間別などで集計してグラフ化する（集計・可視化）。という流れです。

それぞれのステップについて、更に詳しく、順を追って説明していきます。

デコード処理では、カメラから受信した動画データを画像に分解します。Traffic Counter Edgeでは、Intel Iris ™ Xeグラフィックスを用いてデコードしています。ソフトウェアからみると、Intel VAAPI (Video Acceleration API) を使ったデコード処理になります。

Intel Iris™ Xeグラフィックスは、CPU に内蔵されたGPUですが、以前のIntel UHDグラフィックスと比較すると圧倒的に高性能です。本製品では、デコード処理だけでなく、物体検知のためのGPGPUとしても活用しています。

このGPUのお陰で、カメラ３台の解析時でも、本製品のCPU負荷率は４０％程度に抑えられています。電力消費もたったの６４W程度（実測値）で、やっていることを考えると驚異的です。

＜カメラ３台を解析中のCPU負荷＞
デコードと物体検知にIntel Irix Xe™ を活用

話は少しそれますが、世の中では、低消費電力の推論アクセラレーターを後付けするケースも見られるようになりました。しかし、長時間運用による発熱で不安定になる、嵌合不良に悩まされるといった話も聞こえてきます。CPU内蔵のIntel Iris™ Xe グラフィックスには、そういった不安が一切なく、安定性や信頼性といった面でもメリットがあると感じています。推論を行いたいだけなら、Intel Iris™ Xeグラフィックスは消費電力・安定性・価格・性能のすべてに優れた素晴らしいGPUだと思います。

なお、Traffic Counter Edgeは、弊社のデバイス用ミドルウェア “SCORER Edge” のアプリケーションとして構築しており、このデコード処理は、SCORER Edge の基本機能をそのまま活用しています。

Traffic Counter Edgeの物体検知には、深層学習アルゴリズムの YOLOv4 を採用しています。YOLOv4 は、計算量と検知精度のバランスがよく、交通量計測の用途を考えると十分優秀なアルゴリズムです。このアルゴリズムを、弊社独自の「交通量計測用データセット」でファインチューニングし、実用的な精度を実現しています。

「交通量計測用データセット」は、弊社が保有する膨大な録画データから、弊社の基準で画像を抽出しアノーテーションした、独自のデータセットです。様々な気象条件（朝焼け／夕焼け、昼、夜、積雪など）での道路の画像と、人が密集するシーン（交差点、集会場、喫煙室など）の画像が主軸となっており、物体検知カテゴリーも少し特殊です。

例えば、”Pedestrian” は「人」という意味ではなく「歩行者」です。 ”Motorcycle” は単なる「バイク」ではなく「搭乗者とバイク」のセットをアノーテーションしています。有名なMS COCO データセットだと、バイクは ”motorcycle”、搭乗者は “person”、背負っている荷物は “backpack” となり、バイクの交通量を計測しようとしたら、これら３種類の物体が一緒になって動く状況を調べる必要があります。搭乗者と歩行者はどちらも「人」なので、「人」が搭乗者なのか歩行者なのかを見分けるロジックも必要です。このように物体検知のカテゴリーから見直すことで、交通量計測ロジックを簡素化して、精度を向上させています。また、”Kei truck” のように、日本ならではの車種があるのも特徴です。

その他、YOLOv4ファインチューニング時のデータ拡張パラメータや、NMS（Non-Maximum Suppression）などにも、交通量計測を念頭に指向性の工夫がしてあります。

トラッキングは、時間的に続く２枚のフレーム画像（T_nフレームとT_n+1フレーム）の間で検知した物体を、関連付けする作業です。例えば、300フレーム目に写っている車両aと、301フレームの車両bを、もし同じ車両だと推定したなら、両者に ”300A” という共通IDを振ります。そして、車両 ”300A” が、300フレームの位置から301フレームの位置へ移動したと考えます。この移動が検知線を跨げば「車両 “300A”は、301フレーム目で、検知線にヒットした」と判定します。トラッキングさえ継続していれば、以降のフレーム（例えば10000フレーム目）でも車両 ”300A” の場所を特定できます。

なお、関連付けに失敗することも、当然ありえます。T_nフレームで検知した物体が、T_n+1フレームの物体と関連付けできなければ「何かに隠された、画角外に出た、物体検知が一時的に失敗した」などと考えます。反対に、T_n+1フレームの物体が、T_nフレームの物体と関連付けできなければ「背後に隠れていた物体が再び出現した、画角内に入ってきた、存在しない物体を誤検知した」などと見ます。

トラッキングとは詰まるところ、どうやって上手に、この “関連付け” を行うかという課題であり、本質的に難しい作業です。シンプルな実装であれば、T_nフレームの物体とT_n+1フレームの物体で、互いに最も近い場所にある物体を関連付けるかもしれません。しかし、下記にあるような状況を正しく扱わない限り、その精度は期待できません。

• 検知物体が画面端をさまよう（フレームアウトした直後のフレームイン頻発）
• 看板・電柱・傘・すれ違い等で、一時的に見えなくなる（オクルージョン）
• 渋滞や行列で、物体の重なりが多数発生する（オクルージョン）
• 広告やポスターが映り込むサイネージやカーラッピングなど（フェイク・模様）
• 本当は存在しない物体を誤検知（一瞬出現した後、すぐに消える）
• カテゴリーを間違って検知（一時的に自転車をバイクと間違う等）
• ミラーや水たまりによる反射、ガラスによる映り込み／半透過
• 車両を積んだ車両など、積載物を検知してしまう
• 画像の真ん中に出口があり、物体が次々出現する
• 画像の真ん中に入り口があり、物体が次々見えなくなる

これらに１つずつ対処していくと、アルゴリズムは泥臭いものとなりがちです。加えて、エッジ解析のAIデバイスでは計算パワーが限られていることもあり、検知物体が０個から１０００個に増加しても処理時間が極端に伸びない、動画のスキャンを複数回行わなくてもよい（１回で良い）、といった特性も求められてきます。

弊社では、渋滞や駅前の混雑といった映像で検証することにより独自にトラッキングのロジックを作り込んでおり、これらの問題に取り組んできました。深層学習アルゴリズムと比べると地味なモジュールですが、交通量計測の精度に大きく貢献するモジュールです。

トラッキング技術全般をさらに詳しく知りたい方は、内容が少々古いですが、例えばこちらの記事が参考になるかもしれません。最近のトラッキング・アルゴリズムの状況を垣間見たい方は、GIAOTrackerやStrongSORTの解説記事が面白いです。

本製品でも、今後のハードウェア性能の向上とアルゴリズムの進化によって、将来、深層学習ベースのトラッキング・アルゴリズムを採用するかもしれません。

カメラの映像は、デコードすると、ほとんどが似た画像の連続となることが多いので、計算量の大きいアルゴリズムで全フレームに適用するのは、パワーの無駄使いです。

本製品の二次解析は、これまでの物体検知やトラッキング・検知線の通過判定で得られた情報をもとに、重要と考えられるフレームを選別し、任意のアルゴリズムを追加で適用する仕組みです。例えば、車両が検知線を通過したタイミングの画像でナンバープレートを解析するといった使い方をします。

二次解析には、SCORER EdgeのSDK機能を活用しています。これは、Jupyter Labによるアドホックな映像解析コンソール、RDB、メール送信など、アプリケーションを構築するのに便利な機能を集めた、ツールボックスとなっています。

＜SDKを利用した二次解析＞

集計・可視化も、SCORER EdgeのSDK機能を活用しています。検知線の通過判定や二次解析を行ったデータは、一旦、SDKの提供するMySQL データベースに格納され、その後、Apache Supersetで可視化しています。

本記事は、２部構成になっております。
続きは、下記リンクよりお読みいただけます。