Усунення несправностей WBPP: поширені помилки та відомі баги
Ця стаття складена на основі нотаток 2022–2025 років; деякі інструменти або процеси відтоді оновилися, тож майте це на увазі під час читання. Повідомлення про помилки та поведінка, специфічна для версій, у тексті наведені так, як вони були зафіксовані на той момент. Про інтерфейс WBPP, калібрувальні майстер-кадри та звичайний робочий процес читайте в супутній статті «The Complete Guide to WBPP».
Запускати WBPP одним клацанням від початку до кінця — це, безперечно, приємно, але коли доходить до реального використання, завжди трапляються ситуації, коли він зависає, видає помилки або дає результат, який просто виглядає не так. У цій статті я зібрав категорії проблем WBPP, з якими стикався за ці кілька років — і про які мене найчастіше запитують — у практичний довідник з усунення несправностей: від логіки діагностики до кількох конкретних відомих багів.
Перший крок усунення несправностей: спершу перевірте Process Console
Коли під час обробки в PixInsight щось іде не так, перше, про що варто подумати, — це завжди перевірити Process Console. Вона показує, де сталася помилка і якого вона типу; це відправна точка будь-якої діагностики.
Але WBPP — це скрипт, і поки скрипт не виконується, console згорнута і її не можна виділити. Тому, щоб побачити console, часто доводиться спершу закрити WBPP. Це звучить незручно, але для багатьох проблем це єдине джерело підказок — розгадка кількох багів нижче щоразу починалася саме з того одного червоного рядка в console.
Збої та баги на етапі калібрування
Калібрування завершилося помилкою (failed) — спершу закрийте PI й відкрийте знову. Якщо під час виконання WBPP початкове калібрування (з використанням майстер-кадрів) одразу завершується помилкою і status показує червоне failed, можна поставити весь процес на паузу, закрити PI, знову відкрити WBPP і запустити ще раз — зазвичай ця помилка калібрування після цього зникає. Обробляючи OSC-зображення, я стикався з цим багом щонайменше чотири рази, і щоразу вирішував його саме таким чином.
Кадри flat постійно дають помилку калібрування — поверніться до ручної покрокової обробки. У деяких версіях WBPP є баг, через який калібрування кадрів flat раз у раз завершується помилкою. У такому разі важливо вміти обробляти все самостійно, крок за кроком. Заразом освіжімо в пам’яті кроки 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 статті «The Complete Guide to WBPP», тож тут повторювати не буду.
Баг координат RA/DEC: «60 секунд без перенесення»
Це найхитріша проблема і водночас та, яку найбільше варто розглянути окремо, бо її симптоми надзвичайно різноманітні, а корінна причина одна й та сама: у координатах прямого піднесення / схилення в FITS Header значення секунд дорівнює «60», але не було перенесене на наступний розряд.
Я стикався з цим двічі, і щоразу вона проявлялася по-різному.
Перший раз: WBPP не міг завантажити файл. Я закрив WBPP і подивився в Process Console, і виявив, що якийсь рядок js-скрипта повідомляв про «недійсні координати». Тоді я думав, що це баг WBPP, і, пошукавши текст помилки в інтернеті, лише тоді натрапив на PixInsight Forum на кілька таких самих повідомлень про помилку — виявилося, що саме проблема з координатами не давала зображенню завантажитися у WBPP. Маючи вже напрям пошуку, я все одно витратив годину, перебираючи кілька сотень кадрів light, поки не знайшов проблемне зображення: його координата 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 32GB, Gen4 SSD, зображення по 24 мегапікселі; таке очікування справді змушує замислитися про новий комп’ютер).
Особливо багато часу забирають два моменти:
- Separated RGB: окрема обробка каналів RGB кольорового знімка для усунення хроматичної аберації.
- Local Normalization: вибір кількох найкращих зображень як референсу та застосування Local Normalization до решти зображень.
Якщо вимкнути ці два кроки, WBPP стає набагато швидшим. Чи варто жертвувати ними заради швидкості, залежить від ваших вимог до кінцевого результату — щодо практичних вимірювань на тему «які кроки вимкнути, скільки часу заощадиться і наскільки впаде якість», у статті «The Complete Guide to WBPP» я навів набір даних, який показує прискорення у 7–8 разів, тож можете звернутися до нього.
Підсумуємо логіку цього довідника з усунення несправностей: якщо щось не так — спершу перевірте Process Console; якщо калібрування дає failed — закрийте PI й відкрийте знову; якщо кадри flat постійно дають помилку калібрування — поверніться до ручної покрокової обробки; File I/O Error здебільшого означає задовгий шлях або папку, у яку неможливо записувати; а якщо щось не завантажується, зависає або повідомляє recursion — перевірте, чи немає в RA/DEC FITS Header секунд «60» без перенесення. Опануйте ці кілька прийомів, і з більшістю примх WBPP ви впораєтеся.