MediaPipe Face Landmarkerの精度限界にどう立ち向かうか — ランドマーク幾何学による補正の実践
RIOAnotherBall Pte. Ltd.
AndroidのMediaPipe Face Landmarkerが出力するBlend Shape(表情パラメータ)には、精度が極端に低い「死んだパラメータ」が7つ存在します。cheekPuff、tongueOut、jawForward、jawRight、jawLeft、mouthDimpleRight/Leftは、実質的に常に0付近の値しか返しません。この問題はGitHub Issueで2年以上報告されており、Google Research自身が改良モデル(Blendshapes GHUM)を論文で発表しているにもかかわらず、MediaPipeには未だ統合されていません。 本セッションでは、この限界に対してKMPで開発したフェイストラッキングSDKでどう立ち向かったかを、実測データとともに共有します。私たちはアバター配信アプリの開発でこの問題に直面し、Android(MediaPipe)とiOS(ARKit)を単一のKotlin Multiplatform APIで統合するSDKを構築しました。 まず、KMPでの設計課題を説明します。MediaPipeとARKitはどちらも52個のBlend Shapeを出力しますが、ARKitはTrueDepth赤外線センサで深度を直接計測するため、cheek puffのような立体変形を高精度に検出します。KMPのexpect/actualでAPIの型は統一できても、返ってくるデータの質がプラットフォームで根本的に違う。さらにマルチフェイスはAndroidが最大4顔、iOSは1顔のみ。ボディトラッキングはAndroid 33点に対しiOS 17点。この「同じAPIなのに能力が違う」問題は、型レベルの抽象化では解決できません。同一人物の同一表情をAndroid/iOSで同時に計測し、パラメータごとの乖離を実測データで可視化します。 次に、MediaPipeの限界に対して実装した幾何学的な補正アプローチ(BlendShapeEnhancer)を紹介します。MediaPipeは精度が低いBlend Shapeでも、478点のランドマーク座標は高精度に返します。このランドマークの幾何学的関係から、cheek puffを含む7つのBlend Shapeを間接的に推定するソルバーを実装しました。たとえばcheek puffは頬の横幅変化を3倍感度で増幅し、FACS(Facial Action Coding System)の共活性ルール(笑い→頬スクイント連動)を組み込んでいます。 幾何学アプローチの対極として、PyTorchニューラルネットワークでランドマークからBlend Shapeを推定する手法(face-mesh-to-blendshapes)も存在します。ML方式は精度が高い反面、モデルサイズとレイテンシのコストがあります。幾何学方式はモデル不要・追加レイテンシほぼゼロですが、精度に天井がある。この「幾何学 vs ML」のトレードオフと、私たちがなぜ幾何学を選んだかの判断基準を共有します。 さらに、顔の部位ごとに最適化したスムージング(口は3.0Hz、眉は1.0Hzなど部位別カットオフ周波数)と、セッション開始時の自動キャリブレーション(60フレームのウォームアップでニュートラル表情を検出し、ユーザー固有のレンジ正規化を適用)も紹介します。 Android固有の課題にも触れます。私たちのアプリでは、GPU delegateとTensor SoC(Pixel系)の非互換によりフレームレートが低下する問題が実際に発生しました。また連続推論時の熱スロットリングによるスループット低下や、デバイスごとのML推論品質のばらつきなど、デバイスフラグメンテーションがトラッキング品質にどう影響するかを自社アプリの実例で示します。 最後に、KMP SDK全体の設計原則を共有します。クロスプラットフォームSDKは「差を隠す」のではなく「差を可視化する」べきです。Blend Shapeごとの信頼度をcapabilityフラグとしてcommonMainのAPIに公開し、アプリ側が品質に応じた表現を自分で選択できる設計にしました。また、GPU/NPU検出に基づくDeviceCapabilityProfileで、デバイスティアに応じた推論品質プリセットを自動選択する仕組みも紹介します。「プラットフォームの能力差をKMPのAPI設計でどう表現するか」という、フェイストラッキングに限らないクロスプラットフォームSDK設計の汎用的な判断軸を持ち帰っていただけるセッションです。
対象者
・MediaPipeをAndroidアプリで使っている、または導入を検討しているエンジニア ・ML推論やセンサーデータの品質がデバイスで異なる問題に直面している方 ・フェイストラッキングやモーションキャプチャに興味がある方 ・KMPでハードウェア依存の機能を抽象化するパターンを知りたい方