Depanare WBPP: erori frecvente și bug-uri cunoscute
Acest articol este alcătuit din notițe luate în perioada 2022-2025; unele instrumente sau fluxuri de lucru au fost actualizate între timp, așa că țineți cont de acest lucru la lectură; mesajele de eroare și comportamentele specifice versiunilor menționate în text sunt înregistrate așa cum erau la momentul respectiv. Pentru interfața WBPP, cadrele master de calibrare și fluxul normal de execuție, consultați celălalt articol „The Complete Guide to WBPP”.
Rularea WBPP dintr-un singur clic, de la un capăt la altul, este într-adevăr plăcută, însă în utilizarea reală apar mereu situații în care procesul se blochează, generează erori sau produce rezultate care pur și simplu nu sunt corecte. Acest articol adună, într-un manual de depanare, categoriile de probleme legate de WBPP cu care m-am confruntat în ultimii ani și despre care sunt întrebat cel mai des, de la mentalitatea de diagnosticare până la câteva buguri cunoscute concrete.
Primul pas al depanării: verificați mai întâi Process Console
Atunci când apare o problemă la prelucrarea din PixInsight, primul lucru la care trebuie să vă gândiți întotdeauna este verificarea Process Console. Aceasta indică unde a apărut eroarea și ce tip de eroare este; este punctul de plecare pentru orice diagnostic.
Totuși, WBPP este un script, iar atât timp cât scriptul nu rulează, Process Console rămâne restrâns și nu poate fi selectat. Așadar, pentru a vedea Process Console, de multe ori trebuie să închideți mai întâi WBPP. Sună incomod, dar pentru multe probleme este singura sursă de indicii – rezolvarea a câteva dintre bugurile de mai jos a pornit mereu de la acel rând roșu din Process Console.
Eșecuri și buguri în etapa de calibrare
Calibrare eșuată (failed) – închideți mai întâi PI, apoi redeschideți-l. Dacă, la rularea WBPP, calibrarea inițială (care folosește cadrele master de calibrare) eșuează chiar de la început, iar starea afișează un „failed” roșu, puteți întrerupe întregul flux, închideți PI, redeschideți WBPP și rulați-l din nou. De obicei, această eroare de calibrare eșuată dispare atunci. La prelucrarea imaginilor OSC am întâlnit acest bug de cel puțin patru ori, iar de fiecare dată l-am rezolvat cu acest truc.
Cadrele flat eșuează mereu la calibrare – reveniți la prelucrarea manuală, pas cu pas. Unele versiuni de WBPP au un bug care face ca eroarea de calibrare a cadrelor flat să apară mereu. În astfel de situații, devine important să știți să prelucrați singuri, pas cu pas, manual. Cu această ocazie, să trecem în revistă pașii Pre-Process:
- Calibration:
light − dark / ((flat − flat dark) * med(flat)) - Cosmetic Correction
- Debayer: interpolare pe matricea Bayer
- Star Alignment
- NSG
- Integration
Atunci când automatizarea nu poate fi de încredere, descompunerea fluxului de lucru și rularea lui manuală permit, de fapt, identificarea mai ușoară a pasului în care se află problema.
Probleme de cale: două cauze posibile ale unui File I/O Error
Atunci când WBPP este folosit pe Windows, dacă etapa de calibrare (calibration) generează un File I/O Error, cauza este de obicei una dintre următoarele două:
- Calea fișierului plus numele fișierului este prea lungă și depășește limita sistemului, deci trebuie scurtată.
- Nu se poate scrie în folderul de destinație, de exemplu dacă ieșirea este setată într-un folder de sistem.
Prima este cea mai frecventă. Pentru a rezolva definitiv problema „calea este prea lungă”, se poate activa în Windows suportul pentru căi lungi (setați LongPathsEnabled la 1 în regedit); se recomandă, de asemenea, evitarea căilor care conțin caractere din afara setului ASCII (de exemplu chinezești). Pașii detaliați pentru aceste două configurări prealabile ale mediului i-am descris în secțiunea despre configurarea mediului Windows din „The Complete Guide to WBPP”, așa că nu îi repet aici.
Bugul coordonatelor RA/DEC „60 de secunde nereportate”
Aceasta este cea mai complicată problemă și, totodată, cea mai potrivită pentru a fi tratată separat, pentru că simptomele ei sunt extrem de variate, dar cauza de bază este aceeași: în FITS Header, coordonatele de ascensie dreaptă/declinație au o valoare a secundelor de „60” care nu a fost niciodată reportată.
Am întâlnit acest bug de două ori, de fiecare dată cu o manifestare diferită.
Prima dată: WBPP nu putea încărca fișierul. Am închis WBPP și m-am uitat în Process Console, unde am găsit un rând dintr-un script js care raporta „invalid coordinates”. La momentul respectiv am crezut că este un bug al WBPP; am căutat mesajul de eroare pe internet și abia atunci am găsit pe PixInsight Forum câteva rapoarte de eroare identice – se dovedea că problema de coordonate împiedica încărcarea imaginii în WBPP. Cu o direcție de urmat, mi-a luat totuși o oră să scotocesc prin câteva sute de cadre light până am găsit imaginea problematică: coordonata ei OBJCTDEC era greșită. Am deschis în PI procesul FITSHeader, am derulat până la OBJCTDEC și am modificat valoarea care „ar fi trebuit reportată, dar nu a fost” – în acest exemplu, am schimbat -69 26 60 în -69 27 0 – iar acest cadru s-a încărcat apoi fără probleme, iar fișierele următoare nu au mai fost blocate din cauza lui.
A doua oară: fișierele nu se puteau adăuga, iar Console raporta too much recursion. Mai târziu am întâlnit din nou situația: la adăugarea fișierelor în WBPP, programul s-a blocat, iar în final nu a fost adăugat niciun fișier. Am închis WBPP și, uitându-mă în Console, era un InternalError: too much recursion roșu. După redeschiderea WBPP am observat că o parte dintre fișiere erau deja încărcate, iar altele nu; verificând fișierele neîncărcate, era, într-adevăr, tot o anomalie de FITS Header – de data aceasta DEC afișa -46 01 60, unde secundele „60” ar fi trebuit reportate la -46 02 00. De îndată ce WBPP citește o astfel de valoare anormală, se blochează și, în plus, blochează și încărcarea tuturor imaginilor ulterioare. La fel ca înainte, am deschis FITS Header, am reportat manual secundele, iar după corectare am readăugat fișierele și a funcționat. Când toate fișierele se încarcă cu succes, WBPP afișează automat un mesaj de diagnosticare, de exemplu „60 of 60 light frames were added”.
Concluzie comună: această problemă a coordonatelor care nu se reportează automat a apărut, din câte am văzut până acum, aproape întotdeauna în situațiile în care software-ul de captură era MDL (control la distanță), deși nu se poate exclude ca și alte programe de captură să aibă același defect. Așadar, ori de câte ori WBPP se blochează și fișierele nu se pot adăuga, verificați mai întâi Process Console pentru a confirma tipul erorii, apoi verificați dacă RA/DEC din FITS Header prezintă bugul „60 de secunde nereportate”; de obicei, o corectare manuală rezolvă problema.
Performanță: de ce durează atât de mult pachetul complet
În final, să vorbim despre o problemă care, strict vorbind, nu este o „eroare”, dar este oricum chinuitoare – pachetul complet al WBPP este pur și simplu prea lent. Am lăsat odată pachetul complet să ruleze timp de patru ore întregi pentru cinci imagini din care voiam să fac un HDR (mașina de atunci era un AMD R5-4650G, DDR4 3200 32GB, Gen4 SSD, cu imagini de 24 de megapixeli; o astfel de așteptare provoacă, într-adevăr, dorința de a schimba calculatorul).
Există două puncte care consumă în special mult timp:
- Separated RGB: prelucrarea separată a canalelor RGB ale unei fotografii color, pentru a elimina aberația cromatică.
- Local Normalization: selectarea a câteva dintre cele mai bune imagini ca referință și aplicarea Local Normalization asupra celorlalte imagini.
Dacă aceste două opțiuni sunt dezactivate, WBPP devine mult mai rapid. Dacă merită să fie sacrificate pentru viteză depinde de exigențele privind rezultatul final. În privința măsurătorilor concrete despre „ce pași se dezactivează, cât timp se economisește și cât de mult scade calitatea”, în „The Complete Guide to WBPP” există un set de date care arată o accelerare de 7-8 ori, la care se poate face referire.
Pentru a rezuma mentalitatea acestui manual de depanare: atunci când apare o problemă, verificați mai întâi Process Console; dacă o calibrare are status failed, închideți PI și redeschideți-l; dacă cadrele flat eșuează mereu la calibrare, reveniți la prelucrarea manuală, pas cu pas; o File I/O Error înseamnă de cele mai multe ori o cale prea lungă sau un folder în care nu se poate scrie; iar dacă ceva nu se încarcă, se blochează sau raportează recursion, verificați dacă RA/DEC din FITS Header are 60 de secunde nereportate. Cu aceste câteva trucuri bine învățate, majoritatea capriciilor WBPP pot fi rezolvate.