roboforum.ru

Мы делаем сейчас схожий проект. Тоже нужно сделать систему наподобие Google Street View (http://maps.google.com/help/maps/streetview/). Т. е. набор панорам и связанный с ними граф возможных переходов. Но для тех мест куда машина не заедет. Дополнительно стояла задача получать панорамы без разработки специальных устройств.
Мы долго думали какое устройство может подойти и, нашли что это может быть телефон на платформе Android (Samsung Galaxy S II).
Описание системы:
Телефоном простой пользователь снимает видео высокой четкости (1920x1080) и одновременно с ним пишутся его координаты глобальные, значения углов крен, тангаж, рысканье и ряд дополнительных параметров. Снимает он стараясь охватить пространство вокруг себя - фактически вращаясь на одном месте - меняя только угол по высоте. На точку приходится примерно 1-2 Gb видео в формате MPEG-4 30 кадров в секунду. Дальше данные+видео обрабатывается специальным образом математически(CAS Mathematica 8 ) и формируется сфера с текстурированными треугольниками из реального мира (.x файл и текстура высокого разрешения 64 мегапиксела). В специальной программе просмотра можно просмотреть панораму (обычно все не удается покрыть на 100%).
Смотрите картинки для ясности, на пальцах такое не объяснишь.

Пишите, спрашивайте - все что могу расскажу тем более мы продолжаем работу над этим проектом.

здорово

robotics.by, темку бы отдельную, а то тут люди с заказом, а мы налетим с вопросами. если вы и тс не против, думаю будет не проблема модераторам тему разделить.
тоже недавно заинтересовался созданием панорам и 3д моделей помещений. порывшись пока остановился на квалкомовских библиотеках vuforia и fastcv, они под мобильные железки оптимизированы. для пробы примерно такое планирую

именно склейка фрагментов пока опасений не вызывает, а вот на такие косяки с цветопередачей нарваться опасаюсь

если сталкивались с подобным, как решали?

чем клеите-то?

Стараюсь отвечать как и обещал:

Создание 3D представления зданий (модель и текстура) имея на руках только мобильный телефон в полуавтоматическом режиме теоретически возможна. Практически не видел такие приложения.

Проблема Ваша с дисбалансов цветов (чаще белого) должна решаться на этапе склейки.

Процедура "склейки" очень сложный процесс, но слава богу его основные моменты и относительно качественная реализация есть в библиотеке OpenCV. Подробности смотрите тут - http://opencv.willowgarage.com/wiki/opencv_stitching.

вот один из проектов, в которм применяется реконструкция, но над ним еще работают.
по склейке теории болле-менее накопал. готовые ф-и из либ пока не интересны - для лучшего понимания пока планирую свой код написать, поглядывая в том числе как он в различных библиотеках реализован. да и тем более недавно наметилась проблемка с анроидом - на нём с подключением внешних устройств ситуация намного хуже, чем с windows/linux. с текущим железом подружить скорей всего получится, но в общем ситуация не радует. буду пробовать, а там видно будет. или использовать различные библиотеки на андроиде/не андроиде с максимально близким кодом программы или часть алгоритмов придётся писать самому или выдирать из опенсорсных либ и адаптировать.
а вот инфы по цветокоррекции (пока даже не знаю как правильно назвать) найти не удалось. да, попадалась обзорная инфа, но кроме обобщёной воды на пару абзацов с картинками ничего толкового, а это не то.

Angel71 писал(а):вот один из проектов, в которм применяется реконструкция, но над ним еще работают.
по склейке теории болле-менее накопал. готовые ф-и из либ пока не интересны - для лучшего понимания пока планирую свой код написать, поглядывая в том числе как он в различных библиотеках реализован. да и тем более недавно наметилась проблемка с анроидом - на нём с подключением внешних устройств ситуация намного хуже, чем с windows/linux. с текущим железом подружить скорей всего получится, но в общем ситуация не радует. буду пробовать, а там видно будет. или использовать различные библиотеки на андроиде/не андроиде с максимально близким кодом программы или часть алгоритмов придётся писать самому или выдирать из опенсорсных либ и адаптировать.
а вот инфы по цветокоррекции (пока даж не знаю как правильно назвать) найти не удалось. да, попадалась обзорная инфа, но кроме обобщёной воды на пару абзацов с картинками, но это не то.

Проект который Вы привели в качестве примера использует DSLR камеры (зеркальные цифровые камеры). У нас именно речь идет об не стандартном использовании камер телефона. Там снимаются кадры - мы работаем с видео. В любом случае проявляйте интерес к этой теме, возможно Вы станете автором алгоритма/идеи, которая сможет давать людям, имеющим такие телефоны, новые возможности их использования.

имхо в том то и дело, что алгоритму в итоге должно быть без разницы, с чего получены изображения. поток, не поток, а при обработке каждый кадр по отдельности обрабатывается. максимум это отличия в качестве изображений, разрешении, фенечках, на подобии exif или стабилизации изображения, возможность самому управлять параметрами съёмки или невозможность вообще на что-то влиять, как в случае с cctv камерами и т.д.
у вас же стоит конкретная задача и вы её решили. а у меня в том-то и дело, что не одна задача. навигация для робота, создание высококачественной 3d модели модели помещения, дополнения реальность. допустим не у всех планшетов есть задняя камера, да и качество в бюджетных не особо. пусть даже есть и качество будет вполне на уровне, но используя планшет или смартфон в качестве вычислялки робота сразу появляется проблема с тем, что не всегда удобно будет использовать встроеную камеру. другой момент в том, что при необходимости сделать нормального качества панораму или внутреннюю 3д модель помещения, использовать встроеную камеру, простенькую cctv или ip камеру или вебку вариант не особо приемлемый. нужно будет использовать или нормальную зеркалку или хорошую видеокамеру. кстати у многих фото/видеокамер есть возможность получать картинку с тюльпана, что в принципе тоже может оказаться полезным.

Angel71 писал(а):имхо в том то и дело, что алгоритму в итоге должно быть без разницы, с чего получены изображения. поток, не поток, а при обработке каждый кадр по отдельности обрабатывается. максимум это отличия в качестве изображений, разрешении, фенечках, на подобии exif или стабилизации изображения, возможность самому управлять параметрами съёмки или невозможность вообще на что-то влиять, как в случае с cctv камерами и т.д.

Заблуждаетесь - алгоритм при текстурировании (у нас сферу) панорамы при склейке изображений должен учитывать фокусное расстояние и тип объектива для каждого изображения. Т. е. знание информации об инструменте которым снимают очень важно. Дальше проблема - у видео нет exif и фокусное расстояние не известно (а реально вообще автофокусировка, автобаланс белого). Поэтому для фотоаппаратов все несколько проще.

вы с ответом меня опередили, пока я немножко дополнял своё сообщение.
п.с. я писал за поток/отдельные кадры похоже просто сразу немного недопонял, что именно вы подразумевали.

Angel71 писал(а):вы с ответом меня опередили, пока я немножко дополнял своё сообщение.
п.с. я писал за поток/отдельные кадры похоже просто сразу немного недопонял, что именно вы подразумевали.

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

не разделяю вашего пессимистичного взгляда. для примера: раньше для написания ос наподобии доса нужно было сначала чуть ли не институты, потом кафдры или маленького отдела в компании, затем 1-2 человека, а сейчас студент 1-2 курса (если вообще не школьник) при желании за несколько месяцев может написать. всё сам с 0 или частично готовые исходники возьмёт особо значения не имеет, я же образно. с ос пример может и не очень, но можно и другой, ближе к теме. если под дос программировали, поймёте. только создание кода для работы с видеокартой был еще тот головняк - сначала через прерывания нужно было с бубнон инициализировать нужный режим (да еще и потестив на различных видеокартах), написать кучу ф-ий для работы с буфером и отрисовки всяких точечек, линий, окружностей, спрайтов,... попыхтеть над созданием хотя бы жутко примитивной графической оболочки. от многозадачности и работы с картой захвата наверно головняка еще больше было. потом бы еще надо было с 0 написать весь код для обработки поступающей видеоинформации - библиотек никаких толком же небыло, да и такой как сейчас теорией и в помине не пахло. написание кода для поддержки графических файлов (хотя бы банально нормальной работы с bmp или gif) так же особо в восторг не вводила. а сколько сил на это у вас уйдёт сейчас на винде/линухе/андроиде, да еще и с использованием всяких готовых библиотек? надеюсь общий ход мыслей понятен.
п.с. в планах создавать что-то сверхнавороченое и в помине нет.

Обычно когда снимают панорамы, то не используют автоматическую экспозицию, всё в мануале и тогда проблем нет.

Angel71 писал(а):не разделяю вашего пессимистичного взгляда. для примера: раньше для написания ос наподобии доса нужно было сначала чуть ли не институты, потом кафдры или маленького отдела в компании, затем 1-2 человека, а сейчас студент 1-2 курса (если вообще не школьник) при желании за несколько месяцев может написать. всё сам с 0 или частично готовые исходники возьмёт особо значения не имеет, я же образно. с ос пример может и не очень, но можно и другой, ближе к теме. если под дос программировали, поймёте. только создание кода для работы с видеокартой был еще тот головняк - сначала через прерывания нужно было с бубнон инициализировать нужный режим (да еще и потестив на различных видеокартах), написать кучу ф-ий для работы с буфером и отрисовки всяких точечек, линий, окружностей, спрайтов,... попыхтеть над созданием хотя бы жутко примитивной графической оболочки. от многозадачности и работы с картой захвата наверно головняка еще больше было. потом бы еще надо было с 0 написать весь код для обработки поступающей видеоинформации - библиотек никаких толком же небыло, да и такой как сейчас теорией и в помине не пахло. написание кода для поддержки графических файлов (хотя бы банально нормальной работы с bmp или gif) так же особо в восторг не вводила. а сколько сил на это у вас уйдёт сейчас на винде/линухе/андроиде, да еще и с использованием всяких готовых библиотек? надеюсь общий ход мыслей понятен.
п.с. в планах создавать что-то сверхнавороченое и в помине нет.

Ваши рассуждения верные, но их нужно направить. В мире существуют уже очень давно Системы Компьютерной Алгебры (CAS - английское сокращенное название). Все фундаментальные разработки ведутся в них или в них добавляются готовые алгоритмы после признания ценности мировым сообществом. Это такие пакеты как Mathematica (для тех кто работает с символьными вычислениями) и MathLab (для тех кому необходимы численные вычисления). Эти инструменты (мы работаем с Mathematica) позволяют создать мастер-алгоритм. После получения алгоритма и оценки, анализа (обычно доказательства) его возможностей, преимуществ нужно переходить к реализации уже непосредственно на языках программирования. Более того - Mathematica позволяет генерировать и компилировать исходные коды - вызывая компилятор С/C++ с которым вы работаете (мы работаем с профессиональным компилятором от Intel и библиотекой IPP). Примерно так у нас идет разработка по сути.

а для обычных юзеров есть что-то?
я конечно понимаю что можно взять видеоролик и в вегасе порезать его на кадры и сохранить их в джипег
а потом в ptgui сделать панораму из сохранённых джипегов...

но может есть что-то бесплатное для домашнего использования с меньшим геморроем?

Добавлено спустя 1 час 4 минуты 44 секунды:
такс, для айфона есть программа
снимаешь видео, и прога делает панораму.

а для писи чтонибуть...?