Reo's Tech Blog

スマートフォン向け物体検出モデルをPCで比較し、実機検証候補を決めた

スマートフォンのカメラで人や車を見つける機能を作るため、3つのAIモデルをPC上で比べました。この記事では、実験の進め方と結果を、表とグラフを中心に説明します。

この記事を読む前の用語

最初に、本文とグラフへ登場する言葉を短くまとめます。用語名から、もう少し詳しい技術メモも読めます。

用語 この記事での意味
物体検出 画像の中から「人」「車」などを見つけ、種類と場所を示す処理
bbox（バウンディングボックス） 見つけた物体の場所を囲む四角い枠
ONNX AIモデルを別の環境へ受け渡すための共通ファイル形式
ONNX Runtime（ORT） ONNX形式のモデルをPCやスマートフォンで動かすソフトウェア
COCO 人や車の位置を正解データとして持つ、評価用にも使われる画像集
IoU 予測した枠と正解の枠がどれくらい重なるかを0〜1で表す値
AP 50-95 見逃しと誤検出のバランスをまとめた品質指標。大きいほど良い
入力解像度 モデルへ渡す画像の縦横サイズ。今回は320×320
モデル量子化 数値をINT8などで表し、モデルの小型化や高速化を狙う変換
スループット 1秒間に処理できる画像数など、一定時間内の処理量
YOLO26n / s / m 同じYOLO26系列の規模違い。nからs、mへ大きくなる

このほか、p50は測定値を小さい順に並べた中央、p95は95%の測定値が収まる境界を表します。

今回やったこと

目標は、スマートフォンで人と車を検出するモデルをいきなり決めることではありません。まずPC上で候補を絞り、次の比較で基準にするモデルを決めることです。

項目 今回の条件
比較候補 YOLO26n、D-FINE-N、PicoDet-S
検出するもの 人（person）、車（car）
モデルへの入力 320×320ピクセル相当
品質評価 COCO val2017の全5,000画像
速度測定 Windows PCのCPU
Android実機 まだ未検証。追加のPC比較後に実施

640pxから320pxへ変えた理由

YOLO26の公式性能表やD-FINE-Nのnative条件は640pxです。一方、今回の候補間比較では、共通の入力を320×320へ変更しました。

選定理由 320pxで先に測る意味
スマートフォン向けの軽い基準を作る 小さい入力から始め、必要な品質に届くか確認できる
異なる候補を同じ条件で比べる モデルごとのnative条件を混ぜず、入力サイズを固定できる
段階的に切り分ける まずモデル差を見て、その後に320と640の差を測れる
再現しやすくする 同じshape、評価画像、前処理を記録できる

640×640は409,600画素、320×320は102,400画素なので、モデルへ入る画素数は4分の1です。ただし、処理時間まで必ず4分の1になるわけではありません。また、小さな対象の情報が減って品質が下がる可能性もあるため、320pxを最終条件と決めたわけではありません。

YOLO26n、D-FINE-N、PicoDet-Sから利用条件を確認し、共通320pxでONNX一致、COCO品質、PC速度を比較した流れ

この図のように、今回はモデル差を見るための共通基準として320pxを選びました。次回はYOLO26系列の中で、320と640を直接比べます。

比較は次の順番で進めました。

  1. 候補をONNX形式へ変換する
  2. 変換前と変換後で検出結果が変わらないか確認する
  3. 5,000画像で、人と車を見つける品質を比べる
  4. PC上の処理時間を比べる
  5. 次のモデル規模・解像度比較で基準にする候補を決める

3候補の扱い

候補 今回どこまで調べたか
YOLO26n PC上で変換後の一致、品質、速度を評価
D-FINE-N ONNX checker、ORT実行、変換後の一致、品質、速度を評価
PicoDet-S checkpoint固有の利用条件を一次情報で確認できず、実行前に除外

PicoDet-SはsourceがApache-2.0である一方、今回使うcheckpointの条件を確認できませんでした。利用できないと断定したのではなく、不明な状態では進めない判断です。

ONNXへ変換しても結果は変わらないか

モデルをONNXへ変換できても、検出する位置や確からしさが変わってしまえば、元と同じモデルとして扱えません。そこで、同じ100画像を変換前の公式環境とORTへ入力し、検出枠を1件ずつ比べました。この確認をframework/ORT parityと呼びます。

YOLO26nとD-FINE-Nについて、変換前のframeworkとONNX Runtimeの全検出が一致したことを示す集計図

この図で見る箇所は、青とオレンジの棒がどちらも100%になっている点です。

候補 一致した検出 片方だけに出た検出 結果
YOLO26n 185 / 185 0 合格
D-FINE-N 277 / 277 0 合格

D-FINE-NはONNX checkerによる構造確認と、ORTでの実行にも合格しました。どちらの候補も、ONNX変換によって検出結果が崩れていないことを確認できました。

ただし、ここで確認したのは「変換前と変換後が同じか」です。両方が同じ物体を見逃しても一致にはなるため、parity合格と検出品質の高さは別の話です。

COCO全5,000画像で品質を比べる

次に、COCO val2017の全5,000画像を使い、人と車の検出品質を測りました。AP 50-95は大きいほど、見逃しと誤検出のバランスが良いことを表します。

COCO val2017全5,000画像におけるYOLO26nとD-FINE-NのpersonとcarのAP 50-95を比較した棒グラフ

このグラフでは、棒が長いほど品質が高いと読みます。人と車のどちらでも、YOLO26nの棒が長くなりました。

評価項目 YOLO26n D-FINE-N 良い方向
person AP 50-95 約0.401 約0.104 大きい
car AP 50-95 約0.222 約0.057 大きい
5,000画像のruntime failure 0件 0件 少ない

今回の品質条件は、各クラスでYOLO26nとの差を0.02以内にすることです。D-FINE-Nとの差はpersonが約0.298、carが約0.165だったため、この条件には届きませんでした。

処理失敗は両候補とも0件です。D-FINE-Nは途中で動かなくなったのではなく、最後まで動いたうえで品質条件に届かなかったと分かります。

検出枠の下端も比べる

今回は、検出した人の足元や、車が接している路面の方向を考える予定です。そのため、枠全体の重なりだけでなく、bbox下端中央のずれも比べました。

固定500画像で測ったbbox下端中央のp95 d2を比較し、0.08の基準線を示した棒グラフ

このグラフは、棒が短いほど位置のずれが小さいと読みます。d2は画像サイズで調整した距離で、p95は大部分の検出が収まる誤差の境界です。

対象 YOLO26n D-FINE-N 良い方向
person p95 d2 約0.044 約0.075 小さい
car p95 d2 約0.027 約0.049 小さい

D-FINE-Nは絶対条件の0.08以下には収まりました。ただし、YOLO26nからの悪化を0.02以内にする条件は、personが約0.031、carが約0.022となり、どちらも超えました。

なお、COCOのbbox下端は、実際の足先やタイヤ位置を記録したものではありません。ここでは2候補の位置ずれを同じ物差しで比べる代理値として使っています。

PC上の処理時間を比べる

最後に、Windows PCのCPUで、モデルが検出結果を計算する推論部分の時間を測りました。グラフの棒は短いほど高速です。

Windows PCのCPU上で測ったYOLO26nとD-FINE-NのframeworkおよびONNX Runtime推論時間のp50とp95を比較した棒グラフ

ORT CPUの推論時間 YOLO26n D-FINE-N
p50 約6.83ms 約25.81ms

YOLO26nの方が、PC上の推論時間は短い結果でした。ただし、この数値にはスマートフォンのカメラ入力、画面描画、発熱による速度低下などは含まれません。Androidでも約6.83msで動くという意味ではありません。

実験結果をまとめる

比較結果を候補ごとにまとめると、次のようになります。

候補 変換・実行 320pxの品質 PC速度 次の工程
YOLO26n parity 185 / 185 3候補中で最良 最速 次回比較の基準
D-FINE-N checker、ORT、parity 277 / 277に合格 今回の条件に届かず YOLO26nより遅い 今回は渡さない
PicoDet-S 実行前に除外 未測定 未測定 条件確認後に再検討可能

D-FINE-Nは「失敗して動かなかった」候補ではありません。Apache-2.0のsourceとcheckpointを確認でき、ONNX変換からORT実行まで通せたことで、互換性と品質を分けて判断できました。

まだ分かっていないこと

今回分かったのは、YOLO26n 320pxが比較基準として有力なことです。Androidへ渡すモデル、入力解像度、数値精度はまだ決めていません。

次回はYOLO26n / s / mと320 / 640を比較する

次回は、FP32のままモデル規模と入力解像度だけを変えます。6条件を同じPC環境とCOCO val2017で測り、どこから品質向上より処理負荷の増加が大きくなるかを確認します。

モデル 320×320 640×640
YOLO26n 計測 計測
YOLO26s 計測 計測
YOLO26m 計測 計測

主に比較するのは、person / carのAP 50-95、Detection Pointの誤差、ORT CPUのp50 / p95、1秒間の処理量、モデルサイズ、runtime failureです。モデルと入力解像度以外の前処理、評価画像、threshold、実行環境は固定します。

次々回はFP32 / FP16 / INT8を比較する

ベースにするモデルと入力解像度は、次回の結果を見てから決めます。その1条件を固定し、数値精度だけを変えて品質と処理性能への影響を調べます。

数値精度 位置付け 確認したいこと
FP32 変換前の基準 品質と処理時間の基準値
FP16 浮動小数点の低精度化 モデルサイズ、対応runtime、品質、速度
INT8 整数量子化 calibration後の品質低下と高速化の有無

FP16はINT8の整数量子化とは別の変換です。また、ONNX RuntimeのCPU実行はFP16演算をそのまま扱えないため、FP16は対応するExecution Provider上でfull graphを実行できるかも記録します。INT8も、端末やCPUが対応していなければ速くなるとは限りません。

次回にYOLO26n、s、mの320と640を比較し、次々回に選定モデルのFP32、FP16、INT8を比較するロードマップ

2つの比較を終えてから、Android実機へ渡すモデル、入力解像度、数値精度を決めます。

データセットはCOCOのままでよいか

候補間の共通評価には、引き続きCOCO val2017全5,000画像を使います。今回の結果と連続して比べられ、YOLO26の公式性能値もCOCOを基準としているためです。

ただし、COCOだけでスマートフォンの実利用まで保証はできません。距離や遮蔽、実際のカメラ映像への適合は十分に表せないため、モデル選定後は匿名化した実機カメラ画像を別の補助評価へ加えます。

INT8のstatic quantizationでは、値の範囲を決めるcalibration dataが別途必要です。評価結果への混入を避けるため、val2017は品質評価専用に維持し、calibrationにはCOCO train2017から固定した別subsetなどを使います。使用画像、抽出条件、seedは再現できるよう記録します。

参考資料

まとめ

PC上の比較では、YOLO26nが品質、推論速度、framework/ORT parityの総合で最も良い結果でした。そのため、YOLO26n 320pxを次の比較で使う基準候補にします。Androidへ渡すモデルを確定したわけではありません。

ただし、YOLO26nのsourceとcheckpoint licenseはAGPL-3.0です。高性能だから条件を無視したのではなく、現在の個人・非商用・private・第三者非配布の技術実験に限る候補としました。

当初のApache-2.0限定は、将来のAPK配布を想定した保守的な判断でした。利用範囲を明文化したためlocal-only実験の候補へ変更しましたが、次へ進む前には判断をやり直します。

次回はYOLO26n / s / mの320 / 640を比較し、次々回は選んだ条件をFP32 / FP16 / INT8で比較します。その結果からAndroidへ渡す構成を決め、最後にPOCO X8 Proでカメラを含む実効fps、発熱、メモリを確認します。

この記事はReo’s Tech Blogの同名記事にも掲載しています。

Reo’s Tech Blogでは、個人開発や日々の技術的な取り組みを記録しています。興味がありましたら、ほかの記事もご覧ください。