Rozwiązywanie problemów z WBPP: częste błędy i znane bugi
Ten artykuł powstał z notatek z lat 2022–2025; część narzędzi i procedur zdążyła się już zmienić, więc miej to na uwadze podczas lektury. Komunikaty o błędach i zachowania poszczególnych wersji opisane w tekście zapisałem w takiej postaci, w jakiej występowały wtedy. Interfejs WBPP, master klatki kalibracyjne i normalny przepływ pracy opisuję w siostrzanym artykule „The Complete Guide to WBPP” — tam odsyłam po szczegóły.
Przejechanie całego procesu w WBPP jednym kliknięciem jest oczywiście przyjemne, ale kiedy naprawdę zaczniesz z niego korzystać, zawsze trafisz na sytuacje, w których skrypt się zacina, zgłasza błąd albo daje wynik, z którym coś jest nie tak. W tym artykule zebrałem kilka kategorii problemów z WBPP, na jakie natknąłem się przez ostatnie lata i o jakie najczęściej mnie pytają, w jeden podręcznik szukania usterek — od sposobu myślenia przy diagnozie aż po kilka konkretnych, znanych bugów.
Pierwszy krok w szukaniu usterki: najpierw zajrzyj do Process Console
Kiedy w obróbce w programie PixInsight coś pójdzie nie tak, pierwszą rzeczą, o jakiej zawsze warto pomyśleć, jest zajrzenie do Process Console. Powie ci, gdzie wystąpił błąd i jakiego jest rodzaju — to punkt wyjścia każdej diagnozy.
WBPP jest jednak skryptem, a dopóki skrypt nie działa, okno console zostaje zwinięte i nie da się go zaznaczyć. Żeby więc zobaczyć console, zwykle trzeba najpierw zamknąć WBPP. Brzmi to uciążliwie, ale przy wielu problemach jest to jedyne źródło wskazówek — rozwiązanie kilku opisanych dalej bugów zaczęło się właśnie od tej jednej czerwonej linijki w oknie console.
Niepowodzenia i bugi na etapie kalibracji
Kalibracja nie powiodła się (failed) — najpierw zamknij PI i otwórz go ponownie. Jeśli podczas uruchamiania WBPP już pierwsza kalibracja (ta z użyciem master klatek kalibracyjnych) kończy się niepowodzeniem, a status pokazuje czerwone failed, możesz wstrzymać cały proces, zamknąć program PI, otworzyć WBPP na nowo i uruchomić go jeszcze raz — ten błąd kalibracji zwykle wtedy znika. Przy obróbce zdjęć z kamery kolorowej (OSC) trafiłem na tego buga co najmniej cztery razy i za każdym razem rozwiązałem go tą sztuczką.
Klatki flat wciąż zwracają błąd kalibracji — wróć do ręcznej obróbki krok po kroku. Niektóre wersje WBPP mają buga, przez którego kalibracja klatek flat wciąż kończy się błędem. W takich chwilach ważna okazuje się umiejętność samodzielnego przejścia całej ścieżki krok po kroku. Przy okazji przypomnijmy sobie etapy Pre-Process:
- Calibration:
light − dark / ((flat − flat dark) * med(flat)) - Cosmetic Correction
- Debayer: interpolacja na matrycy Bayera
- Star Alignment
- NSG
- Integration
Kiedy nie można polegać na automatyce, rozłożenie procesu na części i ręczne przejście przez niego wręcz ułatwia ustalenie, na którym kroku tkwi problem.
Problemy ze ścieżką: dwie możliwe przyczyny błędu File I/O Error
Jeśli podczas pracy z WBPP w systemie Windows na etapie kalibracji (calibration) wyskakuje File I/O Error, przyczyna jest zwykle jedną z dwóch:
- Ścieżka pliku razem z nazwą pliku jest zbyt długa — przekracza limit systemu i trzeba ją skrócić.
- Do folderu docelowego nie da się zapisywać, na przykład gdy ustawisz wyjście w folderze systemowym.
Pierwsza przyczyna jest najczęstsza. Żeby wyleczyć „zbyt długą ścieżkę” u źródła, możesz włączyć w systemie Windows obsługę długich ścieżek (w regedit ustaw LongPathsEnabled na 1); poza tym radzę unikać ścieżek ze znakami spoza ASCII (na przykład chińskimi). Szczegółowy opis tych dwóch przygotowań środowiska umieściłem w rozdziale o konfiguracji środowiska Windows w artykule „The Complete Guide to WBPP”, więc tutaj go nie powtarzam.
Bug współrzędnych RA/DEC: „60 sekund bez przeniesienia”
To najbardziej podchwytliwy problem i zarazem ten, który najbardziej zasługuje na osobne omówienie, bo jego objawy bywają przeróżne, a przyczyna źródłowa jest zawsze ta sama: we współrzędnych rektascensji / deklinacji w FITS Header wartość sekund wyniosła „60”, ale nie została przeniesiona na wyższą pozycję.
Trafiłem na to dwa razy, za każdym razem w innej postaci.
Za pierwszym razem: WBPP nie mógł wczytać pliku. Zamknąłem WBPP, zajrzałem do Process Console i zobaczyłem, że jakaś linijka pewnego skryptu js zgłasza „nieprawidłowe współrzędne”. Wtedy wziąłem to za buga WBPP, wpisałem komunikat błędu w wyszukiwarkę i dopiero wówczas znalazłem na PixInsight Forum kilka takich samych zgłoszeń — okazało się, że to problem ze współrzędnymi uniemożliwiał wczytanie zdjęcia do WBPP. Choć miałem już kierunek, i tak zajęło mi godzinę przekopanie się przez kilkaset klatek light, zanim wytropiłem felerne zdjęcie: miało błędną współrzędną OBJCTDEC. W programie PI otworzyłem proces FITSHeader, przewinąłem do OBJCTDEC i poprawiłem wartość, która „powinna była zostać przeniesiona, a nie została” — w tym przykładzie zmieniłem -69 26 60 na -69 27 0 — i ta klatka wczytała się bez problemu, a kolejne pliki przestały się na niej zacinać.
Za drugim razem: pliki nie chciały się dodać, a okno console zgłaszało too much recursion. Później trafiłem na to jeszcze raz: przy dodawaniu plików do WBPP program się zawiesił i ostatecznie nie został dodany ani jeden plik. Zamknąłem WBPP, zajrzałem do okna console, a tam czerwone InternalError: too much recursion. Po ponownym otwarciu WBPP okazało się, że część plików została wczytana, a część nie; gdy sprawdziłem te niewczytane, znowu wyszła anomalia w FITS Header — tym razem DEC pokazywało -46 01 60, a sekundy „60” powinny zostać przeniesione do postaci -46 02 00. Wystarczy, że WBPP odczyta taką nieprawidłową wartość, a od razu się zacina, przy okazji sprawiając, że kolejne zdjęcia też nie dają się wczytać. Tak samo otwórz FITS Header, przenieś sekundy ręcznie, a po poprawce dodaj pliki od nowa — i tyle. Kiedy wszystkie pliki wczytają się poprawnie, WBPP sam wyświetli komunikat diagnostyczny, na przykład „60 of 60 light frames were added”.
Wspólny wniosek: ten problem z brakiem automatycznego przeniesienia współrzędnych, z tego, co dotąd widziałem, występował niemal zawsze wtedy, gdy oprogramowaniem do akwizycji był MDL (zdalne sterowanie), choć nie mogę wykluczyć, że inne programy do akwizycji miewają tę samą przypadłość. Dlatego zawsze, gdy WBPP się zatnie i nie da się dodać plików, najpierw zajrzyj do Process Console i ustal rodzaj błędu, a potem sprawdź, czy w nagłówku RA/DEC nie ma buga „60 sekund bez przeniesienia” — po ręcznej poprawce zwykle da się to rozwiązać.
Wydajność: dlaczego pełny pakiet działa tak długo
Na koniec o problemie, który ściśle rzecz biorąc nie jest „błędem”, ale potrafi solidnie umęczyć — pełny pakiet WBPP jest po prostu za wolny. Kiedyś dla pięciu zdjęć, z których chciałem zrobić HDR, puściłem pełny pakiet na całe cztery godziny (ówczesna maszyna to AMD R5-4650G, DDR4 3200 32 GB, dysk SSD Gen4, a zdjęcia miały 24 megapiksele; przy takim czekaniu naprawdę zaczyna się myśleć o wymianie komputera).
Szczególnie czasochłonne są dwa miejsca:
- Separated RGB: rozdzielne przetwarzanie kanałów RGB kolorowego zdjęcia w celu usunięcia aberracji chromatycznej.
- Local Normalization: wybranie kilku najlepszych zdjęć jako referencji i zastosowanie Local Normalization do pozostałych.
Jeśli wyłączysz te dwie rzeczy, WBPP przyspieszy bardzo mocno. To, czy warto poświęcić je dla szybkości, zależy od twoich wymagań wobec gotowej pracy — pomiary tego, „które kroki wyłączyć, ile czasu można zaoszczędzić i ile jakości się traci”, zebrałem w artykule „The Complete Guide to WBPP”, gdzie znajdziesz komplet danych pokazujących 7–8-krotne przyspieszenie.
Podsumujmy zasady tego podręcznika szukania usterek: gdy coś się dzieje, najpierw zajrzyj do Process Console; kalibracja pokazuje failed — zamknij PI i otwórz go ponownie; klatki flat wciąż zwracają błąd kalibracji — wróć do ręcznej obróbki krok po kroku; File I/O Error to zwykle zbyt długa ścieżka albo folder, do którego nie da się zapisywać; a gdy pliki się nie wczytują, program się zacina albo zgłasza recursion — sprawdź, czy w RA/DEC w FITS Header nie ma sekund równych 60 bez przeniesienia. Zapamiętaj dobrze te kilka sztuczek, a poradzisz sobie z większością humorów WBPP.