программа построения 3D модели вокруг машины

[eea_2M]

Сообщение от JokerJek

И где там такой алгоритм? Я увидел только картинку, где по центру машина и вокруг неё "панарама". Где там расстояния? Можт я не туда смотрел?

Алгоритмы тут http://disparity.wikidot.com/, были приведены в посте http://www.pccar.ru/showpost.php?p=99334&postcount=4 данной ветви.
Просто не надо лениться просматривать всю тему

Сообщение от JokerJek

Имхо тема была про 3D, в моём понимании, это http://ru.wikipedia.org/wiki/3D. Потом выяснилось, что нужно сделать панораму вокруг машины. Надо бы по терминам договориться!

Ключевое здесь - построение 3-х мерной модели на основании стереоизображения. Использовать полученный результат можно разными способами - и для построения реального панорамного обзора, и для определения взаимного расположения и относительных скоростей а/м на дороге.

Сделать это одной камерой на каждой стороне а/м (как делают сейчас в Лексусе) можно лишь с погрешностью (недаром в рекламе показывают парковку на пустой площадке - при наличии препятствий адекватность картинки может существенно пострадать).

[JokerJek]

Сообщение от eea_2M

Алгоритмы тут http://disparity.wikidot.com/, были приведены в посте http://www.pccar.ru/showpost.php?p=99334&postcount=4 данной ветви.
Просто не надо лениться просматривать всю тему

Просмотрел
Впринщипе, такую же картинку и нарисовал... Зато сам придумал

Сообщение от eea_2M

Ключевое здесь - построение 3-х мерной модели на основании стереоизображения. Использовать полученный результат можно разными способами - и для построения реального панорамного обзора, и для определения взаимного расположения и относительных скоростей а/м на дороге.

Сделать это одной камерой на каждой стороне а/м (как делают сейчас в Лексусе) можно лишь с погрешностью (недаром в рекламе показывают парковку на пустой площадке - при наличии препятствий адекватность картинки может существенно пострадать).

Очень не люблю вопросы "Зачем". Раз человек спрашивает, значит надо! И при этом, спрошу, а зачем это надо? Мне будет более чем достаточно видео со всех сторон. Расстояние мозг определит, для этого я его и кормлю

[eea_2M]

Сообщение от JokerJek

Очень не люблю вопросы "Зачем". Раз человек спрашивает, значит надо!

Я разве спрашивал?

Сообщение от JokerJek

Мне будет более чем достаточно видео со всех сторон. Расстояние мозг определит, для этого я его и кормлю

Значит тебе данная разработка не нужна.

[AngelOfGrief]

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

[eea_2M]

Сообщение от AngelOfGrief

А разве авто баланс белого -- не софтовая функция?

Понятия не имею я до этого еще не добрался - бьюсь над парами тестовых кадров. Для обработки двух стандартных потоков 640х480 30fps, да так, чтобы проца хватало на отрисовку результирующей картинки и оставляло немного места для других процессов - обсчет одной пары кадров должна занимать не более 10-ти миллисекунд. Не получается пока
Бродит даже крамольная мысль съехать на однокристалку

[JokerJek]

Сообщение от eea_2M

Я разве спрашивал?

Нет!
Удивительно, и я тоже не спрашивал, и много кто НЕ спрашивал. Спросил только создатель темы, ему я и ответил))

Сообщение от eea_2M

Значит тебе данная разработка не нужна.

Не нужна, НО соображения есть по этой теме и определённые наработки, ибо интересовался давным давно этой проблематикой, имхо автору темы они могут помочь...

[eea_2M]

По тестовой паре кадров:



построена адекватная разностная матрица:



Обработка одной пары на Intel DualCore 1,8 занимает чуть более 50 миллисекунд без учета времени на вывод изображения.

Задачи на текущий момент:
1) Определиться с форматом отображения трехмерной модели
2) Увеличение производительности, хотя путей осталось немного
3) Обкатка модели на "уличных" кадрах.

[AngelOfGrief]

Я думаю, нужно попробовать результирующий кадр отобразить не цветами на плоскости, а в виде "расстояний", т.е. смотреть как бы сверху. Т.е., более светлые точки будут ближе к низу, а светлые -- дальше. Думаю, это будет очень наглядно.
А если имеется 3D массив, наверное, можно использовать Direct3D для отображения картинки средствами видеокарты.

50 ms -- как раз 20 кадров/сек -- вполне достаточно.

[eea_2M]

Сообщение от AngelOfGrief

Я думаю, нужно попробовать результирующий кадр отобразить не цветами на плоскости, а в виде "расстояний", т.е. смотреть как бы сверху. Т.е., более светлые точки будут ближе к низу, а светлые -- дальше.

Я склоняюсь к мысли сделать вид не сверху, а под углами 30 - 60 градусов. Тогда можно будет изображения объектов распределить по соответствующим им слоям. Поколдую над прототипом - выложу пример.

Сообщение от AngelOfGrief

А если имеется 3D массив, наверное, можно использовать Direct3D для отображения картинки средствами видеокарты.

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

Сообщение от AngelOfGrief

50 ms -- как раз 20 кадров/сек -- вполне достаточно.

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


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