Как-то это слабовато даже для студенческого проекта.
1) Вы используете Dlib распознавание лиц. Но сейчас 2022 год уже. Не надо так делать. Вот тут я чуть подробнее рассказываю почему так не надо — www.youtube.com/watch?v=2fnNhYCpToE и какие есть альтернативы (как детектор лиц на питоне я может быть даже MediaPipe посоветовал бы сейчас)
2) Для тестирования вы используете… «ORL» — это база для тестирования лиц собранная с 1992 до 1994 года. Тогда не то что нейронных сетей не было, тогда ещё и Haar, HOG и половины алгоритмов классического CV не было. Тогда решались другие цели и задачи.
(чб картинки полного размера которые смотрят в камеру — это не совсем того что вы хотите от датасета)
3) Вы что-то говорите про скорость выполнения. Но не сравниваете с сотнями других современных подходов, которые умеют оптимизироваться под железо. И под RPi и под другие куда более дешевые железки. И вообще сейчас RPi странное решение для FaceRecognition. Например приведу пример Maixduino который с камерой выходит дешевле, а по производительности дешевле
А ещё есть ESP32 который формально тоже может распознавать. Там есть полный аналог чего вы сделали из коробки. Примерно за 5 баксов с камерой, примерно 5fps.
Выбор RPi у вас абсолютно нелогичен:)
4) Вы начинаете рассказывать про ошибки других систем, но не показываете проблемы/ошибки вашей системы/вашего подхода (dlib вы не сможете переобучить, занесение в базу будет иметь кучу ошибок, и.т.д.).
99% качества для стереозрения — хорошие камеры. Приклеить несинхронизированные камеры на картонку — это ужасно. Есть множество готовых стереокамер. Ну, например, прямо с шлейфом под Jetson:
Есть много аналогичных USB камер.
Но, в целом, если есть желание помучить 3D, то проще взять готовую камеру которая его выдает. Я недавно делал обзор на OAK-D-Lite, там ещё есть сопроцессор для нейронных сетей по мощности сравнимы с Jetson Nano. Оно будет чуть дороже варианта выше или из статьи, но качество лучше.
Есть много аналогичных камер выдающих 3D. Есть даже проекционные (Orbbec Astra например), примерно в ту же стоимость. Года 3 назад делал обзор, но с тех пор много нового появилось.
Если уже не терпится самому все делать — очень советую вместо классических алгоритмов восстановления 3D использовать все же нейроночку…
Год назад ставил себе реле напряжения. Вызвал электрика из районного ДЭЗ.
Он с некоторым восторгом смотрел на реле, радостно сказав что за пять лет работы в моем районе Москвы в третий раз ставит такое/видит что этим кто-то озаботился…
Автор очень передергивает. Буквально в каждом абзаце. На много ошибок уже указали. Но их так много, что надо писать статью аналогичного размера чтобы показать каждую ошибку.
Не понимаю только, но реально в это верит или захотел похайповать и накидать на вентилятор.
«Не заметить» реальных цен на спутниковый интернет. «Не заметить» что у старлинка разный upload speed с остальными системами. Не поинтересоваться какое покрытие у геостационарных спутников. Не поинтересоваться на ограничение по скорости/числу обслуживаемых абонентов на них. Не поинтересоваться о разности в антенах которые передают на 500км низкоорбитальной и на 40 000км геостационара. В том насколько все плохо когда абоненты в соседних домах.
и.т.д., и.т.п.
OpenVino в целом тоже ничо. Сильно меньше проблем чем рубленая Cuda)
Остальное, скорее для продуктизации. Но можно придумывать узкие примеры где дома нужно что-то низкоэнергопотребляющее.
1) Они два года назад выпустили сырое нечто. Сейчас большая часть багов пофикшена, я бы сказал.
2) Можно подавать на yolo 200-200, он будет в 4 раза быстрее, а по качеству просядет не так плохо и все равно может быть лучше SSD.
Для ваших целей вы не те модели смотрели/сравнивали. В целом вот вам список более быстрых кандидатов без глубокого погружения:
1) yolov5 достаточно отлажен и неплох уже. И там много быстрых моделей. Когда нужна скорость — там больше вариантов чем у v4. И поддержка неплохая/баги фиксят.
2) Yolox достаточно шустрый
3) Можно использовать указанные у вас yolov4, но дать им сильно меньшее разрешение на вход. Учитывая что это сильно более мощные модели, а ускорение будет пропорционально площади — может и вытянет до нужных вам скоростей.
4) Есть несколько платформ где можно у сеток достаточно удобно менять бэкбоны. И потестить тот же SSD/его ближайшие аналоги с более эффективными под вашу платформу бекбонами. Собственно detectron2, mmdetection, PaddleDetection
По бекбонам — Efficientnet, BlazeNet, младшие реснеты.
Но если честно, то думаю, чтобы вам не запариваться проще всего 1/2 пункты проверить.
Про решение задач таким путем. Классификаторы дают хорошую иллюзию того что задача решается. В реальности она решается лишь на используемом датасете, и куда хуже решается на живом проде:
1) Дебаг классификатора и поиск его проблем и ошибок куда сложнее чем у детекционной модели. Вы видите что возрастает число ошибок на проде — но нет адекватного варианта посмотреть что вызывает эти ошибки. Остается два подхода: переобучить бездумно или угадать. И то и то не продуктовое решение.
Конечно, если у вас классификация на трансформерах, и есть нормальная attention map, то там чуть проще. Но все равно криво будет.
Если обобщить этот пункт — используя классификацию вы теряете прозрачность пайплайна работы.
2) Точность классификатора намного ниже если вы его используете для поиска мелкого дефекта, чем когда вы его используете к кропу найденной целевой области. На некоторых задачах я видел ухудшение метрик почти на порядок (например распознавание каких-нибудь деталей одежды/частей машин, и.т.д.). Да, эта разница будет минимальная если у вас обучающий датасет на много миллионов примеров, а используются в качестве бекбонов трансформеры, либо очень жирные сети. Но у меня сомнение что оно у вас так.
Ваши метрики это хорошо подтверждают, чем меньше площадь дефекта — тем хуже метрика. А уж сколько вы на этом теряете — это второй вопрос. Проще всего оценить сравнив с кроссразметкой людьми.
3) Обычно в задачах вашего плана один из основных источников ошибок — некорректные данные. Неправильный угол съемки/недостаточная видимость и.т.д.
И тут вам либо надо будет ещё один классификатор бахнуть, либо из нормального детектора/сегментатора оценивать набор параметров для работы.
Теперь что касается «не было датасета для детекции».
Сделать детекционную разметку/контейнеризировать её через какую-нибудь Толоку/MechanicalTurk — неделя (и потом просто поднимать нужные задачи по мере подхода новых данных, можно даже автоматом). Есть много фирм которые это очень дешево под заказ делают (или размечают, беря на себя ещё боль поддержания всего и вся).
В случае неуспеха, безусловно, мы бы попробовали иной подход.
Что было мерилом неуспеха?:)
И да, если не секрет, у вас работает ещё тот алгоритм который описан в статье habr.com/ru/company/ods/blog/422873? Вы сравнивали точность с ним?
Оно конечно, не продуктовое небось было (в 2018 году в CV ещё не было удобного инженеринга моделей через MLFlow и Azure). Но делать для явных задач детекции классификацию — ну такое. Или у вас все же не чистая классификация, а какие-то детекторы?
Мне кажется что в картинке с радиантом есть программное часовое ведение (звезды на месте стоят). Когда оно не включено — там даже за минуту-две смаз звезд будет виден.
А на КДПВ — явно звезды все небо пролетели.
Смотрите. Приведу пример:
Никто не сомневается что написать процедуру выполнения нейронной сети в 2021 году можно на фортране. Особенно если в фирме есть такая экспертиза. Но:
1) Имеет ли это смысл когда никто не сможет это поддерживать?
2) Имеет ли это смысл когда заранее можно словить массу проблем совместимости (железо/сторонний код)?
Есть некоторые правила качественной разработки. И когда вы делаете новое решение на устаревших технологиях, делая с нуля — на вас будут странно смотреть.
Что касается реальности:
1) Обобщающая способность Хаара много ниже чем у нейронной сети. Даже слабой. Когда у вас будет больше реальных примеров — Хаар будет работать хуже
2) Обучение нейронной сети более стабильно к изменению датасета. У Хаара есть много внутренних параметров настройки. Передавая решение на нейронной сети — можно передавать модуль дообучения. Или контейнеризировать его. А с Хааром так просто уже не выйдет.
3) Портирование на конечное устройство выпущенное после ~2018г. 100% лучше работать будет с нейронной сетью, чем с Хааром.
4) «задача с заданным уровнем качества и производительности» — по опыту (это правда мы лет 6 назад делали), переход с Хаара на нейронки дает прирост в точности ~ раз в 5 ошибки падают, на той же производительности. Сегодня есть сетки посвежее = > положим в 5-10 раз будет прирост в точности.
И говорить что это прирост вам не нужен — не разумно. это же не столько прирост к точности, сколько страховка от возможных будущих проблем.
«Виолы и Джонса» в 2021 году…
Зачем вы его бенчмаркаете с SSD (какой бекбон?), Yolo 9000?.. Это не оптимизированные сетки 5 летней давности. По какому разрешению вы бенчмаркаете? Судя по размеру модели в памяти (от 700 метров) — вы даже не пробовали брать «нормальные» разрешения для оптимизации производительности. Нейронки обычно дают более качественный результат даже по разрешению в 4-8 раз меньше чем Хаар.
Почему нет графы «точность» рядом с «скорость»? Без этой второй графы любые сравнения бесполезны.
Попробуйте yolox-n, попробуйте SSD с легкими бекбонами. Можете обучить U-Net с 2-3 слоями и 8фильтрами.
Все это будет поддерживаться современным железом лучше чем Haar (дада, сейчас на каждом втором сопроцессоре будет ускоритель который можно заставить крутить нейронки ещё быстрее и оптимальнее без нагрузки на процессор).
Зачем тащить DeepStream в любительский проект?
Я даже от прода на нем всегда отговариваю. Уж лучше GStreamer для грабинга + тритон, например. Куда проще любая дальнейшая миграция, куда проще логика использования, и нет сложности с нестандартными сетками.
Это не делает статью хорошей и интересной, а подход примененный тут правильным (трекинг с 1 FPS это вообще круто). Но даже я, когда делаю что-то по фану делаю все на чистом питончике.
Хорошая статья. Но, целиком эту область в одной статье всегда сложно охватить:)
Я всегда рекомендую начать с существующих на рынке продуктов, с хорошего OpenSource, с качественно выстроенной разметки, и.т.д.
Это упрощает прототипирование, дальнейший полноценный ресерч.
В целом набор своих методов/подходов описывал на VC в пачке статей (1,2,3).
LeanDS хорош, но он скорее про команды/фирмы которые уже вышли их стадии MVP, имеют хоть какой-то штат, где нужна плотная коммуникация между внутренним заказчиком/исполнителем. Если ML нужен мелкой фирме, то там нужно понимать как минимизировать цену входа.
В StyleGan? В некотором ограниченном размере ракурсов - можно (см. раздел "повороты"). Но, глобально, ничего не мешает решать вопрос поворота через другие подходы. Например через такой - https://github.com/AliaksandrSiarohin/first-order-model
Это алгоритмы про разное:)
Почти все что описано в статье — можно сделать и не через StyleGAN. Просто везде будут свои плюсы и минусы.
А так, никто не отменяет комбинирования алгоритмов. Создать несуществующее лицо, наложить чего через дипфейк.
1) Вы используете Dlib распознавание лиц. Но сейчас 2022 год уже. Не надо так делать. Вот тут я чуть подробнее рассказываю почему так не надо — www.youtube.com/watch?v=2fnNhYCpToE и какие есть альтернативы (как детектор лиц на питоне я может быть даже MediaPipe посоветовал бы сейчас)
2) Для тестирования вы используете… «ORL» — это база для тестирования лиц собранная с 1992 до 1994 года. Тогда не то что нейронных сетей не было, тогда ещё и Haar, HOG и половины алгоритмов классического CV не было. Тогда решались другие цели и задачи.
(чб картинки полного размера которые смотрят в камеру — это не совсем того что вы хотите от датасета)
3) Вы что-то говорите про скорость выполнения. Но не сравниваете с сотнями других современных подходов, которые умеют оптимизироваться под железо. И под RPi и под другие куда более дешевые железки. И вообще сейчас RPi странное решение для FaceRecognition. Например приведу пример Maixduino который с камерой выходит дешевле, а по производительности дешевле
А ещё есть ESP32 который формально тоже может распознавать. Там есть полный аналог чего вы сделали из коробки. Примерно за 5 баксов с камерой, примерно 5fps.
Выбор RPi у вас абсолютно нелогичен:)
4) Вы начинаете рассказывать про ошибки других систем, но не показываете проблемы/ошибки вашей системы/вашего подхода (dlib вы не сможете переобучить, занесение в базу будет иметь кучу ошибок, и.т.д.).
Есть много аналогичных USB камер.
Но, в целом, если есть желание помучить 3D, то проще взять готовую камеру которая его выдает. Я недавно делал обзор на OAK-D-Lite, там ещё есть сопроцессор для нейронных сетей по мощности сравнимы с Jetson Nano. Оно будет чуть дороже варианта выше или из статьи, но качество лучше.
Есть много аналогичных камер выдающих 3D. Есть даже проекционные (Orbbec Astra например), примерно в ту же стоимость. Года 3 назад делал обзор, но с тех пор много нового появилось.
Если уже не терпится самому все делать — очень советую вместо классических алгоритмов восстановления 3D использовать все же нейроночку…
Он с некоторым восторгом смотрел на реле, радостно сказав что за пять лет работы в моем районе Москвы в третий раз ставит такое/видит что этим кто-то озаботился…
Не понимаю только, но реально в это верит или захотел похайповать и накидать на вентилятор.
«Не заметить» реальных цен на спутниковый интернет. «Не заметить» что у старлинка разный upload speed с остальными системами. Не поинтересоваться какое покрытие у геостационарных спутников. Не поинтересоваться на ограничение по скорости/числу обслуживаемых абонентов на них. Не поинтересоваться о разности в антенах которые передают на 500км низкоорбитальной и на 40 000км геостационара. В том насколько все плохо когда абоненты в соседних домах.
и.т.д., и.т.п.
Остальное, скорее для продуктизации. Но можно придумывать узкие примеры где дома нужно что-то низкоэнергопотребляющее.
habr.com/ru/post/374
Но им нельзя пользоваться чаще чем раз в какое-то время.
Раньше можно было заходить на страницу поста в голосе и комментировать ( mycod.net/index.php/answer/index/36994 ). Но мне кажется это пофиксили.
2) Можно подавать на yolo 200-200, он будет в 4 раза быстрее, а по качеству просядет не так плохо и все равно может быть лучше SSD.
1) yolov5 достаточно отлажен и неплох уже. И там много быстрых моделей. Когда нужна скорость — там больше вариантов чем у v4. И поддержка неплохая/баги фиксят.
2) Yolox достаточно шустрый
3) Можно использовать указанные у вас yolov4, но дать им сильно меньшее разрешение на вход. Учитывая что это сильно более мощные модели, а ускорение будет пропорционально площади — может и вытянет до нужных вам скоростей.
4) Есть несколько платформ где можно у сеток достаточно удобно менять бэкбоны. И потестить тот же SSD/его ближайшие аналоги с более эффективными под вашу платформу бекбонами. Собственно detectron2, mmdetection, PaddleDetection
По бекбонам — Efficientnet, BlazeNet, младшие реснеты.
Но если честно, то думаю, чтобы вам не запариваться проще всего 1/2 пункты проверить.
1) Дебаг классификатора и поиск его проблем и ошибок куда сложнее чем у детекционной модели. Вы видите что возрастает число ошибок на проде — но нет адекватного варианта посмотреть что вызывает эти ошибки. Остается два подхода: переобучить бездумно или угадать. И то и то не продуктовое решение.
Конечно, если у вас классификация на трансформерах, и есть нормальная attention map, то там чуть проще. Но все равно криво будет.
Если обобщить этот пункт — используя классификацию вы теряете прозрачность пайплайна работы.
2) Точность классификатора намного ниже если вы его используете для поиска мелкого дефекта, чем когда вы его используете к кропу найденной целевой области. На некоторых задачах я видел ухудшение метрик почти на порядок (например распознавание каких-нибудь деталей одежды/частей машин, и.т.д.). Да, эта разница будет минимальная если у вас обучающий датасет на много миллионов примеров, а используются в качестве бекбонов трансформеры, либо очень жирные сети. Но у меня сомнение что оно у вас так.
Ваши метрики это хорошо подтверждают, чем меньше площадь дефекта — тем хуже метрика. А уж сколько вы на этом теряете — это второй вопрос. Проще всего оценить сравнив с кроссразметкой людьми.
3) Обычно в задачах вашего плана один из основных источников ошибок — некорректные данные. Неправильный угол съемки/недостаточная видимость и.т.д.
И тут вам либо надо будет ещё один классификатор бахнуть, либо из нормального детектора/сегментатора оценивать набор параметров для работы.
Теперь что касается «не было датасета для детекции».
Сделать детекционную разметку/контейнеризировать её через какую-нибудь Толоку/MechanicalTurk — неделя (и потом просто поднимать нужные задачи по мере подхода новых данных, можно даже автоматом). Есть много фирм которые это очень дешево под заказ делают (или размечают, беря на себя ещё боль поддержания всего и вся).
Что было мерилом неуспеха?:)
И да, если не секрет, у вас работает ещё тот алгоритм который описан в статье habr.com/ru/company/ods/blog/422873? Вы сравнивали точность с ним?
habr.com/ru/company/ods/blog/422873
Надо сказать что в прошлый раз у вас модель была сильно лучше и адекватнее, судя по той статье:)
Оно конечно, не продуктовое небось было (в 2018 году в CV ещё не было удобного инженеринга моделей через MLFlow и Azure). Но делать для явных задач детекции классификацию — ну такое. Или у вас все же не чистая классификация, а какие-то детекторы?
А на КДПВ — явно звезды все небо пролетели.
Никто не сомневается что написать процедуру выполнения нейронной сети в 2021 году можно на фортране. Особенно если в фирме есть такая экспертиза. Но:
1) Имеет ли это смысл когда никто не сможет это поддерживать?
2) Имеет ли это смысл когда заранее можно словить массу проблем совместимости (железо/сторонний код)?
Есть некоторые правила качественной разработки. И когда вы делаете новое решение на устаревших технологиях, делая с нуля — на вас будут странно смотреть.
Что касается реальности:
1) Обобщающая способность Хаара много ниже чем у нейронной сети. Даже слабой. Когда у вас будет больше реальных примеров — Хаар будет работать хуже
2) Обучение нейронной сети более стабильно к изменению датасета. У Хаара есть много внутренних параметров настройки. Передавая решение на нейронной сети — можно передавать модуль дообучения. Или контейнеризировать его. А с Хааром так просто уже не выйдет.
3) Портирование на конечное устройство выпущенное после ~2018г. 100% лучше работать будет с нейронной сетью, чем с Хааром.
4) «задача с заданным уровнем качества и производительности» — по опыту (это правда мы лет 6 назад делали), переход с Хаара на нейронки дает прирост в точности ~ раз в 5 ошибки падают, на той же производительности. Сегодня есть сетки посвежее = > положим в 5-10 раз будет прирост в точности.
И говорить что это прирост вам не нужен — не разумно. это же не столько прирост к точности, сколько страховка от возможных будущих проблем.
Зачем вы его бенчмаркаете с SSD (какой бекбон?), Yolo 9000?.. Это не оптимизированные сетки 5 летней давности. По какому разрешению вы бенчмаркаете? Судя по размеру модели в памяти (от 700 метров) — вы даже не пробовали брать «нормальные» разрешения для оптимизации производительности. Нейронки обычно дают более качественный результат даже по разрешению в 4-8 раз меньше чем Хаар.
Почему нет графы «точность» рядом с «скорость»? Без этой второй графы любые сравнения бесполезны.
Попробуйте yolox-n, попробуйте SSD с легкими бекбонами. Можете обучить U-Net с 2-3 слоями и 8фильтрами.
Все это будет поддерживаться современным железом лучше чем Haar (дада, сейчас на каждом втором сопроцессоре будет ускоритель который можно заставить крутить нейронки ещё быстрее и оптимальнее без нагрузки на процессор).
Я даже от прода на нем всегда отговариваю. Уж лучше GStreamer для грабинга + тритон, например. Куда проще любая дальнейшая миграция, куда проще логика использования, и нет сложности с нестандартными сетками.
Это не делает статью хорошей и интересной, а подход примененный тут правильным (трекинг с 1 FPS это вообще круто). Но даже я, когда делаю что-то по фану делаю все на чистом питончике.
Мне казалось что cvat был 18ого, правда там в 20ом какой-то большой апдейт был.
Или он вам сильно меньше нравиться? Мы часто какую-то мелочевку по видео через него размечаем.
Я всегда рекомендую начать с существующих на рынке продуктов, с хорошего OpenSource, с качественно выстроенной разметки, и.т.д.
Это упрощает прототипирование, дальнейший полноценный ресерч.
В целом набор своих методов/подходов описывал на VC в пачке статей (1,2,3).
LeanDS хорош, но он скорее про команды/фирмы которые уже вышли их стадии MVP, имеют хоть какой-то штат, где нужна плотная коммуникация между внутренним заказчиком/исполнителем. Если ML нужен мелкой фирме, то там нужно понимать как минимизировать цену входа.
В StyleGan? В некотором ограниченном размере ракурсов - можно (см. раздел "повороты").
Но, глобально, ничего не мешает решать вопрос поворота через другие подходы. Например через такой - https://github.com/AliaksandrSiarohin/first-order-model
Почти все что описано в статье — можно сделать и не через StyleGAN. Просто везде будут свои плюсы и минусы.
А так, никто не отменяет комбинирования алгоритмов. Создать несуществующее лицо, наложить чего через дипфейк.