本站提供正體中文版。切換到正體中文本站提供简体中文版。切换到简体中文This site is available in English.View in Englishこのサイトには日本語版があります。日本語で表示이 사이트는 한국어로도 제공됩니다.한국어로 보기Diese Website ist auch auf Deutsch verfügbar.Auf Deutsch ansehenEste sitio web también está disponible en español.Ver en españolCe site est également disponible en français.Afficher en françaisEste site também está disponível em português.Ver em portuguêsDeze website is ook beschikbaar in het Nederlands.In het Nederlands bekijkenЭтот сайт также доступен на русском языке.Смотреть на русскомयह वेबसाइट हिन्दी में भी उपलब्ध है।हिन्दी में देखेंهذا الموقع متاح أيضًا باللغة العربية.عرض بالعربيةSitus ini juga tersedia dalam bahasa Indonesia.Lihat dalam bahasa IndonesiaBu site Türkçe olarak da mevcut.Türkçe görüntüleTa strona jest dostępna także po polsku.Wyświetl po polskuTrang web này cũng có phiên bản tiếng Việt.Xem bằng tiếng Việtاین وب‌سایت به فارسی هم در دسترس است.مشاهده به فارسی

La guida completa a WBPP: interfaccia, master di calibrazione e pipeline di esecuzione

Preelaborazione e stacking2021.03Note iniziali

Questo articolo raccoglie appunti presi tra il 2021 e il 2024; alcuni strumenti o procedure sono nel frattempo stati aggiornati, quindi ne tenga conto durante la lettura. Alcune interfacce, opzioni e comportamenti legati alla versione qui citati (per esempio le versioni 2.1.2 e 2.5) rispecchiano tutti lo stato di allora. Quanto agli errori e ai bug noti che si possono incontrare durante l’esecuzione, veda l’articolo a parte «Risoluzione dei problemi di WBPP».

WBPP (WeightedBatchPreprocessing) è lo script di PixInsight che esegue in automatico, dall’inizio alla fine, «calibrazione, registrazione e integrazione»: è di una comodità sorprendente. In questi anni è stato aggiornato di frequente e a poco a poco ho scritto parecchi appunti sparsi; questo articolo li raccoglie in una spiegazione abbastanza completa, articolata su tre livelli: i concetti di fondo che cambiano poco da una versione all’altra, il flusso di esecuzione attuale e alcune modifiche importanti introdotte nelle varie versioni nel corso degli anni. Qualunque sia la versione che usa, se prima si fissano bene i concetti, per quanto cambi l’interfaccia non ci si troverà mai nel panico.

Concetto fondamentale 1: l’immagine integrata da WBPP è soltanto un’anteprima

Questo è il punto che più di ogni altro voglio affrontare per primo, ed è anche quello che la maggior parte delle persone trascura.

Ci sono cascato io stesso: una volta, dopo aver usato la Drizzle Integration, mi sono accorto che il centro delle stelle (le zone sovrasature) era diventato addirittura nero. Andando a fondo, il colpevole si è rivelato essere proprio l’aver usato WBPP per fare l’integrazione.

Comoda quanto si vuole, ma sul master light che WBPP integra in automatico la posizione ufficiale è chiarissima: è solo una comoda anteprima del «risultato ottenibile», da buttare una volta finito, e non va mai considerata un prodotto finito. Riporto qui di seguito un estratto della risposta ufficiale sul forum:

The integrated image generated by WBPP is just a convenience preview of the achievable image, but it should always be deleted/ignored, and the integration should always be done manually with the registered frames. This is the only way to obtain an optimal integrated image with full control over the normalization, pixel rejection and noise reduction tasks.

La risposta ufficiale ha persino detto, quasi per scherzo, di voler ripetere questa frase «n+1 volte, dove n tende ormai all’infinito»: il master light prodotto da WBPP non va usato per scopi seri, è soltanto un’anteprima, e il risultato migliore si ottiene solo con una Image Integration manuale che ottimizzi la pixel rejection e il rapporto segnale/rumore (S/N).

Perciò la mia abitudine è questa: con WBPP mi spingo al massimo fino al passo della «registrazione delle stelle»; la vera integrazione la riaffido a una Image Integration manuale. L’approccio corretto, suddiviso in fasi distinte — calibrazione (affidata a WBPP), allineamento (Star Alignment) e integrazione (Image Integration) — richiede sì qualche passaggio in più, ma non appena qualcosa va storto è molto più facile capire quale anello della catena si è rotto. Questa è diventata poi la mia convinzione consolidata. Anche quei due video tutorial su WBPP, molto dettagliati, realizzati agli inizi da appassionati giapponesi, li consiglio caldamente, ma anche a loro va aggiunto lo stesso avvertimento: prenda il risultato dell’integrazione solo come riferimento.

Concetto fondamentale 2: distinguere quali file nella cartella Master sono i prodotti finiti

Dopo un’esecuzione completa di WBPP, nella cartella Master predefinita si ritrova una pila di file, e molti non riescono a distinguere quale sia quello che cercano davvero. Ecco una spiegazione:

Schema che distingue i vari file di output nella cartella Master di WBPP

  • L’immagine nel riquadro rosso è il master light integrato e completato che sta cercando.
  • L’immagine nel riquadro giallo è l’immagine di riferimento (Ref) della Local Normalization, non il master light: non le confonda.
  • Le immagini senza riquadro sono i master di calibrazione, che qui comprendono il master flat, il master bias e il master dark.

(Detto ciò, come al paragrafo precedente, questo «master light» ha comunque natura di anteprima di WBPP; a voler essere rigorosi, è meglio reintegrarlo di persona un’altra volta.)

Il flusso di esecuzione attuale: il pacchetto completo per una fotocamera a colori

WBPP va fino in fondo con un solo clic, ma dietro le quinte si tratta in realtà di una lunga sequenza di procedure automatizzate eseguite in ordine. Prendendo come esempio una fotocamera a colori (OSC), l’ordine di esecuzione completo è il seguente:

Schermata con l’ordine di esecuzione completo del pacchetto completo per fotocamera a colori in WBPP

  1. Calibration File Integration: creare i master di calibrazione
  2. Calibration: calibrare i light frame
  3. Cosmetic Correction: rimuovere i pixel caldi (hot pixels) o le righe difettose
  4. Debayer: debayering (separare l’RGB)
  5. Measurements: misurare i light frame e assegnare loro un peso
  6. Reference frame selection: scegliere l’immagine di riferimento per la registrazione
  7. Plate solving reference frames: eseguire il plate solving (risoluzione astrometrica) sui frame di riferimento
  8. Registration: registrazione delle stelle
  9. LN reference generation: generare l’immagine di riferimento per la Local Normalization
  10. Local Normalization: eseguire la Local Normalization
  11. Integration: integrare i light frame
  12. RGB Combination: ricombinare i tre canali RGB

Volendo dirlo in modo più sintetico, si può anche condensare in otto passi: creazione dei file immagine di calibrazione → calibrazione delle immagini → Cosmetic Correction → debayering (separazione dei tre canali RGB) → registrazione delle stelle → Local Normalization → integrazione delle immagini → combinazione dei tre canali RGB.

Il flusso di pre-elaborazione per fotocamera a colori in versione sintetica

Due di questi passi meritano qualche parola in più: la separazione RGB serve a superare la dispersione cromatica (per cui i bordi delle stelle sembrano avere colori diversi sui due lati), al prezzo di un tempo di esecuzione maggiore; la Drizzle Integration, se la si usa, qui non ha lo scopo di ingrandire l’immagine, bensì di evitare gli artefatti, e perciò ha senso solo quando si dispone di un numero sufficiente di frame ditherati — in genere, sotto i 50 frame, si può anche farne a meno. Per inciso, una nota sulla percezione reale dei tempi: una volta ho elaborato 360 frame da nove megapixel, dalla calibrazione fino alla Drizzle Integration 1x, e ci è voluta comunque più di un’ora; con più megapixel diventa solo più «adrenalinico».

Schermata di esecuzione di un pacchetto completo su 360 frame da nove megapixel

I master di calibrazione: dove WBPP è ingegnoso

Nel gestire i frame di calibrazione (flat, dark, bias e così via) WBPP nasconde parecchi accorgimenti premurosi, tali da meritare una sezione a sé.

I frame di calibrazione conviene rifarli da zero, a partire dai file originali, dentro WBPP. Non poche persone, dopo la calibrazione, scoprono che i light frame hanno problemi, e la causa principale è spesso l’aver applicato «file Master creati con altri software o procedure» (master flat/bias/dark). L’approccio più sicuro è gettare i file originali di calibrazione dentro WBPP e lasciare che rifaccia i Master.

Piccole discrepanze nel tempo di esposizione? Le lasci gestire a Exposure tolerance. Un appassionato una volta chiese nel gruppo: scattava i dark con il controllo del segnale via Eqmod e, a causa della latenza, i suoi dark da 5 secondi potevano in realtà cadere tra 4,980 e 5,02 secondi, così voleva passare a scattare con NINA. In realtà WBPP l’aveva già previsto: i frame di calibrazione entro una certa differenza di tempo possono essere assegnati allo stesso gruppo, e WBPP esegue automaticamente sui frame di calibrazione dello stesso gruppo l’elaborazione che serve, abbinandoli in automatico ai light frame. Questo valore di tolleranza è appunto Exposure tolerance.

L’impostazione del valore di tolleranza dell’esposizione Exposure tolerance di WBPP

Immagini scattate in giorni diversi? Le sistema tutte in una volta con i Grouping Keywords. Dopo un aggiornamento WBPP ha guadagnato una funzione di raggruppamento, così anche immagini scattate in date diverse si possono buttare dentro tutte insieme ed elaborare in blocco, purché le si classifichi nei Grouping Keywords con una parola chiave (per esempio la data). Prenda quel mio gruppo di file: i flat cambiavano da un giorno all’altro, eppure WBPP riusciva a calibrarli separatamente per data in automatico, senza che dovessi impostare a mano l’abbinamento tra light e flat per ogni data diversa: comodissimo.

Usare i Grouping Keywords per raggruppare e calibrare automaticamente per data

Vuole creare solo i master di calibrazione? Non serve nemmeno mettere i light frame. È un uso che molti non conoscono: senza alcun light frame, getti dentro WBPP i dark, i bias, i flat e i flat dark, e lui, con intelligenza, trasforma questi frame di calibrazione in master di calibrazione seguendo i passi corretti, esportandoli nella cartella che indica: le si risparmia la seccatura di crearli a mano con svariate procedure diverse.

Inserire solo i frame di calibrazione, senza light frame, per far sì che WBPP crei esclusivamente i master di calibrazione

Le opzioni della pagina Light e i trucchi per velocizzare

La pagina Light di WBPP presenta una fila di opzioni che l’utente può spuntare a seconda delle necessità. Per impostazione predefinita, tranne subframe weighting sono tutte deselezionate.

Spiegazione della funzione delle varie opzioni della pagina Light di WBPP

Dato che questi passi si possono includere o escludere, sorge una domanda pratica: disattivando le elaborazioni che non servono, quanto tempo si risparmia? Ho fatto una prova reale con un set di dati scaricabili liberamente dall’estero, 372 frame da sedici megapixel in tutto, e, tolte le elaborazioni che non mi servivano, i tempi sono diventati circa 7-8 volte più rapidi (25 min 03 sec contro 03 min 30 sec), mentre la qualità dell’immagine ha subito solo una lieve perdita: sulla mia macchina circa il 15% di differenza, e dopo la compressione e l’invio via rete praticamente indistinguibile. Per le situazioni in cui si rincorre una scadenza o si vuole solo dare un’occhiata sommaria, questo compromesso conviene parecchio.

Confronto dei tempi di esecuzione prima e dopo aver disattivato una parte delle elaborazioni

Quanto a quali passi consumino più tempo e quali convenga di più disattivare, ne riparlerò nell’articolo «Risoluzione dei problemi di WBPP».

Le modifiche di versione: queste sono arrivate dopo

In questi anni WBPP ha aggiunto parecchie cose; riepilogo alcuni snodi importanti, così da poterli confrontare con la versione che ha tra le mani:

Alcune cose dalla versione 2.1.2. A partire da questa versione, tre punti meritano attenzione: primo, se i light frame danno problemi dopo la calibrazione è spesso perché si sono mescolati file Master creati esternamente (vedi sopra); secondo, la Dark frame optimization si usa principalmente quando la durata dei light e dei dark non coincide (per esempio un light da 20 minuti abbinato a un dark da 30 minuti), dà il meglio con lunghe esposizioni e più frame, e l’opzione compare solo cliccando su un file di light frame; terzo, chi usa un CCD vede comparire via via, con l’uso, dei defect, in particolare i column defect, che in passato si dovevano rimuovere costruendo una defect map, cosa molto dispendiosa in termini di tempo, e WBPP ha introdotto la Linear Pattern Subtraction per aiutare a gestirli.

Le opzioni relative a WBPP 2.1.2 e la Linear Pattern Subtraction

Execution Monitor (finestra di monitoraggio dell’esecuzione). Dopo l’aggiornamento a una versione più recente, durante l’esecuzione WBPP fa comparire una finestra WBPP Execution Monitor che indica a quale passo è arrivato e quali lavori ha svolto, con contenuti che si possono anche scorrere e trascinare su e giù. Nelle versioni più vecchie l’utente, oltre a fissare la console del momento, non aveva alcun modo di conoscere l’avanzamento: poteva solo aspettare che tutto finisse, o che si fermasse su un errore, per poi verificare dalla console.

La finestra di monitoraggio dell’esecuzione WBPP Execution Monitor

La funzione Cache (dalla versione 2.5 in poi). È un miglioramento cruciale. Se, dopo un’esecuzione del pacchetto completo, si scopre un errore o qualcosa che non è all’altezza delle aspettative e si cambiano alcune impostazioni, bisogna davvero rieseguire tutto da capo? No. La cache di WBPP fa questa valutazione: finché le impostazioni modificate non influiscono sulle immagini, riutilizza direttamente i risultati in cache della volta precedente; viene rielaborata solo la porzione di immagini realmente interessata, e così il tempo della seconda esecuzione si accorcia drasticamente.

Spiegazione della funzione di cache di WBPP

Lo script riproducibile nella cartella log. Dopo l’esecuzione, la versione più recente di WBPP conserva nella cartella log un log dettagliato e lo script di esecuzione. Una volta letto lo script con lo Script Editor di PI, compilato ed eseguito, compare un Process Container che racchiude tutte le icone dei processi del sottomenu Pipeline della finestra principale di WBPP, ciascuna apribile singolarmente in PI. Questo è estremamente comodo per il debug: se per esempio vuole capire perché la Cosmetic Correction non è stata eseguita correttamente o non ha avuto effetto, può aprire quel passo da qui e verificare se si tratta di un problema di parametri o di un bug del programma. Un altro impiego: chi non ha dimestichezza con la pre-elaborazione può, con questo metodo, ricavare ogni passo procedurale e ogni parametro usati da WBPP, prendendoli come modello di riferimento per eseguire il tutto a mano da sé.

Usare lo Script Editor per leggere lo script di esecuzione di WBPP e riprodurre il Process Container

Il primo passo quando si apre WBPP, in realtà, non è caricare i file

Infine, torniamo alla cosa più elementare, e insieme la più facile da sbagliare. Il primo passo dopo aver aperto WBPP non è precipitarsi a «caricare i file di light, dark, flat e bias».

WBPP è uno dei pochi script che conserva ciò che si è usato l’ultima volta. Se lo ha già usato prima, tutte le impostazioni sono ancora lì. Perciò il primo passo dovrebbe essere svuotare l’elenco dei file; se cancellare anche gli altri parametri dipende dalle necessità.

E il secondo passo si dimentica facilmente, e molti video tutorial nemmeno lo menzionano: premere Purge Cache. Ho già detto del vantaggio della cache (dalla versione 2.5 in poi): quando si cambiano solo alcuni parametri, WBPP esegue solo le parti modificate e per il resto riutilizza la cache. Ma, al contrario, quando si è già fatta un’esecuzione e quei contenuti in cache non servono più, occorre cancellarli tutti, altrimenti, eseguendo file nuovi, la duplicazione dei contenuti in cache può provocare errori imprevedibili.

Dopo aver aperto WBPP, prima svuotare l’elenco dei file, poi premere Purge Cache

Le impostazioni preliminari dell’ambiente per gli utenti Windows

Se esegue WBPP su Windows, conviene sistemare fin da subito due impostazioni dell’ambiente: le eviteranno una sfilza di errori incomprensibili più avanti (per i relativi messaggi di errore e la diagnosi, veda «Risoluzione dei problemi di WBPP»):

Attivare il supporto ai percorsi lunghi. Dopo un certo aggiornamento, WBPP su Windows ha cominciato a mostrare spesso un avviso sui percorsi lunghi, dicendo di non poter generare percorsi più lunghi di 256 caratteri. A me è capitato che, per un percorso troppo lungo, i file prodotti da WBPP risultassero danneggiati (perché il file non si poteva salvare). La soluzione è cercare regedit nella barra delle applicazioni per aprire l’Editor del Registro di sistema, individuare la posizione corrispondente e cambiare a 1 il valore di LongPathsEnabled; dopo aver riavviato PixInsight, questo avviso non comparirà più.

L’avviso sui percorsi lunghi di Windows e l’impostazione di LongPathsEnabled in regedit

Evitare percorsi con caratteri non ASCII (per esempio cinesi). È anche il motivo per cui sconsiglio di usare caratteri non ASCII, come quelli cinesi, nei percorsi dei file. Su Windows, se il programma predefinito per l’apertura è PI, basta fare doppio clic su un file il cui percorso contiene caratteri non ASCII perché compaia un messaggio di errore: quei caratteri illeggibili non sono altro che il testo cinese. L’espediente è: senza modificare il percorso, trascinare direttamente il file dentro PI, e si aprirà.

L’errore illeggibile che PixInsight mostra quando apre un file con un percorso in cinese


Mettendo insieme tutto quanto sopra, il quadro complessivo di WBPP diventa più o meno chiaro: è un potente motore di pre-elaborazione automatizzata, ma deve ricordare che il suo prodotto di integrazione è solo un’anteprima, sapere come raggruppare la calibrazione, come sfruttare bene la cache, e cosa cancellare e quale ambiente configurare prima di iniziare. Una volta assodati i concetti, il resto è solo questione di pratica.