Nuzhny

Это да, особенно если брать цвета разных рас. Но тот же стандартный 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 как один бин в гистограмме. Небольшой проигрыш в точности, но очевидный выигрыш в скорости. Да, программирование под видеокарты - это не такое уж простое занятие.

Вот. Надо использовать LSTM сеть из С++ кода и почти всегда исполняться будет на CPU. Кроссплатформенно, на Windows в том числе. По результатам исследований: 1. Caffe практически перестал развиваться, не перспективно. Что на нём с LSTM непонятно из-за отсутствия примеров и документации. 2. Caffe 2 сырой, стандартный пример с LSTM не работал, потом глюк исправили, но шаг влево, шаг вправо - опять не работает. На issues на Гитхабе не отвечают, площадки для обсуждения нет. 3. TensorFlow официально не поддерживает С++ API под Windows. Собрать самому можно по инструкциям со SO, но не все доступные опции заработали. 4. Тут хавалят MXNet. Стоит ли пробовать? Вроде как на нём можно и обучать и использовать в продакшене. 5. Неожиданно выяснилось, что OpenCV умеет на CPU и быстро использовать сети, обученные в том же TF и Torch. Это было бы удобно. Кто что использует или посоветует для подобных целей? Что лучше выбрать 4 или 5?

"Список поддерживаемых слоев 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. А реализаций есть много.

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

Для начала - да. Тут ещё вопрос - сколько ключевых точек будет на снимке и в этом месте на карте. Очень часто делают итеративно (кадр меньше карты, на нём ключевых точек меньше): 1. Находят все соответствия точек кадра к точкам карты, это может быть один ко многим (одно соответствие на кадре может соответствовать 0, 1, 2,... точкам на карте). 2. Находят область на карте, куда выпадает большая часть соответствий. 3. Если область карты по масштабу больше снимка, то повторяются шаги 1-2. 4. Если область карты по масштабу совпадает со снимком, то ищут уже соответствия методом, который ты привёл: один к одному, чтобы совпадали в обе стороны.

Меня всё таки не покидает мысль о ключевых точках. Найти их на карте, хранить. Они же содержат в себе и масштаб также, часто точка+дескриптор - описывают целое озеро. Или вообще что-то типа MODS посмотреть.

1. Нет и никогда им не был. У него другие достоинства. Он быстрый! И может достаточно корректно определить факт пропажи объекта. Также видел проект, где KCF в качестве short-term tracker'а успешно заменил Лукаса-Канаде в составе TLD. И стало только лучше во всех отношениях. Думаю, что топ-трекеры надо искать на VOT. 2. Специально не искал, но должны подойти классические PETS или https://motchallenge.net/

Ммм, что фазовую корреляцию, что Лукаса-Канаде надо применять к исходным снимкам, до сегментации. Они полезны в качестве метода доуточнения позиции, найденной моментами. Про моменты: ты можешь сохранять моменты не только изображений регулярной сетки как сейчас, а ещё и моменты перекрытий? Другими словами, у тебя сейчас есть плавающее окно размером 256х256 с шагом 256 по вертикали и горизонтали - перекрытий нет, вся площадь покрывается. Может стоит сделать окно 256х256 с шаком 128 по вертикали и по горизонтали? Окон получится в 4 раза больше, но моменты же сравниваются всё равно быстро.