Face tracking в AR: точність, анімація та продуктивність

Face tracking в AR: де втрачається точність міміки

Face tracking в AR — це контур із кількох десятків ключових точок і набору мімічних коефіцієнтів, які перераховуються на кожному кадрі з камери. Користувач бачить лише результат: аватар блимає, повторює усмішку й нахил голови.

Щойно оцінки точок втрачають стійкість, враження від продукту ламається — маска «пливе», віртуальний макіяж сповзає, персонаж виглядає неживим.

Перший типовий збій — тремтіння ключових точок. На статичному обличчі контур починає дрібно рябіти: згладжування не встигає за шумом кадрів, і повіки або куточки губ тремтять із частотою, яку око читає як дефект.

Найпомітніше це на тонких каналах міміки — примруженні, піднятій брові, легкій асиметрії усмішки, де ціна помилки в пару точок одразу видна.

Другий — залипання міміки при повороті голови.

У профіль частина точок губиться, і якщо фільтр не розрізняє «обличчя повернулося» та «обличчя зникло», ваги міміки залишаються від останнього достовірного кадру: користувач відвертається й повертається, а аватар усе ще тримає напівусмішку.

Такий збій анімації обличчя ламає і діалог із персонажем, і запис відео, заради якого застосунок часто й відкривають.

Третій — розпад контуру при слабкому світлі та на недорогих пристроях: контраст падає, кількість упевнених точок знижується, між ними з’являються стрибки.

Тут працює керована деградація — спочатку віддаємо деталізацію дрібної міміки, потім переходимо на велику артикуляцію, але не втрачаємо відстеження повністю.

Це обходиться дорожче, ніж здається: незавершена примірка, закрита маска, відгук «обличчя смикається» — прямі втрати конверсії та довіри до продукту. Далі розбираємо, з чого складається стійкість: калібрування, фільтрація, передбачення пози та запас часу на обробку кадру.

Що дає вивірена міміка: ефект у вимірюваних метриках

Стійкість відстеження обличчя — це не один алгоритм, а зв’язка: детекція ключових точок, часова фільтрація координат і передбачення пози між кадрами.

Сирий потік точок тремтить, втрачає брови й куточки губ при швидкому повороті голови, а трекер мовчки віддає останній валідний стан.

Тому в проєктах ми дивимося не на «середню точність» face tracking, а на частку кадрів із коректною позою та на довжину безперервних ділянок без зривів.

Що фіксуємо як результат

• Частка розпізнаних кадрів у робочих умовах — від 99%, включно з поворотом голови та частковим перекриттям обличчя рукою або волоссям.
• Стабільна міміка при повороті й нахилі: артикуляція та брови не «зриваються» в нейтраль, а плавно деградують за зрозумілим сценарієм.
• Робота при слабкому освітленні: фільтрація за історією кадрів тримає трекінг там, де за поодиноким кадром обличчя вже не детектується.
• Передбачувана поведінка на різних класах пристроїв: замість обриву — зниження частоти оновлення й поступове звуження набору мімічних каналів.
• Зменшення ручного доопрацювання анімації: частка кадрів, які аніматор править вручну, падає з третини до одиниць відсотків.

Поведінку платформних трекерів на кшталт ARKit ми розглядаємо як базове джерело, а не як готове рішення: стійкість дає шар обробки поверх нього — згладжування з адаптивною інерцією, відновлення втрачених точок за сусідніми кадрами та явний стан «обличчя втрачено» замість хибних координат.

Для замовника підсумок виражається в тому, що лицьова анімація йде з реального відео без покадрового доопрацювання, а результат однаково пояснюваний на всіх підтримуваних пристроях.

Режими face tracking: порівняння підходів та обмежень

Вибір режиму визначається не класом пристрою, а тим, де припустимо платити затримкою. Обробка на пристрої дає передбачувану реакцію без мережі, віддалена обробка кадрів відкриває доступ до важких моделей, але прив’язує міміку до якості каналу. На слабкому парку різниця проявляється вже в першому сценарії — довга сесія з жестами й розмовою.

Гібридна схема відстеження знімає цю суперечність: базові точки обличчя рахуються локально, а уточнення міміки йде назовні лише при стійкому з’єднанні. Нижче — як режими співвідносяться за умовами застосування та які обмеження режимів доведеться прийняти заздалегідь.

Ми вибираємо режим за профілем парку пристроїв і реальним каналом: частину сценаріїв перевіряємо на слабких моделях, а не на флагманах, — інакше обмеження спливуть уже в релізі.

Етапи впровадження: від аудиту до передачі команді

Впровадження face tracking починається не з коду, а з розбору того, як застосунок уже працює з камерою.

Інженери знімають заміри на реальних пристроях: де між захопленням кадру та відрисовкою накопичується затримка, на яких сценах трекер втрачає обличчя, скільки ресурсів обробка забирає в решти інтерфейсу.

1. Аудит обробки відео. Розбираємо поточний шлях кадру: режим захоплення, частоту обробки, хто і коли звільняє буфери. На виході — список вузьких місць із замірами, а не припущення.

2. Схема потоків даних. Фіксуємо, де живе кадр, де рахуються точки обличчя, де працює згладжування і як усе це синхронізується з відрисовкою. Схема стає контрактом між модулями.

3. Налаштування моделей. Підбираємо модель трекінгу та пороги впевненості під конкретний контент: макіяж, окуляри, борода, головний убір, слабке світло. Окремо налаштовуємо згладжування, щоб анімація не тремтіла й не відставала.

4. Калібрування під контент. Прогоняємо сцени з продукту — маски, аксесуари, накладення графіки — і правимо прив’язку точок до обличчя. Дивимося поведінку при перекритті обличчя рукою та при виході з кадру.

5. Навантажувальна перевірка. Довгі сесії, нагрів, слабкі пристрої, кілька облич у кадрі. Оцінюємо не середні значення, а найгірші випадки: де з’являються провали й як швидко система повертається до норми.

6. Передача команді. Віддаємо конфігурації, схему потоків, набір тестових сцен і метрики, за якими видно регрес. Проводимо навчання, щоб калібрування команда правила сама.

Що замовник отримує на руки після впровадження

Впровадження можна вважати завершеним не тоді, коли демо стабільно тримає обличчя в кадрі, а коли ваша команда сама змінює параметри й розуміє, що саме зламається.

Тому разом із працюючим відстеженням обличчя (face tracking) передаємо набір артефактів — від конфігурацій до регламентів, за якими застосунок живе після запуску.

• Конфігурації відстеження. Профілі під сценарії — близький портрет, груповий кадр, слабке освітлення, зйомка в русі; до кожного опис, які пороги змінюються і на що це впливає.
• Схеми потоків даних. Шлях від кадру камери до відрисованої маски: де буферизується потік, у якій точці синхронізуються графіка й розпізнавання, де губляться кадри при просіданні.
• Правила доступу до даних. Що залишається на пристрої, що йде на сервер, скільки зберігається, хто має доступ і як це логується.
• Регламент оновлення моделей. Коли модель можна підмінити, як перевіряється точність до випуску, за якими метриками ловиться деградація і як повернутися до попередньої версії.
• Документація з інтеграції. Карта модулів, точки розширення, перелік подій і форматів обміну між шарами застосунку.
• Інструкції для команди. Чек-лист приймання, набір тестових сцен, пороги продуктивності та порядок дій при просіданні на слабкому пристрої.

Кейс: як прибрали ривки міміки в застосунку-примірочній

Проєкт — застосунок-примірочна MirrorFit: віртуальна маска з мімікою користувача накладалася на обличчя в реальному часі. На топових моделях це працювало стабільно, на решті парку розпадалося на ривки та відвал анімації.

Що було до

На третині парку моделей анімація відвалювалася в перші секунди примірки: трекінг втрачав обличчя на швидкому повороті голови, а контур не відновлювався — маска залишалася вмороженою в останню позу.

Ще в кожній п’ятій сесії міміка йшла рвано: ваги лицьових морф-таргетів оновлювалися нерівномірно, і на усмішці обличчя смикалося. Користувачі закривали примірочну, не встигнувши роздивитися товар.

Що змінили

Розвели трекінг на незалежні шари — детекцію обличчя, розрахунок пози голови та розрахунок міміки — і перестали оновлювати їх в одному проході: міміці не потрібна повна частота пози.

Додали передбачення пози на кадр уперед, згладжування ваг з адаптивним вікном (коротким на різких рухах, довгим у спокої) і ліміт активних морф-таргетів.

Жорсткий відвал замінили деградацією: при втраті обличчя маска плавно гаситься й повертається за частки секунди, кадр не рветься.

Що стало

Частка сесій із ривками міміки впала з 22% до 3%, відвал анімації — з третини парку моделей до нуля: відмова перейшла в клас непомітної користувачеві деградації. Середня тривалість примірки виросла приблизно вдвічі, частка повторних заходів — на третину.

Пороги згладжування та ліміти тримаємо в конфігурації, тож вони підкручуються без перезбирання релізу.

Що робити, якщо відстеження обличчя вже впроваджено?

Перше, що варто зробити, — не переписувати рішення, а розкласти його на шари й зрозуміти, на якому саме втрачається стабільність. Зазвичай це чотири незалежні ділянки: захоплення кадру, детекція обличчя, власне face tracking і передача результату в анімацію.

Поки причина не локалізована, будь-яке доопрацювання перетворюється на вгадування — команда править анімацію там, де винне захоплення.

Діагностика відстеження починається з телеметрії на реальних пристроях, а не на стенді.

Збираємо частку кадрів з упевненим захопленням, час відновлення після втрати обличчя, дрейф ключових точок на нерухомій голові, поведінку при слабкому світлі, різких поворотах і частковому перекритті. Набори налаштувань порівнюємо за цими числами — одразу видно, де вузьке місце.

Частину дефектів закриває точкова заміна компонентів, без перебудови всього конвеєра. Змінюють модель детекції на стійкішу до ракурсів, переналаштовують згладжування, щоб прибрати тремтіння без запізнення, переписують правила скидання та повторного захоплення.

Якщо просідання йдуть від освітлення, допомагає робота з експозицією та передобробкою кадру, а не заміна трекера.

Перебудова обробки потрібна, коли кадри йдуть через один потік: затримка накопичується, і на слабкому пристрої рішення розвалюється цілком.

Тоді розділяють захоплення, обчислення та відрисовку, вводять буфер із відкиданням застарілих кадрів, прибирають зайві виділення пам’яті в циклі обробки. Після цього точкові правки знову дають ефект і не ламають решту.

Технічні питання, які ставлять перед стартом

Перед стартом інженерні команди ставлять приблизно один і той самий набір питань: чи витримає відстеження обличчя реальні умови зйомки, чи вбудується воно в уже випущений застосунок, як поведе себе на слабкому парку пристроїв і кому залишаться напрацювання. Нижче — короткі відповіді.

Ми виходимо з того, що обличчя в кадрі — рухомий об’єкт із відблисками, перекриттями та непостійним світлом, а не еталонний портрет із тестового набору.

Окуляри, борода, медична маска?

Перекриті зони не добудовуються з повітря — вони заповнюються за симетрією та сусідніми стійкими точками, тому кути не «плавають» і не смикаються. Якщо в аудиторії характерні аксесуари, дообучаємо на ваших записах.

Чи можна додати у випущений застосунок?

Компонент віддається з вузьким інтерфейсом: на вході кадр, на виході параметри обличчя — екран і логіка застосунку не переписуються. Викочуємо поступово й залишаємо можливість вимкнути його віддалено, якщо на частині пристроїв поведінка відрізняється.

Як перевіряєте на слабких пристроях?

Тримаємо матрицю апаратів нижнього цінового сегмента й дивимося час відгуку, частку кадрів із знайденим обличчям і витрату батареї. Під навантаженням вмикається полегшений режим: деталізація сітки нижча, частота оновлення зберігається, щоб анімація не пливла.

Кому належать напрацювання?

Код, модель і навчені ваги передаємо вам; за нами залишаються лише знеособлені базові компоненти, використані до проєкту. Записи для дообучення зберігаються окремо й не потрапляють до загального набору даних.

Обговоримо задачу й повернемося з планом впровадження

Щоб повернутися з оцінкою обсягу робіт, а не із загальними словами, нам потрібні ввідні щодо задачі. Нижче — мінімум, з якого збирається схема робіт і порядок етапів.

• Цільові пристрої та найслабша модель у списку підтримки — під неї підбираємо режим трекінгу й поведінку при просіданні.
• Сценарій зйомки: одне обличчя в кадрі чи кілька, дистанція, освітлення, наскільки глибоко повертається голова.
• Що має видавати анімація: положення голови, морфи обличчя, скелет персонажа чи все разом.
• Як перевіряємо точність: на яких записах рахуємо частку кадрів із коректним трекінгом і що вважаємо зривом.
• Запас часу на кадр під трекінг і відрисовку — він задає вибір моделі та глибину постобробки.
• Приватність: обробка на пристрої чи відправлення кадрів на сервер, чи потрібно зберігати відео.
• Що вже є: прототип, рушій, тестові записи, розмітка — це скорочує перший етап.

З цих ввідних складається план впровадження: від прототипу трекінгу та замірів на ваших записах до інтеграції в застосунок і приймання за заздалегідь узгодженими метриками. Окремо проговорюємо точки, де можна зупинитися й подивитися результат, і що входить у кожен етап.

Опишіть задачу в зручному вигляді — повернемося з оцінкою, схемою робіт і порядком етапів.