Сегментація зображень у мобільному додатку: де вона ламається
Сегментація зображень у мобільному додатку майже ніколи не ламається «в теорії» — вона ламається за конкретних умов зйомки.
При слабкому світлі датчик віддає шумний кадр, поріг за кольором і яскравістю перестає розділяти об'єкт і фон, і маска об'єкта на кадрі рветься по контуру: користувач отримує вирізаний силует, з якого випадають рукав, тінь або частина зачіски.
Окрема біда — напівпрозорі та тонкі деталі: скло, шерсть тварин, велосипедні спиці. Модель, навчена на «чистих» студійних прикладах, такі межі просто не розрізняє.
Друга точка відмови — затримка обробки кадру. Якщо модель рахує кадр довше, ніж користувач готовий чекати, ефект сегментації втрачає сенс: людина вже навела камеру на інший об'єкт, а на екрані все ще висить попередня маска.
Гірше, коли важкий розрахунок виконується в тому ж потоці, що й малювання прев'ю — інтерфейс починає смикатися, кнопки не відгукуються, додаток виглядає зламаним, хоча код формально працює.
Третій збій проявляється там, де його найменше чекають: у полі, у підвалі, в літаку. Інженери нерідко будують схему «кадр іде на сервер, звідти повертається готова маска», і тоді робота додатка без мережі перетворюється на завислий екран з нескінченним індикатором.
Користувач не розуміє, що сталося, закриває додаток і більше не повертається — а за логами це виглядає як обрив зв'язку, а не як дефект продукту.
І четвертий шар — якість розмітки меж. Саме по кромці маски видно, наскільки акуратно зібрано весь тракт: від підготовки навчальних прикладів до згладжування контуру при малюванні.
Рвана зубчаста межа, «ореол» навколо об'єкта і тремтіння маски від кадру до кадру дратують сильніше, ніж сама помилка виділення. Нижче розбираємо, як це закривається: де рахувати модель, що робити при обриві мережі і як утримати стабільну кромку.
Що дає сегментація на пристрої та в хмарі
Різниця між обчисленням на телефоні та на сервері видна не в якості маски, а в тому, скільки кадрів доїжджає до відповіді.
П'ять ефектів вимірювані на реальному трафіку: частка кадрів без мережі, час відгуку інтерфейсу, збіг результату на різних моделях телефонів, відхід відмов «немає відповіді від сервера», обсяг переданих кадрів.
Обробка на пристрої: що йде в офлайн
Модель компілюється у формат платформи — через Core ML висновок іде на самому телефоні, без звернення до сервера. В офлайн іде все, що не потребує важкого контексту: людина, об'єкт, фон, межі.
Це 80–90% кадрів потоку: додаток працює без мережі, а інтерфейс відповідає за частки секунди замість секунд очікування.
Однаковий результат на різних моделях телефонів дає зафіксована попередня обробка: один розмір входу, одна нормалізація, один поріг маски. Відмінності залишаються у швидкості, не в геометрії — це перевіряється порівнянням частки збіглих пікселів на матриці пристроїв.
Гібрид: де рахувати і що зберігати
У хмару йдуть пограничні кадри: дрібні об'єкти, сильні перекриття, нестандартні сцени — там модель більша, і результат точніший.
Відбір скорочує обсяг переданих кадрів у рази, а клас відмов «немає відповіді від сервера» йде: локальна маска віддається відразу, уточнена підміняє її пізніше.
Зберігати достатньо маски і ознак, а не самих кадрів — це знімає питання приватності і тримає чергу на відправлення передбачуваною. Кадри, що не пішли по мережі, чекають її в локальній черзі і йдуть повторно.
Варіанти розрахунку: на пристрої, на сервері, гібрид
Режим розрахунку визначає, де живе модель і скільки ресурсів вона забирає в користувача.
Локальна обробка кадрів рахується прямо на телефоні і не відправляє зображення в мережу; серверна обробка кадрів знімає навантаження з пристрою, але прив'язує результат до каналу зв'язку; гібридна схема ділить завдання між ними.
Вибір впливає на затримку відгуку, приватність і те, на якому парку пристроїв додаток взагалі запуститься.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Локальна обробка кадрів | Маска потрібна миттєво, кадри йдуть потоком, зображення чутливі і не повинні покидати пристрій | Вимоги до пристрою вищі: модель постійно тримає пам'ять, обмеження за пам'яттю і нагріванням відсікають старий парк, на складних сценах якість нижча за серверну |
| Серверна обробка кадрів | Потрібна максимальна точність, модель важка і часто оновлюється, зйомка обробляється пакетом, а не в реальному часі | Затримка залежить від мережі, передача кожного кадру — витрата трафіку, окремий контур зберігання і захист персональних зображень |
| Гібридна схема | Потрібен баланс: швидкий чорновий результат на екрані і точне уточнення там, де воно важливе | Складніше в підтримці: дві гілки розрахунку, узгодження форматів маски, контроль розсинхрону версій моделі між клієнтом і сервером |
Коли вистачає локальної обробки
Якщо завдання — відокремити об'єкт від фону в реальному часі, а сцена однотипна, виграє розрахунок на пристрої: відгук не залежить від якості зв'язку, а кадри не покидають телефон.
Ми заздалегідь перевіряємо вимоги до пристрою на цільовому парку і підбираємо легку модель так, щоб вкластися в обмеження за пам'яттю без просідання частоти кадрів.
Гібрид: попередня обробка на пристрої, уточнення в хмарі
На телефоні виконується швидкий прохід — він дає чорнову маску і відсікає зайве, а важке уточнення йде на сервер за запитом.
Так знімається основне навантаження з пристрою і скорочується обсяг переданих даних, але з'являється обов'язок стежити за сумісністю версій моделі на обох сторонах.
Як проходить впровадження: від аудиту даних до передачі
Впровадження сегментації в мобільний додаток будуємо так, щоб кожен крок спирався на перевірений результат попереднього. Спочатку фіксуємо, які класи об'єктів потрібно виділяти і в яких умовах знімає користувач, — від цього залежать і розмітка, і вимоги до моделі.
- Аудит кадрів і розмітки. Перевіряємо сцени, освітлення, ракурси і баланс класів, окремо шукаємо розбіжності масок з реальними межами об'єктів: модель відтворює помилки розмітки, а не виправляє їх.
- Схема обробки. Вирішуємо, де йде обчислення — на пристрої, на сервері чи гібридно, — як кадр готується до подачі і що додаток робить з готовою маскою.
- Складання і навчання моделі. Донавчаємо попередньо навчену основу на розмічених кадрах, окремо проганяємо рідкісні класи і складні сцени, щоб контур виділення працював не лише на типових прикладах.
- Перевірка на реальних пристроях. Дивимося не лише точність маски, а й витрату пам'яті, швидкість відгуку і поведінку при слабкому освітленні — частина дефектів видна лише на живому пристрої.
- Замір якості. Рахуємо метрики на відкладеній вибірці і на записах з пристроїв, розбираємо кадри, де маска рветься, і за ними уточнюємо розмітку і донавчаємо.
- Передача команді замовника. Віддаємо модель, код обробки кадру, інструкцію з донавчання на нових даних і порядок перевірки перед публікацією релізу.
Що уточнюємо до старту робіт
До початку уточнюємо три моменти: де виконується висновок, який обсяг кадрів є для донавчання і як виглядає приймання — на якій вибірці і за якою метрикою вважаємо якість. Відповіді задають обсяг робіт і термін.
Що залишається в проєкті: моделі, розмітка, регламенти
Після виведення сегментації в робочу експлуатацію замовнику переходить не лише додаток, а набір артефактів, від яких залежить поведінка моделі на нових знімках. Нижче — що саме ми залишаємо в проєкті і чому без кожного пункту система втрачає керованість.
- Модель і її конфігурація — ваги, структура, вхідний дозвіл, поріг впевненості та параметри постобробки масок, плюс скрипт складання, щоб результат відтворювався на вашому стенді.
- Набір даних з розміткою — вихідні кадри і маски, правила для спірних областей: напівпрозорі краї, перекриття, дрібні об'єкти; журнал правок з автором і датою.
- Схема обробки кадрів — шлях від камери до маски: приведення розміру, нормалізація, розрахунок на пристрої або вивантаження на сервер, згладжування меж між кадрами.
- Регламент перенавчання — яка метрика і який її просадок запускають донавчання, як часто перевіряємо на контрольній вибірці, хто готує нові дані.
- Інструкція для команди — як підняти оточення, прогнати перевірку якості, порівняти версію з поточною і відкотитися, якщо метрика просіла.
Права на дані та модель
Окремо фіксуємо, кому належать знімки, розмітка і навчені ваги, які відкриті моделі і на яких ліцензіях використані. Якщо в кадрах є люди або документи, описуємо знеособлення, терміни зберігання і порядок видалення за запитом — так передача проєкту не створює правових ризиків.
Кейс: маски об'єктів у додатку для зйомки на складі
Клієнт — мережа розподільчих центрів СкладЛайн, завдання — облік товару за знімками з камери. Проєкт стартував на чотирьох майданчиках: оператор наводив камеру на палету, додаток виділяв маску кожної коробки, результат ішов в облікову систему.
Перша версія рахувала все на сервері — кадр стискався, ставав у чергу і повертався з готовою маскою.
У зонах з нестійким сигналом це оберталося завислими зйомками і переробками зміни: заміри до впровадження дали 74% коректних масок, близько 0,9 с на обробку кадру і до п'яти звернень до сервера на один знімок.
Що змінили в схемі обробки
Основну роботу перенесли на пристрій: легка модель рахує маску прямо на телефоні, а на сервер кадр йде лише при впевненості нижче порогу — приблизно кожен двадцятий знімок.
Кадри складаються в локальне сховище і досилаються самі, коли зв'язок повертається, тому обрив мережі більше не рве зйомку. На сервері залишилися перерахунок складних кадрів і накопичення розмітки для донавчання моделі на даних конкретного складу.
Після переходу частка коректних масок виросла до 96%, час обробки кадру скоротився до 0,2 с, а число звернень до сервера — до одного на десять знімків.
Пікове навантаження на серверну частину впало майже втричі: ті самі потужності тримають втричі більше одночасних зйомок, а скарги на зависання при зникненні зв'язку пішли зі звітів підтримки.
Чим відрізняється семантична сегментація від розпізнавання об'єктів рамками?
Детектор відповідає на питання «де об'єкт»: на виході — прямокутник і клас. Семантична сегментація розмічає кожен піксель кадру, тому результат — попіксельна маска, що повторює контур. Для силуету людини рамка захопить і фон, і руки, а маска пройде по межі точно. Звідси різні вимоги до розмітки, розміру моделі і обчислень на пристрої.
Рамки достатньо, коли результат — лічильники, відстеження переміщення, зони інтересу або груба аналітика: розмітка збирається в рази швидше, модель легша і стабільніше працює на телефоні.
Маска потрібна там, де контур і є результат: заміна фону, примірка, накладення графіки, вирізання об'єкта.
Окрема розвилка — однотипні об'єкти. Семантична сегментація зіллє дві машини в один клас; якщо потрібно і порахувати, і обвести — це третя постановка, з окремою маскою на кожен об'єкт. Вибір іде від питання «що саме повернемо в додаток», а не від краси картинки.
Якщо в додатку вже працює розпізнавання рамками, переписувати його не потрібно. Донавчаємо існуючу модель: детектор залишається, до нього додається гілка передбачення маски, навчання йде на невеликому наборі з точною розміткою контурів.
Зовнішній контракт у додатку не змінюється — інтерфейс отримує той самий результат плюс маску, а поки маска непевна, віддаємо рамку: користувач не бачить відмови.
Якість маски перевіряємо метриками перетину з еталоном — на публічних наборах з подвійною розміткою, наприклад COCO, і на власних кадрах з камер користувачів. Розбір найгірших випадків іде до включення режиму на всіх пристроях.
Технічні сумніви: точність, пристрої, дані
Сегментація ламається не на великих об'єктах, а на тонких структурах. Метрику фіксуємо до старту: частка перетину масок і частка вірних пікселів за кожним класом, приймання — на складній вибірці, а не на студійних кадрах.
Чи вистачить точності на складних кадрах?
Тонкі межі — волосся, відблиски, напівпрозорі об'єкти — вимагають входу у високому дозволі і постобробки контуру. Донавчаємо на знімках з цільових пристроїв і тих самих умовах світла.
Що робити з телефонами слабшими?
Полегшена гілка моделі: менший вхід, стиснення ваг, частина операцій на спрощеному контурі. Маска рахується в зниженому дозволі і уточнюється по краях — інтерфейс залишається чутливим.
Хто володіє даними та моделлю?
Розмітка, ваги і конфігурація навчання передаються замовнику. Якщо знімки не повинні покидати периметр, навчання йде на його інфраструктурі, а ми працюємо з знеособленими метриками.
Як бути з рідкісними класами?
Балансуємо вибірку і додаємо об'єкти рідкісного класу в кадри синтетично, поріг впевненості за ним задаємо окремо. Клас не виводиться в інтерфейс, поки не набрана метрика на відкладеній вибірці.
Якість падає після оновлення парку пристроїв?
Ведемо регрес-набір еталонних кадрів і проганяємо його на кожному складанні моделі. Просадка видна до релізу: відкочуємо ваги, а розбіжність між моделями пристроїв розбираємо за звітом.
Обговоримо задачу: що надіслати для оцінки
Щоб повернутися з оцінкою і планом робіт, не потрібен том технічного завдання — достатньо п'яти вступних. За ними ми розуміємо обсяг, порядок етапів і те, де проєкт може піти не за планом.
- Приклади кадрів — 10–20 реальних знімків або коротких відео з робочих пристроїв. Важливі не лише вдалі: контрове світло, розмитий фон, однотипні об'єкти поруч, зйомка під кутом — саме на них маска найчастіше рветься.
- Сценарії зйомки — звідки приходить кадр: галерея, камера всередині додатка, потік з фронтальної камери, робота без мережі. Від цього залежить, де рахувати маску і як часто.
- Обмеження за пристроями — мінімальна підтримувана версія системи, частка слабких моделей в аудиторії, припустимий час обробки кадру і запас за пам'яттю.
- Вимоги до приватності — обробляється кадр на пристрої чи йде на сервер, що зберігається в журналах, чи потрібна анонімізація облич і номерів.
- Класи об'єктів і точність — що саме виділяємо, яка частка помилок вважається прийнятною і як додаток поводиться при непевному результаті.
- Терміни і віхи — до якої дати потрібен працюючий прототип, що потрапляє в першу чергу, що можна винести в другу.
Після цього повернемося з оцінкою і планом робіт: етапами, порядком перевірок і точками, де ви приймаєте результат. Якщо частина даних поки не зібрана — опишіть задачу словами, допоможемо сформулювати вимоги на дзвінку.
