BeS

1) Автокалибровка по фичам - плохая идея. т.к. всякие Ши-Томаси и прочие сифты не дают сабпиксельной точности. 2) По стереозрению есть крутецкая книга "multiple view geometry in computer vision", советую начинать с неё. А дальше по списку литературы двигаться.

Ну теоретически можно условно "от балды" взять интринсики и ими пользоваться. Вот только в чем проблема камеру то откалибровать? Если вы планируете стереоматчинг делать, то он очень чувствителен к калибровке камеры. При точности хуже, чем полпикселя SGBM уже может начать расползаться по результатам.

Ну вместо шахматной доски можно взять какиенибудь ассиметричные круги (= В любом случае нужны какие-то априорные знания о геометрии наблюдаемых камерой объектов, чтобы по ним калиброваться. Шахматаная доска - самый простой способ. И одной стереопары не хватит для калибровки, нужно с полсотни картинок.

Если камера ректифицирована, то оптический поток в общем виде считать не обязательно, можно и стереоматчинг заиспользовать. В opencv есть сносная реализация SGBM.

А что у этого алгоритма с применимостью к реальным задачам?

std::to_string() есть только начиная с C++11.

Так то не FPGA, а ARM + CUDA, причем плата для Computer Vision задач довольно таки хилая (довелось мне с ней довольно плотно поработать, впечатления не вот чтобы очень приятные о ней), ну и работает она не как сопроцессор к большому PC, а как автономный вычислитель. Тут имеет смысл ждать следующего поколения Tegra X1, который, по обещаниям NVIDIA, должен стать в разы шустрее.

Обычно народ вот с этой платой играется: https://www.altera.com/products/boards_and_kits/dev-kits/altera/kit-cyclone-v-soc.html Человеку совсем не в теме наверно стоит начать с изучения основ программирования под FPGA, иначе там совсем ничего не понятно... В CV fpga и прочие ПЛИС просто рвут шаблоны :-) Даже не при самой экстремальной оптимизации, на задачах аля стереоматчинг, оптический поток, свертки и тд и тп уделывают CUDA по полной программе...

Ну сойтись куда-то оно скорей всего сойдется и при рандоме. Но т.к. мы CNN "сходим" к локальным, а не глобальным максимумам, то за счет "правильного" начального значения теоретически можно в разы ускорить сходимость модели. А то по 15M итераций обучения проводить не слишком круто :-) По крйней мере это должно быть не так напряжно для железа, как использование всяких Batch Normalization техник.

А кто-то имплементировал эту статью: http://arxiv.org/pdf/1312.6120.pdf ? И вообще кто какие методы использует для выбора начального приближения?

Как вариант чего-нибудь менее увесистого, моя имплементация вайба: https://github.com/BelBES/VIBE Работает шустро (правда без каких либо софтварных оптимизаций) и на сценах с искуственным освещением, скорей всего, качества будет достаточно. Ну так в чем конкретно у вас трудности при обобщении имеющегося кода на озвученный в ТЗ случай?

Так вопрос то в чем?

LMDB - это спец.формат баз данных для быстрого к ним доступа (можно хранить не только картинки). В caffe можно и просто картинки скармливать, но лично у меня скорость тренировки при использовании LMDB увеличивается ~10 раз (использую обычный HDD + ext3 файловую систему). Блоб можно создать на тойже памяти. что и cv::Mat

экстра модули из opencv_contrib пишутся для opencv3, на 2.4 теоретически можно портировать, но иногда проще с нуля написать модуль, чем переносить между этими версиями. нет, в OPENCV_EXTRA_MODULES_PATH прописывается путь до папки modules: <path_to_opencv_contrib>/modules А потом нужные модули включаются/выключаются cmake-командами -DBUILD_<module_name>=ON/OFF или -DWITH_<module_name>=ON/OFF

LMDB нужен только для быстрой тренировки. А в opencv запихивается с минимальной перепаковкой данных в сотню строк кода. Для POC подходит, а в продакшен все равно никто за собой не будет таскать такие зависимости, как caffe ;-)

Нуу....make (nmake в Windows) на выходе должен выплевывать готовые бинарники. в MSVS вроде бы нужно будет только пути до них и до инклюдов прописать, чтобы подключить к проекту.

Если в protobuf'конфиге указать weight_filter без параметров, то, если верить документации, он инитит веса дефолтным значением, а не рандомом. По хорошему вообще иметь бы возможность ручками задавать начальные свертки, а не только выбирать закон их генерации из заданных, но похоже придется руками в код лезть А проблема с DIGITS у меня в том, что я пользуюсь нестабильными релизами Ubuntu, на них тычков требуется немного больше :-) з.ы. пошаговая перепроверка всех шагов показала, что проблема была действительно в плохом начальном приближении, теперь вроде бы бежит и тренируется сетка. Спасибо за советы)

Возможно, но у меня learning rate вроде вполне адекватный....не похоже, чтобы метод перепрыгивал какой-то хороший экстремум и убегал дальше. Наоброт похоже, что он застревает в первом же подвернувшемся и дальше просто шаг затухает. Пробовал играться с параметрами метода оптимизации, но особых результатов оно не дает. Вот на это большие подозрения. Насколько я понимаю, что задавая тип и std для weight_filter он генерит все свертки на текущем слое одинаковыми...caffe как-нибудь умеет рандомайзером заполнять веса, или для этого надо лезть в код библиотеки и фиксить? Я в нем замучался фиксить депенденси (что-то многовато ему нужно python-пакетов для работы), а потом он у меня наотрез отказался видеть caffe (брал кастомную NVIDIA версию). В итоге плюнул и собрал мейнстримную версию, с ней тоже проблем хватает (типа тех, когда модельки полугодовалой давности не совместимы по формату с новой версией caffe)

Оу, как в ms vs собирать его я не в курсе. Я это делаюи примерно так (в консоли): mkdir opencv_work_dir cd opencv_work_dir git clone https://github.com/Itseez/opencv.git git clone https://github.com/Itseez/opencv_contrib.git mkdir build cd build cmake -DOPENCV_EXTRA_MODULES_PATH=../opencv_contrib/modules/ ../opencv make -j8 (в Windows наверно nmake можно сделать) Как-то так. В GUI у CMake скорей всего есть отдельный propertiy, который называется OPENCV_EXTRA_MODULES_PATH, куда надо вписать путь до контрибных модулей.

в билдовой папке в строку cmake'у добавляешь -DOPENCV_EXTRA_MODULES_PATH=<path to opencv_contrib> и пересобираешь. Ребилд будет инкрементальный без пересборки самой библиотеки.

Кстати говоря, эта книга через виртуальный принтер сохраняется в качественно отформатированный PDF (автор указывает, что сразу выкладывать в PDF или прочих удобных для скачивания форматах запрещает издательство).

Теоретически можно исопльзовать семантическую сегментацию на основе глубокого обучения, а потом поверх её результатов запроцессить картинку суперпикселями для более точной оценки границ объектов. Но нужна хорошая тренировочнгая база для сетки.

Так он красным по английски пишет, что переменные CMAKE_C_COMPILER и CMAKE_CXX_COMPILER не определены. На stackoverflow эта проблема гуглится не по одной ссылке. А толку вам от чужого билда, если оно будет собрано разными компиляторами с разным рантаймом?) Шаг №0: установить более приспособелнную для разработки OS ;-)

А в чем проблема самостоятельно собрать? Там нужно то тупо в cmake'е выставить необходимые caffe_option'ы и всё...

Когда речь заходит о Калмановском сглаживании в 3D пространстве применительно к компьютерному зрению, нужно не забывать, что операция триангуляции в 3-х мерном Евклидовом пространстве имеет анизатропную ошибку, соответственно для того, чтобы применить opencv'шный Линейный Калман Фильтр, придется линеаризовать модель, или, в случае когда модель линеаризовать не представляется возможным, переходить на использование чего-то типа Unscented Kalman Filter.