Nuzhny

Если говорить о готовом ПО, то есть openalpr с открытыми исходниками. Возможно, она и подойдёт.

Ну, 5 точек как-то маловато будет. Посмотрю сейчас...

Подумалось, что для вычисления пульса по лицу надо не искать лицо Хааром и вычислять участки с кожей, а делать что-то посовременнее. К тому же пульс можно считать двумя способами: как по частоте изменения цвета кожи, так и по микродвижениям головы в такт сердечным сокращениям. Для последнего в статье из MIT используют просто оптический поток для произвольных точек. Сразу напрашивается мысль, как можно убить двух зайцев одним ударом: и более точно определять лицо с кожей и находить движение точек. Для этого искать face landmarks - ключевых точек на лице. По ним можно определить и область лица (кожа) с углом поворота, а также, сравнивая их на соседних кадрах, находить микрокачания головы. И на основании этих двух измерений уже выдавать пульс. Как считаете, подход рабочий? И второй вопрос, технический. Соответственно нужен быстрый алгоритм поиска лица и ключевых точек на нём. Желательно, чтобы он работал точнее древнего Хаара и не требовал установки монструозных нейросетевых фреймворков, был кроссплатформенным типа OpenCV (тот же TensorFlow слабо кроссплатформенный, CUDA версия под Windows не заводится), всё работало без Питона и на С++. Если удастся ограничиться только OpenCV и остаться в его рамках (это я о dlib), то будет здорово. Модуль opencv_dnn работает здорово, OpenCL версия тоже подтягивается. Вот.

Блин, вроде стараюсь отслеживать эту тему, но постоянно что-то новое и неизвестное всплывает.

Если будет что-то интересное в плане результата, то я с удовольствием бы посмотрел. У самого из-за загруженности не хватает времени интегрировать это в проект трекинга.

Я так понимаю, что сначала тебе надо все детекции людей на разных камерах перевести в единую для них систему координат относительно магазина. А потом применить что-то типа такого dctracking. Там есть и статьи, и видео, и код на Матлабе.

Я занимался номерами жд вагонов лет 7 назад. Баз открытых тогда не было, уверен, что и сейчас нет. Надо всё делать самому. Проблем может быть много, начиная с этапа поиска этого номера, посколько стандартов написания никаких нет (есть стандарт на сам номер, есть алгоритм проверки его корректности), цифры написаны по-разному, иногда разделены рёбрами жёсткости вагона, залиты нефтью, стёрты от старости, стрёртые могут быть поверх написаны свежей краской и т.д. Тема сложная, интересная, готовых решений не видел.

Не знаю. У меня пока получается, что на видео с неплохого фотоаппарата с 60 fps пульс считается хуже, чем при съёмке обычным китайским телефоном.

Ну, попробуй перевести и умножить. Если получится, то всё нормально.

Формулы перевода. Да, их много. И конкретная формула зависит от того, что именно делается. Например, в JPEG используется такая. Далее не очень понятно, с чем ты имеешь дело. С камеры снимается сырой сигнал, потом происходит операция дебайеризации (в OpenCV тоже есть). Потом перед сжатием в JPEG или h.264 происходит перевод в YUV (YUV420, YUV422, YUV444 или что-то другое). После декодирования кадра опять получается тот же YUV. OpenCV внутри себя переводит в BGR и отдаёт пользователю. Теперь уточнение: на каком этапе предстоит цветокоррекция? Ещё можно добавить, что OpenCV представляет внутри себя кадры в виде некоторого вектора на пиксель. BGR - вектор размера 3, GRAY - размер 1, HSV - размер 3. YUV так представить уже нельзя, разве что редкий YUV444. YUV естественным образом хранится в виде planes (то есть матриц), в которых пиксель с координатами (x, y) хранится в 3-х разных матриц. OpenCV так не умеет, насколько я знаю. Там есть перевод в один из вариантов YUV, но это не обязательно тот вариант, который был использован в камере. Вообще в OpenCV с этим плохо.

Практика. Молодцы, вывели свою работу на рынок. Эх! Хочу безусловный доход, чтобы была возможность самому больше времени уделять таким интересным штукам.

Нет, но тренируется элементарно по датасету с Хабра. Что показательно, как раз на этом датасете и сделан приведённый выше каскад Хаара. Эти ребята в OpenCV его и добавили. Что очень здорово - можно сравнить.

Кстати да. Тот же детектор автомобильных номеров на классификаторе из dlib (продвинутый HOG, насколько я понял что-то типа DPM) работает намного лучше, чем детектор из OpenCV на основе каскадов Хаара (data/haarcascades/haarcascade_russian_plate_number.xml).

Данных маловато, конечно. Рекомендуется несколько тысяч - несколько десятков тысяч только положительных примеров. Отрицательных примерно также, но классификатор нарежет их сам. Если база такая маленькая, то лучше попробовать HOG. И... почему такие маленькие размеры? 10 на 30! Лучше раза в два или четыре больше. И ты уверен, что пропорции верные? Время обучения несколько часов или несколько суток - это нормально.

Всё чёрно-белое (grayscale). Можно подавать и цветное, но цвет не используется.

Это так себе способ, убивает все достоинства h.264. Лучше научиться нормально с ним работать. А то вдруг может оказаться, что сеть не пропускает видео.

Возможно, не хватает процессора на декодирование. Я бы проверил обычным ffplay с такими же параметрами: проигрывается нормально? И убедился бы при этом, что OpenCV также использует ffmpeg. Если на оба вопроса ответ "да", то надо делать видеозахват самому на том же ffmpeg или другой библиотеке. Дело в том, что ffplay использует многопоточность с тремя потоками: поток для сети и очередь пакетов из сети, поток на декодирование и очередь сырых кадров, поток на отображение. OpenCV всё делает в одном потоке и тормоза в одном месте могут привести к потере пакетов. И ещё ffplay отображает через SDL напрямую исходные YUV кадры, а OpenCV вызывает внутри себя sw_scale с конвертацией в RGB. Что по понятным причинам дополнительно загружает процесс. Это раз. И два: а пропускной способности сети точно хватает? Если есть возможность снизить битрейт и поставить реже частоту ключевых кадров (I frame), то стоит проверить и это.

Всё равно обычно делают по несколько снимков одного человека, чтобы он уверенно распознавался. Из открытых библиотек одна из самых лучших - это openface. Думаю, что стоит разобраться с ним.

Однозначно второй вариант. Сейчас такая ситуация, что многие менее мощные карты нового поколения могут именно для CUDA оказаться быстрее, чем более мощные предыдущих. К тому же старые карты не будут поддерживать новые стандарты CUDA, что не есть хорошо для программирования.

Не очень понятно, в чём сложность задачи.

armv8 будет явно быстрее. Но тут же всё зависит больше от алгоритма обработки видео. Что это? В каждой новой версии OpenCV всё больше функций имеют реализацию через NEON. Возможно ли при обработке использовать их? Или свой алгоритм переписать на NEON? Низкоуровневая или алгоритмическая оптимизация в принципе возможны? Или код и алгоритм уже ускорить нельзя, а вся надежда на железо?

Facebook + Microsoft Думаю, должно пойти в массы.

Да, не так хорошо, как хотелось бы. Если двигаться дальше в этом направлении. 1. Надо вручную разметить данные: набрать примеров картинок и сделать маски для них: 0 - фон, 1 - печатный шрифт, 2 - от руки. 2. Этот датасет визуализировать. У тебя есть 3 признака (H, S и V), в 3D вывести два датасета: красными точками пиксели печатного текста, а синим - рукописного. Посмотреть, насколько они сливаются. 3. Обучить что-то сложнее EM, например SVM с RBF (радиально-базисными функциями). 4. Если будет не намного лучше, то добавлять признаков.

Если у тебя есть сомнения на счёт пути к файлу, то проверь с полным путём. Если у тебя есть сомнения на счёт кодеков, то поставь кодеки. Если хочется, чтобы OpenCV проигрывала файлы даже тогда, когда кодеки не установлены, то убедись, что есть opencv_ffmpeg*.dll

1. Nuget?!! Я всегда качаю репозиторий с Гитхаба и компилирую. Но выбирать, конечно, надо Itseez! 2. Надо продолжать.