BeS

Это типа расширения к OpenVX с заоптимизированными под железо от Nvidia примитивами. Более подробную информацию можно в презентации посмотреть: http://on-demand.gputechconf.com/gtc/2014/presentations/S4714-nvidia-vision-toolkit-adas-photography.pdf

Хм...не знаю как там в DirectX, но в OpenGL только cv::flip (чтобы там все лежало по столбцам) сделать надо и потом cv::Mat сразу копировать в память GPU. Чисто теоретически можно и этого не делать, если написать шейдер, который будет точки cv::Mat прямо на GPU переводить в нужный формат.

А через OpenGL не вариант? Должно по идее быть быстрее всего.

Как я уже писал чуть выше, мы предполагаем, что все объекты панорамы бесконечно удалены от камеры, а не то, что камера только вращается. Просто объекты на бесконечности склеивать проще, чем близкие, где нужно учитывать еще и перемещения)

Это происходит потому, что панорама стичится на сферц. Мы вынуждены использовать сферические проекции в силу некоторых допущений при работе с панорамами. В случае панорам предполагают, что все трансформации камеры являются афинными, а все объекты панорамы бесконечно удалены от камеры. В такой постановке задачи можно пренебречь трансляциями камеры(т.к. относительно расстояния до объектов оно бесконечно малое) и искать только повороты камеры. Алгоритм Левенберга-Марквардта - это один из способов решения задачи о наименьших квадратах - это и есть один из способов реализовать Bundle Adjustment по сути.

Спасибо! Что-то так себе мощности для Computer Vision...20 ядер CPU это совсем не серьезно, да и без GPU...

А не подскажете на каких условиях они предоставляют свое облако(ограничения на энвайромент, стоимость аренды и выдаваемые за эти деньги ресурсы etc)? Что-то не нашел на их сайте этой информации.

Лучше покажите, какую строку вы передаете CMake'у при сборке OpenCV. Нельзя, кстати, исключать вероятность того, что вы ннатренировали большой каскад и он действительно долго работает...

Очевидно, что если кожи не видно, то детектор кожи не отработает, не понимаю к чему этот комментарий...

А OpenCV собран в дебаге или релизе? Просто такое иногда бывает, когда opencv собран с отладочной информацией и отключенными оптимизациями, попробуйте собрать opencv в релиз

Вообще говоря gpu::Mat по умолчанию аллоцирует память на девайсе (device memory), но если вы пишете код под SoC процессор(например новая NVIDIA Tegra K1 и ей подобные), то можно руками аллоцировать память в шарной памяти для CPU и GPU(unified memory) и просто перенацеливать указатель на память у gpu::Mat в нужное место при передачи этой памяти оптимизированным под GPU функциям.

Хороший вопрос. Формально писать это в статье сейчас времени нету, поэтому отвечу пока тут: Если рассмотреть пару SOINN vs. ESOINN, то второй алгоритм предпочтительней использовать всегда, т.к. он аккуратней работает с нечеткими границами классов, но иногда имеет смысл вводить второй слой аналогично тому, как он вводится в SOINN, на cross validation это скорей всего даст худшую точность классификации, но зато будет значительно проще анализировать топологическую стрктуру кластеров. Это дает профит, если мы сомневаемся в качестве кластеризации, тогда можно прогнать сеть с разными параметрами много раз, для каждой сети построить второй слой и по нему выделять общие паттерны во всех построенных моделях. Но вообще основной смысл применения ESOINN - это случаи, когда у нас нет обучающей выборки и мы вынужденны строить модель "на ходу"(например пытаемся строить какието гипотезы по получаемым с каких-то датчиков данным) или когда мы хотим в процессе работы продолжать адаптацию модели под данные, в таком случае у ESOINN практически нет аналогов. Но если есть возможность обучаться по выборке, и не требуется потом эту модель дообучать, то имеет смысл использовать что-то другое, хоть теже глубокие сети. Есть еще вариант использовать ESOINN для обучения SVM без учителя, но в виде кода у меня руки не доходят его реализовать)

Всем привет! Если кому-то интересна тема самоорганизующихся нейронных сетей, то можете почитать мою новую статью на хабре про алгоритм ESOINN: http://habrahabr.ru/company/itseez/blog/206116/

Советую почитать книгу Mastering OpenCV. Там целая глава посвящена работе с маркерами при помощи OpenCV&OpenGL

А сингулярное разложение не спасет отца русской демократии?

Ну на самом деле ESOINN более мощная штука Но она больше не для визуализации данных, а для майнинга. По сути она дает представление о данных "с высоты птичьего полета", т.е. качественное представление о топологической структуре классов, а нейронный газ просто пытается построить триангуляцию Делоне для показываемых классов - оттуда и лучшие результаты на задачах связанных с визуализацией, но в более "серьезных" задачах выдаваемая им информация и избыточна и зашумлена(очевидно, что на шумных классах он будет переобучаться по полной программе), ну и там есть еще ряд проблем которые можно долго перечислять) А вообще нейронный газ(как и самоорганизующиеся карты Кохонена) можно считать прародителем всех алгоритмов класса *SOINN)

Чтобы поиграться с растущим нейронным газом, можно взять простую реализацию у меня на github.

Есть еще библиотека LibCVD, это библиотека компьютерного зрения с оптимизациями под ARM. Но на мой взгляд предпочтительней использовать OpenCV и поддерживать отечественного производителя

Да конечно не против, open source же. Забавная демка получилась)

В OpenCV есть пример использования этой функции: https://github.com/Itseez/opencv/blob/master/samples/c/polar_transforms.c

SOINN - по сути для определения топологической структуры данных, поэтому там сетки не получится, там получатся плотные подграфы в областях высокой плотности вероятности, и разреженные в других...поэтому поверхность вы не построите. ESOINN - модификация SOINN, разница по большому счету в том, что тут только 1 слой у сети и алгоритм обучения другой. Тут скорей подойдет алгоритм растущего нейронного газа(Growing Neural Gas), он как раз пытается построить фактически триангуляцию Делоне для входного множества точек, т.ч. для построения поверхностей эта штука должна подойти. з.ы. раз уж зашла речь о всяких самоорганизующихся алгоритмах, то немного пропиарю себя: про SOINN можно почитать в моей статье тут: http://habrahabr.ru/post/192978/, тамже есть и ссылка на код чтобы можно было поиграться. А про ESOINN в начале января опубликую статейку на хабре...

dereyly, SOM параллелятся просто. Там и Best Match можно параллельно искать(через редукцию) и веса адаптировать тоже независимо можно(т.к. зависят только от Best Match и собственных координат в сетке).

Ну вот тут вроде решили эту проблему используя boost'овые треды.

Когда-то писал заметку на хабре(http://habrahabr.ru/post/169709/), как по контуру ладони можно найти ключевые точки. Для поиска самой ладони по идее можно пытаться выделять из всего изображения объекты с текстурой кожи.