Nuzhny

1. Предлагаю забить на C# и проверить вообще будет ли подход работать, на С++, например. или на Питоне. 2. Да, я предлагаю именно два класса с разными чёрными. Фон вообще отсекать по порогу, чтобы он в EM не участвовал. Уверен, что оттенков фона может быть много и он попадёт не в одну, а в две модели. 3. Да, HSV очень удобен для таких задач. Лучше добавлять в качестве признаков и H, и S каналы.

Если цвет различается, то самое время для сегментации. Убери фон, чтобы не мешал, а оставшееся сегментируй с помощью EM на два класса. Только сегментируй не в RGB пространстве, а переведи в HSV и возьми либо значения первых двух каналов, либо просто цвет.

MeanShift/CamShift алгоритмы называются, в их сторону и надо копать

При помощи чего?

Нашёл чувака, который занимается пульсом. Его работы впечатляют больше, чем успехи из MIT. К сожалению, исходники являются собственностью Phillips и их не потестить. Вот. Насколько я понимаю, главным его нововведением является замена PCA (PCA у MIT, ICA у Smorodov) на POS (Plane Orthogonal to the Skin-tone direction). Что и дало такую точность.

Это да, особенно если брать цвета разных рас. Но тот же стандартный EM из OpenCV умеет несколько эллипсоидов.

Возвращаясь к моему первому вопросу по коже и деревьям: оказалось, что деревья довольно быстрые (что логично), конкуренты отстают нормально. Но всё равно медленновато и есть вопросы по качеству. Кожи на моём лице с дешёвой вебки из ноутбука находит совсем мало.

Сдаётся мне, что код у тебя довольно расисткий, на первом попавшемся негре не отработал. Ай-ай-ай!

Один раз обучить и сохранить - да. Почему EM, например? Или GMM - это похожая степь. На первый взгляд кажется, что области цвета кожи должны быть достаточно локальными в цветовом пространстве. Почему бы не описать их эллипсоидами? Кажется, что так и должно быть, при этом мы как раз и получим самые настоящие вероятности. Разумеется, в HSV области будут более компактными, чем в RGB, а в Lab ещё лучше. Но для скорости лучше остаться в RGB. Собственно, так оно и есть:

Добавил вычисление цвета только по коже. За детектор кожи взял Decision tree от mrgloom. Вопрос к нему: почему именно Decision tree? Мне бы что-нибудь самое быстрое и не сильно лажающее. Можно, конечно, самому опытов напроводить, но интересно, почему первоначально был выбран именно этот вариант. EM будет не точнее и быстрее?

Новость. Основные нововведения: стабильность, скорость и dnn в основном репозитории. Релиз видится хорошим, чтобы на него перейти.

Последнее. Там всё по классической схеме: есть один Гауссиан, которому скармливаются значения. Как только они выходят за рамки нормального распределения для первого Гауссиана, создаётся для них второй и т.д. пока не получится 6 штук (может вообще не получиться). Чем чаще значения выпадают на конкретный гауссиан, тем больше его вес. Ну и внутри каждого Гауссиана среднее и дисперсия обновляются экспоненциальным сглаживанием, что должно отслеживать постепенное изменение пульса.

Появилось немного времени и обновил проект. Пытался разобраться с непонятными скачками пульса. Для этого я считал не одно значение с экспоненциальным сглаживанием, а добавил микстуру из 6 Гауссианов. Почему 6? 1. 3 штуки на ошибку с выбором независимой компоненты, выбираем мы 1 из 3-х. 2. В выбранной независимой компоненте я считаю 2 максимума. В итоге 3 * 2 = 6. В результате в одном из Гауссианов получается достаточно точное значение пульса и вес у него неплохой. Вот.

Практическая задача: для детектора движения, у которого есть более 10 самых разных параметров и настроек, подобрать оптимальные наборы для конкретных задач. Например, для дневного видео, для ночного, для видео с тепловизора и т.п. Можно это сделать вручную (так и делается), но это же не тру-метод. Умом я понимаю, что это задача глобальной оптимизации: 1. все настройки выделить в один вектор; 2. написать функцию ошибок, которую хотим минимизировать, она может быть сложной, обеспечивающей не только качество, но и быстродействие; 3. запустить метод оптимизации. Но! Если говорить о детекторе движения, то это много-много времени работы, чтобы прогнать его по датасету с конкретными настройками. Использовать какие-нибудь генетические алгоритмы (первое, что пришло в голову из универсальных методов) выглядит слишком наивным. А надо ещё разметить каждое видео из датасета. А ещё в функцию ошибок надо добавлять время работы, чтобы оно не получилось больше, грубо говоря, 1000 мс / fps и вообще как можно меньше. Далее как его (время) связать с качеством? Чтобы не минимизировалось что-то одно в ущерб другому. И качество: кому-то важно не пропустить цель, но допустимы ложные сработки, а кому-то наоборот: по максимуму исключить ложные сработки, но при этому допустимо пропустить цель. Описал сумбурно, но, надеюсь, проблема понятна. Есть ли общепринятая теория на этот счёт? Именно специализированная, а не отсылка к учебнику по методам оптимизации. Может, есть уже хорошие продукты, которые позволяют запускать свой бинарник, писать свою функцию потерь, а остальное делают сами. Кто как решает такую проблему у себя? Спасибо.

Боюсь, что это может получиться достаточно медленно. Впрочем, как и генетические алгоритмы. Про эти два метода я писал выше, но только не генетическое программирование, а генетические алгоритмы, так же? Вот ещё и BOBYQA нашёл. Всё попробовать времени нет, поэтому и спрашиваю про опыт сообщества.

Ага, очень похоже на то. У тебя случайно нет в планах самому потестить эти штуки на предмет их эффективности? А то как-то времени не хватает.

На GPU будут совсем другие алгоритмы. Например, в первом kernel одна workgroup будет обрабатывать участок изображения 64х64 и сделает для него не полную гистограмму, а список того, что ей попалось. А уже второй kernel будет объединять эти результаты в глобальную гистограмму в global memory. Ещё можно применить небольшую компрессию и считать отдельно не каждый цвет, а объединять соседние в одни бины. Например, брать кубик 3х3х3 как один бин в гистограмме. Небольшой проигрыш в точности, но очевидный выигрыш в скорости. Да, программирование под видеокарты - это не такое уж простое занятие.

"Список поддерживаемых слоев AbsVal AveragePooling BatchNormalization Concatenation Convolution (with dilation) Crop DetectionOutput Dropout Eltwise Flatten FullConvolution FullyConnected LRN LSTM MaxPooling MaxUnpooling MVN NormalizeBBox Padding Permute Power PReLU PriorBox ReLU RNN Scale Shift Sigmoid Slice Softmax Split TanH" Чего не хватает? Разные "но", разумеется, будут, потому что оригинальные фреймворки развиваются, а тут пытаются их догнать. Но dnn это всё таки больше, чем конвертер, так что не всё так плохо. Ну и опыт работы с caffe и caffe 2 говорит, что в оригинальных фреймворках багов просто завались и ни на что рассчитывать 100% нельзя. С TensorFlow, кстати, та же беда, не получается из С++ выставить batch size > 1. Что за хрень? В случае OpenCV радует тот факт, что вечеринку спонсирует Интел.

Я и не ставлю, caffe уже умер. Достаточно посмотреть историю коммитов на Гитхабе. Tensorflow C++ API не кроссплатформенный, поэтому не очень интересен изначально. Кроме того, Tensorflow ещё и не самый быстрый фрейворк. Мне кажется, что он будет развиваться достаточно узко, больше в направлении внутренних потребностей Гугла, в том числе и под его собственное железо. Пока мне кажется лучшим выходом именно что MXNet. OpenCV тоже хочется посмотреть, а вдруг?

Много всего непонятного, но в dlib нашёл интересный алгоритм BOBYQA. До конца в нём не разобрался, но, кажется, он мне и нужен.

У меня на этот счёт есть большие сомнения. Тут же есть не только фильтр Кальмана, но и всякие пороги: через сколько кадров считать, что найден объект, а не шум; через сколько кадров считать, что объект потерян. Например, у нас есть солнечный день: чувствительность вычитания фона выкручиваем пониже, объектов (шума) детектируется меньше, начинает быстрее работать сегментация контурами, быстрее работает Венгерский алгоритм, истинные объекты детектируются и трекаются хорошо. Наступают сумерки, контраст объект/фон падает, надо повышать чувствительность вычитания фона, попадает больше шумов, всё типа замедляется. При этом сами объекты детектируются хуже, поэтому надо повышать пороги для их отсева, иначе траектории будут постоянно прерываться. Тут трекер зависит от детектора, мне видится ситуация типа бустинга: нельзя оптимизировать второй, пока не устаканится первый. Поэтому, думаю, надо в оптимизатор подавать весь вектор параметров: и детекции, и трекинга. Статические картинки для детектора лиц или пешеходов - да. Для вычитания фона уже нужны видео. Брать случайные куски видео - это хорошо, может значительно ускорить процесс без потери качества. Что-то я сам не додумался до этого. И самый главный вопрос - то такое оптимизатор? Генетические алгоритмы? Начал читать ещё про какой-то Байесовский оптимизатор, вроде, тоже должен подойти. У меня явно функция гладкой не будет. Что-то ещё? Может, есть хорошие библиотеки/фреймворки, которые позволяют запускать программу с вектором параметров, писать свою целевую функцию, визуализировать процесс оптимизации? Подойдёт С++ или Питон.

Хорошего вычислителя пульса по видео ещё нет. Проекты есть, но все с очень ограниченными внешними условиями и вычислительно тяжелы.

gdal, вроде, для этого есть.

Суперпикселей ровно 1600, данное значение задаётся изначально, т.к. они расположены на регулярной сетке. Почему я выбрал столько. Желательно, чтобы машина минимального размера разместилась хотя бы в одном суперпикселе. Если он будет слишком большой, то машина будет занимать только часть его, а остальная часть уйдёт на дорогу или на другую машину. Если же суперпиксели будут слишком маленькими, то пользы от них будет меньше - скажется на быстродействии. 1. Размер машины вдали около 20х16 пикселей. 2. Размер картинки 1024х576. 3. Примерное число суперпикселей N получаем из выражения: N = (1024 / 20) * (576 / 16) ~= 1800. Я взял 1600. Вот и всё. Понятно, что первоначально надо иметь представление, какого размера в пикселях должная быть самая маленькая машина. Но это вполне можно сделать при первоначальной настройке, когда вешается камера. Или автоматически: на какое-то время включить распознавалку автомобилей, чтобы набрать статистики. По скорости работы скажу завтра. Но я взял первый попавшийся код с гитхаба с классической реализацией SLIC. А реализаций есть много.

Будет как-то так: