Nuzhny
-
Количество публикаций
1 427 -
Зарегистрирован
-
Посещение
-
Days Won
176
Сообщения, опубликованные пользователем Nuzhny
-
-
Если цвет различается, то самое время для сегментации. Убери фон, чтобы не мешал, а оставшееся сегментируй с помощью EM на два класса. Только сегментируй не в RGB пространстве, а переведи в HSV и возьми либо значения первых двух каналов, либо просто цвет.
-
1
-
-
MeanShift/CamShift алгоритмы называются, в их сторону и надо копать
-
10 minutes ago, prim.ko said:при помощи семантической
При помощи чего?
-
Нашёл чувака, который занимается пульсом. Его работы впечатляют больше, чем успехи из MIT. К сожалению, исходники являются собственностью Phillips и их не потестить. Вот.
Насколько я понимаю, главным его нововведением является замена PCA (PCA у MIT, ICA у Smorodov) на POS (Plane Orthogonal to the Skin-tone direction). Что и дало такую точность.
-
2
-
-
5 minutes ago, mrgloom said:Гауссианы это хорошо, но одной отделаться не получится
Это да, особенно если брать цвета разных рас. Но тот же стандартный EM из OpenCV умеет несколько эллипсоидов.
-
Возвращаясь к моему первому вопросу по коже и деревьям: оказалось, что деревья довольно быстрые (что логично), конкуренты отстают нормально. Но всё равно медленновато и есть вопросы по качеству. Кожи на моём лице с дешёвой вебки из ноутбука находит совсем мало.
-
12 minutes ago, Smorodov said:Собственно есть изящный метод как раз с эллипсом:
Сдаётся мне, что код у тебя довольно расисткий, на первом попавшемся негре не отработал. Ай-ай-ай!
-
3 hours ago, mrgloom said:Изначально decision tree, т.к. этот метод интерпретируемый, т.е. там дерево из threshold'ов которые выучены из данных, чтобы не было таких вот хардкодов threshold'ов или in range как тут:
http://bytefish.de/blog/opencv/skin_color_thresholding/
И да их сначала можно выучить, а потом для скорости захардкодить)
Такой же вопрос почему в grabcut используется GMM? по сути нам там без разницы какой метод будет выдавать probability пикселя?
Один раз обучить и сохранить - да.
Почему EM, например? Или GMM - это похожая степь. На первый взгляд кажется, что области цвета кожи должны быть достаточно локальными в цветовом пространстве. Почему бы не описать их эллипсоидами? Кажется, что так и должно быть, при этом мы как раз и получим самые настоящие вероятности. Разумеется, в HSV области будут более компактными, чем в RGB, а в Lab ещё лучше. Но для скорости лучше остаться в RGB.
Собственно, так оно и есть:
-
Добавил вычисление цвета только по коже. За детектор кожи взял Decision tree от mrgloom.
Вопрос к нему: почему именно Decision tree? Мне бы что-нибудь самое быстрое и не сильно лажающее. Можно, конечно, самому опытов напроводить, но интересно, почему первоначально был выбран именно этот вариант. EM будет не точнее и быстрее?
-
Основные нововведения: стабильность, скорость и dnn в основном репозитории. Релиз видится хорошим, чтобы на него перейти.
-
1
-
-
Последнее. Там всё по классической схеме: есть один Гауссиан, которому скармливаются значения. Как только они выходят за рамки нормального распределения для первого Гауссиана, создаётся для них второй и т.д. пока не получится 6 штук (может вообще не получиться). Чем чаще значения выпадают на конкретный гауссиан, тем больше его вес.
Ну и внутри каждого Гауссиана среднее и дисперсия обновляются экспоненциальным сглаживанием, что должно отслеживать постепенное изменение пульса.
-
Появилось немного времени и обновил проект. Пытался разобраться с непонятными скачками пульса.
Для этого я считал не одно значение с экспоненциальным сглаживанием, а добавил микстуру из 6 Гауссианов. Почему 6?
1. 3 штуки на ошибку с выбором независимой компоненты, выбираем мы 1 из 3-х.
2. В выбранной независимой компоненте я считаю 2 максимума.
В итоге 3 * 2 = 6.
В результате в одном из Гауссианов получается достаточно точное значение пульса и вес у него неплохой. Вот.
-
1
-
-
9 minutes ago, mrgloom said:Просто grid search с отстреливанием по времени исполнения\пику памяти не подходит?
Боюсь, что это может получиться достаточно медленно. Впрочем, как и генетические алгоритмы.
10 minutes ago, mrgloom said:Есть еще варианты с bayesian optimization и genetic programming
Про эти два метода я писал выше, но только не генетическое программирование, а генетические алгоритмы, так же? Вот ещё и 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 радует тот факт, что вечеринку спонсирует Интел. -
10 minutes ago, mrgloom said:В Caffe LSTM layer есть, но я не пробовал:
http://caffe.berkeleyvision.org/tutorial/layers/lstm.html
На caffe я бы не ставил.
Я и не ставлю, caffe уже умер. Достаточно посмотреть историю коммитов на Гитхабе.
MXNet я не пробовал, но это выглядит более подходящим вариантом, и как бонус там еще есть поддержка Mobile Devices и Distributed Training.
Есть еще такой проект, но видимо LSTM/RNN там в зачаточном состоянии.
https://github.com/tiny-dnn/tiny-dnn
Вообще меня тоже интересует вопрос как например python код из Keras перевести на C++, по идее можно Keras->Tensorflow->Tensorflow C++ (но возможно C++ api не полный?) ?
Tensorflow C++ API не кроссплатформенный, поэтому не очень интересен изначально. Кроме того, Tensorflow ещё и не самый быстрый фрейворк. Мне кажется, что он будет развиваться достаточно узко, больше в направлении внутренних потребностей Гугла, в том числе и под его собственное железо.
Пока мне кажется лучшим выходом именно что MXNet. OpenCV тоже хочется посмотреть, а вдруг?
-
Вот.
Надо использовать 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?
-
Много всего непонятного, но в dlib нашёл интересный алгоритм BOBYQA. До конца в нём не разобрался, но, кажется, он мне и нужен.
-
1 hour ago, Smorodov said:Мне видится, что нужно настраивать параметры системы блоками.
Например: детектор отдельно фильтр Кальмана отдельно.
У меня на этот счёт есть большие сомнения. Тут же есть не только фильтр Кальмана, но и всякие пороги: через сколько кадров считать, что найден объект, а не шум; через сколько кадров считать, что объект потерян.
Например, у нас есть солнечный день: чувствительность вычитания фона выкручиваем пониже, объектов (шума) детектируется меньше, начинает быстрее работать сегментация контурами, быстрее работает Венгерский алгоритм, истинные объекты детектируются и трекаются хорошо.
Наступают сумерки, контраст объект/фон падает, надо повышать чувствительность вычитания фона, попадает больше шумов, всё типа замедляется. При этом сами объекты детектируются хуже, поэтому надо повышать пороги для их отсева, иначе траектории будут постоянно прерываться.
Тут трекер зависит от детектора, мне видится ситуация типа бустинга: нельзя оптимизировать второй, пока не устаканится первый. Поэтому, думаю, надо в оптимизатор подавать весь вектор параметров: и детекции, и трекинга.
1 hour ago, Smorodov said:Для детектора можно использовать статические картинки и тут вроде все понятно. Есть вполне очевидная целевая функция, есть вектор параметров. Засовываем в оптимизатор, получаем результат. Весовые коэффициенты, например "время детекта"/"точность детекта", задавать пользователем.
Для трекера, брать рандомный кусок, считать время до срыва трека. Далее применять целевую функцию на этом куске, понятно, что тут без весовых коэффициентов задаваемых пользователем тоже не обойтись. И засовывать в оптимизатор. Каждую итерацию брать новый рандомный кусок до срыва трека. Получится что с улучшением качества, будет расти набор данных для подстройки, что позволит недать более точные оптимизации.
Статические картинки для детектора лиц или пешеходов - да. Для вычитания фона уже нужны видео.
Брать случайные куски видео - это хорошо, может значительно ускорить процесс без потери качества. Что-то я сам не додумался до этого.
И самый главный вопрос - то такое оптимизатор? Генетические алгоритмы? Начал читать ещё про какой-то Байесовский оптимизатор, вроде, тоже должен подойти. У меня явно функция гладкой не будет. Что-то ещё? Может, есть хорошие библиотеки/фреймворки, которые позволяют запускать программу с вектором параметров, писать свою целевую функцию, визуализировать процесс оптимизации? Подойдёт С++ или Питон.
-
Практическая задача: для детектора движения, у которого есть более 10 самых разных параметров и настроек, подобрать оптимальные наборы для конкретных задач.
Например, для дневного видео, для ночного, для видео с тепловизора и т.п. Можно это сделать вручную (так и делается), но это же не тру-метод.
Умом я понимаю, что это задача глобальной оптимизации:
1. все настройки выделить в один вектор;
2. написать функцию ошибок, которую хотим минимизировать, она может быть сложной, обеспечивающей не только качество, но и быстродействие;
3. запустить метод оптимизации.
Но! Если говорить о детекторе движения, то это много-много времени работы, чтобы прогнать его по датасету с конкретными настройками. Использовать какие-нибудь генетические алгоритмы (первое, что пришло в голову из универсальных методов) выглядит слишком наивным.
А надо ещё разметить каждое видео из датасета.
А ещё в функцию ошибок надо добавлять время работы, чтобы оно не получилось больше, грубо говоря, 1000 мс / fps и вообще как можно меньше. Далее как его (время) связать с качеством? Чтобы не минимизировалось что-то одно в ущерб другому. И качество: кому-то важно не пропустить цель, но допустимы ложные сработки, а кому-то наоборот: по максимуму исключить ложные сработки, но при этому допустимо пропустить цель.
Описал сумбурно, но, надеюсь, проблема понятна. Есть ли общепринятая теория на этот счёт? Именно специализированная, а не отсылка к учебнику по методам оптимизации. Может, есть уже хорошие продукты, которые позволяют запускать свой бинарник, писать свою функцию потерь, а остальное делают сами. Кто как решает такую проблему у себя?
Спасибо.
-
Хорошего вычислителя пульса по видео ещё нет. Проекты есть, но все с очень ограниченными внешними условиями и вычислительно тяжелы.
-
gdal, вроде, для этого есть.
-
Суперпикселей ровно 1600, данное значение задаётся изначально, т.к. они расположены на регулярной сетке.
Почему я выбрал столько.
Желательно, чтобы машина минимального размера разместилась хотя бы в одном суперпикселе. Если он будет слишком большой, то машина будет занимать только часть его, а остальная часть уйдёт на дорогу или на другую машину. Если же суперпиксели будут слишком маленькими, то пользы от них будет меньше - скажется на быстродействии.
1. Размер машины вдали около 20х16 пикселей.
2. Размер картинки 1024х576.
3. Примерное число суперпикселей N получаем из выражения: N = (1024 / 20) * (576 / 16) ~= 1800. Я взял 1600.
Вот и всё.
Понятно, что первоначально надо иметь представление, какого размера в пикселях должная быть самая маленькая машина. Но это вполне можно сделать при первоначальной настройке, когда вешается камера. Или автоматически: на какое-то время включить распознавалку автомобилей, чтобы набрать статистики.
По скорости работы скажу завтра. Но я взял первый попавшийся код с гитхаба с классической реализацией SLIC. А реализаций есть много.
Очистка изображения от печатного текста
в OpenCV
Опубликовано · Report reply
1. Предлагаю забить на C# и проверить вообще будет ли подход работать, на С++, например. или на Питоне.
2. Да, я предлагаю именно два класса с разными чёрными. Фон вообще отсекать по порогу, чтобы он в EM не участвовал. Уверен, что оттенков фона может быть много и он попадёт не в одну, а в две модели.
3. Да, HSV очень удобен для таких задач. Лучше добавлять в качестве признаков и H, и S каналы.