В статье идет сравнение с устаревшими на тот момент подходами. Если вы откроете бенчмарки, то найдете что в те годы были подходы которые выдавали точность не хуже.
В статье был явный акцент на то что «Вот так они тоже умеют». И да, на тот момент это был прикольный факт.
По современным меркам у этих подходов вообще все не очень.
Ну и «machinelearningmastery» это неплохой список примеров. Но не рефенс того «как надо делать продуктовую систему».
А вообще, на будущее, в современном мире ML любая статья старше двух лет должны вызывать подозрения. Писал как-то об этом.
Кроме того, ваше явное отличие в структуре данных от регулярного языка. И что у вас оно применим — надо доказывать.
Я бы начал с более простых/более подходящих сетей;)
А зачем вам сверточная сеть? Сверточные сети для объектов обладающих локальной корреляцией (изображение/звук/и.т.д.). А вы на её вход подаете какой-то ембеддинг (если я правильно понял).
Скорее всего если вы будете использовать однослойную полносвязную сеть результат будет не хуже.
Визуализация вен это всегда забавно.
Мы когда-то делали это для систем биометрической идентификации людей.
Но к продукту есть пара вопросов.
1) При чем тут ИИ? Операция визуализации вен обычно делалась 1-2 фильтрами более классическими. Аппараты которые для этого использовались лет 10 назад это так и делали — www.youtube.com/watch?v=uWjx4yyNPww
2) В чем отличие от существующих аппаратов? Многие из них достаточно маленькие и компактные, например такие — www.medicalexpo.com/prod/christie-medical/product-122281-859227.html
Привет! Да, за TinyML будущее. Но статья немного сумбурно написала, особенно со стороны ML-специалиста.
1) У вас идет путаница TensorFlow/TensorFlow lite/TensorFlow Micro и системами их инференса (не все из того что вы приводите использует /требует TensorFlow)
2) Вы приводите лишь несколько вариантов запуска на ESP32. В реальности из больше. И у того же Eloquent много проблем (например у него нет моделей исходных для CV, он конвертирует рандомно найденные в инете). Если хотите, посмотрите, я тут обзор делал про другие способы — youtu.be/w_sCTPDuutQ
3) Сегодня есть платы примерно в цену ESP32, но с куда большей производительностью. Про k210 и Alwinner'овский процессор я тут рассказываю — youtu.be/Hf4Ra59_DCA
И, может быть любопытно, вот тут я показываю минималистический End-to-end пример с обучением для ESP32 — youtu.be/ms6uoZr-4dc
Где-то я ещё видел сравнения детекторов по классическим задачам/датасетам, yolov5 было не впереди.
А вот про это можно подробнее?
Говорят вот эта имплементация ускоряет на tensorrt ощутимо — github.com/enazoe/yolo-tensorrt
Но сам не пробовал, все хочу. Говорят там NMS и какие-то операции вокруг него перенесены тоже на TensorRT.
1) Максимальное качество? Там много претендентов, но все Трансформеры.
2) Максимальное качество на свертках? Там вроде Yolov4-p7
3) Максимальное качество при каких-то скоростях? Ну, там есть и yolop и yolox github.com/hustvl/YOLOP github.com/Megvii-BaseDetection/YOLOX
Но вообще там ооочень много вариантов если лезть внутрь.
4) Максимальное удобство конвертации на разные платформы? Но если разобраться то оказывается что даже в TensorRT yolov5 конвертируется не оптимально. Есть кастомные конвертаторы которые ускоряют примерно в 2 раза итоговые модели…
Это не отмменяет что Yolov5 очень удобный и быстрый для использования. Но говорить что он «SOTA». Ну, такое…
1) там была ещё пачка улучшений при обучении, судя по их статьям. Не только повышение размера
2) зависит от задачи и от ракурсов. Посмотрите на примеры проблем которые я привожу (в видео чуть более полные примеры). Для большинства задач с которыми работали мы просто за счёт переобучения детектора число ошибок падало в несколько раз. Но да, я согласен что могут быть задачи где это не критично. Там не должно быть сложных условий наблюдения где объект теряется, постоянного входа и выхода из кадров новых объектов.
И кстати, для рук там по дефолту, если в кадре нет двух рук, детектор достаточно часто проверяет наличие.
Я сам не специалист в оценке скорости такой разметки. Но когда мы привлекаем наших разметчиков то я обычно закладываю где-то 500 картинок в час на такой тип (10 в минуту). Сам я конечно за минуту штук 20-30 прокликиваю, но долго в таком режиме наверное нельзя (я максимум минут 20-30 обычно так делаю чтобы оценить что за задача вообще).
Вообще на Хабре много кто специализируется именно на лейблинге, можно позвать например kucev, думаю что он может примерно оценить какие у них стандарты на такие таски.
Однажды, в районе 2015-2016 года одному нашему заказчику продали сервак с Xeon Phi. А заказчик этот заказывал у нас различные computer vision решения для распознавания составов.
Это было на границе расцвета сверточных сетей. И у нас была было два решения. Одно на caffe (ещё не доделанное), второе на классическом computer vsion: что-то вокруг OpenCV, haar, решающие деревья, фильтры канни и.т.д.
И попросил нас заказчик все это дело перенести на Xeon Phi. Мы, естественно, сказали что сначала надо потестить, уж большо странная машина. И где-то несколько недель мы тестировали. Воспоминания живы до сих пор:)
Главное моё непонимание тогда вызвало целеполагание этого девайса. Для кого/для какой аудитории? Процессы для которых была важна скорость одного ядра по понятным причинам работали не очень. По этому отваливался классичеcкий ComputerVision (или требовалось многое переписывать).
Для нейронок на тот момент не работало почти ничего. Билдились только очень обрубленные и старые библиотеки.
Я тогда попробовал посмотреть вокруг и понял что у Xeon Phi тогда было лишь две группы пользователей:
1) Там где закупщики не советовались с разработчиками. А маркетинг у Intel всегда был сильный
2) Метеорологи. Они могли очень просто использовать распараллеливание. В Phi была какая-то неплохая поддержка фортрана.
Мне кажется что в плане ML intel потом как-то развивал платформу, но первоначального опыта хватило чтобы больше нигде с ней не связываться.
Штука в том что процессоров для ML сейчас сотни (вот тут подборка github.com/basicmi/AI-Chip/blob/master/README.md ). И до массового применения доходят единицы. Ещё десятки это очень corner-case для специфических применений (та же ambarella).
И гадать чем этот хорош — абсолютно бесполезно обычно, так как 99% информации держится в секрете..:)
С второй половиной все ок (хранение/кластер/сравнение, и.т.д.).
А вот с первой вы что-то намудрили. Это (sift,orb,Akaze, FAST,...) алгоритмы 10-летней давности. Сейчас много что поновее есть. Можно и нейросетевые дескрипторы брать. Но в целом, конечно, такие задачи скорее через формирование правильных embedding решаются. Чтобы не делать этого жесткого матчинга.
Спасибо!
Ну, статье уже год)
Ещё есть RV1109 с такими безумными девайсами — en.t-firefly.com/product/dev/camc1126s2u.html
Год назад чего-то из этого не было.
Можно ещё вглубь уходить и смотреть что на RK3399Pro есть штук 5 разных бордов от разных производителей.
Я неделю назад делал небольшой апдейт на своем Youtube канале. Но там я скорее акцентировал внимание на всяких совсем дешевых платах — youtu.be/Hf4Ra59_DCA
В целом все правильно. Но очень кратенько. Сейчас пока что есть способы получать деньги в России, но их становится все меньше и меньше.
С переездом — много разумных стран подсуетились и сейчас упрощают въезд для разработчиков из России.
Я недавно опросил ~15-20 компаний вокруг себя, с которыми мы работаем по COmputer Vision/где у меня товарищи сделал примерный обзор ситуации в Data Science — youtu.be/sf-g11yKu54 там же в описании подборка хороших гайдов. И про вывод денег из/в Россию, и про юридические особенности переезда.
С удовольствием бы почитал про особенности Ingenic T40
Обычно исходя из особенностей платформ можно заранее понять где что работать будет/не будет. Например почему не использовать более мощную сетку детекции? Какие ограничения на сети/на fps. Почему не использовать сегментацию/детекции с поворотом (переход все же плохо описывается прямоугольным BoundingBox). И.т.д., и.т.п.
Ещё отмечу, что у вас не понятна постановка задачи из написанного. В общем случае переход искать сложно. Скорее всего у вас авторегистраторы? Это очень сильно сжимает домен данных, можно более точно нацелиться на то как переход выглядит для ракурсов с дороги. Скорее всего у вас машина не будет ехать перпендикулярно переходу.
End-to-end тесты говорят про качество алгоритма сильно больше чем метрики.
Не очень понимаю про какие телодвижения вы говорите.
Есть Torch-TensorRT | TF-TRT, где даже ничего менять не надо.
Есть инструменты инференса чистого. ONNX-Runtime (а вот тут я ещё десяток разбираю — habr.com/ru/company/recognitor/blog/524980 ), которые не тащат с собой кучу дополнительного кода + 1-2 строчками на разных платформах используются.
В статье был явный акцент на то что «Вот так они тоже умеют». И да, на тот момент это был прикольный факт.
По современным меркам у этих подходов вообще все не очень.
Ну и «machinelearningmastery» это неплохой список примеров. Но не рефенс того «как надо делать продуктовую систему».
А вообще, на будущее, в современном мире ML любая статья старше двух лет должны вызывать подозрения. Писал как-то об этом.
Кроме того, ваше явное отличие в структуре данных от регулярного языка. И что у вас оно применим — надо доказывать.
Я бы начал с более простых/более подходящих сетей;)
Скорее всего если вы будете использовать однослойную полносвязную сеть результат будет не хуже.
Мы когда-то делали это для систем биометрической идентификации людей.
Но к продукту есть пара вопросов.
1) При чем тут ИИ? Операция визуализации вен обычно делалась 1-2 фильтрами более классическими. Аппараты которые для этого использовались лет 10 назад это так и делали — www.youtube.com/watch?v=uWjx4yyNPww
2) В чем отличие от существующих аппаратов? Многие из них достаточно маленькие и компактные, например такие — www.medicalexpo.com/prod/christie-medical/product-122281-859227.html
1) У вас идет путаница TensorFlow/TensorFlow lite/TensorFlow Micro и системами их инференса (не все из того что вы приводите использует /требует TensorFlow)
2) Вы приводите лишь несколько вариантов запуска на ESP32. В реальности из больше. И у того же Eloquent много проблем (например у него нет моделей исходных для CV, он конвертирует рандомно найденные в инете). Если хотите, посмотрите, я тут обзор делал про другие способы — youtu.be/w_sCTPDuutQ
3) Сегодня есть платы примерно в цену ESP32, но с куда большей производительностью. Про k210 и Alwinner'овский процессор я тут рассказываю — youtu.be/Hf4Ra59_DCA
И, может быть любопытно, вот тут я показываю минималистический End-to-end пример с обучением для ESP32 — youtu.be/ms6uoZr-4dc
«Кстати ее нет на paperswithcode, так как нет статьи»
Иногда AlexeyAB интересные картинки у себя в твиттере (https://twitter.com/alexeyab84) постит с реальным сравнением разных yolo
Например — twitter.com/alexeyab84/status/1481982576818630662/photo/1
Где-то я ещё видел сравнения детекторов по классическим задачам/датасетам, yolov5 было не впереди.
Говорят вот эта имплементация ускоряет на tensorrt ощутимо — github.com/enazoe/yolo-tensorrt
Но сам не пробовал, все хочу. Говорят там NMS и какие-то операции вокруг него перенесены тоже на TensorRT.
paperswithcode.com/sota/object-detection-on-coco
paperswithcode.com/task/real-time-object-detection
1) Максимальное качество? Там много претендентов, но все Трансформеры.
2) Максимальное качество на свертках? Там вроде Yolov4-p7
3) Максимальное качество при каких-то скоростях? Ну, там есть и yolop и yolox
github.com/hustvl/YOLOP
github.com/Megvii-BaseDetection/YOLOX
Но вообще там ооочень много вариантов если лезть внутрь.
4) Максимальное удобство конвертации на разные платформы? Но если разобраться то оказывается что даже в TensorRT yolov5 конвертируется не оптимально. Есть кастомные конвертаторы которые ускоряют примерно в 2 раза итоговые модели…
Это не отмменяет что Yolov5 очень удобный и быстрый для использования. Но говорить что он «SOTA». Ну, такое…
1) в тексте есть прямое упоминание
2) Про sota я бы поспорил...)
1) там была ещё пачка улучшений при обучении, судя по их статьям. Не только повышение размера
2) зависит от задачи и от ракурсов. Посмотрите на примеры проблем которые я привожу (в видео чуть более полные примеры). Для большинства задач с которыми работали мы просто за счёт переобучения детектора число ошибок падало в несколько раз. Но да, я согласен что могут быть задачи где это не критично. Там не должно быть сложных условий наблюдения где объект теряется, постоянного входа и выхода из кадров новых объектов.
И кстати, для рук там по дефолту, если в кадре нет двух рук, детектор достаточно часто проверяет наличие.
Вообще на Хабре много кто специализируется именно на лейблинге, можно позвать например kucev, думаю что он может примерно оценить какие у них стандарты на такие таски.
Спасибо! Да, вы все правильно описали.
Если человек в кадре один/два, если нет высоких требований на точность детекции то это 500-1500 в час. В зависимости от анотатора и датасета.
При разметке скелетов там конечно уже все очень медленно становится.
Это было на границе расцвета сверточных сетей. И у нас была было два решения. Одно на caffe (ещё не доделанное), второе на классическом computer vsion: что-то вокруг OpenCV, haar, решающие деревья, фильтры канни и.т.д.
И попросил нас заказчик все это дело перенести на Xeon Phi. Мы, естественно, сказали что сначала надо потестить, уж большо странная машина. И где-то несколько недель мы тестировали. Воспоминания живы до сих пор:)
Главное моё непонимание тогда вызвало целеполагание этого девайса. Для кого/для какой аудитории? Процессы для которых была важна скорость одного ядра по понятным причинам работали не очень. По этому отваливался классичеcкий ComputerVision (или требовалось многое переписывать).
Для нейронок на тот момент не работало почти ничего. Билдились только очень обрубленные и старые библиотеки.
Я тогда попробовал посмотреть вокруг и понял что у Xeon Phi тогда было лишь две группы пользователей:
1) Там где закупщики не советовались с разработчиками. А маркетинг у Intel всегда был сильный
2) Метеорологи. Они могли очень просто использовать распараллеливание. В Phi была какая-то неплохая поддержка фортрана.
Мне кажется что в плане ML intel потом как-то развивал платформу, но первоначального опыта хватило чтобы больше нигде с ней не связываться.
paperswithcode.com/task/image-similarity-detection
Ну, например такое.
И гадать чем этот хорош — абсолютно бесполезно обычно, так как 99% информации держится в секрете..:)
А вот с первой вы что-то намудрили. Это (sift,orb,Akaze, FAST,...) алгоритмы 10-летней давности. Сейчас много что поновее есть. Можно и нейросетевые дескрипторы брать. Но в целом, конечно, такие задачи скорее через формирование правильных embedding решаются. Чтобы не делать этого жесткого матчинга.
Ну, статье уже год)
Ещё есть RV1109 с такими безумными девайсами — en.t-firefly.com/product/dev/camc1126s2u.html
Год назад чего-то из этого не было.
Можно ещё вглубь уходить и смотреть что на RK3399Pro есть штук 5 разных бордов от разных производителей.
Я неделю назад делал небольшой апдейт на своем Youtube канале. Но там я скорее акцентировал внимание на всяких совсем дешевых платах — youtu.be/Hf4Ra59_DCA
С переездом — много разумных стран подсуетились и сейчас упрощают въезд для разработчиков из России.
Я недавно опросил ~15-20 компаний вокруг себя, с которыми мы работаем по COmputer Vision/где у меня товарищи сделал примерный обзор ситуации в Data Science — youtu.be/sf-g11yKu54 там же в описании подборка хороших гайдов. И про вывод денег из/в Россию, и про юридические особенности переезда.
Обычно исходя из особенностей платформ можно заранее понять где что работать будет/не будет. Например почему не использовать более мощную сетку детекции? Какие ограничения на сети/на fps. Почему не использовать сегментацию/детекции с поворотом (переход все же плохо описывается прямоугольным BoundingBox). И.т.д., и.т.п.
Ещё отмечу, что у вас не понятна постановка задачи из написанного. В общем случае переход искать сложно. Скорее всего у вас авторегистраторы? Это очень сильно сжимает домен данных, можно более точно нацелиться на то как переход выглядит для ракурсов с дороги. Скорее всего у вас машина не будет ехать перпендикулярно переходу.
End-to-end тесты говорят про качество алгоритма сильно больше чем метрики.
Есть Torch-TensorRT | TF-TRT, где даже ничего менять не надо.
Есть инструменты инференса чистого. ONNX-Runtime (а вот тут я ещё десяток разбираю — habr.com/ru/company/recognitor/blog/524980 ), которые не тащат с собой кучу дополнительного кода + 1-2 строчками на разных платформах используются.
Не понимаю, правда, почему вы бенчмаркаете pytorch|tensorflow без оптимизации под железо с оптимизированным matlab'ом…
Думаю как и большинство авторов у которых спрашивали.