WBPP-hibaelhárítás: gyakori hibák és ismert bugok
Ez a cikk a 2022–2025 közötti jegyzeteimből áll össze; néhány eszköz vagy munkafolyamat azóta frissült, ezt olvasás közben tartsuk szem előtt. A szövegben szereplő hibaüzenetek és verziófüggő viselkedések mind úgy vannak rögzítve, ahogy annak idején tapasztaltam. A WBPP felületéről, a master kalibrációs képekről és a szokásos futtatási folyamatról bővebben a testvércikkben, a „The Complete Guide to WBPP” című írásban olvashatunk.
Kétségtelenül jó érzés, ha a WBPP egyetlen kattintással végigfut az egészen, de a gyakorlatban használva mindig akad olyan helyzet, amikor elakad, hibát dob, vagy az eredmény egyszerűen nem stimmel. Ebben a cikkben azokat a WBPP-vel kapcsolatos problémákat gyűjtöttem össze egy hibaelhárítási kézikönyvbe, amelyekkel az elmúlt években a leggyakrabban találkoztam, és amelyekről a legtöbbet kérdeznek tőlem – a diagnosztikai gondolkodásmódtól kezdve néhány konkrét, ismert bugig.
A hibaelhárítás első lépése: nézzük meg a Process Console panelt
Ha a PixInsight feldolgozás közben elromlik valami, az első dolog, amire mindig gondolnunk kell, hogy nézzük meg a Process Console panelt. Ez megmutatja, hol történt a hiba és milyen típusú, és minden diagnózis innen indul.
A WBPP azonban egy szkript, és amíg a szkript nem fut, a panel összecsukott állapotban van, és a tartalmát sem lehet kijelölni. Ha tehát meg szeretnénk nézni a panelt, gyakran előbb be kell zárnunk a WBPP-t. Ez körülményesnek hangzik, mégis sok probléma esetében ez az egyetlen nyom forrása – az alább következő néhány bug megfejtése is mind a panel egyetlen piros sorával kezdődött.
Hibák és bugok a kalibrációs szakaszban
A kalibráció sikertelen (failed) – először zárjuk be a PI-t, majd nyissuk meg újra. Ha a WBPP futtatásakor már a kezdeti kalibráció (a master kalibrációs képek használatával) is elhasal, és a status piros „failed” státuszt mutat, szüneteltethetjük az egész folyamatot: zárjuk be a PI-t, nyissuk meg újra a WBPP-t, és futtassuk le még egyszer, ez a kalibrációs hiba ilyenkor általában eltűnik. Amikor OSC-képeket dolgoztam fel, ezzel a buggal legalább négyszer találkoztam, és mindig ezzel a trükkel oldottam meg.
A flatek folyamatosan hibásan kalibrálódnak – térjünk vissza a manuális, lépésenkénti feldolgozáshoz. A WBPP egyes verzióiban van egy bug, amely miatt a flatek kalibrációja folyamatosan hibára fut. Ilyenkor fontos, hogy tudjuk saját magunk, lépésről lépésre, kézzel is elvégezni a feldolgozást. Egyúttal idézzük fel a Pre-Process lépéseit is:
- Calibration:
light − dark / ((flat − flat dark) * med(flat)) - Cosmetic Correction
- Debayer: interpoláció a Bayer-mátrixon
- Star Alignment
- NSG
- Integration
Amikor nem lehet megbízni az automatizálásban, a folyamat szétszedése és kézi futtatása éppen hogy megkönnyíti annak behatárolását, melyik lépésben van a probléma.
Útvonalproblémák: a File I/O Error két lehetséges oka
Ha Windows alatt a WBPP-t használva a kalibrációs szakaszban (calibration) felugrik egy File I/O Error, az többnyire a következő két ok egyike miatt van:
- A fájl elérési útja a fájlnévvel együtt túl hosszú, meghaladja a rendszer korlátját, ezért rövidíteni kell.
- A célmappába nem lehet írni, például ha a kimenetet egy rendszermappába állítjuk be.
Az első a leggyakoribb. Ha véglegesen meg akarjuk oldani, hogy „az útvonal túl hosszú”, a Windowsban bekapcsolhatjuk a hosszú útvonalak támogatását (a regedit programban állítsuk a LongPathsEnabled értékét 1-re); emellett érdemes elkerülni az ASCII-n kívüli karaktereket (például kínai) tartalmazó útvonalakat is. Ennek a két környezeti előkészítésnek a részletes lépéseit a „The Complete Guide to WBPP” Windows környezetbeállítási részében írtam le, itt nem ismétlem meg.
Az RA/DEC-koordináta „60 másodperc nem lett átvíve” bugja
Ez a legkényesebb, és egyben a leginkább megéri külön foglalkozni vele, mert a tünetei rendkívül változatosak, a kiváltó ok viszont mindig ugyanaz: a FITS-fejlécben a rektaszcenzió/deklináció koordináták másodpercértéke „60”, ám ez nem lett átvíve a következő egységre.
Ennek két különböző megjelenési formájával találkoztam.
Először: a WBPP nem tudta betölteni a fájlt. Bezártam a WBPP-t, hogy megnézzem a Process Console panelt, és azt találtam, hogy egy js szkript egyik sora „érvénytelen koordinátákat” jelzett. Akkoriban azt hittem, ez a WBPP bugja, ezért rákerestem az interneten a hibaüzenetre, és csak ekkor találtam néhány ugyanilyen hibabejelentést a PixInsight Forumon – kiderült, hogy valójában a koordinátaprobléma akadályozta meg, hogy a kép betöltődjön a WBPP-be. Volt már merre indulnom, mégis egy órámba telt, mire több száz light kép közül megtaláltam a hibás felvételt: az OBJCTDEC mező koordinátaértéke volt rossz. Megnyitottam a FITSHeader folyamatot a PI-ben, legörgettem az OBJCTDEC mezőig, és kijavítottam az értéket, amelynek „át kellett volna vinnie, de nem vitte át” – a példában a -69 26 60 értéket -69 27 0 értékre változtattam –, ekkor ez a felvétel gond nélkül betöltődött, és a rákövetkező fájlokat sem akasztotta meg többé.
Másodszor: nem sikerült hozzáadni a fájlokat, a panel too much recursion hibát jelzett. Később megint találkoztam ezzel: amikor fájlokat próbáltam hozzáadni a WBPP-hez, a program lefagyott, végül egyetlen fájl sem került be. Bezártam a WBPP-t, megnéztem a panelt, és ott volt a piros InternalError: too much recursion. A WBPP újranyitása után kiderült, hogy néhány fájl betöltődött, néhány pedig nem; a be nem töltődötteket megvizsgálva megint csak FITS-fejléc-rendellenességet találtam – ezúttal a DEC mező -46 01 60 értéket mutatott, ahol a „60” másodpercet át kellett volna vinni -46 02 00-ra. Amint a WBPP ilyen rendellenes értéket olvas be, lefagy, és emellett a rákövetkező felvételek betöltését is megakadályozza. Ugyanúgy megnyitottam a FITS-fejlécet, kézzel átvittem a másodperceket, és a javítás után újra hozzáadtam a fájlokat, ez már működött. Amikor minden fájl sikeresen betöltődik, a WBPP automatikusan felugrik egy diagnosztikai üzenettel, például: „60 of 60 light frames were added”.
Közös következtetés: ezt a problémát, hogy a koordináták nem íródnak át automatikusan, eddig szinte mindig olyan helyzetekben láttam, amikor az MDL (távvezérlés) volt a felvételkészítő szoftver, de nem zárható ki, hogy más felvételkészítő szoftvereknél is felléphet ugyanez a hiba. Szóval, ha a WBPP elakad és a fájlokat nem lehet hozzáadni, először nézzük meg a Process Console panelt, hogy megállapítsuk a hiba típusát, majd ellenőrizzük, hogy az RA/DEC fejlécében nincs-e „60 másodperc nem lett átvíve” bug, ezt kézi javítással a legtöbbször meg lehet oldani.
Teljesítmény: miért tart ilyen sokáig a teljes csomag
Végül beszéljünk egy szigorúan véve nem „hibának” számító, mégis igen fárasztó problémáról – a WBPP teljes csomagja egyszerűen túl lassú. Volt, hogy öt, HDR-ré alakítandó képhez teljes négy órán át futtattam a teljes csomagot (a gép akkoriban egy AMD R5-4650G volt, DDR4 3200 32GB, Gen4 SSD, a képek 24 megapixelesek voltak – egy ilyen várakozástól tényleg kedve támad az embernek gépet cserélni).
Ebből különösen két rész eszik meg sok időt:
- Separated RGB: a színes fotó RGB-csatornáinak külön feldolgozása a kromatikus aberráció megszüntetésére.
- Local Normalization: a képek közül a legjobbak kiválasztása referenciának, majd Local Normalization végrehajtása a többi képen.
Ha ezt a két lépést kikapcsoljuk, a WBPP jóval gyorsabb lesz. Hogy megéri-e feláldozni ezt a kettőt a sebességért, az attól függ, milyen elvárásaink vannak a végeredménnyel szemben – arról, hogy „mely lépéseket kapcsoljuk ki, mennyi időt takarítunk meg vele, és mennyi minőséget veszítünk”, a „The Complete Guide to WBPP” című cikkemben van egy 7–8-szoros gyorsulást bemutató adatsor, amit érdemes megnézni.
Foglaljuk össze ennek a hibaelhárítási kézikönyvnek a lényegét: ha valami történik, először nézzük meg a Process Console panelt; ha a kalibráció failed, zárjuk be a PI-t és nyissuk meg újra; ha a flatek folyton hibásan kalibrálódnak, térjünk vissza a manuális, lépésenkénti feldolgozáshoz; a File I/O Error többnyire azt jelenti, hogy az útvonal túl hosszú, vagy a mappa nem írható; ha valami nem tölt be, elakad, vagy recursiont jelez, nézzük meg, nincs-e a FITS-fejléc RA/DEC-jében 60 másodperc, ami nem lett átvíve. Ha ezt a néhány trükköt jól bevéssük, a WBPP legtöbb szeszélyével elboldogulunk.