Свежие комментарии

А у тебя же 24 мм? И им можно панорамы снимать? Нет, я понимаю, что можно, я не очень понимаю на практике, сюжет и т.д. Очень близко и очень низко?

Это, естественно, круг.

При этом, на 24-мм края этого круга уже существенно виньетированы на открытой дырке, у 90-мм гораздо лучше все.

L-bracket у меня, естественно, есть.

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

Почему пластина - это кривое решение?

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

L-bracket, панорамная база на голове и т.п. - это есть и так, пластина - это избыточный вес относительно того, что я и так таскаю.

Еще мысль!

А попробуй-ка ты включить в PTGUI viewpoint оптимизацию

Оно малость не про то, но вдруг поможет.

Я бы посоветовал для начала соптимизировать центральный ряд, снятый без смещения поворотом камеры (оптимизацию и использование контрольных точек исходников верхнего и нижнего рядов отключаем в закладке "оптимизация")
включить все исходники, включить исходникам вернего и нижнего рядов viewpoint optimisation и соптимизировать целиком.

Ну идея, что надо сначала склеить тройки, а потом уже из них клеить цилиндр или там сферу - она и в исходном посте отражена.

Ну да, можно варез для этого написать. Можно фотошопом клеить, он это клеит отлично.

Ну "однорядная голова" - это просто кусок дюраля весом 110 граммов, причем он много для чего еще годится (RRS-овские рельсы MPR).

А многорядная голова, если в исполнении RRS, - это еще одни рельсы и и еще одна панорамная база. Добавочные 400 грамм и примерно столько же баксов.

А про вертикали - оно верно, но ценой лишних преобразований. Конечно, пикселей в панорамах обычно более чем хватает....

Во, а мне надо небесную твердь иметь в виде цилиндра.

Так точно никто не умеет?

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

Алгоритм действия ЛЮБОГО панорамного софта один и тот же:
1. исходники виртуально отображается на сферу, т.е. для любого кадра находятся параметры, позволяющие отобразить любую точку любого кадра на небесную твердь - хрустальный шар, центр которого - не на черепахе, но в голове наблюдателя с камерой :)

2. небесная твердь отображается на плоскость в одной из известных из уроков географии проекций :)

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

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

так что понасилуй hugin'а, должен найти то, что я не нашел (где там галка, включающая независимую оптимизацию параметров оптики для каждого кадра - не знаю, в ptgui она я явно торчит в lens settings, но он независимо оптимизирует только a,b,c)

Чтобы у журнала была нормальная скорость записи - его нужно на отдельном массиве собирать.

В том смысле, что шифт-кадры нужно "обратно" искривить, дабы они стали сферическими?

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

Теоретиццки - тот же Hugin, задавши хитрые параметры оптимизации (создать N "объективов" с одинаковым фокусным и привязать их к сдвинутым кадрам; в оптимизаторе расставить галки напротив "x shift" и "y shift" для тех "объективов", которые привязаны к тем кадрам, которые снимались со сдвигом; далее действовать обычным образом). Возможно удастся сократить количество нажатий кнопок мыши, написавши скриптик, создающий готовый "проект" (это обычный текстовый файл с расширением .pto) с уже прописанными в нём "объективами" и параметрами оптимизации.

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

Создание такой панорамы требует дополнительного геометрического преобразования, обратного шифту в объективе. Поддержка этого есть в панорамных сборщиках, основанных на panorama tools (ptgui, hugin), но, к сожалению кругом разложены грабли:

1. в PTGUI это параметр однозначно оптимизируется только глобально, в пользовательском интерфейсе есть возможность индивидуального включения оптимизации подкаждый кадр только параметров a, b, c. Т.е. панораму с фиксированнм шифтом - сделаешь.

2. в HUGIN в пользовательском интерфейсе оптимизатора вроде бы дял всех параметров оптики есть списки "у каких исходников оптимизировать". Но ... у меня он вообще показывает в этих списках лишь 1 исходник. Хотя просто обязан работать с панорамами, снятыми разными объективами. Где та кнопка, которая включит ему оптимизацию шифта индивидуальную - не знаю.

Дерзай.