Цилиндрические панорамы (Q)

А какой-нибудь софт умеет одним проходом склеивать панорамы, которые сняты "цилиндрическим" образом в несколько рядов:

  • В горизонтальной плоскости крутим вокруг нодальной точки.
  • В вертикальной плоскости делаем сдвиг с помощью шифт-объектива (3 кадра).

Понятно, что можно склеить тройки, обозвать все это кадром 58x24 (или 44x36) и дальше клеить обычную однорядку, но это же ручной работы сильно больше.....

Update. Что-то ответы, которые пишут - какие-то разочаровывающие. Так недолго и мизантропом стать. Разжую помельче:

  • Я знаю слова PTGui, Panorama Tools, Realviz, Autopano и много других страшных слов. Мне не надо их вываливать списком.
  • Я снимал и склеивал панорамы "обычным способом" (несколько рядов с вращением вокруг нодальной точки или просто как получится).
  • Вопрос выше - это про довольно специальную методику съемки, когда горизонтальный охват обеспечивается вращением, а вертикальный - сдвигом объектива (shift-оптика).
  • Более всего мне интересно мнение людей, которые так уже делали. Общие соображения тоже интересны, хотя и меньше.
  • Вообще, просто склейка трех кадров снятых шифтом - довольно неприятное испытание для панорамного софта. Для плоской проекции не нужно вообще никаких геометрических преобразований, а обсуждаемый софт так не умеет (в смысле автоподбора параметров, естественно).

Comments

AutoPano PRO, PtGUI + panotools, думаю и Hugin справится.

А они понимают, что пространство изогнуто по-разному? У меня с Autopano нормальной сшивки кадров снятых с шифтом так и не получилось нормально, там фантазии у софта были всякие чудовищные.

Autopano шифт не понимает. Расслабься.

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

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

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

Дерзай.

Это был я

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

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

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

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

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

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

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

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

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

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

Ты не понял.

небесная твердь - она по определению в виде шара. Это то, что вокруг тебя, только без объема и дистации до объектов. Примерно как звездное небо.

тебе нужен софт, который смещенные кадры на сферическую твердь отобразит. Я тебя уже дважды послал в нужном направлении разными путями :)

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

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

Да не надо никакого вареза:

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

либо написать микроварез для перевода шифт-кадров в нормальные.

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

Если не поможет - есть путь настоящего джедая! Ты справишься, я уверен:

Если ты знаешь смещение, то остается написать простенький фильтр, который делает из исходного смещенного кадра 24mm полный кадр на 14mm (с расширением поля). Сливать в tiff с альфа-каналом на пустые места. Такое можно скормить Autopano, она понимает альфа-канал в тиффах.

Посмотрел совет человека снизу, проверил - да, все нужные галки загораются. Очень нетрадиционный вариант они придумали, сходу не догадаешься.

Т.е. в хугине идешь в окно "камера и объектив", выделяешь группу исходников, снятых с одним шифтом и жмешь новый объектив. У них меняется цифра в колонке # объектива.

Потом в оптимизации оптимизируешь все, разрешив оптимизировать смещение.

Попробуй и расскажи про результат. И про вариант с PTGUI и ее viewpoint optimisation - тоже. Но мне вариант с hugin кажется самым прямым.

Еще мысль!

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

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

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

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

Потому что весь панорамный софт пересмотреть - у меня здоровья столько нет.

Оно не настолько страшное для пользователя, как то, с чем ты привык иметь дело :)
Нет, я не клею такие панорамы, как в твоем вопросе, но я не думаю, что ты потратишь на выяснение ответа с ICE больше получаса, учитывая загрузку и установку.

А оно хорошо чем-либо, ради чего его стоит попробовать?

Нет, конечно. Оно мерзко, затхло и отвратительно.

А если серьезно, то там прямо на той <a href=http://research.microsoft.com/en-us/um/redmond/groups/ivm/ICE/>странице</a>, на которую я ссылку давал, сразу под картинкой живет описание. Врядли я скажу что-то новое, кроме банальной констатации "да, работает".

<i>Нет, конечно. Оно мерзко, затхло и отвратительно.</i>

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

На "той странице" я не нашел ни малейшего намека на что-то достойное внимания, кроме поддержки двух новых форматов, MSовских же.

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

С фишаем я панорамы не снимаю, поэтому здесь ничего сказать не могу, а вот снятого на полтинник и 17-35 у меня вагон с тележкой. В 99% случаев - с рук. Сейчас вот ради интереса натравил ICE на 7 или 8 разных "панорам" (в кавычках, потому, что минимум 4 из них - это просто кадры из одной точки без всяких попыток снять панораму). В одном случае оно действительно не осилило, а во всех остальных случаях сшило корректно. В одном из случаев ошиблось с типом проекции - поправлено в один клик. Простые случаи сейчас не пробовал вообще.
Мне кажется, что 15% ошибки - хороший результат, даже если эти 15 процентов придется клеить в другом фреймворке.

Что значит "сшило корректно"?

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

А сшивать корректно на автомате нынче умеют многие. В APP это можно сделать для пачки панорам вообще без участия человека, выставив все параметры заранее. Про "ошиблось с типом проекции" - из той же области. Хотя лично я считаю, что не дело софта выбирать проекцию - часто она подбирается исходя из чисто художественных критериев. Да и меркатора у ICE нет, а он часто нужен.

Без переднего плана я вообще почти никогда не снимаю, но на моих "панорамах" оно отработало нормально. Если не забуду, завтра попробую скормить ей то, что снимал с кораблика при волне балла в 3-4, там, как понимаешь, если в кадре горизонт прямо - уже удача :)

И отмечу, что все же "выставить параметры заранее" - уже не называется "на автомате" (или я не понял, что подразумевается под выставлением параметров). На автомате это именно "сшей само вот эту груду картинок". Задачи разные.

Отступая чуть в сторону: если у тебя есть примеры, где оно шьет неправильно и ты готов ими поделиться и показать, что именно неправильно (либо как правильно), то я готов донести эти примеры до авторов ICE. Ибо я охотно допускаю, что на моих примерах этого просто не видно, несмотря на наличие переднего плана.

Я тестировал эту панораму:
http://pics.livejournal.com/skoblov/pic/000420g9

Это двухрядка

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

К тому же, авторы погнались за визуальной красотой "вращалки", крутящей панораму, а мне бы инструмент "вертикали", без него неудобно. Или numeric transform для того, чтобы делать мелкими шажками. Кручение мышью - неудобно

"Выставить параметры" - это поставить параметры разрешения, выходного файла, куда писать и т.д. :)

Кстати, попробую-ка я реально сложные примеры :)

Скормил ей сложную многорядную панораму с озером, солнцем над ним, отражением солнца в воде и черными горами над озером.

В отсуствии явных вертикалей и горизонта геометрическая часть результата - отличная. Убедительная кромка гор и нет явных перекосов. переходы между кадрами видны там, где очень плохое перекрытие (браковання кадр стер). Мелочи исправил блендер и местами там торчат артефакты. Но я бы сказал, что ни PTGUI, ни APP это автоматом не собирают.

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

Большая часть кадра просто замылена. Причем там в принципе и перекрытия кадров-то не было. Явный глюк.

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

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

В завершение. Я прогнал ту же сложную панораму, но сделал "слоеный" PSD и посмотрел. Короткое резюме из теста следующее:

я не думаю, что алгоритмы у ICE по идеологии другие, хотя уверен, что это не просто очередная реинкарнация того же SIFT'а, panorama tools и smartblend. Чисто по ощущениям:

1. За. на сложной панораме (с засвечеными и сильно недодержанными кадрами) их генератор контрольных точек сработал лучше SIFT'а. Хоть к.т. увидеть и нельзя, но это можно оценить по результату работы оптимизатора - сложные кадры легли туда, куда ожидалось.

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

3. За. Автовыравнивалка работает действительно приятно. Картинка на автомате лучше, чем картинка на автомате от APP и PTGUI. Но я на автомате собираю только превьюшки и панорамы, снятые с панорамной головы

4. За. Блендер действительно хорош, смартбленд хуже справляется с ошибками совмещения кадров и однозначно хуже - с кадрами, снятыми с разной экспозицией.

5. За. мечта идиота - слоеный PSD с масками блендинга. APP/PTGUI так не умеют

6. Против. Отсуствие HDR процесса и какой-либо экспокоррекции, кроме выравнивалка в блендере, делает софт абсолютно непригодным для меня. В описании упоминается некий exposure blending, я ожидал что-то типа exposure fusion, но видимо так названо выравнивание яркостей в блендере.

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

PTGui, Hugin, PTassembler, Autopano Pro.

Конкретно Autopano pro даже просто три кадра снятых шифтом склеивает с изрядной фантазией.

Согласен. Я им сам сначала попольвовался, а потом выкинул. Хотя, справедливасти ради, стоит отметить, что сделан он на том же движке, что и остальные вышеперечисленные товарищи. В результате пользовался PTGui и был счастлив.

Все-таки уточню ответ - вы именно эту комбинацию (шифт и поворот) пробовали клеить ?

Там же засад две
1) разная кривизна поля по горизонтали и вертикали. Что там у движка panorama tools - он это место умеет?
2) (минимальная) - высота оптической оси/нодальной точки все-таки меняется, хоть и всего на 10-12 миллиметров, но корректировать это место для ближнего плана конечно тоже хотелось бы.

Я клеил 360-градусные панорамки, <a href=http://mapia.com.ua/api_panoramas.html>такие вот</a>. Плоские тоже пробовал. Лучше движка пока не нашёл.

Там по ссылке пишут null 0%
поэтому я еще раз явно перезадам вопрос.

Эти 360-градусные панорамки сняты так, как я спросил, шифт по одной оси и вращение по другой?

Что движки - хорошие и многие задачи решают, я знаю. У меня вопрос про конкретную задачу.

Вращение по одной оси, поворот в плоскости, вращение в наклоне и потом ещё один поворот.

То бишь "обычные" панорамы.

Скажите, вы снимали/склеивали панорамы так, как написано в исходном вопросе?
Или просто уверены, что ничего сложного нет и все будет работать?

Нет, но надеюсь, что сработает, в частности PTGui. М на дискуссию потратим больше времени, чем на ксперимент.

Ну вот Скоблов мне пишет, что с PTGui счастья ожидать не следует

http://blog.lexa.ru/2009/01/29/cilindricheskie_panorami_q.html#comment-6146

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

А я еще не снимал, а наоборот только собираюсь.

Техника хороша тем, что вертикали не искажаются, кроме того панорамной головой для однорядной панорамы (с одной осью вращения) можно снять куда более "высокую" панораму (эквивалентное поле зрения по длинной стороне у 24/TS-E будет как у 14 миллиметров).

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

Так что выигрыш - действительно только в возможности использования однорядкой панорамной головы.

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

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

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

Ой! Я аж испугался.

Пластина - это самое кривое решение. Имеет смысл только для кругового фишая на полном кадре - там уже пофиг.

Найди человека с руками и закажи себе slim rotaror:
http://michel.thoby.free.fr/Nadir/Slim/Slim_rotator.html

или купи l-bracket у того же RSS

получишь совсем нахаляву выигрыш по разрешению при том же минимальном весе

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

преобразований при обработке многорядки, снятой обычным объективом, и при сборке многорядке, снятой с шифтом по вертикали и кручением по горизонтали будет ровно одинаковое количество - 1 штука :)

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

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

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

Теряешь треть от угла обзора объектива.

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

Ты чегой-то тормозишь.

Размер кадра (в пикселях и градусах) по короткой стороне меньше, чем по длинной :)

Вращая камеру в одной плоскости, по горизонтали ты имеешь сколько хочешь, а по вертикали - 1 кадр. При "просто планке" размер по вертикали - короткая сторона кадра, при L-брекете или слим-ротаторе - длинная :)

Для обычного обектива это однозначно. Для шифтовых многорядок с однорядной головой - сложнее. Какой виртуальный размер кадра у шифта при максимальном сдвиге, я не знаю. Если там получается квадрат - то и не страшно, что камера в горизонтальной плоскости крутится, а если, не дай бог, прямоугольник - то смотри комментарий с начала :)

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

А я уж за тебя испугался :)

А что с форматом "виртуального полного кадра" у шифта. Это квадрат или прямоугольник?

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

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

Да, чей-то я туплю. Да, круг, с отсеченными с четырех сторон краями. Т.е. при горизонтальном положении камеры ты теряешь чуть-чуть от максимального обзора, но не сильно, можно и не париться.

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

Т.е. если камера горизонтальна (и сдвиг вверх-вниз), то склейка из трех имеет виртуальный размер кадра 46x36, а для вертикальной камеры будет 24x58, чуть-чуть не хватает до 7-й мамии с панорамным адаптером.

Во втором случае, правда, виньетирование уже очень заметно.

Ну ты понял мою мысль ... :)

С шифтом?

Написал апдейт исходного поста, боюсь развивающейся мизантропии...

нет не клеил
я вот одной вещи про шифт не понимаю: если мы двигаем попой камеры, что можно делать например на кардане, у нас действительно получаются кадры сшиваемые [почти]простым наложением. Если мы двигаем линзой, то параллакс всё таки возникает, хотя оценить его не берусь.

Так в чём ценность шифта перед двумя конусами... если снимать с панорамной головки, конечно.

Re: нет не клеил
Параллакс возникает, но
1) Для горизонтального шифта он правится путем сдвига камеры в голове. Нужна голова-площадка, которая это дозволяет, но у меня все такие (я вообще влюбился в L-brackets)

2) Для вертикального шифта и, условно говоря, пейзажа, область где происходит наложение и параллакс будет в метрах или десятках метров. Для сдвига в 11 миллиметров - какой уж там параллакс.

А про панорамную голову я уже в блоге отписался - моя "панорамная голова" - это кусок дюраля с зажимом, общим весом в 110 граммов. Кроме того, у этого куска дюраля есть и другие функции, например держать вынос вспышки.

Re: нет не клеил
ну если всё "железо" есть, собирать такие картинки ты уже пробовал, в смысле какие проблемы?

Re: нет не клеил
геморойно получается - я клею тройки фотошопом, а второй проход - панорамными средствами. Отсюда и вопрос

опять немного не про то
>>Вообще, просто склейка трех кадров снятых шифтом - довольно неприятное испытание для панорамного софта.

панарамку в ~200мр снимал перемешенным картинки относительно камеры на 1/3 кадра (линейка, уровень, рыжая ассистентка) так вот это безобразие автопано про собрало в цилиндрический проекции вполне честно без искажений.

Re: опять немного не про то
Только в 1 ряд, обманув APP и сказав ему, что у нас объектив с очень большим ФР. А Алексей хочет многорядку.

Re: опять немного не про то
Моей автопане рвало от этого моск, во всяком случае в автоматическом режиме.

С плоскими картинками фотошоп сам в себе справляется лучше

а что за сюжет планируется к съёмке, что он не влазит в один ряд 24мм линзы?

если PTGUI не справится - искать более грамотный кусок алюминия.

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

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

> создать N "объективов" с одинаковым фокусным и привязать их к сдвинутым кадрам

Да, если съемка велась по принципу "сняли ряд - сдвинули объектив - сняли ряд", а не наоборот, то есть сдвиг одинаков на всём ряду, то очевидно что достаточно создать в hugin три объектива (точнее, один и так будет, создать надо будет два): "сдвинутый вверх" и "сдвинутый вниз". И включить для них галки "оптимизировать shift x/y". Т.е. задача сведется к штатной для hugin - "есть объективы с shift, это надо учесть при оптимизации" :-)

Но, повторюсь, именно трехрядку не клеил.

Общие соображения в принципе.

Я так вроде делал. Кажется Autopano. Но. У меня 90 мм фокусное. А с этим, как я понимаю, проще. Каких-то особенных проблем не помню, все как-то сразу склеилось и все, я даже теперь и не найду, что именно так снимал.

Но для себя решил как-то так незаметно, что смысла нет особого. При шифте яркость "сдвинутого" кадра падает, если я правильно помню. Лишние телодвижения при этом ничего особенного кроме потери времени не дают. Я не очень понял, но если у тебя там какие-то особенности с головой штативной (или вообще ее нет), то может быть и стоит. Я перешел на съемку вида "передний план тилтом, остальное прямым", иногда после смартбленда приходится помахать кисточкой, выбирая нужное (резкое) из нужного кадра. А при тилте перспективу колбасит сильно, но вроде собирается, на 90 мм, повторюсь. Вот только недавно снимал именно таким образом. Правда тут проще, ибо снег и т.п. http://www.sergeignatkin.ru/images.php?type=vpano -- предпоследняя.

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

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

У меня теперь и 24 и 90.

TS-E90 отличное стекло. С телеконвертором тоже великолепно, правда с 2х я не пробовал. Уже снимал или недавно завел? Главное фокусировку при тилте освоить. :)

Только завел, что-то поснимал, призадумался о другом экране.

К сожалению, извести все стекла темнее чем f/2.8 возможности не имею, поэтому родной пятерочный для ручного фокуса может не быть решением.

Ну я примерно так-же мучаюсь -- хотя мне проще, у меня только 400/5.6 темнее, но насколько темнее... боюсь с ee-s будет вообще. С одной стороны и черт с ним, но иногда приходится 1.4х ставить. Что фигово, angle finder с увеличением 2х не особенно с тилтом помогает, по центру показывает, а вот края, что очень важно не показывает. :)

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

А может и не так сильно /4 будет темнее? Кто бы попробовал...

На LL кстати есть статья с таблицами соотв. углов наклона и высоты установки камеры. В принципе попадает.

Но 90 пожалуй узковат, был бы миллиметров 70 такой.

Я в тяжелых случаях (когда нодальная точка не соблюдена и вообще косяки) использую <a href="http://qtvr.by.ru/NewQTWR/sm/smartblend.htm">smartblend</a>. Иногда помогает.

на днях прислали баг-репорт с юз-кейсом, а там (в юз-кейсе) белым по наглоязычному написано (цЫтирую дословно): "Aspirin may cause mouth and skin rash/lesions. This symptom may occur in patients who take the drug rectally."

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

.

Воздух сотрясен, можно переходить к содержательной части.

Ну, перефразируя, "ты похвастался - я тоже посмеялся" (э)

что же касается "содержательной части"...

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

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

.

E-mail ставится, дабы я мог лично ответить. Поэтому не надо ставить левые, мне это неприятно. Вместо нотификации - есть RSS-лента комментариев каждой заметки.
Но к делу.

Про аберрации и прочее - это верное замечание. Я же говорю скорее про размен - "не хочу таскать многорядную панорамную голову, что можно сделать?" (а хочу таскать что-то более полезное, скажем вес фото ограничен 6 кило, ибо едет на горбине с прочим барахлом). Ну и второе предположение (чисто для примера) - вертикального поля зрения как у 28-мм по длинной стороне - достаточно.
Вариантов получается два - 28-мм и однорядная панорама или 45-мм с шифтом и трехрядная, но однорядной головой. Второй вариант - это больше точек по вертикали (т.к. 3 кадра клеим), косинус - тот же самый, на хроматику надо смотреть, конкретно у 45/TS там все неплохо.

И ограничение одно - оно должно быть нормально поддержано софтом.

1. да, что-то я не из того поля (from vs to) скопировал свой ЖыЖешный мейл. Поправил, извиняюсь.

2. что касается хроматики, то оно не может быть "хорошо" - даже у _хороших_ "фиксов" на краях уже видна хроматика.

3. клеить панораму в "ландскейп", на мой взгляд, это вообще ребячество. Нужно снимать в "портрет" и многорядку (если уж нужно). Т.е. нужен либо "уголок" либо "шарик" (и ни то ни другое особой тяжестью не отличается).

4. софт типа PTGui нормально клеит даже панорамки с рук (т.е. вообще без штатива), главное, чтобы перекрытие по кадрам было примерно на треть (меньше - хуже. больше, что характерно, - тоже хуже), а если хочется "высокого качества", то см. п.3 (причём на зумах лучше уходить на "середину" диапазона, минимизируя геометрические "дисторсии") да ещё с expose bracketing.

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

.

Add new comment