Хмм, интересная история. Я сперва скачал 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 не был существенно оптимизирован.
Короче говоря вот такой бардачок там. Если вы разбираетесь в вопросе, то может подскажите как самую свежую версию заставить работать?
Полазил внимательно по результату. Есть в ICE пара мест с небольшими недочетами. Но в целом, чтобы их найти надо присматриваться. Вобщем всегда стоит перепроверять результат сшивки. Я сам внимательнее относился бы к результатам ice, т.к. уже привык к высокому качеству autopano. Но я подумал, что не стоит загромождать пост картинками, все-таки исследовать качество надо более детально.
По звукам диска и если смотреть на график загрузки CPU, то минимальный ввод-вывод у ICE, у hugin и autopano заметно интенсивнее операции ввода-вывода. У autopano кстати увеличение размера дискового кэша привело к меньшему дерганию (произвольный доступ) диска, ну и ускорение думаю там отчасти из-за этого было.
Ага, все понял, прочел в почте в отрыве от контекста. Несколько странно, может зависить от вклада дисковой сисетмы в задержки, где-то они могут сильнее влиять где-то меньше, но это только предположение.
Опция доступна в сборке 2009.4.0, которую я сперва поставил, но пришлось заменить на последний официальный релиз 0.7.0, т.к. она почему-то не находила autopano-sirf-c. Вобщем скопировал эту штуку в 2009.4.0 и все заработало. В первом тесте GPU был задействован на стадии рендеринга, это было видно по диагностике, но радикального ускорения это не дало.
Итог: до превью все как раньше, рендер 1:27 против 1:43.
Пожалуйста! Я просто стал отвечать более формально, народу тут захотелось исходников, я никак втолковать не могу, что это ничего не даст. Вобщем спасибо за отклик!
Да, в первом тесте я тестировал autopano на дефолтных настройках и делал пару докруток, но это принципиально ничего не изменило. Все равно результат не сильно отличался и на расстановку мест и степень отставания отставания от ICE не повлияло.
Отлично, если все устраивает, то наверное и не нужно заморачиваться. Здесь информация скорее для тех кого не устраивает или для кого кто еще не определился с выбором.
Я думаю надо закончить это обсуждение. Коротко изложу позицию.
Я получил результат на своих данных, которые не хочу выкладывать. Но это не потому что я хочу кого-то ввести в заблуждение, а потому что, если бы мне казалось, что это было полезно, то бы взял другой пример и выложил бы исходники.
1) Если бы данные теста были бы какими-то не страндартными, ну например с ними плохо все справляются, то они бы имели интерес для тестирования другими. Здесь это не так.
2) Качественное отличие в скорости сшивки этих программ можно получить на любых входных данных и в этом можно убедиться на своих данных и своей конфигурации.
3) Проверки качества сшивки здесь не проводилось, да и данные подобраны как раз вполне обычные, поэтому не вижу смысла опираться именно на эти данные тем кто хочет проверить качество.
Других из перечисленных причин зачем бы потребовались исходники я не вижу.
Понятно. Но я все-же думаю что не всегда это обязательно.
Попробую пояснить.
Я недавно тестировал hd плееры на совместимость с видео — там использовалось более полусотни hd фильмов или например тестировал совместимость кодеков со спутниковыми потоками — там их было более десяти. Я подробно указал параметры потоков, чтобы было видно на каком именно материале возникают проблемы и какое имеется покрытие. В данном случае приводить исходный материал не особенно нужно, важно именно качественное покрытие примерами разного рода потоков.
В вашем примере используется единственный тестовый файл, на котором нитересно людям посмотреть другие настройки, дургие кодеки — тут люди могут попробовать и получить результаты дополняющие приведенные.
В моем случае, чтобы получить продолжение приведенных таблиц надо выполнить все тесты на своей конфигурации или же иметь идентичную моей конфигурацию. Т.к. полностью идентичную конфигурацию никто не гарантирует, то если хочется расширить статистику, то так или иначе придется проводить полное перетестирование, а это с тем же успехом можно сделать на других данных.
Про какое сравнение видеокодеков идет речь? Там следуя логике надо было все видео зашарить? :)
Файлы панорам большие и в обычный формат фотохостингов не вписываются, разве что заливать на файлообменники.
Если уж заниматься анализом качества то надо это делать отдельно, на несколько более репрезентативной выборке. Я думаю добавить в конец ряд картинок крупным планом показывающие стыковочные места, мне кажется этого будет достаточно.
Я не спорю с тем, что нужно сравнивать качество, просто это отдельный вопрос. Здесь сравнивалось время. Это может подтолкнуть кого-то, чтобы попробовать этот продукт, бесплатных сшивалок не так уж и много.
Конкретно по этим примерам думаю кусочки выложу, чтобы сравнить качество.
Здорово. Вообще-то не совсем корректно считать технологию ICE незрелой, скорее она просто не была видна широкой публике. Как только появился сервис карт у Microsoft, тогда все эти вещи уже внутри вовсю использовались. Опять-же photosynth близкий по математике проект.
Здесь я не ставил задачу сравнить качество сшивки, для этого надо более репрезентативный набор примеров. Но в принципе можно выложить несколько кусков в разрешении 1:1, чтобы было видно что получилось, вечером вырежу кусочки.
Мы не можем точно утверждать какой объем работы до момента превью проделывает та или иная программа, поэтому как минимум можно полагаться на общее время — бросил фотки, нажал формирование панорамы, нажал экспорт. Превью я привел скорее как дополнительная информация. Ведь обычно работа строится так — сперва делаем превью, все докручиваем и потом уже пакетно считаем. Но в данном тесте упор делается не на это.
Что касается алгоритмов интерполяции — не думаю что в них дело. Например в hugin и autopano стоит bicubic по умолчанию, а вот блендинг, оптимизация, проецирование и прочее у них могут заметно отличаться.
По качеству могу сказать, что на данных примерах оно сравнимое, очевидных ляпов нет. Здесь я не утверждаю что одна программа лучше другой, это вопрос большого количества тестов да и скорее всего не будет такого что по всем параметрам одна лучше другой.
Творчество присутстсвует на этапе между превью и рендером. Корректировка параметров панорамы. А вот ручную расстановку контрольных точек и докрутку не хотелось бы относить к творческому процессу. Ну и результат все-же надо просмотреть и где-то докрутить вручную.
А секунды менрить действительно не стоит, но когда речь идет о десятках минут, то это уже несколько напрягает. Ведь workflow обычно такой — в превью все подгоняешь, а потом в пакетном режиме рендеришь и перепроверяешь, так вот эта стадия может растянуться на часы и это не очень хорошо, т.к. возможно потребуется новая итерация.
Но меня в комментах попросили проверить быстродействие с nona-gpu (там используется GPU ускорение при сшивке), эта опция есть только в новой версии. Тогда autopano-sirf-c я подложил в bin для версии 2009.4 и смог получить результат. На первой время до preview не изменилось, а время сшивки стало 1:27 против 1:43 и это при активации GPU алгоритма. Т.е. я думаю что качественно картина едва ли изменилась от версии 0.7.0, только если тот самый autopano-sirf-c не был существенно оптимизирован.
Короче говоря вот такой бардачок там. Если вы разбираетесь в вопросе, то может подскажите как самую свежую версию заставить работать?
Итог: до превью все как раньше, рендер 1:27 против 1:43.
Я получил результат на своих данных, которые не хочу выкладывать. Но это не потому что я хочу кого-то ввести в заблуждение, а потому что, если бы мне казалось, что это было полезно, то бы взял другой пример и выложил бы исходники.
1) Если бы данные теста были бы какими-то не страндартными, ну например с ними плохо все справляются, то они бы имели интерес для тестирования другими. Здесь это не так.
2) Качественное отличие в скорости сшивки этих программ можно получить на любых входных данных и в этом можно убедиться на своих данных и своей конфигурации.
3) Проверки качества сшивки здесь не проводилось, да и данные подобраны как раз вполне обычные, поэтому не вижу смысла опираться именно на эти данные тем кто хочет проверить качество.
Других из перечисленных причин зачем бы потребовались исходники я не вижу.
Попробую пояснить.
Я недавно тестировал hd плееры на совместимость с видео — там использовалось более полусотни hd фильмов или например тестировал совместимость кодеков со спутниковыми потоками — там их было более десяти. Я подробно указал параметры потоков, чтобы было видно на каком именно материале возникают проблемы и какое имеется покрытие. В данном случае приводить исходный материал не особенно нужно, важно именно качественное покрытие примерами разного рода потоков.
В вашем примере используется единственный тестовый файл, на котором нитересно людям посмотреть другие настройки, дургие кодеки — тут люди могут попробовать и получить результаты дополняющие приведенные.
В моем случае, чтобы получить продолжение приведенных таблиц надо выполнить все тесты на своей конфигурации или же иметь идентичную моей конфигурацию. Т.к. полностью идентичную конфигурацию никто не гарантирует, то если хочется расширить статистику, то так или иначе придется проводить полное перетестирование, а это с тем же успехом можно сделать на других данных.
Файлы панорам большие и в обычный формат фотохостингов не вписываются, разве что заливать на файлообменники.
Если уж заниматься анализом качества то надо это делать отдельно, на несколько более репрезентативной выборке. Я думаю добавить в конец ряд картинок крупным планом показывающие стыковочные места, мне кажется этого будет достаточно.
Конкретно по этим примерам думаю кусочки выложу, чтобы сравнить качество.
Что касается алгоритмов интерполяции — не думаю что в них дело. Например в hugin и autopano стоит bicubic по умолчанию, а вот блендинг, оптимизация, проецирование и прочее у них могут заметно отличаться.
По качеству могу сказать, что на данных примерах оно сравнимое, очевидных ляпов нет. Здесь я не утверждаю что одна программа лучше другой, это вопрос большого количества тестов да и скорее всего не будет такого что по всем параметрам одна лучше другой.
А секунды менрить действительно не стоит, но когда речь идет о десятках минут, то это уже несколько напрягает. Ведь workflow обычно такой — в превью все подгоняешь, а потом в пакетном режиме рендеришь и перепроверяешь, так вот эта стадия может растянуться на часы и это не очень хорошо, т.к. возможно потребуется новая итерация.