Risoluzione dei problemi di WBPP: errori frequenti e bug noti
Questo articolo è tratto da appunti presi tra il 2022 e il 2025; alcuni strumenti o flussi di lavoro sono nel frattempo stati aggiornati, quindi La invito a tenerlo presente durante la lettura; i messaggi di errore e i comportamenti legati alla versione riportati nel testo sono tutti annotati così com’erano allora. Per l’interfaccia di WBPP, i master di calibrazione e il normale flusso di esecuzione, La rimando all’altro articolo «Guida completa all’uso di WBPP».
Far girare WBPP dall’inizio alla fine con un solo clic è senz’altro una soddisfazione, ma quando lo si usa davvero ci si imbatte sempre in situazioni in cui si blocca, restituisce errori o produce risultati che non tornano. Questo articolo raccoglie le categorie di problemi di WBPP in cui mi sono imbattuto in questi anni — quelle su cui più spesso mi viene chiesto — in un manuale per la risoluzione dei problemi, dalla mentalità diagnostica fino ad alcuni bug noti concreti.
Primo passo della risoluzione: guardare prima la Process Console
Quando l’elaborazione in PixInsight va storta, la prima cosa a cui pensare è sempre consultare la Process Console. Le dice dove si è verificato l’errore e di che tipo di errore si tratta; è il punto di partenza di ogni diagnosi.
WBPP è però uno script e, finché lo script non è in esecuzione, la console viene richiusa e non è selezionabile. Perciò, per vedere la console, spesso occorre chiudere prima WBPP. Sembra una scocciatura, ma per molti problemi è l’unica fonte di indizi: la soluzione di parecchi dei bug che seguono è iniziata tutta da quella riga di testo rosso nella console.
Fallimenti e bug nella fase di calibrazione
Calibrazione fallita (failed): chiudere prima PI e riaprirlo. Se, eseguendo WBPP, la calibrazione iniziale (che usa i master di calibrazione) fallisce subito e lo status mostra un «failed» rosso, può mettere in pausa l’intero flusso, chiudere PI, riaprire WBPP ed eseguirlo di nuovo; questo errore di calibrazione fallita di solito a quel punto scompare. Elaborando immagini OSC mi sono imbattuto in questo bug almeno quattro volte, e ogni volta l’ho risolto con questo trucco.
I flat falliscono continuamente la calibrazione: tornare all’elaborazione manuale, passo per passo. Alcune versioni di WBPP hanno un bug che fa fallire di continuo la calibrazione dei flat. In casi come questi diventa importante saper elaborare da sé, un passo alla volta. Cogliamo l’occasione per ripassare i passaggi del Pre-Process:
- Calibration:
light − dark / ((flat − flat dark) * med(flat)) - Cosmetic Correction
- Debayer: interpolare sulla matrice di Bayer
- Star Alignment
- NSG
- Integration
Quando non ci si può fidare dell’automazione, scomporre il flusso ed eseguirlo a mano rende anzi più facile individuare in quale passaggio si trovi il problema.
Problemi di percorso: due possibili cause di un File I/O Error
Usando WBPP su Windows, se la fase di calibrazione (calibration) genera un File I/O Error, di solito è dovuto a una di queste due cause:
- Il percorso del file più il nome del file è troppo lungo e supera il limite di sistema, quindi va accorciato.
- Non è possibile scrivere nella cartella di destinazione, per esempio se si imposta l’output in una cartella di sistema.
La prima è la più comune. Per curare alla radice il «percorso troppo lungo», si può abilitare in Windows il supporto ai percorsi lunghi (impostando LongPathsEnabled a 1 nell’Editor del Registro di sistema, regedit); inoltre è consigliabile evitare i percorsi con caratteri non ASCII (ad esempio cinesi). I passaggi dettagliati per questi due prerequisiti dell’ambiente li ho descritti nella sezione sulla configurazione dell’ambiente Windows di «Guida completa all’uso di WBPP», quindi non li ripeto qui.
Il bug delle coordinate RA/DEC «60 secondi non riportati»
Questo è il problema più insidioso e insieme quello che più merita di essere trattato a parte, perché i suoi sintomi sono quanto mai vari, ma la causa di fondo è sempre la stessa: nel FITS Header, le coordinate di ascensione retta / declinazione hanno un valore dei secondi di «60» che non è mai stato riportato alla posizione successiva.
Mi ci sono imbattuto due volte, ogni volta con una manifestazione diversa.
La prima volta: WBPP non riusciva a caricare il file. Ho chiuso WBPP e sono andato a guardare la Process Console, scoprendo che una certa riga di uno script js segnalava «invalid coordinates». Sul momento ho pensato fosse un bug di WBPP; ho preso il messaggio di errore e l’ho cercato in rete, e solo allora ho trovato sul PixInsight Forum diverse segnalazioni di errore identiche: si scopriva che il problema delle coordinate impediva all’immagine di caricarsi in WBPP. Pur avendo una direzione da seguire, ho comunque impiegato un’ora a frugare tra diverse centinaia di light per stanare l’immagine problematica: la sua coordinata OBJCTDEC era sbagliata. Ho aperto in PI il processo FITSHeader, sono sceso fino a OBJCTDEC e ho modificato il valore che «avrebbe dovuto essere riportato ma non lo era» — in questo esempio ho cambiato -69 26 60 in -69 27 0 — e questo frame si è poi caricato senza problemi, e i file successivi non sono più rimasti bloccati per colpa sua.
La seconda volta: i file non si aggiungevano e la console segnalava too much recursion. Più tardi mi è ricapitato: aggiungendo file a WBPP il software si è bloccato e, alla fine, non è stato aggiunto alcun file. Ho chiuso WBPP e, guardando la Console, c’era un InternalError: too much recursion rosso. Dopo aver riaperto WBPP ho visto che una parte dei file era già caricata e una parte no; controllando quelli non caricati, era di nuovo, come da copione, un’anomalia del FITS Header: stavolta DEC mostrava -46 01 60, dove i secondi «60» avrebbero dovuto essere riportati a -46 02 00. Non appena WBPP legge un valore anomalo del genere si blocca, e per giunta si trascina dietro tutte le immagini successive, impedendo anche a esse di caricarsi. Allo stesso modo, ho aperto il FITS Header e ho riportato i secondi a mano; dopo averlo corretto ho aggiunto di nuovo i file e ha funzionato. Quando tutti i file si caricano correttamente, WBPP fa comparire automaticamente un messaggio diagnostico, per esempio «60 of 60 light frames were added».
Una conclusione comune: questo problema del mancato riporto automatico delle coordinate, per quanto ho visto finora, si è quasi sempre verificato quando il software di acquisizione era MDL (controllo remoto), anche se non posso escludere che altri software di acquisizione presentino lo stesso difetto. Perciò, ogni volta che WBPP si blocca e i file non si aggiungono, consulti prima la Process Console per confermare il tipo di errore e controlli poi se l’Header di RA/DEC presenta il bug dei «60 secondi non riportati»; dopo una correzione manuale, nella maggior parte dei casi si risolve.
Prestazioni: perché il pacchetto completo impiega così tanto
Infine, parliamo di un problema che, a rigore, non è un «errore» ma è comunque un tormento: il pacchetto completo di WBPP è semplicemente troppo lento. Una volta ho lasciato girare il pacchetto completo per ben quattro ore per cinque immagini con cui volevo realizzare un HDR (la macchina di allora era un AMD R5-4650G, DDR4 3200 32GB, SSD Gen4, con immagini da 24 megapixel; un’attesa del genere fa venire davvero voglia di cambiare computer).
Due punti in particolare divorano tempo:
- Separated RGB: elaborare separatamente i canali RGB di una foto a colori per eliminare l’aberrazione cromatica.
- Local Normalization: scegliere le migliori immagini (poche) come riferimento e applicare la Local Normalization alle altre.
Se si disattivano questi due, WBPP diventa molto più veloce. Se valga la pena sacrificarli per la velocità dipende dalle Sue esigenze sul risultato finale: riguardo alle misurazioni concrete su «quali passaggi disattivare, quanto tempo si risparmia e quanta qualità si perde», in «Guida completa all’uso di WBPP» ho una serie di dati che mostra un’accelerazione di 7-8 volte a cui può fare riferimento.
Riassumiamo la mentalità di questo manuale per la risoluzione dei problemi: quando qualcosa va storto, guardi prima la Process Console; se la calibrazione dà failed, chiuda PI e lo riapra; se i flat falliscono di continuo la calibrazione, torni all’elaborazione manuale passo per passo; un File I/O Error è per lo più un percorso troppo lungo o una cartella in cui non si può scrivere; e se le cose non si caricano, si bloccano o segnalano recursion, vada a controllare se RA/DEC nel FITS Header ha un valore dei secondi di 60 non riportato. Se impara bene questi pochi trucchi, saprà tenere testa alla maggior parte dei capricci di WBPP.