Устранение неполадок WBPP: частые ошибки и известные баги
Эта статья составлена по заметкам 2022–2025 годов; некоторые инструменты или процессы с тех пор были обновлены, учитывайте это при чтении; сообщения об ошибках и особенности поведения версий в тексте зафиксированы такими, какими они были на тот момент. Об интерфейсе WBPP, мастер-калибровочных кадрах и обычном порядке выполнения см. другую статью «Полное руководство по WBPP».
Прогонять WBPP от начала до конца одним нажатием кнопки, конечно, приятно, но когда доходит до реального использования, всегда приходится сталкиваться с ситуациями, когда всё зависает, выдаёт ошибку или результат выглядит как-то не так. В этой статье я собрал в единый справочник по устранению неполадок несколько категорий проблем с WBPP, с которыми сталкивался за эти годы и о которых меня чаще всего спрашивают, — от диагностического подхода до нескольких конкретных известных багов.
Первый шаг устранения неполадок: сначала смотрим Process Console
Когда при обработке в PixInsight что-то идёт не так, первое, о чём всегда стоит подумать, — это посмотреть Process Console. Она подскажет, где произошла ошибка и какого она типа, — это отправная точка любой диагностики.
Однако WBPP — это скрипт, и пока скрипт не выполняется, console свёрнута и её нельзя выделить. Поэтому, чтобы увидеть console, часто приходится сначала закрыть WBPP. Звучит хлопотно, но для многих проблем это единственный источник подсказок — разгадка каждого из описанных ниже багов начиналась именно с той красной строки в console.
Сбои и баги на этапе калибровки
Калибровка завершилась ошибкой (failed) — сначала закройте PI, потом откройте заново. Если при запуске WBPP уже самая первая калибровка (с использованием мастер-калибровочных кадров) заканчивается неудачей и status показывает красный failed, можно приостановить весь процесс, закрыть PI, снова открыть WBPP и запустить ещё раз — эта ошибка калибровки обычно после этого исчезает. При обработке снимков с OSC-камеры я сталкивался с этим багом как минимум четыре раза, и каждый раз решал его именно этим приёмом.
Флэты постоянно выдают ошибку калибровки — вернитесь к ручной, пошаговой обработке. В некоторых версиях WBPP есть баг, который постоянно вызывает ошибку калибровки флэтов. В таких случаях важно уметь обрабатывать всё самостоятельно, шаг за шагом. Заодно повторим шаги Pre-Process:
- Calibration:
light − dark / ((flat − flat dark) * med(flat)) - Cosmetic Correction
- Debayer: интерполяция по матрице Байера
- Star Alignment
- NSG
- Integration
Когда на автоматизацию нельзя положиться, разбор процесса на этапы и ручной прогон, наоборот, облегчает определение того, на каком шаге возникла проблема.
Проблемы с путями: две возможные причины File I/O Error
При использовании WBPP в Windows, если на этапе калибровки (calibration) выскакивает File I/O Error, обычно это одна из двух причин:
- Путь к файлу вместе с именем файла слишком длинный и превышает системное ограничение, поэтому его нужно сократить.
- В целевую папку нельзя записать данные, например если вывод настроен в системную папку.
Первая причина встречается чаще всего. Чтобы устранить «слишком длинный путь» в корне, можно включить в Windows поддержку длинных путей (в regedit установить LongPathsEnabled в 1); также рекомендуется избегать путей с символами не из ASCII (например, китайскими). Подробные шаги для этих двух предварительных настроек среды я описал в разделе о настройке среды Windows статьи «Полное руководство по WBPP», поэтому здесь не повторяю.
Баг координат RA/DEC «60 секунд без переноса»
Это самая коварная и вместе с тем самая заслуживающая отдельного разбора проблема, потому что её симптомы бывают самыми разными, а первопричина всегда одна: в координатах прямого восхождения / склонения в FITS Header значение секунд равно «60», но перенос в старший разряд не произошёл.
Я сталкивался с этим дважды, и каждый раз проявление было разным.
Первый раз: WBPP не мог загрузить файл. Я закрыл WBPP и посмотрел Process Console — оказалось, что одна из строк какого-то js-скрипта сообщала «invalid coordinates». В тот момент я решил, что это баг WBPP, взял текст ошибки и поискал в интернете, и только тогда нашёл на PixInsight Forum несколько таких же сообщений об ошибке — выяснилось, что проблема с координатами мешает изображению загрузиться в WBPP. Имея направление поиска, я всё же потратил час, копаясь в нескольких сотнях лайтов, прежде чем нашёл проблемное изображение: его координата OBJCTDEC была неверной. Я открыл в PI процесс FITSHeader, прокрутил до OBJCTDEC и изменил значение, которое «должно было перенестись, но не перенеслось», — например, -69 26 60 я изменил на -69 27 0, — и этот кадр после этого успешно загрузился, а последующие файлы больше не застревали из-за него.
Второй раз: файлы не добавлялись, а console сообщила too much recursion. Позже это случилось снова: при добавлении файлов в WBPP программа зависла, и в итоге ни один файл не добавился. Я закрыл WBPP и посмотрел Console — там была красная строка InternalError: too much recursion. После повторного открытия WBPP оказалось, что часть файлов уже загрузилась, а часть нет; проверив те, что не загрузились, я снова обнаружил аномалию FITS Header — на этот раз DEC показывал -46 01 60, где секунды «60» должны были перенестись в -46 02 00. Стоит WBPP прочитать подобное аномальное значение, как программа зависает, а заодно тянет за собой все последующие изображения, из-за чего они тоже не могут загрузиться. Я снова открыл FITS Header, вручную перенёс секунды, и после исправления просто заново добавил файлы — этого хватило. Когда все файлы успешно загружаются, WBPP автоматически выводит диагностическое сообщение, например «60 of 60 light frames were added».
Общий вывод: эта проблема автоматического непереноса координат, по моим наблюдениям на сегодняшний день, почти всегда возникает в ситуациях, когда программой съёмки выступал MDL (удалённое управление), но нельзя исключить, что тот же дефект встречается и в другом программном обеспечении для съёмки. Поэтому всякий раз, когда WBPP зависает и файлы не добавляются, сначала проверьте Process Console, чтобы определить тип ошибки, а затем проверьте Header RA/DEC на наличие бага «60 секунд без переноса» — после ручного исправления проблема в большинстве случаев решается.
Производительность: почему полный пакет выполняется так долго
Напоследок поговорим о проблеме, которая формально не является «ошибкой», но выматывает — полный пакет WBPP работает попросту слишком медленно. Однажды ради пяти изображений, из которых я хотел сделать HDR, я оставил полный пакет работать целых четыре часа (тогдашняя машина была AMD R5-4650G, DDR4 3200 32 ГБ, Gen4 SSD, изображения по 24 мегапикселя — от такого ожидания и правда хочется поменять компьютер).
Особенно много времени отнимают два момента:
- Separated RGB: раздельная обработка каналов RGB цветного снимка для устранения хроматической аберрации.
- Local Normalization: выбор нескольких лучших изображений в качестве опорных и применение Local Normalization к остальным.
Если отключить эти два пункта, WBPP станет намного быстрее. Стоит ли жертвовать ими ради скорости, зависит от ваших требований к итоговому результату — что касается практических замеров того, «какие шаги отключить, сколько времени это сэкономит и сколько качества будет потеряно», в статье «Полное руководство по WBPP» у меня есть набор данных, показывающий ускорение в 7–8 раз, на который можно ориентироваться.
Подведём итог принципам этого справочника по устранению неполадок: если что-то пошло не так, сначала смотрите Process Console; если калибровка завершилась failed — закройте PI и откройте заново; если флэты постоянно выдают ошибку калибровки — вернитесь к ручной пошаговой обработке; File I/O Error чаще всего означает слишком длинный путь или папку, недоступную для записи; а если что-то не загружается, зависает или сообщает о recursion — проверьте, не остались ли в RA/DEC в FITS Header секунды со значением 60 без переноса в старший разряд. Освойте эти несколько приёмов, и вы справитесь с большинством капризов WBPP.