PTStitcherNG сшивает набор перекрывающихся фотографий в широкую, цилиндрическую или полную сферическую панораму: геометрию кадров задаёт текстовый проект Panorama Tools или PTGui, движок исправляет параметры объектива и перспективы, перепроецирует изображения, а затем объединяет их многомасштабным смешиванием; для сложных стыков доступны оптимизация шва, цветовая диагностическая маска и загрузка вручную исправленной карты швов, а для панорам 360×180° предусмотрена отдельная обработка областей зенита и надира.

Основная единица работы здесь — файл проекта с параметрами будущей панорамы и описанием каждого исходного кадра. PTStitcherNG не ищет контрольные точки и не предлагает интерактивно двигать фотографии поверх предпросмотра: выравнивание, калибровку объектива, выбор углов и подготовку проекта выполняют заранее, после чего программа занимается вычислительной частью — геометрическим преобразованием пикселей, определением области результата и смешиванием перекрытий. Поэтому удобнее всего использовать её как рендерер уже проверенного проекта.

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

Как устроен рабочий процесс PTStitcherNG

Запуск строится вокруг простой схемы: сначала готовят проект, затем передают его PTStitcherNG и явно задают файл результата. В командной строке после имени программы указываются опции и projectfile; ключ -o задаёт итоговый файл. Если имя результата оканчивается на .tif или .jpg, движок использует соответствующий формат независимо от записи формата в проекте. Это удобно для тестов одного проекта: геометрия остаётся прежней, а контрольный JPEG и финальный TIFF можно получать отдельными запусками.

Сам projectfile — обычный текстовый файл в синтаксисе Panorama Tools. В нём есть строка параметров панорамы, строки исходных изображений и их геометрические характеристики. PTStitcherNG понимает подмножество традиционных команд PTStitcher и строк, которые создаёт PTGui. Практически это означает, что проект следует считать контрактом между подготовительным интерфейсом и рендерером: если в нём неверно рассчитаны углы, фокусное расстояние, тип объектива, размер холста или положение отдельных кадров, движок послушно применит именно эти данные.

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

Почему перед запуском нужно проверять проект

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

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

Какие изображения программа принимает

Нативное чтение предусмотрено для JPEG, TIFF и PPM. Это наиболее предсказуемые форматы, если нужна воспроизводимая пакетная обработка без дополнительных преобразователей. JPEG подходит для компактных исходников и тестов, TIFF — для рабочего потока с меньшим количеством потерь и повышенной разрядностью, PPM удобен как простой формат обмена между консольными инструментами. Для нестандартных и RAW-источников предусмотрен внешний механизм чтения.

Ключ -r задаёт программу или команду-reader, которая должна отдать PTStitcherNG изображение в PPM через стандартный вывод. В документации в качестве типичных вариантов упоминаются dcraw и инструменты Netpbm. По умолчанию программа использует правила из текстового файла PTImageReader.txt. Такой подход не означает, что движок сам понимает структуру каждого RAW: фактическое декодирование выполняет зарегистрированный внешний reader, а PTStitcherNG получает уже преобразованный поток пикселей.

Из этого следует важное правило диагностики. Если JPEG и TIFF из того же проекта обрабатываются, а конкретный RAW не открывается, сначала проверяют не геометрию проекта, а цепочку reader: наличие программы-конвертера, корректность команды в PTImageReader.txt, доступность входного файла и способность конвертера вывести валидный PPM. Ошибку декодера не следует лечить настройками шва или уровней пирамиды — эти параметры вступают в работу позже.

16-битный режим

Ключ -p переключает выходные данные на 16 бит на канал, то есть 48-битный RGB. Согласно manpage, этот режим применим к TIFF и PPM; обычное значение — 8 бит на канал. Выбор разрядности имеет смысл делать до длительного финального расчёта, потому что он влияет на объём результата и требования к последующей программе. Если дальнейшая коррекция включает заметные изменения экспозиции или цвета, 16-битный TIFF обычно сохраняет больше градаций, чем 8-битный файл.

Повышенная разрядность не создаёт дополнительной информации, которой не было в исходных данных. JPEG с 8-битными каналами не становится по-настоящему более детальным только потому, что контейнер результата хранит 16 бит. Польза проявляется прежде всего при работе с исходниками, в которых уже есть достаточная тональная точность, а также при последующих вычислениях без раннего квантования.

Выходной файл и управление именем результата

Файл результата задаётся ключом -o; он обязателен для обычной команды. Расширение .tif или .jpg имеет специальный смысл и принудительно выбирает формат. Если в качестве имени указать один дефис, панорама выводится в стандартный поток в PPM, при этом включается отложенное объединение. Такой вариант нужен в цепочках команд, где следующий процесс сразу читает пиксели без промежуточного файла.

Для больших панорам важно заранее оценивать не только число мегапикселей, но и реальный размер контейнера. Документация PTStitcherNG предусматривает BigTIFF для результатов, которые выходят за ограничения обычного TIFF. Совместимость BigTIFF с программой, которой предстоит открывать панораму дальше, следует проверить до многочасового расчёта: не каждый TIFF-reader одинаково работает с расширенным вариантом формата.

Многослойный TIFF имеет иной смысл, чем обычный смешанный TIFF. При выборе TIFF_m blender отключается, а в выходе сохраняются ремапированные слои исходных изображений с информацией об их положении на общем холсте. Это удобно, когда окончательный шов нужно собирать позже другим инструментом. Одновременно такой режим меняет обычную логику PTStitcherNG: не следует ожидать от него готового бесшовного изображения, если специально выбран выход, предназначенный для дальнейшего композитинга.

Проекции, которые определяет проект

PTStitcherNG ориентируется на панорамную модель Panorama Tools. Среди документированных вариантов есть прямолинейная, цилиндрическая, эквидистантная сферическая и другие сферические отображения; отдельно поддерживаются multiple-rectilinear и General Panini. Выбор проекции задаёт не эффект, а математическое соответствие между направлением луча в пространстве и координатами на плоском изображении. Поэтому одна и та же серия кадров при разных проекциях может выглядеть радикально иначе, хотя исходные фотографии не меняются.

Прямолинейная проекция сохраняет прямые линии прямыми, но при очень широком поле зрения сильно растягивает края. Цилиндрическая удобна для широких горизонтальных панорам, где вертикальные линии должны оставаться прямыми, а горизонтальная геометрия допускает цилиндрическое разворачивание. Эквидистантная проекция типична для полной сферы 360×180°: ширина соответствует полному обороту по азимуту, высота — углу от южного до северного полюса.

General Panini предназначена для широких видов, где нужно ослабить неприятное растяжение по краям по сравнению с прямолинейным отображением и при этом сохранить выразительную перспективу. В документации Hugin специально отмечено, что реализация PTStitcherNG работает из скрипта и не имеет интерактивного предпросмотра. Поэтому параметры такой проекции рациональнее сначала подобрать в совместимом визуальном инструменте, а уже затем передать готовый проект в рендерер.

Полная сферическая панорама

При достаточном наборе исходников PTStitcherNG формирует полную сферу 360×180°. Для такой панорамы левый и правый края итогового эквидистантного изображения представляют одно и то же направление в пространстве. Это отличает её от обычной широкой фотографии: шов может проходить через границу файла, а области около верхнего и нижнего края соответствуют полюсам, где геометрия сильно сжимается.

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

Смешивание зенита и надира

Для эквидистантной сферы предусмотрены ключи -z и -n, которые заставляют движок отдельно смешивать область соответственно зенита и надира. В обычной прямоугольной развёртке полюс представлен всей верхней или нижней границей, поэтому стандартная обработка перекрытия оказывается неудобной. PTStitcherNG строит промежуточные полярные изображения, обрабатывает их и возвращает результат в основную панораму.

Использовать эти ключи имеет смысл только тогда, когда геометрия проекта действительно соответствует полной эквидистантной панораме 360×180°. Попытка компенсировать ими обычный дефект на частичном панорамном кадре не решает исходную причину. Сначала проверяют размер и поле зрения проекта, наличие достаточного покрытия полюса, правильность поворота исходников и отсутствие выраженного параллакса, а уже затем оценивают качество специализированного полюсного смешивания.

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

Многомасштабное смешивание

По умолчанию PTStitcherNG использует многомасштабное смешивание с восемью уровнями. Идея состоит в том, что изображения и маски представлены на нескольких масштабах: крупные уровни обеспечивают плавный переход низкочастотных различий яркости, а мелкие удерживают локальные детали ближе к выбранной линии шва. Такой blender может скрывать умеренное несовпадение экспозиции лучше простого линейного feathering, но он не отменяет необходимость согласовать исходники.

Ключ -l задаёт максимальный размер пирамиды. Документированный верхний предел равен 10, значение по умолчанию — 8. Ширина области смешивания может доходить до степени двойки, определяемой этим уровнем, если перекрытие кадров достаточно широкое. Увеличение параметра делает переход более крупномасштабным, однако не гарантирует лучшего результата: слишком широкая смесь вокруг тонкого объекта может разнести несовпадение по большей области.

Ключ -m задаёт минимальный уровень пирамиды; документация сравнивает его действие с feathering маски. Значение по умолчанию — 3. Этот параметр полезен для сокрытия небольших несовпадений непосредственно возле стыка. При настройке важно менять по одному параметру и сохранять одинаковый тестовый участок, иначе трудно понять, исправил артефакт -m, изменение линии шва или сама корректировка проекта.

Как выбирать уровень смешивания на практике

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

При уменьшении итогового изображения часть дефектов исчезает визуально, поэтому контроль лучше проводить на масштабе 100% исходного рендера. Особенно это касается тонких линий, проводов, ветвей и контрастных оконных рам. Одновременно полезен уменьшенный вид всей панорамы: он быстрее показывает крупные полосы экспозиции и неестественные изменения тона, которые трудно заметить при просмотре отдельных пикселей.

Размещение линии шва

Ключ -b управляет стратегией шва. Значение 0 выбирает центр области перекрытия и является стандартным. Оно предсказуемо: при одинаковом проекте линия проходит там, где ожидается геометрически. Такой режим хорош для стабильных серий, где кадры сняты с одной точки и в перекрытиях нет движущихся объектов, потому что сложная оценка содержания не требуется.

Значение 1 включает оптимизацию шва по содержанию. В manpage этот режим прямо отмечен как экспериментальный и недоступный на CUDA-платформе. Он может помочь увести шов от заметной детали, но полагаться на него как на универсальный умный исправитель нельзя. В потоковом процессе раннее решение о маршруте шва не всегда возможно пересмотреть после появления следующей области изображения, поэтому сложная сцена требует визуальной проверки.

Значение 2 отключает обычную линию шва и смешивает изображения с равным весом. Это диагностический режим, предназначенный в том числе для редактирования швов. Он хорошо показывает, где исходники геометрически расходятся: вместо скрытого выбора одного кадра становятся видны двойные контуры. Поэтому результат -b 2 полезен не как финальная панорама, а как способ понять, что именно маскирует стандартный stitch.

Цветовая карта и ручное редактирование швов

Ключ -a переводит вывод в диагностический цветовой режим: вместо реальных пикселей каждый исходный кадр представлен уникальным цветом. Получается карта принадлежности, по которой видно, какой источник выбран в каждой точке панорамы. Это один из наиболее практичных инструментов PTStitcherNG для сложных перекрытий, потому что он превращает невидимое решение blender в редактируемое изображение.

Рабочая последовательность состоит из трёх шагов. Сначала генерируют цветовую карту. Затем открывают её в любом растровом редакторе и корректируют границы областей, не меняя сами индексные цвета. После этого передают отредактированную маску ключом -e mask. Цвета служат индексами исходных изображений, поэтому документация рекомендует сохранять маску в формате без потерь, например TIFF.

При редактировании важно не добавлять сглаженные промежуточные оттенки по краю кисти. Полупрозрачность, JPEG-сжатие, цветовой профиль с преобразованием значений или автоматическая коррекция редактора способны изменить точные индексные цвета. Если PTStitcherNG перестаёт корректно интерпретировать маску, в первую очередь проверяют, не появился ли новый оттенок на границе, не было ли изображение конвертировано в другой режим и совпадает ли размер маски с диагностическим выводом.

Ручной шов особенно полезен возле движущихся людей, автомобилей, воды, листьев на ветру и других объектов, которые различаются между кадрами. Задача состоит не в том, чтобы смешать больше, а в том, чтобы провести границу через место с минимальным визуальным конфликтом и по возможности оставить целый объект из одного источника. Если один человек разрезан между двумя моментами съёмки, широкий multiband-переход часто создаёт призрак; маска позволяет выбрать один кадр.

Порядок обработки исходников

Ключ -s определяет, обязан ли движок придерживаться порядка изображений из projectfile. При -s 0 кадры объединяются точно в перечисленной последовательности. Стандартное поведение позволяет PTStitcherNG оптимизировать порядок ради скорости и меньшей потребности в памяти. Для обычного финального расчёта оптимизация полезна, но при разборе проблем иногда лучше временно зафиксировать порядок, чтобы получить воспроизводимый промежуточный ход обработки.

Порядок не меняет математически заданное положение кадров, однако в потоковом алгоритме может влиять на момент, когда доступна конкретная область перекрытия и принимаются решения смешивания. Если нестабильный артефакт возникает только при сложной автоматической линии шва, сравнение стандартного режима с -s 0 даёт диагностическую информацию. Полученный эффект всё равно следует оценивать на одинаковом проекте и одинаковых параметрах blender.

Многопоточность и использование процессора

Ключ -j задаёт число потоков. По умолчанию PTStitcherNG ориентируется на количество доступных процессорных ядер. Увеличивать число потоков значительно сверх физически доступных вычислительных ресурсов обычно бессмысленно: рендер включает не только арифметику, но и чтение, запись, память и части алгоритма с собственными зависимостями. Практический выбор делается по замеру на типичном проекте, а не по максимальному числу, которое принимает командная строка.

Для сравнения производительности важно исключить кэш и различия формата. JPEG может сместить нагрузку в декодирование, большой TIFF — в дисковый ввод-вывод, а 16-битный режим увеличивает объём данных. Поэтому тест -j проводят на одной серии исходников, с одним выходным размером и одним накопителем. Кроме общего времени полезно следить за пиковым объёмом памяти и отсутствием ошибок: самый быстрый запуск непригоден, если он нестабилен на финальном проекте.

CUDA и видеопамять

В сборках с CUDA часть вычислений может выполняться на совместимом графическом процессоре. Наличие ключей CUDA в документации не означает, что любой современный GPU автоматически запустит старый бинарный файл: совместимость зависит от конкретной сборки, архитектуры устройства, драйвера и набора библиотек. Поэтому CPU-режим следует считать базовой контрольной точкой, а GPU-ускорение — отдельной конфигурацией, которую нужно проверить на реальном проекте.

Ключ -u предназначен для CUDA-конфигураций с небольшим объёмом видеопамяти: временные данные размещаются в оперативной памяти хоста вместо памяти видеокарты. На не-CUDA варианте этот ключ не оказывает действия. Компромисс очевиден: использование host RAM может позволить обработать более крупную панораму, но обмен между CPU и GPU способен снизить выигрыш в скорости.

Оптимизация шва -b 1 в документации отмечена как недоступная на CUDA-платформе. Это важно учитывать при сравнении двух рендеров: если CPU-вариант использует content-aware seam, а GPU-вариант вынужденно работает по другой стратегии, отличаться может не только время, но и рисунок стыка. Для честного теста качества параметры, которые реально поддерживаются обеими конфигурациями, должны совпадать.

Определение области преобразования: ключ -x

Перед обратным преобразованием PTStitcherNG оценивает, куда попадает каждый исходный кадр на итоговой панораме. Ключ -x управляет тем, насколько подробно делается предварительное прямое преобразование. Значение 0 проверяет все пиксели, 1 — только внешнюю рамку исходника, а 2 вообще не использует предварительно вычисленный прямоугольник и рассматривает всю область панорамы как потенциальное назначение.

Режим с одной рамкой быстрее, но может ошибаться для изображений, которые оборачиваются через границу 0/360° или имеют такое нелинейное преобразование, что экстремальная точка результата находится не на внешнем контуре исходного кадра. Поэтому программа по умолчанию выбирает более осторожный вариант для панорам с полным горизонтальным охватом. Для non-invertible multiple-rectilinear преобразования документация указывает использование -x 2.

Практический симптом неверно оценённой области — неожиданно обрезанный кусок ремапированного кадра при том, что геометрия проекта выглядит правильной. Если дефект расположен возле горизонтального шва сферы или связан с необычной проекцией, сравнение -x 1 с -x 0 или -x 2 помогает отделить ошибку определения bounds от проблем blender. Менять этот параметр ради качества самого интерполятора смысла нет: он решает вопрос области расчёта.

Отложенное объединение -d

Ключ -d откладывает merge до тех пор, пока не будут преобразованы остальные изображения. Согласно manpage, режим действует для плоского TIFF и PPM, предназначен для систем, которым неудобно выполнять seek по большим разреженным файлам, и потребляет значительно больше памяти. В обычной ситуации документация ожидает более высокую скорость без этой опции, поэтому включать её по привычке не следует.

Полезный способ диагностики — сначала убедиться, что проект стабильно строится без -d, затем испытать отложенный режим только при конкретной проблеме файловой системы или записи. Если панорама огромная, рост потребления памяти может стать более серьёзным ограничением, чем потенциальное удобство другого порядка I/O. Нельзя переносить результат теста с небольшого JPEG на гигапиксельный 16-битный TIFF без повторного измерения.

Инверсное преобразование -i

Ключ -i file включает inverse mode: вместо обычной сборки панорамы программа выполняет обратное преобразование, используя указанный файл как источник. Это специальный режим, который требует внимательного контроля имён. Документация предупреждает, что файлы, перечисленные в проекте как источники, при такой операции могут быть перезаписаны. Поэтому тестировать inverse mode в каталоге с единственными оригиналами опасно для данных.

Безопасная практика — сделать отдельную рабочую копию проекта и исходных файлов, проверить пути и запускать инверсную операцию только в изолированной папке. Здесь важна не только резервная копия: projectfile может содержать относительные пути, которые после переноса начинают указывать не туда, куда ожидает пользователь. Перед запуском полезно раскрыть проект текстовым редактором и убедиться, какие имена файлов действительно перечислены в строках изображений.

Работа через PTGui

PTGui умеет использовать PTStitcherNG как внешний stitcher. В его настройках путь задаётся в разделе Panorama Tools, после чего на вкладке создания панорамы выбирается stitching engine PTStitcherNG. Такая связка удобна тем, что визуальные операции — загрузка изображений, контрольные точки, оптимизация, кадрирование и проверка проекции — выполняются в графическом интерфейсе, а расчёт итогового изображения передаётся отдельному движку.

Параметры PTStitcherNG, которые не представлены отдельными элементами интерфейса PTGui, можно передавать через поле command line parameters. При первом запуске лучше оставить его пустым и убедиться, что базовый проект вообще рендерится. Затем дополнительные ключи вводят по одному: так легче отследить, какой именно параметр изменил результат или вызвал ошибку.

Выбор внешнего blender в такой конфигурации не имеет обычного эффекта: PTStitcherNG выполняет собственное смешивание внутри процесса stitching. Это принципиально для диагностики. Если пользователь меняет Enblend или другой внешний blender и не видит разницы, причина не в зависшей настройке, а в том, что выбранный движок не передаёт ему работу по финальному объединению.

Почему PTGui и PTStitcherNG могут дать неидентичные файлы

Совместимый projectfile описывает геометрию, но разные stitcher-движки не обязаны совпадать пиксель в пиксель. У них могут отличаться интерполяция, seam placement, multiband blending, обработка границ, метаданных и конкретных форматов. Поэтому правильнее сравнивать одинаковые участки по геометрии, видимости шва и тону, а не ожидать идентичного бинарного файла только потому, что исходный проект один.

Отдельно следует проверять цветовые профили и служебные теги результата. В пользовательских обсуждениях встречались сообщения о различиях в переносе профиля по сравнению с внутренним stitcher PTGui. Это не универсальная гарантия поведения каждой сборки, поэтому рабочий процесс должен включать фактическую проверку ICC в полученном TIFF или JPEG тем инструментом, который будет использоваться дальше.

Сценарий: широкая панорама из одного ряда

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

Если экспозиция снимков заметно менялась от кадра к кадру, multiresolution blending смягчит часть перехода, но лучше выровнять тон исходников заранее. Особенно плохо сочетаются локально обработанные JPEG, где соседние файлы имеют разные кривые, баланс белого или усиление контраста. Blender распределяет переход в пространстве; он не восстанавливает физически одинаковое освещение сцены.

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

Сценарий: полная сфера 360×180°

Для полной сферы проект должен описывать непрерывный круг и покрывать оба полюса. Эквидистантный выход имеет соотношение сторон 2:1 при полном угле 360×180°, если пиксельная плотность одинакова по осям. Перед рендером проверяют горизонтальное замыкание, чтобы объекты около нулевого меридиана не оказались разорваны из-за ошибочного crop.

Кадры зенита и надира лучше снимать так, чтобы на полюсе не сходилось слишком много сложных перекрытий. Если такой набор уже существует, специализированные -z и -n помогают blender работать в удобном полярном представлении. Однако они не исправляют отсутствие покрытия: пустой участок или участок, закрытый штативом, требует отдельного изображения либо ретуши после stitching.

Финальную сферу проверяют в viewer, а не только как плоский TIFF. В эквидистантном файле верхняя строка визуально растянута по всей ширине, хотя в сфере это одна окрестность полюса. Дефект, который на плоскости выглядит длинным, при интерактивном просмотре может сжаться; и наоборот, крошечный разрыв у горизонтальной границы становится заметным, когда зритель поворачивает камеру через шов.

Сценарий: многорядная и гигапиксельная панорама

Большая многорядная мозаика предъявляет требования прежде всего к геометрической оптимизации и памяти. Чем больше кадров, тем выше цена одной локальной ошибки: неверный yaw или параметр объектива может постепенно накапливать смещение по всей сетке. Перед финальным рендером полезно построить уменьшенный вариант того же проекта, потому что он быстро выявляет общий перекос, дырки, неправильное поле зрения и неожиданный crop.

Стандартная оптимизация порядка обработки -s 1 как раз направлена на скорость и минимизацию памяти. Для огромного результата без причины фиксировать исходную последовательность невыгодно. Если выходной TIFF становится слишком большим для обычного контейнера, используют BigTIFF и заранее проверяют поддержку его следующей программой. В противном случае вычисление может завершиться успешно, а открыть файл в привычном редакторе не получится.

При ограниченной памяти не стоит автоматически включать -d: manpage прямо предупреждает о большом расходе RAM в отложенном режиме. На CUDA-сборке с малой VRAM вместо этого предусмотрен -u, который переносит временные данные в host RAM. На CPU-конфигурации ключ -u не меняет работу, поэтому экономию памяти нужно искать в размере проекта, формате, порядке обработки и доступной системной памяти.

Сценарий: RAW через внешний reader

Если исходники хранятся только в RAW, PTStitcherNG можно связать с конвертером, который выдаёт PPM. Для серьёзной работы лучше сначала вручную проверить команду reader на одном файле: она должна без интерактивных вопросов записать корректный поток в stdout и вернуть понятный код завершения. Затем то же правило добавляют в PTImageReader.txt и тестируют небольшой projectfile.

Настройки RAW-конвертации должны быть одинаковыми для серии. Автоматический баланс белого, локальная экспокоррекция или различная тональная кривая на соседних кадрах усложняют seam blending. Если цель — последующая цветокоррекция, полезнее получать линейно и предсказуемо обработанные данные с единой установкой баланса, чем надеяться, что blender скроет каждое изменение проявки.

Ошибка в shell quoting особенно вероятна, когда путь содержит пробелы или не-ASCII символы. PTStitcherNG видит только результат внешнего reader, поэтому сообщение может выглядеть как проблема изображения. Для проверки временно используют короткий путь без сложных символов, запускают конвертер отдельно и только после успешного теста возвращают рабочую структуру каталогов.

Сценарий: ручной шов вокруг движущегося объекта

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

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

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

Параметры projectfile, которые особенно важны

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

Строки изображений содержат путь к файлу, тип объектива и параметры преобразования. Для панорамной геометрии критичны yaw, pitch и roll; параметры поля зрения и дисторсии определяют, как исходный кадр разворачивается в выбранную проекцию. PTStitcherNG применяет эти значения, но не решает заново задачу оптимизации. Если нужно изменить калибровку, корректируют проект в инструменте, который умеет работать с контрольными точками.

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

Относительные и абсолютные пути

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

Пути с пробелами требуют правильного quoting в командной оболочке и в строках проекта. Сложные национальные символы могут дополнительно упираться в особенности конкретной сборки и системной кодировки. Для диагностики достаточно скопировать два исходника и проект в короткую папку с латинскими именами. Если такой тест проходит, проблема не в stitching-алгоритме, а в обработке пути или имени.

Типичные ошибки запуска и их разбор

Если команда немедленно завершается без результата, прежде всего проверяют наличие -o, существование projectfile и читаемость исходников. Затем запускают с диагностическим выводом, не используя -q. На Windows не стоит добавлять -c, если нужны встроенные сообщения и progress report: этот ключ как раз отключает окна и переводит процесс в консольный режим. В автоматизации наоборот, -c помогает избежать модальных сообщений, но журнал должен сохраняться отдельно.

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

Сообщение об ошибке чтения одного кадра не обязательно означает повреждение фотографии. Для RAW это может быть внешний reader, для TIFF — конкретный вариант сжатия или глубины, которую не понимает данная цепочка. Полезно конвертировать проблемный файл в простой TIFF или PPM и подставить его в копию проекта. Успешный запуск с заменой локализует проблему в декодировании, а не в положении кадра.

Двойные контуры и призраки

Двойной контур появляется, когда два источника показывают одну деталь в разных координатах, а blender вынужден использовать оба. Причина обычно одна из трёх: геометрическая ошибка выравнивания, параллакс или движение сцены. Для первой исправляют контрольные точки и параметры объектива; для второй выбирают иной шов или возвращаются к корректной точке съёмки; для третьей вручную назначают владельца объекта через seam mask.

Диагностический -b 2 особенно полезен, потому что равное смешивание делает несовпадение очевидным. Если два контура уже там совпадают точно, а дефект появляется только при обычном режиме, исследуют seam placement и уровни пирамиды. Если контуры расходятся на несколько пикселей или больше, смена ширины blend лишь перераспределит ошибку и может сделать её менее резкой, но не устранит геометрическую причину.

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

Полосы яркости и различия цвета

Широкая полоса на стыке чаще говорит о различной экспозиции, балансе белого или тональной обработке исходников, а не о неправильном yaw. Multiresolution blender способен распределить переход, но при большой разнице появляются заметные градиенты. Лучше подготовить серию с одинаковыми параметрами проявки и отключить автоматические локальные корректировки, которые по-разному реагируют на содержание соседних кадров.

Если различается оттенок, полезно сравнить сами источники вне stitcher. Автоматический баланс белого в RAW-конвертере может дать каждому кадру свою температуру и tint. Смешивание таких файлов создаёт широкую цветовую зону, которую легко принять за ошибку PTStitcherNG. После выравнивания проявки рендер повторяют с теми же геометрическими параметрами; если полоса исчезла, seam engine работал с тем, что ему дали.

Отдельный случай — цветовой профиль итогового файла. Даже при одинаковых числах RGB изображение может выглядеть иначе, если профиль отсутствует или интерпретируется другой программой. Поэтому контроль включает чтение ICC-тега и просмотр в color-managed приложении. Важные архивные панорамы разумно хранить вместе с записанной информацией о рабочем цветовом пространстве, а не рассчитывать только на внешний вид в одном viewer.

Ошибки на границе 0/360°

Для полной сферы кадр может пересекать горизонтальную границу выходного файла. При слишком агрессивной оценке bounds часть такого изображения рискует считаться находящейся с другой стороны холста. В manpage именно wrapping input images приведены как случай, где оценка только внешней рамки при -x 1 способна ошибаться. Поэтому полный горизонтальный охват по умолчанию обрабатывается осторожнее.

Проверка проста: временно сдвигают центральный меридиан проекта так, чтобы подозрительный объект оказался далеко от границы. Если дефект исчез, проблема связана с wrap/crop или определением области, а не с локальным совпадением кадров. После этого возвращают нужное направление и подбирают корректный режим -x, одновременно убеждаясь, что сама панорама действительно описана как 360°.

Артефакты у полюсов

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

Если остаётся вихрь или раздвоение, проверяют, сколько кадров одновременно покрывает полюс и как они выровнены. Иногда лучший результат даёт один отдельный снимок зенита с чистым покрытием, чем множество косых перекрытий. PTStitcherNG не может выбрать недостающую информацию, если каждый источник содержит разные объекты или параллакс; ручной шов и более простая структура покрытия часто эффективнее расширения blend.

Почему панорама может получиться обрезанной

Обрезка бывает заданной и вычислительной. В первом случае проект сам содержит недостаточный размер или crop: это исправляется в подготовительном интерфейсе. Во втором случае конкретный remapped image неправильно ограничен предварительной оценкой destination rectangle. Здесь исследуют -x. Отличить случаи помогает тест: если пустой фрагмент отсутствует на preview проекта ещё до PTStitcherNG, причина почти наверняка в самом проекте.

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

Проблемы с seam mask

Если -e будто игнорируется, проверяют четыре вещи: имя файла, размеры, точность цветов и соответствие тому же набору исходников. Цветовая карта кодирует индексы изображений; если в проект добавили или переупорядочили кадры после генерации маски, её смысл может измениться. Поэтому диагностическую карту и финальный рендер следует считать парой, связанной с конкретной ревизией projectfile.

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

Когда -q и -c полезны в автоматизации

Ключ -q подавляет диагностический и временной вывод. Он делает лог чище, но на этапе настройки лишает полезной информации. Сначала pipeline отлаживают с сообщениями, затем включают quiet только после того, как ошибки надёжно ловятся по коду завершения и наличию корректного выходного файла. Тихий режим не должен превращать сбой в незаметное отсутствие результата.

Windows-ключ -c отключает progress report и message boxes, что важно для процесса без оператора: модальное окно иначе может остановить очередь до ручного клика. Но автоматизация должна записывать stdout/stderr, фиксировать команду и проверять размер результата. Простое существование файла ещё не доказывает успешный stitching, особенно если предыдущая неудачная попытка оставила старый файл с тем же именем.

Как строить надёжную пакетную очередь

Каждый job лучше помещать в отдельный каталог или давать уникальное имя результата. Перед запуском проверяют наличие всех исходников, парсят projectfile хотя бы на список файлов и убеждаются, что output не совпадает с input. После завершения фиксируют код процесса, размер, время и контрольную сумму результата. Такая обвязка не относится к алгоритмам PTStitcherNG, но делает консольный движок пригодным для воспроизводимого производства.

Для большого набора проектов полезно хранить командную строку рядом с результатом. Тогда через месяц можно понять, использовались ли -z, -n, ручная маска, 16-битный режим или нестандартные уровни пирамиды. Визуально похожие панорамы могут быть рассчитаны по разным правилам; без журнала невозможно отделить изменение проекта от изменения параметров stitcher.

Параллельный запуск нескольких экземпляров следует ограничивать по памяти и дисковому вводу-выводу. Один PTStitcherNG уже способен использовать несколько потоков; запуск большого числа jobs одновременно может замедлить каждый из-за конкуренции за RAM и накопитель. Оптимальное число параллельных процессов находят по реальной загрузке машины и типичному размеру проектов, а не только по числу ядер CPU.

Совместимость с операционными системами

Дистрибутив PTStitcherNG распространялся с отдельными исполняемыми файлами для Windows, macOS и Linux. Это важно отличать от универсальности projectfile: текстовый проект может описывать одну и ту же панораму, но бинарный файл должен соответствовать системе и процессорной архитектуре. При переносе проекта между компьютерами безопаснее переносить только данные и настройки, а исполняемый файл выбирать для конкретной платформы.

Для Windows существовали CPU-варианты и сборки с CUDA. При проверке на современной системе сначала лучше использовать CPU-исполняемый файл, потому что он не зависит от совместимости старой CUDA-цепочки с нынешним драйвером. Если базовая сборка корректно строит тестовую панораму, GPU-вариант можно проверять отдельно, сравнивая не только время, но и доступные параметры шва.

В macOS-пакете исторически встречались два объекта с похожим названием: небольшой AppleScript wrapper и настоящий Unix executable. В обсуждении установки для PTGui пользователям прямо советовали выбирать исполняемый файл PTStitcherNG, а не wrapper-приложение. Если внешний фронтенд сообщает, что stitcher не запускается, проверяют именно путь к бинарному файлу, а также право на выполнение.

Linux-сборки также зависят от ABI и библиотек окружения. Даже когда файл предназначен для Linux, это не гарантирует запуск на произвольном современном дистрибутиве. Для практической проверки достаточно вызвать help на копии бинарника и затем построить крошечный проект из двух TIFF. Если проблема возникает до чтения projectfile, искать её нужно в совместимости executable и библиотек, а не в настройках панорамы.

Что PTStitcherNG не делает

Программа не предлагает встроенного редактора контрольных точек. Она не показывает пару изображений, не ставит маркеры совпадений и не оптимизирует положение камеры на основе этих маркеров. Для такой работы используют фронтенд Panorama Tools, PTGui или другой совместимый инструмент. Это главное отличие от современных комплексных stitcher-программ, где подготовка и рендер объединены в одном интерфейсе.

Нет интерактивного окна, в котором можно мышью поворачивать панораму и немедленно видеть результат смены проекции. Документация General Panini специально отмечает работу PTStitcherNG из scripts без interactive preview. Поэтому программа не подходит как самостоятельная среда визуального поиска композиции. Её сильная сторона — вычислить уже заданную композицию быстро и воспроизводимо.

PTStitcherNG не является RAW-проявщиком. Поддержка необычных форматов строится через внешний reader, а значит такие задачи, как выбор демозаики, баланса белого, шумоподавления и профиля камеры, принадлежат конвертеру. Чем стабильнее и одинаковее проявлены кадры, тем проще blender скрывает переходы. Смешивание не следует рассматривать как замену единой цветовой подготовке.

В документации вывода нет OpenEXR как штатного конечного формата. Для потока, где принципиально нужен EXR или 32-битный float HDR, стоит выбрать инструмент, который явно поддерживает такой результат. 16-битный режим PTStitcherNG относится к integer TIFF и PPM. Нельзя приравнивать 16 бит на канал к плавающей точке HDR только по размеру числового поля.

Встроенное смешивание не является отдельным внешним blender, который можно заменить настройкой Enblend. Если нужен конкретный алгоритм стороннего blender, практичнее получить ремапированные слои и смешать их далее другим инструментом либо использовать stitcher, рассчитанный на такой pipeline. PTStitcherNG оптимизирован вокруг связки собственного remapper и merger.

Выбор между обычным TIFF и TIFF_m

Обычный TIFF нужен, когда ожидается готовая объединённая панорама. PTStitcherNG выполняет seam placement и multiresolution blending и записывает единый растр. Это минимальный путь для публикации или дальнейшей общей цветокоррекции. Если же требуется вручную работать с каждым ремапированным кадром, обычный смешанный TIFF лишает такой возможности, потому что вклад источников уже объединён.

TIFF_m решает противоположную задачу: сохраняет отдельные ремапированные кадры в многокадровом TIFF и записывает их offset относительно общей панорамы. Blender при этом выключен. Такой результат крупнее и требует редактора или compositing-инструмента, который понимает структуру файла. Не стоит выбирать TIFF_m только из-за слова слои, не проверив, умеет ли следующая программа корректно прочитать именно этот вариант.

Поскольку TIFF_m отключает внутренний blender, к нему неприменимы ожидания от -z, -n и отложенного merging в обычном смысле. Если задача — получить отдельно ремапированные области вокруг полюсов и потом смешать их вручную, весь дальнейший процесс проектируют заранее. Формат результата определяет не только контейнер, но и то, какая часть работы вообще выполняется внутри PTStitcherNG.

JPEG как быстрый контрольный результат

JPEG удобно использовать для чернового рендера из-за меньшего размера и быстрого просмотра. Поскольку расширение .jpg принудительно выбирает JPEG, один и тот же projectfile легко просчитать сначала в уменьшенном варианте, убедиться в кадрировании и швах, а затем запустить финальный TIFF. Такой контроль особенно экономит время на многорядных проектах.

Финальное качество JPEG определяется параметрами, указанными в скриптовой строке формата, включая quality и progressive flag, если они используются. Но повторное JPEG-сжатие после уже сжатых исходников способно добавить артефакты. Для ретуши, цветокоррекции и архивного мастер-файла TIFF обычно предпочтительнее; JPEG разумно считать доставочным или проверочным форматом.

PPM как технический формат обмена

PPM прост: он хранит RGB-пиксели без сложной структуры контейнера, поэтому хорошо подходит для Unix-конвейеров. PTStitcherNG использует PPM и для внешних readers: конвертер читает необычный формат и пишет PPM в stdout, после чего stitcher принимает поток. Тот же принцип работает в обратную сторону, когда -o - направляет панораму в стандартный вывод.

Недостаток PPM — большой объём. Файл без эффективного сжатия быстро становится огромным, особенно в 16-битном режиме. Поэтому его выбирают ради совместимости с pipe и простоты обмена, а не ради экономии места. Если промежуточный файл нужно хранить долго, TIFF обычно удобнее, при условии что используемые программы согласны по варианту TIFF и разрядности.

Как оценивать скорость без самообмана

Чужие коэффициенты ускорения нельзя переносить на другую машину и другой проект без собственного измерения. Корректный тест строится на одинаковых исходниках, одинаковом output size, одинаковом типе данных и одном хранилище. Измеряют несколько повторов после прогрева файлового кэша либо, наоборот, осознанно сбрасывают его для теста холодного чтения; главное — не смешивать эти два режима в одной серии замеров.

Отдельно измеряют CPU и CUDA, если обе конфигурации действительно запускаются. Сравнение должно учитывать различия доступных функций: экспериментальный -b 1 не работает на CUDA, поэтому рендеры с разным seam algorithm нельзя считать полностью эквивалентными. Для производственного решения важнее время того режима, который даёт приемлемое качество, чем минимальное число секунд любой ценой.

Пиковая память измеряется вместе со временем. Потоковый характер PTStitcherNG рассчитан на ограничение memory footprint, однако настройки могут изменить картину. -d явно требует больше RAM, -u переносит временные CUDA-данные в host memory, 16-битный output увеличивает объём пикселей. Поэтому таблица тестов должна содержать не только секунды, но и пик памяти и размер результата.

Проверка качества после рендера

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

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

Для гигапиксельной панорамы необязательно просматривать весь файл на 100% подряд. Выбирают набор контрольных координат и сохраняют одинаковые crop для повторных тестов. Это делает сравнение параметров объективнее: можно мгновенно сопоставить шов на проводе, тон неба и участок возле полюса между двумя рендерами, вместо того чтобы каждый раз искать дефект заново.

Последовательность настройки без лишних экспериментов

1. Подготовить и визуально проверить геометрию projectfile в совместимом фронтенде.
2. Сделать небольшой контрольный рендер с параметрами PTStitcherNG по умолчанию.
3. Убедиться, что входные форматы, output и пути читаются без ошибок.
4. Проверить геометрию и только затем исследовать seam placement.
5. При локальном конфликте получить цветовую карту и при необходимости отредактировать маску.
6. Для полной сферы отдельно проверить зенит, надир и горизонтальное замыкание.
7. После подтверждения качества выбрать разрядность, формат и окончательный размер.
8. Только затем оптимизировать число потоков, CUDA и параметры памяти.

Такой порядок разделяет ошибки данных и ошибки производительности. Если сразу менять -j, -l, -m, -b и CUDA, любой новый результат становится трудно объяснить. Один изменяемый параметр на один тест — простое правило, но оно особенно полезно в программе без интерактивного preview, где каждый вариант нужно полностью просчитать.

Краткий справочник ключей

Ключ	Назначение	Когда применять
-o	Имя выходной панорамы	Обязателен для обычного рендера; .tif и .jpg принудительно выбирают формат
-i	Инверсное преобразование	Только в изолированной рабочей копии из-за риска перезаписи файлов проекта
-f	Перезапись результата	Когда автоматизация осознанно разрешает заменить существующий файл
-j	Число потоков	Для измеренной настройки CPU-нагрузки
-z	Смешивание зенита	Для полной эквидистантной сферы 360×180°
-n	Смешивание надира	Для полной эквидистантной сферы 360×180°
-r	Внешний reader	Для RAW и иных форматов через PPM-поток
-p	16 бит на канал	Для TIFF или PPM, когда нужна повышенная разрядность
-c	Консоль без окон Windows	Для пакетного запуска без progress/message boxes
-s	Порядок слияния	0 фиксирует projectfile; стандартный режим оптимизирует скорость и память
-u	Host RAM для CUDA	Когда на видеокарте мало памяти
-x	Оценка области назначения	Для wrap и нестандартных преобразований при проблемах с bounds
-l	Максимальный уровень пирамиды	Для настройки масштаба multiresolution blending
-m	Минимальный уровень пирамиды	Для управления локальной шириной feathering у шва
-b	Стратегия шва	0 центр, 1 content optimization, 2 equal-weight диагностика
-a	Цветовая карта источников	Для диагностики и подготовки ручной seam mask
-e	Загрузка карты шва	Для ручного выбора источника в спорных областях
-d	Отложенное merging	Для специальных проблем seek; требует больше памяти
-q	Тихий режим	После отладки пакетного процесса
-h	Справка	Для проверки доступного синтаксиса конкретной сборки

Ограничения, которые нужно учитывать заранее

Главное ограничение — отсутствие собственного интерактивного этапа выравнивания. Если проект не готов, PTStitcherNG не предлагает полноценного рабочего места для его исправления. Это делает программу очень конкретным инструментом: она хороша как render engine внутри цепочки, но неудобна человеку, который хочет загрузить фотографии и пройти все шаги мышью в одном окне.

Второе ограничение связано с современными системами. Доступные бинарные архивы относятся к прежнему поколению ОС, процессоров и CUDA. Функции программы документированы, но фактический запуск конкретного executable на нынешней машине требует проверки. Для производственной среды нельзя считать совместимость доказанной только наличием файла для Windows, Mac или Linux в старом архиве.

Третье ограничение — собственный blender и набор поддерживаемых конечных форматов. Для современной HDR-цепочки с EXR, для сложного локального warp или для масок, которые нужно интерактивно рисовать поверх живого preview, другой stitcher будет удобнее. PTStitcherNG следует выбирать тогда, когда его script-driven модель и прямой контроль seam/multiresolution параметров действительно соответствуют задаче.

Сравнение PTStitcherNG с аналогами

Программа	Лучше подходит для	Главное ограничение
PTStitcherNG	Воспроизводимого рендера подготовленных проектов Panorama Tools и PTGui, включая полные сферы и управляемые швы	Нет интерактивного предпросмотра и редактора контрольных точек
PTGui	Полного визуального цикла: выравнивания, оптимизации, кадрирования и сшивания сложных панорам	Для работы как минимальный script-driven render engine избыточен по интерфейсу и функциям
Hugin	Подготовки и оптимизации панорам в графическом интерфейсе с открытым набором инструментов Panorama Tools	Рабочий процесс включает несколько компонентов и требует понимания панорамной геометрии
nona	Скриптового ремаппинга проектов Panorama Tools и использования в автоматизированных цепочках Hugin	Для финального бесшовного объединения обычно нужен отдельный blender
PTStitcher	Выполнения классических скриптов Panorama Tools с традиционной моделью параметров	Не даёт специфических настроек многомасштабного seam workflow PTStitcherNG

PTStitcherNG рационально выбирать, когда геометрия проекта уже подготовлена и нужен именно быстрый повторяемый рендер с собственным многомасштабным смешиванием, диагностикой швов и возможностью вручную подать seam mask. Если требуется поставить контрольные точки, визуально менять проекцию, исправлять горизонт или сразу видеть результат перемещения кадра, удобнее начать с PTGui или Hugin. Nona лучше вписывается в современную свободную цепочку Hugin, особенно когда remap и blending намеренно разделены. PTStitcher полезен прежде всего для совместимых сценариев Panorama Tools, тогда как PTStitcherNG интереснее там, где нужны его параметры потокового remap-and-merge.

Как понять, подходит ли PTStitcherNG для конкретной задачи

Подходит — если уже есть корректный projectfile, конечный формат укладывается в возможности движка, а работа повторяется много раз или должна запускаться из скрипта. Особенно логичны серии одинаковых сфер, пакетные пересчёты с разным output size и проекты, где важен ручной контроль seam mask. В такой конфигурации отсутствие большого интерфейса перестаёт быть недостатком: все творческие решения принимаются раньше, а рендерер выполняет предсказуемую вычислительную операцию.

Не подходит — если задача начинается со случайной папки фотографий и ожидается автоматическое нахождение совпадений, исправление горизонта, интерактивный crop и готовая панорама без подготовки. PTStitcherNG не закрывает эти этапы. Также другой инструмент лучше выбрать, когда финальный pipeline требует формата, которого здесь нет, либо современного GPU-ускорения с гарантированной поддержкой текущих драйверов без проверки старого бинарного файла.

Отдельный критерий — сложность сцены. Для архитектуры с близкими объектами и сильным параллаксом нужен фронтенд с удобным анализом контрольных точек, масок и локальных проблем. PTStitcherNG сможет отрендерить исправленный проект и провести шов по заданной карте, но сам не создаст локальную геометрию, которой в проекте нет. Чем сложнее конфликт, тем важнее подготовительная часть рабочего процесса.

Контрольный запуск перед большим проектом

Перед первой серьёзной панорамой полезно собрать небольшой тест из двух или трёх TIFF с понятным перекрытием. Сохранить проект в совместимом фронтенде, выполнить базовую команду с -o и убедиться, что выход открывается. Затем повторить с -a, чтобы проверить диагностическую карту, и только после этого добавлять нестандартные параметры. Такой тест одновременно подтверждает путь к executable, чтение проекта, входные форматы и запись результата.

На полной сфере отдельный контроль делают для wrap и полюсов. Уменьшенная копия проекта должна закрываться по горизонтали, а зенит и надир — иметь реальное покрытие. После этого можно проверять -z и -n. Если базовый тест уже содержит дыру, запуск полюсного blend только усложнит диагностику: сначала требуется исправить геометрию или состав исходников.

Итоговая схема работы

Надёжный процесс с PTStitcherNG выглядит так: фотографии выравниваются и калибруются во внешнем интерфейсе, проект проверяется на уменьшенном preview, после чего stitcher получает готовые параметры. Первый рендер выполняется со стандартным seam и стандартной пирамидой. Проблемные перекрытия диагностируются через equal-weight режим и цветовую карту, а действительно сложные линии стыка корректируются lossless-маской.

Финальный формат выбирается по следующему этапу: JPEG — для компактной выдачи, TIFF — для готового мастер-растра, 16-битный TIFF — когда нужна повышенная тональная точность, TIFF_m — когда remapped sources должны остаться раздельными. Для очень больших TIFF заранее проверяется BigTIFF-совместимость. RAW передаётся через проверенный внешний reader, а любые различия проявки исправляются до stitching.

Производительность настраивается только после подтверждения качества: сначала число потоков, затем при наличии совместимой сборки — CUDA, а -u используется только при реальной нехватке VRAM. -d не является общей оптимизацией памяти и, наоборот, требует её больше. Такая последовательность позволяет использовать сильные стороны PTStitcherNG — скриптовое управление, тесный remap-and-blend и точный контроль seam — без попыток заставить движок выполнять задачи, которые относятся к подготовке панорамного проекта.