Я вот не понял. Задается вопрос «что ждёт». И нет ни одного ответа на эту тему. Ни по деньгам, ни по тому насколько нужны специалисты, и какие специалисты. Пардон, но даже я более обстоятельное видео недавно запилил —
Если кто кликбейтнулся, и хоть какие-то оценки хочет)
Вы в тексте путаете доход с выручкой, а доллары с юанями. И все цифры не соответствуют официальным отчётам. Прямо флеш-рояль из ошибок собрали!:) 1 2 3 4 5
Добрый день. Не советую использовать алгоритмы разницы фона. Это алгоритмы 15-20 летней давности. Уже лет 10 назад использовались куда более хитрые подходы. В своей статье про трекинг я их упоминал (predator, и.т.д.).
За 12 лет работы с CV мы не видели ни одной задачи где бы такие алгоритмы стабильно зашли. Они нестабильны к любым изменениям условий, не работают для людей чей цвет сравним с фоном, и.т.д.
На мой взгляд это единственный правильный путь в ML. Обучение через курсы/через лекции — всё пусто. ML про «научится бороться с незнакомыми проблемами», а это постигается только через боль и практику.
Чуть более подробно на эту тему видео даже как-то делал, ибо осмысленности для статьи на Хабр мало, а для своего блога долго и влом на эту тему писать было:
Ещё полезное, о чём я там рассказываю, а тут нет — это всякие kaggle, пробовать участвовать там. Читать адекватные сообщества/адекватные подборки, чтобы во времени оставаться привязанным. А остальное да- всё норм написано.
Ну разве что наставников на мой взгляд не на какой-то платформе искать, а в ODS-е чатиться и общаться)
Моя позиция была всё же, что оптический трекер не нужен когда есть хорошая детекция. И я приводил много примеров когда детекторы дают высокую скорость на процессоре.
Сетей которые быстро детектируют достаточно много. Конечно, их нужно на железо портировать и пробовать максимально его использовать. И круто, что в их семействе появилась ещё одна.
Мы с этой задачей сталкивались в конце 16-начале 17 года в первый раз, месяца два потратили. И где-то в середине 17ого второй раз, месяца за три сделали, там было больше задач.
Это ещё до появления этих статей.
И там и там сделали вполне рабочий бизнес прототип который позволял внедрить его в бизнес. В одной фирме, как я слышал, следующие года два вообще ничего не меняли, у них даже не было на поддержке специалистов по DL. Во второй активно развивали, но вроде основная структура тоже пару лет продержалась. Может быть потом они что-то аналогичное вкрутили, но мы им только другие части продукта помогали развивать.
Статьи хорошие, сейчас если бы хоть по одной был пример исходников — взял бы пробовать в первую очередь. Но сейчас выбор есть. Я часто натыкался на сети/подходы которые могут решить эту задачу.
Плюс тут есть ещё такая штука. Мы в своих работах обычно не занимаемся большим ресёрчем. У нас в большинстве своём не очень большие, ограниченные договора, в рамках которых надо максимально быстро сделать прототип. Мы стараемся максимально заложить в договор разные вариации на случай если что-то не будет работать, но сверять 5-6 сетей обычно сил и рук нет. Обычно берём 2-3 подхода, которые выглядят наиболее перспективными. И как только на каком-то достигаем продуктовой точности — останавливаемся, решаем другие вопросы эксплуатации.
Это не про трекинг задача, а про детекцию всё же. Если детектор хорошо работает — то и не надо трекать. Если не работает — трекинг ничего нового не даст.
Но это и не суть. Сделать стабильное решение для такой задачи + запилить интерфейсы — может без проблем стоить несколько миллионов рублей. При этом 100% стабильного решения оно не даст + будет требовать человека на поддержку время от времени.
Как результат — такие проекты не окупаются.
Куда проще такие задачи делаются через понижение цены работы разметчика. Сделать разметку через Толоку, и всё. Это по цене и стабильности будет на порядок лучше нейронки, будет устойчивой к странным костюмом и кривой съёмке.
Но я думаю что даже это не выгодно будет.
Ну… Могу лишь сказать, что по нашему опыту — и в OpenVino и в TensorRT неплохо можно переносить кастомные архитектуры, если нет там совсем уже хитрых слоёв (да и их можно с большей болью перенести).
Года полтора назад всё хуже было. А сейчас если конвертится в ONNX — скорее всего заработает.
Нужно ли делать инференс на OpenVino? У нас есть задачи где так и делается. НО не уверен что это везде применимо.
Мне кажется, что пока единственный удачный эксперимент в применении Transformer к картинкам был вот этот — arxiv.org/pdf/2005.12872.pdf (я даже по его поводу небольшую статью накатал — cv-blog.ru/?p=310 )
Трансформер всё же достаточно большой и нетривиальный. Подкатывать его ради минимального улучшение точности можно только если это какая-то уже хорошо вылизанная задача. Чтобы получить последние единицы точности. Его и прикрутить сложно. И обучить. И датасет должен быть огромным.
Я думаю что такие статьи уже появились, или вот-вот должны появиться. Но смысла использовать в продакшне такие эксперименты первое время точно не будет.
OpenCV хорош для прода. Он очень много что простого умеет — и достаточно эффективно.
Взять хотя бы что OpenCV инференс нейронок эффективнее чем на дефолтном TensorFlow или PyTorch.
И это не считая OpenVino.
Захват камер опять же. Простые подготовки/преобразоваия изображений.
И работает почти везде.
Изначально заказчик использовал Google, мы целиком свою переделали.
Пока обучали по маленькой базе — ошибок стало где-то на 30-40% меньше чем у Google, когда переобучили по большой — сильно лучше.
Но у нас достаточно много разных OCR сеток под разные проекты. Из 3-4 выбирали.
Но на 10к примерах нейронной сети проще их запомнить, чем генерализовать алгоритм, поэтому нужна аугментация.
Тоже так думали. Но на практике логика немного другая оказывается. Делали распознавание ценников однажды (описание текстовое +цена). У нас по тексту было где-то 6-7 тысяч неплохо размеченных ценников (где ~95% были правильные). В итоге нейронка давала где-то 80% точность (сейчас числа условные, точно не помню, давно было).
При этом датасет был достаточно разнообразный по разным магазинам, камерам и типам продуктов.
Нам было понятно, что если точность датасета вывести под 100%, то где-то треть ошибок уйдёт. Но это надо было заново перепроверить весь датасет.
И тут заказчик решил запустить нашу нейронку обучиться не по маленькому хорошему датасету, а по всему продуктовому, где было где-то тысяч 300 изображений. Который нефига не сбалансированный, и имел точность разметки ниже 90%
На этом качество скакнуло куда больше, чем на уточнении первоначального могло бы.
Так что не советую недооценивать объём больших данных. Не даром же все современные нейронки используемые в медицине обучаются по очень большым объёмам плохо размеченных данных (а потом тюнингуются под задачку).
Это да.
Но тут как всегда «слишком много если». Есть ситуации когда такой трекинг может быть и проще… :) Например если камеры 3D и можно создать плотное поле. Мне кажется, что у Amazon Go примерно так и должно быть реализовано. Напихали 3d камер сверху с шагом полтора метра — и стабильный трекинг готов!
В целом я всё это месяц назад в статье своей на хабре рассказывал.
Если кто кликбейтнулся, и хоть какие-то оценки хочет)
Ну, с другой стороны, чего можно ждать…
1
2
3
4
5
За 12 лет работы с CV мы не видели ни одной задачи где бы такие алгоритмы стабильно зашли. Они нестабильны к любым изменениям условий, не работают для людей чей цвет сравним с фоном, и.т.д.
Чуть более подробно на эту тему видео даже как-то делал, ибо осмысленности для статьи на Хабр мало, а для своего блога долго и влом на эту тему писать было:
Ещё полезное, о чём я там рассказываю, а тут нет — это всякие kaggle, пробовать участвовать там. Читать адекватные сообщества/адекватные подборки, чтобы во времени оставаться привязанным. А остальное да- всё норм написано.
Ну разве что наставников на мой взгляд не на какой-то платформе искать, а в ODS-е чатиться и общаться)
Обязательно попробую!
Сетей которые быстро детектируют достаточно много. Конечно, их нужно на железо портировать и пробовать максимально его использовать. И круто, что в их семействе появилась ещё одна.
UFO ты здесь?
Это ещё до появления этих статей.
И там и там сделали вполне рабочий бизнес прототип который позволял внедрить его в бизнес. В одной фирме, как я слышал, следующие года два вообще ничего не меняли, у них даже не было на поддержке специалистов по DL. Во второй активно развивали, но вроде основная структура тоже пару лет продержалась. Может быть потом они что-то аналогичное вкрутили, но мы им только другие части продукта помогали развивать.
Статьи хорошие, сейчас если бы хоть по одной был пример исходников — взял бы пробовать в первую очередь. Но сейчас выбор есть. Я часто натыкался на сети/подходы которые могут решить эту задачу.
Плюс тут есть ещё такая штука. Мы в своих работах обычно не занимаемся большим ресёрчем. У нас в большинстве своём не очень большие, ограниченные договора, в рамках которых надо максимально быстро сделать прототип. Мы стараемся максимально заложить в договор разные вариации на случай если что-то не будет работать, но сверять 5-6 сетей обычно сил и рук нет. Обычно берём 2-3 подхода, которые выглядят наиболее перспективными. И как только на каком-то достигаем продуктовой точности — останавливаемся, решаем другие вопросы эксплуатации.
Но это и не суть. Сделать стабильное решение для такой задачи + запилить интерфейсы — может без проблем стоить несколько миллионов рублей. При этом 100% стабильного решения оно не даст + будет требовать человека на поддержку время от времени.
Как результат — такие проекты не окупаются.
Куда проще такие задачи делаются через понижение цены работы разметчика. Сделать разметку через Толоку, и всё. Это по цене и стабильности будет на порядок лучше нейронки, будет устойчивой к странным костюмом и кривой съёмке.
Но я думаю что даже это не выгодно будет.
Года полтора назад всё хуже было. А сейчас если конвертится в ONNX — скорее всего заработает.
Нужно ли делать инференс на OpenVino? У нас есть задачи где так и делается. НО не уверен что это везде применимо.
Трансформер всё же достаточно большой и нетривиальный. Подкатывать его ради минимального улучшение точности можно только если это какая-то уже хорошо вылизанная задача. Чтобы получить последние единицы точности. Его и прикрутить сложно. И обучить. И датасет должен быть огромным.
Я думаю что такие статьи уже появились, или вот-вот должны появиться. Но смысла использовать в продакшне такие эксперименты первое время точно не будет.
Взять хотя бы что OpenCV инференс нейронок эффективнее чем на дефолтном TensorFlow или PyTorch.
И это не считая OpenVino.
Захват камер опять же. Простые подготовки/преобразоваия изображений.
И работает почти везде.
Пока обучали по маленькой базе — ошибок стало где-то на 30-40% меньше чем у Google, когда переобучили по большой — сильно лучше.
Но у нас достаточно много разных OCR сеток под разные проекты. Из 3-4 выбирали.
Тоже так думали. Но на практике логика немного другая оказывается. Делали распознавание ценников однажды (описание текстовое +цена). У нас по тексту было где-то 6-7 тысяч неплохо размеченных ценников (где ~95% были правильные). В итоге нейронка давала где-то 80% точность (сейчас числа условные, точно не помню, давно было).
При этом датасет был достаточно разнообразный по разным магазинам, камерам и типам продуктов.
Нам было понятно, что если точность датасета вывести под 100%, то где-то треть ошибок уйдёт. Но это надо было заново перепроверить весь датасет.
И тут заказчик решил запустить нашу нейронку обучиться не по маленькому хорошему датасету, а по всему продуктовому, где было где-то тысяч 300 изображений. Который нефига не сбалансированный, и имел точность разметки ниже 90%
На этом качество скакнуло куда больше, чем на уточнении первоначального могло бы.
Так что не советую недооценивать объём больших данных. Не даром же все современные нейронки используемые в медицине обучаются по очень большым объёмам плохо размеченных данных (а потом тюнингуются под задачку).
www.quora.com/What-is-the-best-image-labeling-tool-for-object-detection
2) Обучить любую детекционную сетку. Например — YOLOv4 — github.com/AlexeyAB/darknet#how-to-train-to-detect-your-custom-objects
Или сетку попроще. В Tensorflow detection API много разных есть, тренируются они наверное попроще — towardsdatascience.com/custom-object-detection-using-tensorflow-from-scratch-e61da2e10087
3) Использовать мой пример который в конце статьи, где используется SORT. Он склеит детекции в треки
Но тут как всегда «слишком много если». Есть ситуации когда такой трекинг может быть и проще… :) Например если камеры 3D и можно создать плотное поле. Мне кажется, что у Amazon Go примерно так и должно быть реализовано. Напихали 3d камер сверху с шагом полтора метра — и стабильный трекинг готов!