Pull to refresh

Comments 76

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

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

Что касается алгоритмов интерполяции — не думаю что в них дело. Например в hugin и autopano стоит bicubic по умолчанию, а вот блендинг, оптимизация, проецирование и прочее у них могут заметно отличаться.

По качеству могу сказать, что на данных примерах оно сравнимое, очевидных ляпов нет. Здесь я не утверждаю что одна программа лучше другой, это вопрос большого количества тестов да и скорее всего не будет такого что по всем параметрам одна лучше другой.
Аккурат в них, к примеру Lancsoz5 в шесть раз медленней чем bicubic работает.
Никаких артефактов сшивки не замечено, во всех случаях результат вполне приличный. А что касается медленного построения preview в hugin — там возможно уже много чего рассчитывается, что ускоряет основной рассчет, ну и разрешение возможно повыше, вобщем такова специфика hugin.
Вы бы выложили оригиналы фото и результаты склейки, а то пост напоминает недавнее сравнение видекодеков… У каждого ведь свои попугаи.
Про какое сравнение видеокодеков идет речь? Там следуя логике надо было все видео зашарить? :)

Файлы панорам большие и в обычный формат фотохостингов не вписываются, разве что заливать на файлообменники.

Если уж заниматься анализом качества то надо это делать отдельно, на несколько более репрезентативной выборке. Я думаю добавить в конец ряд картинок крупным планом показывающие стыковочные места, мне кажется этого будет достаточно.
Кажется этот, если память не изменяет.
Через время появился более подробный топик со всеми попугаями.

Там следуя логике надо было все видео зашарить? :)

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

Попробую пояснить.

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

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

В моем случае, чтобы получить продолжение приведенных таблиц надо выполнить все тесты на своей конфигурации или же иметь идентичную моей конфигурацию. Т.к. полностью идентичную конфигурацию никто не гарантирует, то если хочется расширить статистику, то так или иначе придется проводить полное перетестирование, а это с тем же успехом можно сделать на других данных.
Причем тут повторение тестов? Дай посмотреть тем кому интересно на исходник и результаты, полученные тобой.
Я думаю надо закончить это обсуждение. Коротко изложу позицию.

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

1) Если бы данные теста были бы какими-то не страндартными, ну например с ними плохо все справляются, то они бы имели интерес для тестирования другими. Здесь это не так.

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

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

Других из перечисленных причин зачем бы потребовались исходники я не вижу.
В тесте я выполнял сшивку кротчайшим для пользователя путем — кинул фотки, нажал на создание, получил превью, далее без редактировани запустил рендер. В hugin и ICE превью уже доступен для редактирования, а в autopano giga превьюшка маленькая и для редактирования надо нажимать кнопку, вход в редактор требует еще немного времени. В этом смысле autopano giga находится в несколько более выгодном положении, но workflow в ICE и hugin вполне сопоставимы.
Вы пробовали менять алгоритм интерполяции изображения? У сравниваемых программ просто они разные, от этого и скорость скачет.

Попробуйте поставить Lancsoz5 (3) к примеру, или Sync1024
Можно там очень много что менять, но это уже тонкая настройка и вариантов будет очень много, здесь скорее качественная картина показана в режимах по умолчанию.

По умолчанию в hugin интерполятор Poly3 (bicubic), в autopano giga — bicubic, в ice нет таких настроек.
Вообще говоря и в Hugin'e можно повысить кеш с дефолтны 100Мб (если память не подводит) до 500 или до 1024 (как у меня).

Плюс еще число контрольных точек — где побольше по дефолту, где поменьше. Это тоже влияет на скорость превьюшки, рассказали бы.

А в целом интересно, не думал что МS так хорошо продвинулись и здесь. Надо будет ICE попробовать.
Можно там очень много что менять, но это уже тонкая настройка и вариантов будет очень много, здесь скорее качественная картина показана в режимах по умолчанию.

По умолчанию в hugin интерполятор Poly3 (bicubic), в autopano giga — bicubic, в ice нет таких настроек.
Про память это я к тому, что вы тестировали autopano как раз на кастомных настройках)
Да, в первом тесте я тестировал autopano на дефолтных настройках и делал пару докруток, но это принципиально ничего не изменило. Все равно результат не сильно отличался и на расстановку мест и степень отставания отставания от ICE не повлияло.
Извиняюсь, предыдущий комментарий был ответом на замечания о интерполяторе.

Тут отображена качественная картина на основе того, что предлагается по умолчанию. Если варьировать определение контрольных точек, то разброс получится весьма существенным и не очень понятно как их сравнивать, параметры алгоритмов в разных программах разные. С кэшем hugin-а можно поэкспериментировать, будет видно насколько хорошо при установке они подстраиваться под систему.
Попробовал установить кэш 512 mb вместо 78 mb по умолчанию, изменения в пределах нескольки секунд на рендере панорамы из 10 кадров, стадия preview совсем не изменилась.
странно, у меня станция такая же как у вас по параметрам, но сшивает существенно быстрее. Превью да, там много памяти и не нужно, на это не повлияет.
В какой программе у вас быстрее сшивает? Какие ее параметры? Какие входные данные? Надо сперва все это проверить и потом делать выводы.
выше по треду вы говорили о hugin'e, я тоже.

Сшивает быстрее не в сравнении с ваши результатом, а по мере увеличения кеша один и тот же проект сшивает быстрее. Возможно я не ясно выразился.
Ага, все понял, прочел в почте в отрыве от контекста. Несколько странно, может зависить от вклада дисковой сисетмы в задержки, где-то они могут сильнее влиять где-то меньше, но это только предположение.
можно для чистоты эксперимента работать с ramdisk'ом или через tmpfs, главное что б памяти хватило))
кстати, это идея — надо будет посмотреть, мб стану собирать панорамы там если будет быстрее.
По звукам диска и если смотреть на график загрузки CPU, то минимальный ввод-вывод у ICE, у hugin и autopano заметно интенсивнее операции ввода-вывода. У autopano кстати увеличение размера дискового кэша привело к меньшему дерганию (произвольный доступ) диска, ну и ускорение думаю там отчасти из-за этого было.
А почему в тест не включили PTgui?

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

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

Т.к. большая часть панорам все-же правильная (расстояние до объектов большое, поэтому нет необходимости честно крутить вокруг нодальной точки), то тест совсем не лишен смысла — это типичная ситуация. А если снимать в упор и не учитывать нодальную точку, то задача никем нормально не решается — это просто неправильно так снимать. Вопрос качества blending-а и работу с движущимися объектами (деревья например колышатся) я здесь не рассматриваю и не утверждаю, что ICE качественнее других, в любом случае надо проверять результат.
а где же элемент творчества и искусства, если нужно по-быстрому склеить панорамы, сделанные в поездке…
хотя я это уже занудничаю :)

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

А секунды менрить действительно не стоит, но когда речь идет о десятках минут, то это уже несколько напрягает. Ведь workflow обычно такой — в превью все подгоняешь, а потом в пакетном режиме рендеришь и перепроверяешь, так вот эта стадия может растянуться на часы и это не очень хорошо, т.к. возможно потребуется новая итерация.
Тогда можно смело продолжить — не претендую на полноту и объективность =)
ptgui одна из популярнейших программ в своем роде, не включить её в тест — руководствоваться своими личными предпочтениями в подобных вещах думаю сводит проведенную работу на нет.
Что же касается выбора сложности кадров — то же самое.
В итоге совсем не понятна цель теста, пусть и не большого, параметры которого подбирались сугубо личными предпочтениями — разве что можно порадоваться, что нашли быстрый инструмент для удовлетворения своих конкретных нужд.

ps Эйфория от использования ICE проходит достаточно быстро — сразу же после первой более-менее сложной панорамы =)
Эйфории никакой и нет, просто я думаю, что это самая быстрая сшивалка на данный момент. Не думаю, что если взять какую-то другую панораму, то расклад сил не изменится, во всяком случае каждый сам может проверить сам.

А результат следует рассматривать именно как то, что я поделился собственным опытом.
Самая быстрая сшивалка — Core i7
у меня 17000х8500 собирается минут за 25 в PtGUI с откратия файлов, с авто расстановкой и смартблендом в конце, причем 20 минут работает смартбленд потому что он старый однопоточный.
Самая быстрая из трёх выбранных программ для склейки простых кадров.
Да и скорость сама по себе вещь бессмысленная — более интересны скорость И качество при склейке сложных кадров.
Вот эти два аспекта имхо на корню рубят абсолютную уместность фразы «самая быстрая сшивалка на данный момент».
Я в отличие от вас не делал утверждений относительно качества, а вы делаете — утверждаете, что она дескать хороша только для склейки простых кадров. В таком случае докажите это.
потому что мы тоже пробовали, и сделали соответствующие выводы…
я могу вечером дать вам исходники сферы средней тяжести, а вы посмотрите что вам ICE нарисует
Замечательно. Я тут слышал противоположный пример — на широкоугольной панораме ICE как раз хорошо отработала. Нужно нормальное тестирование с хорошей подборкой панорам.

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

Мне лично доказывать не нужно, я вобщем не утверждаю обратного вам, может ICE и имеет проблемы на таких панорамах, но если вы хотите указать на проблему, то надо опубликовать результаты множества тестов, если вы претендуете на некую общую оценку. Я смотрю на том что есть у меня и не ввоже никого в заблуждение, что если у меня работает, то будет работать на любых данных. Поэтому опубликуйте открыто, пусть с вами поделятся и другие своими соображениями.
говоря про «легкий материал для сшивания» я в первую очередь имел ввиду пейзаж. даже если софт и нарисует лишнее дерево, на результате этого будет не заметно
Ясно, я с панорамами архитектуры не часто сталкивался и по видимому не замечал проблем, но сам использую в основном autopano.
Давайте не мешать слова в кучу.
Утверждение относительно качества заключалось лишь в важности его учёта при тестировании, пусть даже это тест скорости — как минимум она зависит от набора данных. Остальное было лишь замечанием и личным предпочтением, четко отделенным от основного текста дабы не вносить раздор и не отклоняться от темы обсуждения.
А вы в Hugin включали экспериментальную (вроде бы) функцию которая позволяет использовать видеокарту на некоторых этапах?
Да, видел эту опцию, но не включал ее, т.к. она все-же находится в стадии beta. Сегодня доберусь до домашнего компа и попробую ее включить. Знаю, что они хотели в редакторе добавить поддержку GPU — когда допустим меняешь тип проекции или центральную точку, добавляешь наклон (в ICE кстати с первой версии в режим редактирования был в реальном времени на GPU), если это то, то скорее всего не повлияет на результат, т.к. это лишь для предварительного просмотра для быстроты редактирования, а далее в начале рассчета перепроецирование думаю идет по честному. Вобщем проверю это.
Ну вообще эта опция находится в настройках для Nona, а она отвечает за интерполяцию, так что должно повлиять
Опция доступна в сборке 2009.4.0, которую я сперва поставил, но пришлось заменить на последний официальный релиз 0.7.0, т.к. она почему-то не находила autopano-sirf-c. Вобщем скопировал эту штуку в 2009.4.0 и все заработало. В первом тесте GPU был задействован на стадии рендеринга, это было видно по диагностике, но радикального ускорения это не дало.

Итог: до превью все как раньше, рендер 1:27 против 1:43.
Ну и кроме того, вряд ли Вы пользовались enblend 4.0, который многопоточен
Я брал то, что давалось по умолчанию, без применения напильника. Вобщем не являюсь спецом в этой навороченой программе, сам пользуюсь autopano.
Полагаю, неплохо бы выложить результаты всех этих сшиваний. Чтобы можно было сравнить качество.
Здесь я не ставил задачу сравнить качество сшивки, для этого надо более репрезентативный набор примеров. Но в принципе можно выложить несколько кусков в разрешении 1:1, чтобы было видно что получилось, вечером вырежу кусочки.
Вот тут вы в конце неправы. Зачем что-то сравнивать не смотря на качество?
Я не спорю с тем, что нужно сравнивать качество, просто это отдельный вопрос. Здесь сравнивалось время. Это может подтолкнуть кого-то, чтобы попробовать этот продукт, бесплатных сшивалок не так уж и много.

Конкретно по этим примерам думаю кусочки выложу, чтобы сравнить качество.
я в паинте еще быстрее могу сложить панорамку, но ведь оттого она лучше не станет (
Вопрос качества здесь не поднимается, речь идет о скорости работы программ с параметрами по умолчанию.
Полазил внимательно по результату. Есть в ICE пара мест с небольшими недочетами. Но в целом, чтобы их найти надо присматриваться. Вобщем всегда стоит перепроверять результат сшивки. Я сам внимательнее относился бы к результатам ice, т.к. уже привык к высокому качеству autopano. Но я подумал, что не стоит загромождать пост картинками, все-таки исследовать качество надо более детально.
Есть у меня одна панорама — полная сфера 360х360 градусов (ну если по честному то, во всей панораме не хватает одного кадра — зенита, но это не суть важно), всего 65 кадров. Сюжет — небольшая поляна в лесу. Снято на хорошую панорамную голову — вращение вокруг нодальной точки, паралакса нет.
Тем не менее в панораме есть изъяны: дым от костра двигался и менял направления.
Hugin и Autopano Giga в автоматическом режиме сшивают в какой-то высокохудожственный бред, больше похожий на картины современных концептуальных художников, чем на лес.
За пол дня мучений с Hugin, в ручном режиме удалось собрать панораму так, как надо.

ICE собрал панораму в полностью автоматическом режиме без ошибок и артефактов, и достаточно быстро.
360х180 вы хотели сказать.

Раз на раз не приходится, у меня порой ptgui автоматически сшивает на первый взгляд несшиваемое, а иногда и сфотографируешь правильно, а контрольные точки во всех кадрах ставишь вручную, но и результат радует.
Здорово. Вообще-то не совсем корректно считать технологию ICE незрелой, скорее она просто не была видна широкой публике. Как только появился сервис карт у Microsoft, тогда все эти вещи уже внутри вовсю использовались. Опять-же photosynth близкий по математике проект.
Autodesk STITCHER попробуйте. Жуёт тоже всё.
ну да, 360х180 :)

Это я написал не к тому, что Hugin или Autopano Giga плохой продукт, это совсем наоборот. Это я к тому, что, не смотря на моё предвзято отрицательное отношение к Microsoft, должен признать, что ICE вполне себе достойный продукт.
надо было подождать до апреля со статьей, там фотошоп будет новый…
Я не претендую на полноту, панорамного софта очень много, тестировать можно до бесконечности. Пишу про то что интересно мне.
Та ладно, что там;)
Пасиб за статью
Пожалуйста! Я просто стал отвечать более формально, народу тут захотелось исходников, я никак втолковать не могу, что это ничего не даст. Вобщем спасибо за отклик!
Я не каждый день делаю панорамы, чтобы один раз не подождать минутку ) Так что использую PhotoStitch — в большинстве случаев устраивает.

Вот примерчик (4Мб) — река Хопер в Волгоградской области. Снято на мыло.
Отлично, если все устраивает, то наверное и не нужно заморачиваться. Здесь информация скорее для тех кого не устраивает или для кого кто еще не определился с выбором.
А ещё более старую версию Hugin нельзя было взять? :)
Хмм, интересная история. Я сперва скачал hugin по кнопке «get hugin now» первой ссылке на этой странице. После full установки при старте сшивки он не находил autopano-sirf-c, этого exe файла действительно не было. Тогда я на той же странице чуть ниже увидел ссылку «Pre-compiled versions: Windows: official 0.7.0», она-то и заработала без проблем. Оказывается она годичной давности.

Но меня в комментах попросили проверить быстродействие с nona-gpu (там используется GPU ускорение при сшивке), эта опция есть только в новой версии. Тогда autopano-sirf-c я подложил в bin для версии 2009.4 и смог получить результат. На первой время до preview не изменилось, а время сшивки стало 1:27 против 1:43 и это при активации GPU алгоритма. Т.е. я думаю что качественно картина едва ли изменилась от версии 0.7.0, только если тот самый autopano-sirf-c не был существенно оптимизирован.

Короче говоря вот такой бардачок там. Если вы разбираетесь в вопросе, то может подскажите как самую свежую версию заставить работать?
исходный материал не самый сложный для сшивания. попробуйте собрать городской пейзаж и без SmartBlend вам обеспечены долгие ночи в фотошопе
в догонку…
сшивание панорам это не только финальный просчет, я бы даже сказа финальный просчет никого не волнует. самое сложное в этом деле подготовить кадры, расставить контрольные точки… и тот MS ICE который я пробовал в июне 2009-го на этапе сборки панорамы был очень неудобен.
Соглашусь с тем, что в сложных случаях там где требуется ручная подгонка контрольных точек ICE не самый подходящий инструмент. Гибкости в этом плане не хватает, нет даже пакетной обработки, которую уже давно просят. Это сужает область его применения продвинутыми пользователями, но только в случае если результат проблемный.
Тестирование качества — это отдельный вопрос, требующий тестирования на большой выборке покрывающей всякие случаи. Я не утверждаю того, что ICE лучше всех, я лишь указал на скорость работы.

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

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

То, что найдутся примеры с которыми неважно справится та или иная программа сшивки я не спорю, это вопрос другого исследования. Кого-то на своих данных устраивает результат сшивки ICE, кого-то нет. Если у вас есть что рассказать и показать на эту тему — пожалуйста напишите об этом, всем будет интересно посмотреть.
В общем, нужны исходники. Автору спасибо, но устный «минус» (кармы нет)! :-)
мне одному кажется, что сравнение MS ICE и Hugin напоминает сравнение трехколесного велосипеда, укомплектованного реактивным двигателем и гоночного болида F1?
Sign up to leave a comment.

Articles