» Цифровые панорамы. Часть 2.

Rodeus


Цитата:

век живи, век учись...

.....

Она кажется старается приравнять объем сферы к объему куба, но может ли в нашем случае идти речь об объеме?

Я об этом давно уже упоминал... Особенности проекции... а также с учетом, что в сферической текстуре часть пикселов интерполируется "в никуда" ближе к полярным точкам, когда она проецируется "в сфере"... у "куба" тоже самое часть пикселов скрадывается ближе к углам... и у каждой проекции этот процент "потерь" разный.

Я не технарь не умею красочно говорить оперируя циферами... иногда беру на веру, то что говорят профи (Цар сказал: "Люминий".. Значит "Люминий" и я не спорю)

и тут никакой занудной математики не нужно... можно проверить опытным путем...

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

теперь разбиваем эту же текстуру на стороны куба, не меняя положение камеры...

1. по формуле Пи
2. по формуле 1\4+20%

Накладываем на сферическую текстуру изображение того же объекта (который оказался на одной из сторон куба) "под кальку" и сравниваем полученый объем в пикселах...

во-втором случае контуры предмета практически совпадут т.е. ничего при интерполяции мы сильно не утратили...

в первом же случае мы увидим явно отличающийся объем информации после реммапинга...

Цитата:

Это неточный реммапинг... лучше пользоваться тридэшной формулой...

Длину сферческой текстуры делим на четыре плюс 20% к значению...

Что равно "поделить на 3.2"

Это правда точнее, чем "поделить на "3.14"? Кто сказал?


Цитата:

Интерполирует объем pixel-to-pixel

pixel-to-pixel в принципе интерполировать нельзя при переходе из проекции в проекцию. Но вот небольшие области в соприкосновения граней куба и сферы (2 полюса и 4 точки на экваторе), можно интерполировать на куб с длиной стороны равной длине экватора (длинная сторона эквижистантной проекции) поделенной на Пи. Это школьный курс геометрии - длина окружности равна диаметру, умноженному на Пи. А сторона куба как раз и равна диаметру экватора.

Попробовал сравнить варианты ремапинга. Создал тестовое изображение размером 4000х2000 пикселей. По центру провёл вертикальную линию толщиной 2 пикс, далее провёл справа и слева вертикальные линии толщиной 2 пикс через каждые 50 пикс, добавил ещё две вертикальные линии толщиной 2 пикс справа и слева от центральной через 20 пикс. Далее открыл в Pano2VR 2.2.0 и перевёл в кубическую проекцию двумя методами (интерполятор Lanczos3):
1) метод humanoid67 (1/4+20%)
2) метод через коэфф Pi
Открыл в ФШ (поставил масштаб 400%) выровнял относительно средней линии, вот что вышло:
http://pics.livejournal.com/sk_aka_noname/pic/0005s247.png
Сверху вниз:
- метод humanoid67
- тестовая картинка 4000х2000
- метод через коэфф Pi
Вывод (для меня): метод humanoid67 (1/4+20%) более верный и изображение меньше замыливается в результате интерполяции. То, что крайние линии не соответствуют оригинальным (ближе к центральной линии) это как раз и говорит о верности метода. А в случае через коэфф Pi изображение излишне раздувается.

drop

Цитата:

А есть какой то html-код, что бы запихнуть панораму в мой блог?

Если собираешь quicktime, то можно так:
http://vu1tur.eu.org/qtvr/bulk.html (в коде заменить qtvr_file.mov на свой, ну и названия)
так же нужны http://vu1tur.eu.org/qtvr/p2q_embed_object.js ну и сам файл.mov в той же папке.
Модифицировано из шаблонов pano2qtvr.
Сейчас я правда перешел на скрипт от DevalVR — там можно вставлять сразу QT/DevalVR/Flash с автодетектом доступных плагинов.


Добавлено:
1drey

Цитата:

Теперь можно ловко вставлять панорамы прямо в ЖЖ, как ютубовские ролики

Вот только жж горизонтальный скроллбар отображает, нужно руками потом ужимать ширину.

Кстати, а для таких embedded панорам используется полноразмерная картинка? Ибо трафик ведь — для форума такое малопригодно.

1drey

Цитата:

Теперь можно ловко вставлять панорамы прямо в ЖЖ, как ютубовские ролики

Это можно достаточно давно

Добавлено:
SK74

Цитата:

Вывод (для меня): метод humanoid67 (1/4+20%) более верный и изображение меньше замыливается в результате интерполяции. То, что крайние линии не соответствуют оригинальным (ближе к центральной линии) это как раз и говорит о верности метода. А в случае через коэфф Pi изображение излишне раздувается.

Вообще-то, Ваш результат показывает, что деление на 3.14 ближе по масштату к оригиналу, чем деление на 3.2, к которому призывал гуманоид, о чем я говорил раньше, и это явно противоречит сказанному Гуманоидом. Что неудивительно - ятжело спорить с школьным курсом геометрии.

Ну а то, что сверху результат менее "мыльный" - это идиотский результат идиотского теста. ланкрос не рассчитаны на масштабирование рисованных линий. То, что результат завиист от коэффициента масштабирования - это факт, но он по-разному зависит на фото и на рисованной графике. Увы.

Цитата:

Это можно достаточно давно

Да? А где такая CMS лежит, чтобы код для эмбеддинга динамически генерировала? Я тоже хочу - дай ссылочку.


Цитата:

Вот только жж горизонтальный скроллбар отображает, нужно руками потом ужимать ширину.

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

1drey

Цитата:

Да?

Да. Полтора года уже (фича в ЖЖ появилась летом 2007 года).


Цитата:

А где такая CMS лежит, чтобы код для эмбеддинга динамически генерировала?

А какое отношение этот вопрос имеет к "теперь можно ловко вставлять панорамы прямо в ЖЖ, как ютубовские ролики"? К чему CMS будем прикручивать? К ЖЖ? Облом К хранилищу панорам? Ну так это личное дело хозяина этого хранилища. Надо - пусть напишет. Для того, чтобы вставить в ЖЖ панораму, не нужна ни CMS, ни динамическая генерация кода для вставки на хранилище - в object все равно ничего динамически не вставляется, а ЖЖ javascript не принимает

Вот тут
http://skoblov.livejournal.com/tag/qtvr
пара панорам вставлены в ЖЖ.

Сами панорамы лежат на viewat.org

zusker

Цитата:

Это школьный курс геометрии....

Насколько мне позволяют судить мои знания математики, в случае формулы Гумира объем сферы равняется объему куба, в который она ремаппится (требует проверки, мне лень искать формулу объема шара). В таком случае диаметр сферы будет несколько меньшим, чем сторона куба. Иными словами сфера не вписана в куб, а куб рассекает ее в 6 местах.

Цитата:

идиотский результат идиотского теста

старый форум, "привычный" формат общения...

SK74
для проверки точности методики измерения можно еще на глаз сделать сторону куба чуть меньшую, чем по формуле Гумира, скажем прибавив не 20 проц а 15, и посмотреть что будет

zusker
смысловой акцент был на слове "ловко"
мне лень писать код каждый раз

zusker

Цитата:

А какое отношение этот вопрос имеет к "теперь можно ловко вставлять панорамы прямо в ЖЖ, как ютубовские ролики"? К чему CMS будем прикручивать? К ЖЖ? Облом К хранилищу панорам? Ну так это личное дело хозяина этого хранилища. Надо - пусть напишет. Для того, чтобы вставить в ЖЖ панораму, не нужна ни CMS, ни динамическая генерация кода для вставки на хранилище - в object все равно ничего динамически не вставляется, а ЖЖ javascript не принимает

О! Наконец то, мне хоть понятно объяснили

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

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

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

*а zusker'a и "хлебом не корми"... дайте любую спорную тех.тему.. и он начнет тут разводить свои поучения напирая как танк... и гранатой его не остоновишь...

короче "за что купил, за то и продал"... кому надо - пользуйтесь, кому не надо - забудте как страшный сон....

Rodeus

Цитата:

Насколько мне позволяют судить мои знания математики

Неверная формулировка! Правильно так: "поскольку я давно забыл математику, рискну предположить" и далее по тексту


Цитата:

в случае формулы Гумира объем сферы равняется объему куба, в который она ремаппится (требует проверки, мне лень искать формулу объема шара).

К сожалению, это неверно.

Объем сферы - это 4/3*pi*r^3
Для удобства перейдем к диаметру 1/6*pi*d^3
объем куба - x^3
1/6*pi*d^3=x^3
d^3/x^3=6/pi=1.91

d/x=1,24
это соотношение диаметра сферы и длины ребра куба равного объема

ну а для перехода к длине экватора надо умножить это на pi, и получим 3.89, а никак не 3.2, на которые предлагал делить Гуманоид. Впрочем, какой нам был бы прок от вычисления куба равного объема я все равно не знаю

Ну а волшебная формула "поделить на 4 и прибавить 20%" - это не какой-то альтернативный вариант рассчета, а просто правило устного счета, позволяющее с приемлимой точностью в уме прикинуть результат деления на pi (легко в уме делим на 3.2 вместо сложного деления на бумажке на 3.14). Для любого хоть как-то обоснованного вычисления мы бы сразу имели "поделить на 3.2", а не двухходовку


Цитата:

старый форум, "привычный" формат общения...

Я всегда так общаюсь, когда мы обсуждаем одно, а тестируем другое


Цитата:

для проверки точности методики измерения можно еще на глаз сделать сторону куба чуть меньшую, чем по формуле Гумира, скажем прибавив не 20 проц а 15, и посмотреть что будет

А зачем прибавлять 15%, если уже при "прибавлении 20%", как видно из проведенного SK74 исследования, мы получили результат чуть меньше, чем оригинал (что, видимо, и помогло интерполятору отмасштабировать в центре исходные линии красиво - там же коэффициент масштабирования меньше 1 получился, а ближе к краям он увеличивается), и исходно шла речь про интерполяцию pixel-to-pixel (впрочем, это вообще исходно бредовая задача, о чем я раньше написал)

Добавлено:
1drey

Цитата:

смысловой акцент был на слове "ловко"
мне лень писать код каждый раз

Т.е. речь шла не о том, что что-то появилось в ЖЖ, а о том, что что-то появилось на неназванном сайте? Тады понятно

Впрочем, чего его писать каждый раз? Просто URL файла в двух местах поменял и готово.

Под панорамы я знаю только 1 бесплатный хостинг с выдачей флеша для показа на чужих сайтов - это viewat.org, там действительно все "не ловко" - они выдают код с javascript, а для ЖЖ надо прямо object+embed, и его приходится выковыривать из их скрипт-файла.

Вообще, после практического исследования (на реальных текстурах), я зрительно не смог установить какой же метод лучше и пришёл в тупик.
Теперь такой вопрос: а нужно ли говорить об объёме, т.е. стараться привести объём шара к объёму куба? Может правильней исходить из площадей, т.е. приводить площадь сферы к площади поверхности куба?

drop

Цитата:

О! Наконец то, мне хоть понятно объяснили

Тонкая издевка?

Объясняю понятно:

Что-бы поместить панораму в блог, надо:
1. поместить ее на какой-то файлохостинг, выдающий ее по внешним ссылкам (если у блога нет своего файлохостинга)
2. поместить куда-то какой-то флеш-файл проектора, работающий при запуске с сайта блога
3. поместить в блог код, вызывающий проектор с файлом панорамы.

Для шага 1 можно использовать panolab.com, например (или просто какой-то файлохостинг с внешними ссылками)
Если нет настроенного проектора, то для шага 1 и 2 можно использовать панорамный хостинг viewat.org - он позвоялет показ панорам на внешних сайтах
шаг 3 зависит от движка блога. В зависимости от движка возможны 3 варианта вставки проектора в блог:
1. iframe
2. javascript (который сгенерит iframe или object+embed)
3. object+embed

конкретный livejournal поддерживает только object+embed (код вставляется в тег lj-embed). viewat.org его прямо не выдвает, поэтому надо скачать его javascript и выковырить из него html

Добавлено:
humanoid67

Цитата:

обратился за советом к спецам... мне сказали, что это точный метод...

Никогда не стоит воспроизводить на публике то, что "сказали спецы", если они не объяснили, почему так надо делать. Или, воспроизводя, стоит добавлять "есть такое мнение, может и неверное". А то глупо выглядит. Я так полагаю, что спецы имели в виду все же деление на pi, но просто научили как делать его в уме


Цитата:

*а zusker'a и "хлебом не корми"... дайте любую спорную тех.тему.. и он начнет тут разводить свои поучения напирая как танк... и гранатой его не остоновишь...

Так я просто со школьным курсом математики дружен. Ну и немножко представляю, что мы тут обсуждаем


Добавлено:
SK74

Цитата:

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

Поэтому я и назвал тест идиотским.

Сравнивать можно разные интерполяторы.


Цитата:

Теперь такой вопрос: а нужно ли говорить об объёме, т.е. стараться привести объём шара к объёму куба? Может правильней исходить из площадей, т.е. приводить площадь сферы к площади поверхности куба?

Что-бы о чем-то говорить, надо подумать, зачем это нам

Зачем нам нужен куб с размером "экватор поделить на пи" - понятно. Это максимальный размер куба, который имеет смысл (точка в центре грани воспроизводится 1:1, на краях - растягиваются). Любой куб большего размера не будет содержать в себе больше информации - мы будем просто растягивать исходник. Любой куб меньшего размера потеряет информацию, как минимум в центре граней. Терять информацию в общем случае - это не хорошо и не плохо, все зависит от того, как мы ее собираемся использовать. Но если нам нужен максимум детализации и не важен размер, то надо делать максимальный размер куба, т.е. делить на пи.

Добавлено:
Добавлю:

"по краям - расттягивается" - это про отображенеи точек с экватора и меридианов на грани куба. С параллелями все не так просто

zusker
Спасибо

zusker

Цитата:

Я всегда так общаюсь

это мы все помним
дальше смысла полемизировать в этом ключе не вижу смысла

SK74

Цитата:

а нужно ли говорить об объёме

если уж говорить о плоскости (будь то шара (сферы), будь то куба), которая растягивается, то нужно говорить о площади поверхности. Ведь именно ее и составляют те самые пиксели, которые составят в итоге простыню экви

Rodeus

Цитата:

если уж говорить о плоскости (будь то шара (сферы), будь то куба), которая растягивается, то нужно говорить о площади поверхности. Ведь именно ее и составляют те самые пиксели, которые составят в итоге простыню экви

Я попробовал, ради интереса, исходя из Sсф=Sкуб найти размеры сторон куба, получилось плохо (в смысле не найти, а итоговый результат ремаппинга). Попробую поставить AutoCAD нарисовать свои измышлизмы - слова zuskerа, чтобы всё это выглядело наглядней. Я всё таки переосмыслил всё вышесказаное и думаю, что zusker хоть и хамит но всё же прав

SK74

Цитата:

Я всё таки переосмыслил всё вышесказаное и думаю, что zusker хоть и хамит но всё же прав

А хамлю любителям засорять информационное пространство. Уважать надо окружающих Впрочем, это к Гуманоиду относится в первую очередь.

Посчитать куб равной площади - не проблема. Но вопрос я задал: зачем? Я же объяснил выше, чем интересен куб с гранью "экватор поделить на pi".

А считается просто:
Sсферы: pi*d^2
Sкуба: 6*x^2
pi*d^2=6*x^2
d^2/x^2=6/pi

d/x=1.38

Ну или через экватор:
x=Lэкватора/pi/1.38

Цитата:

Впрочем, это к Гуманоиду относится в первую очередь.

Чего докопался как мент до столба (?)

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

humanoid67

Цитата:

Чего докопался как мент до столба (?)

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


Цитата:

А не много ли чести (?) гражданин хороший... или уже возомнил себя "столпом" теории панорамной фотографии (?)

А для того, чтобы пользоваться школьным курсом математики нужно быть столпом?

Мы ж уже обсуждали гуманитариев и технарей применительно к теме.

всем привет весь форум не осилил....но почитав Зубца и его статьи за 2 недели склепал самодельную панорамную головку и сделал 5 панорам ...Мужики оцените...
http://mmk.name/index.php?option=com_content&task=blogcategory&id=51&Itemid=91

GUI+2VR/ завёрнуто во флаш

tackuro вполне для первого раза, тока кажись у меня не работает кнопка "ВО ВЕСЬ ЭКРАН" - это бага или фича?

Manofjesus
скорее баг, т.к. в локальном режиме кнопка работает

да из под сайта не всё просто раоботает. Кстати сделал виртуальный тур тунельный типа. Из пано в пано нажатием перейти можно в самой панораме.
http://mmk.name/index.php?option=com_content&task=blogcategory&id=51&Itemid=91


а вот вид самодельной головки панорамной
http://picasaweb.google.ru/aksessuar/vDDhmK#5291599329272691090

Друзья, помогите пожалуйста найти Object2VR!
Очень понравилась программа.

Никак не могу разобраться с PTGui 8.02 x64 Не видит Pano12.dll.

Винда - Vista 64bit

Raimon
64-битной pano12.dll нет. Поэтому просто пользуйся 32-битной PTGui, если хочешь использовать Panorama Tools.

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

Manofjesus

Цитата:

решаем этот вопрос или нет

Ответ выше одним сообщением. Надо компилить Dll-ку

понеслась....
два года тишины на руборде и опять.....
Хамство оно и в Африке хамство. И ему оправдания искать не надо. И менторский тон уже задолбал. Кому адресовано все знают.