Эта тема мне очень интересна, но буду краток. Когда мы выбирали между хорошо изученным и работающим 2D и более «исследовательским» 3D, то решили за 3D не браться по таким соображениям:
Для «точного» 3D необходимо дополнительное оборудование, а нашей целью были минимальные ограничения по оборудованию. Для живого примера использования depth-камеры можно посмотреть на www.onyx.fit (которых не так давно купили)
Без дополнительного оборудования получить 3D estimation — крайне нетривиальная задача, которую сложно назвать решённой. Здесь думаю самым успешным можно назвать www.arielai.com — авторов DensePose, которых купил Snap. Такие решения связаны с на порядки более сложной разметкой данных, либо непростыми попытками оценить положение тела человека с помощью «лифтинга» из 2D в 3D. Думаю такие решения неплохо сработают для «обычного» фитнеса или развлекательных приложений, но для йоги, которая практически целиком состоит из особых случаев, вряд ли будет выдавать что-то более полезное, чем 2D.
В недавнем обновлении MediaPipe добавили 3ю координату для поз, здесь можно посмотреть, как это работает (глубина подсвечивается цветом)
Модель реагирует так, как реагировал бы человек, который размечает такую картинку :) Если говорить именно о нашем случае — то особых проблем в работе с такой одеждой мы не замечали, т.к в данных такая одежда встречается.
В целом насчёт одежды очень хорошо выполняется правильно — что легко человеку, легко и машине. Например, часто встречающаяся проблема с чёрными леггинсами: из-за того, что человеку при разметке бывает тяжело определить, какая нога правая, а какая левая, эта неуверенность переносится и на модель (последняя гифка в статье как раз об этом)
Проблема неоднозначности разметки очень интересная, как со стороны того, что это не очень хорошо и для обучения модели, и для подсчёта метрик качества. Используемая в COCO метрика OKS справляется тем, что для разных точек использует разные допустимые погрешности — они самые маленькие для глаз, носа, и самые большие для плеч, коленей и т.д — это скорее иллюстрация того, что да, проблема есть :)
С точки зрения обучения мне вспомнилась работа LAB — в ней авторы предложили переразмечать неоднозначно размеченные точки с помощью знаний об «устройстве» лица.
К сожалению, найти документы для разметчиков открытых баз мне не удалось. У нас процесс разработки правил разметки шёл итеративно, и, честно говоря, подхода «поставить на глазок в центр плеча» было достаточно при большом количестве данных. Способ «на глазок» можно улучшить с помощью инструментов — например, производить разметку не установкой точки, а рисовать окружность, которая своими краями касается границ конечности. Подобный подход используется в разметке MPII-TRB. В целом для того, чтобы разметка была более консистентной, мы ведём документ, в котором указаны общие правила и особые спорные случаи. Если хотите более подробно изучить то, какие схемы разметки существуют, рекомендую посмотреть на список датасетов в mmpose.
Спасибо за комментарий. Да, нюансов в йоге много, поэтому приложение не заменяет личную работу с инструктором. Новичкам оно помогает преодолеть первоначальный барьер, сделать йогу более доступной и менее травматичной. Более опытных пользователей поддерживает на занятиях с инструкторами онлайн, когда идти в студию неудобно. Инструктору подсвечивает учеников, которые стоят в асане неправильно.
Да, вы верно подметили, что с этой точки зрения сравнение не совсем честное. Мы старались поставить модели в максимально равные условия (например, не считали за ошибки случаи, когда система совсем не нашла человека на картинке), но здесь решающую роль играют данные. Мы аккуратно следим за тем, чтобы данные между обучающей и тестовой выборкой не пересекались, однако сам факт того, что они из одной доменной области даёт нам преимущество.
Дообучить модель из MediaPipe (BlazePose) на наших данных, к сожалению, невозможно, т.к авторы не предоставили код обучения.
Спасибо за вопрос.
Для обучения мы используем pytorch. Для деплоя модельки конвертируются в нужные форматы для каждой из платформ — на iOS это CoreML, на Android tflite, в вебе — tfjs.
На следующем уровне (который и отвечает за все пре- и пост- процессинги) на iOS самописный мини-фреймворк на Swift, на Android — MediaPipe + Kotlin. Части пайплайна переиспользуются с помощью Kotlin Multiplatform (Kotlin Native + Kotlin JS).
Конвертация часто бывает связана с определёнными приключениями, поэтому после неё мы проверяем, что результаты, которые выдаёт моделька до и после конвертации, совпадают, а также тестируем полные пайплайны.
Различия платформ — отдельная очень интересная тема, думаю о ней ещё расскажем.
Рад, что было интересно! С точки зрения моделей хотим задействовать подходы, более полно использующие то, что мы всё-таки работаем с видео. Текущие системы опираются на изображения, а видео используют уже для пост-обработки или трекинга. При этом сама модель ничего о видео не знает.
С точки зрения “интеграций” — улучшение работы моделек для Android и Web — бесконечный потенциал для роста :)
С точки зрения бизнеса мы начинаем гораздо больше смотреть и развивать аналитику того, как пользователи взаимодействуют с приложением внутри занятий. А т.к у нас серьёзный акцент на privacy, это не всегда просто.
Ну и активно расширяем команду. Если интересно поработать с нами, пишите :)
Спасибо за комментарий!
Более подробно об устройстве pose estimation можно посмотреть в https://habr.com/ru/post/555162/
Если коротко - у нас самописный пайплайн и модели, которые идеологически близки к BlazePose.
Отрисовка скелета на iOS делается на CALayer, в Android - средствами MediaPipe, в вебе - svg + canvas.
Эта тема мне очень интересна, но буду краток. Когда мы выбирали между хорошо изученным и работающим 2D и более «исследовательским» 3D, то решили за 3D не браться по таким соображениям:
В недавнем обновлении MediaPipe добавили 3ю координату для поз, здесь можно посмотреть, как это работает (глубина подсвечивается цветом)
Модель реагирует так, как реагировал бы человек, который размечает такую картинку :) Если говорить именно о нашем случае — то особых проблем в работе с такой одеждой мы не замечали, т.к в данных такая одежда встречается.
В целом насчёт одежды очень хорошо выполняется правильно — что легко человеку, легко и машине. Например, часто встречающаяся проблема с чёрными леггинсами: из-за того, что человеку при разметке бывает тяжело определить, какая нога правая, а какая левая, эта неуверенность переносится и на модель (последняя гифка в статье как раз об этом)
Проблема неоднозначности разметки очень интересная, как со стороны того, что это не очень хорошо и для обучения модели, и для подсчёта метрик качества. Используемая в COCO метрика OKS справляется тем, что для разных точек использует разные допустимые погрешности — они самые маленькие для глаз, носа, и самые большие для плеч, коленей и т.д — это скорее иллюстрация того, что да, проблема есть :)
С точки зрения обучения мне вспомнилась работа LAB — в ней авторы предложили переразмечать неоднозначно размеченные точки с помощью знаний об «устройстве» лица.
К сожалению, найти документы для разметчиков открытых баз мне не удалось. У нас процесс разработки правил разметки шёл итеративно, и, честно говоря, подхода «поставить на глазок в центр плеча» было достаточно при большом количестве данных. Способ «на глазок» можно улучшить с помощью инструментов — например, производить разметку не установкой точки, а рисовать окружность, которая своими краями касается границ конечности. Подобный подход используется в разметке MPII-TRB. В целом для того, чтобы разметка была более консистентной, мы ведём документ, в котором указаны общие правила и особые спорные случаи. Если хотите более подробно изучить то, какие схемы разметки существуют, рекомендую посмотреть на список датасетов в mmpose.
Дообучить модель из MediaPipe (BlazePose) на наших данных, к сожалению, невозможно, т.к авторы не предоставили код обучения.
Для обучения мы используем pytorch. Для деплоя модельки конвертируются в нужные форматы для каждой из платформ — на iOS это CoreML, на Android tflite, в вебе — tfjs.
На следующем уровне (который и отвечает за все пре- и пост- процессинги) на iOS самописный мини-фреймворк на Swift, на Android — MediaPipe + Kotlin. Части пайплайна переиспользуются с помощью Kotlin Multiplatform (Kotlin Native + Kotlin JS).
Конвертация часто бывает связана с определёнными приключениями, поэтому после неё мы проверяем, что результаты, которые выдаёт моделька до и после конвертации, совпадают, а также тестируем полные пайплайны.
Различия платформ — отдельная очень интересная тема, думаю о ней ещё расскажем.
Рад, что было интересно! С точки зрения моделей хотим задействовать подходы, более полно использующие то, что мы всё-таки работаем с видео. Текущие системы опираются на изображения, а видео используют уже для пост-обработки или трекинга. При этом сама модель ничего о видео не знает.
С точки зрения “интеграций” — улучшение работы моделек для Android и Web — бесконечный потенциал для роста :)
С точки зрения бизнеса мы начинаем гораздо больше смотреть и развивать аналитику того, как пользователи взаимодействуют с приложением внутри занятий. А т.к у нас серьёзный акцент на privacy, это не всегда просто.
Ну и активно расширяем команду. Если интересно поработать с нами, пишите :)