Ghidul complet pentru WBPP: interfață, cadre master de calibrare și fluxul de execuție

Acest articol este alcătuit din notițe din perioada 2021-2024; unele instrumente sau fluxuri de lucru au fost între timp actualizate, așa că acest lucru merită reținut la lectură. Interfețele, opțiunile și comportamentele specifice unor versiuni menționate în text (de exemplu versiunile 2.1.2 și 2.5) reflectă starea de atunci. Pentru erorile și bugurile cunoscute întâlnite la rulare, consultați articolul separat „WBPP Troubleshooting”.

WBPP (WeightedBatchPreprocessing) este scriptul din PixInsight care parcurge automat, de la un capăt la altul, întregul lanț „calibrare, aliniere, stacking” – o comoditate uimitoare. În ultimii ani a fost actualizat frecvent, iar eu am scris pe parcurs destule notițe răzlețe despre el; acest articol le adună într-o explicație mai completă, tratată pe trei niveluri: conceptele fundamentale, care se schimbă puțin de la o versiune la alta, fluxul de execuție actual și câteva schimbări importante survenite de-a lungul versiunilor din ultimii ani. Indiferent de versiunea folosită, dacă noțiunile de bază sunt bine fixate, nicio schimbare de interfață nu va provoca panică.

Concept fundamental 1: rezultatul de stacking generat de WBPP este doar o previzualizare

Acesta este punctul pe care vreau să-l abordez primul și, în același timp, cel pe care majoritatea oamenilor îl ignoră.

Am pățit-o și eu: după ce am folosit odată Drizzle Integration, am observat că centrele stelelor (zonele suprasaturate) deveniseră negre. Investigând, am descoperit că vinovatul era chiar stackingul realizat cu WBPP.

Oricât de comod ar fi WBPP, în privința cadrului master light produs automat de acesta prin stacking, poziția oficială este foarte clară – este doar o previzualizare comodă a „rezultatului posibil”, care ar trebui aruncată după utilizare și nu ar trebui folosită niciodată ca rezultat final oficial. Redau mai jos un fragment din răspunsul oficial de pe 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.

Cei de la echipa oficială au spus chiar, pe jumătate în glumă, că ar vrea să repete această propoziție „de n+1 ori, unde n se apropie deja de infinit”: cadrul master light produs de WBPP nu ar trebui folosit pentru scopuri oficiale, este doar o previzualizare, iar cel mai bun rezultat se obține doar printr-un Image Integration manual, care optimizează pixel rejection și raportul semnal-zgomot.

Așa că obiceiul meu este: folosesc WBPP cel mult până la pasul „alinierea stelelor”, iar stackingul propriu-zis îl las tot pe seama Image Integration, aplicat manual. Metoda formală, împărțită pe etape separate – calibrare (lăsată în seama WBPP), aliniere (Star Alignment), stacking (Image Integration) – necesită ceva mai mulți pași, dar în momentul în care apare o problemă, este mult mai ușor de identificat veriga defectă. Aceasta a devenit și convingerea mea ulterioară; recomand cu căldură și cele două tutoriale video foarte detaliate despre WBPP realizate cu ceva timp în urmă de niște pasionați japonezi, dar cu aceeași observație adăugată: rezultatul de stacking trebuie tratat doar ca referință.

Concept fundamental 2: care fișiere din folderul Master sunt rezultatele finale

După ce WBPP rulează complet, în folderul Master implicit rămân o mulțime de fișiere, iar mulți nu reușesc să distingă care este de fapt cel de care au nevoie. Iată o lămurire:

• Imaginea din chenarul roșu este cadrul master light finalizat prin stacking, cel dorit.
• Imaginea din chenarul galben este imaginea de referință (Ref) pentru Local Normalization, nu cadrul master light; a nu se confunda.
• Imaginile fără chenar sunt cadrele master de calibrare; aici sunt incluse master flat, master bias și master dark.

(Totuși, așa cum s-a arătat în secțiunea anterioară, acest „master light” rămâne tot doar o previzualizare oferită de WBPP; pentru un rezultat riguros, este nevoie de un stacking propriu, repetat manual.)

Fluxul de execuție actual: pachetul complet pentru camerele color

WBPP rulează dintr-un singur clic până la capăt, dar în spate se ascunde de fapt un lanț lung de procese automatizate, executate în ordine. Luând ca exemplu o cameră color (OSC), ordinea completă de execuție este următoarea:

1. Calibration File Integration: crearea cadrelor master de calibrare
2. Calibration: calibrarea cadrelor light
3. Cosmetic Correction: eliminarea hot pixelilor sau a liniilor defecte
4. Debayer: debayerizare (separarea canalelor RGB)
5. Measurements: măsurarea cadrelor light și atribuirea ponderilor
6. Reference frame selection: stabilirea imaginii de referință pentru aliniere
7. Plate solving reference frames: plate solving pe imaginile de referință (astrometrie)
8. Registration: alinierea stelelor
9. LN reference generation: generarea imaginii de referință pentru Local Normalization
10. Local Normalization: execuția Local Normalization
11. Integration: stackingul cadrelor light
12. RGB Combination: recompunerea celor trei canale RGB

Într-o formulare mai concisă, procesul poate fi condensat în opt pași: crearea fișierelor de calibrare → calibrarea imaginilor → Cosmetic Correction → debayerizare (separarea celor trei canale RGB) → alinierea stelelor → Local Normalization → stackingul imaginilor → combinarea celor trei canale RGB.

Merită detaliate două etape: separarea RGB are rolul de a corecta dispersia cromatică (marginile stelelor par să aibă culori diferite pe cele două părți), cu prețul unui timp de rulare mai lung; dacă se folosește Drizzle Integration, scopul acesteia aici nu este mărirea imaginii, ci evitarea artefactelor, așa că are sens doar atunci când numărul de cadre cu dither este suficient de mare – de regulă, sub 50 de cadre poate fi omisă. Ca reper de timp real: am rulat odată 360 de imagini de 9 megapixeli, de la calibrare până la Drizzle Integration 1x, și a durat peste o oră; la o rezoluție mai mare, lucrurile devin doar mai „palpitante”.

Cadrele master de calibrare: unde WBPP este cu adevărat ingenios

WBPP ascunde destule soluții bine gândite în prelucrarea cadrelor de calibrare (flat, dark, bias etc.), motiv pentru care merită o secțiune separată.

Cadrele de calibrare ar trebui, ideal, refăcute în WBPP direct din fișierele originale. Destui utilizatori observă probleme la cadrele light după calibrare, iar cauza principală este de multe ori aplicarea unor „fișiere Master create cu alt software sau prin alt proces” (master flat/bias/dark). Cea mai sigură metodă este introducerea fișierelor originale de calibrare în WBPP și lăsarea acestuia să refacă fișierele Master.

Există o mică diferență în timpul de expunere? Aici intervine Exposure tolerance. Cineva a întrebat odată într-un grup: fotografia cadrele dark controlate prin semnalul Eqmod, iar din cauza întârzierilor, un cadru dark de 5 secunde poate ajunge de fapt între 4,980-5,02 secunde, motiv pentru care se gândea să treacă la NINA. De fapt, WBPP s-a gândit deja la asta: cadrele de calibrare aflate într-o anumită marjă de timp pot fi desemnate ca aparținând aceluiași grup, iar WBPP aplică automat prelucrarea necesară cadrelor din același grup și le asociază automat cu cadrele light. Această marjă de toleranță este Exposure tolerance.

Imaginile din zile diferite se rezolvă dintr-o dată cu Grouping Keywords. După actualizare, WBPP a primit o funcție de grupare: chiar și imaginile din date diferite pot fi introduse și prelucrate deodată – este suficient să se clasifice după cuvinte-cheie (de exemplu data) în Grouping Keywords. La setul meu de fișiere, de pildă, cadrele flat difereau în fiecare zi, iar WBPP tot a reușit să calibreze automat separat, în funcție de dată, fără să mai fie nevoie de o configurare manuală separată pentru fiecare pereche de cadre light și flat din fiecare zi – extrem de comod.

Se dorește doar crearea cadrelor master de calibrare? Se poate și fără cadre light. Aceasta este o utilizare pe care mulți nu o cunosc: fără niciun cadru light, introducând doar cadre dark, bias, flat și flat dark în WBPP, acesta parcurge inteligent pașii corecți și transformă aceste cadre de calibrare în cadre master, exportându-le în folderul specificat – ceea ce elimină bătaia de cap a creării manuale prin diverse alte procese.

Opțiunile din pagina Light și trucuri pentru accelerare

Pagina Light din WBPP conține un rând de opțiuni, care pot fi bifate în funcție de nevoi. Implicit, niciuna nu este bifată, cu excepția subframe weighting.

Din moment ce aceste etape pot fi selectate după nevoie, apare o întrebare practică: cât timp se poate economisi dezactivând prelucrările inutile? Am testat efectiv cu un set de date disponibil liber pentru descărcare din străinătate, în total 372 de imagini de 16 megapixeli; după eliminarea prelucrărilor inutile, timpul a scăzut de aproximativ 7-8 ori (25 de minute și 3 secunde față de 3 minute și 30 de secunde), iar calitatea imaginii a scăzut doar ușor – aproximativ 15% pe mașina locală, diferență aproape imperceptibilă după compresia prin rețea. Pentru situațiile în care timpul presează sau se dorește doar o privire de ansamblu, acest compromis este foarte avantajos.

Cât despre care etape consumă cel mai mult timp și care este cel mai eficient de dezactivat, voi reveni asupra acestui subiect în articolul „WBPP Troubleshooting”.

Schimbări de versiune: elemente apărute ulterior

WBPP a primit destule elemente noi de-a lungul anilor; iată o trecere în revistă a câtorva repere importante, utilă pentru a compara cu versiunea aflată la îndemână.

Câteva lucruri din versiunea 2.1.2. Începând cu această versiune, merită reținute trei aspecte: în primul rând, problemele apărute la cadrele light după calibrare se datorează adesea amestecării unor fișiere Master create în exterior (a se vedea mai sus); în al doilea rând, Dark frame optimization se folosește în principal atunci când lungimea cadrelor light și dark nu se potrivește (de exemplu un cadru light de 20 de minute asociat cu un cadru dark de 30 de minute), condiția optimă fiind expuneri lungi și mai multe imagini, iar opțiunea devine vizibilă doar după ce se face clic pe fișierul light; în al treilea rând, utilizatorii de camere CCD acumulează treptat defecte, în special column defect, care în trecut trebuiau eliminate printr-o defect map, un proces extrem de consumator de timp – WBPP oferă Linear Pattern Subtraction pentru a ajuta la această sarcină.

Execution Monitor (fereastra de monitorizare a execuției). După actualizarea la o versiune mai nouă, în timpul rulării WBPP apare o fereastră WBPP Execution Monitor, care arată la ce pas s-a ajuns și ce operații s-au efectuat; conținutul poate fi și derulat, în sus și în jos, prin tragere. În versiunile mai vechi, singura opțiune era urmărirea consolei curente, fără nicio altă modalitate de a afla progresul – trebuia așteptată finalizarea completă sau oprirea din cauza unei erori pentru a putea verifica situația prin consolă.

Funcția de cache (începând cu versiunea 2.5). Aceasta este o îmbunătățire esențială. Dacă, după rularea pachetului complet, se constată o eroare sau un rezultat sub așteptări și se modifică anumite setări, oare trebuie rulat din nou întregul pachet? Nu este nevoie. Cache-ul WBPP evaluează situația: atât timp cât setarea modificată nu afectează imaginea, se folosește direct rezultatul din cache-ul anterior; doar acea parte a imaginilor efectiv afectată este prelucrată din nou, iar timpul celei de-a doua rulări se scurtează astfel considerabil.

Scriptul reproductibil din folderul log. După rularea celei mai noi versiuni de WBPP, în folderul log rămân un jurnal detaliat și un script de execuție. Dacă acest script este citit, compilat și rulat cu Script Editor din PI, apare un Process Container, care conține toate pictogramele de proces din submeniul Pipeline al ferestrei principale WBPP, fiecare putând fi deschisă separat în PI. Acest lucru este extrem de util pentru depanare – de exemplu, dacă se dorește să se afle de ce Cosmetic Correction nu a rulat corect sau nu a avut efect, acel pas poate fi deschis de aici, pentru a verifica dacă e o problemă de parametri sau un bug de programare. O altă utilizare: cei care nu sunt familiarizați cu preprocesarea pot folosi această metodă pentru a vedea fiecare proces și parametru al WBPP, ca șablon de referință pentru propria execuție manuală.

Primul pas după deschiderea WBPP nu este, de fapt, încărcarea fișierelor

În final, revenim la cel mai elementar aspect, dar și cel mai ușor de greșit. Primul pas după deschiderea WBPP nu este să se încarce în grabă fișierele light, dark, flat și bias.

WBPP este unul dintre puținele scripturi care păstrează conținutul folosit ultima dată. Dacă a mai fost folosit anterior, toate setările rămân intacte. Așadar, primul pas ar trebui să fie golirea listei de fișiere; dacă și ceilalți parametri trebuie șterși odată cu ea depinde de necesități.

Iar al doilea pas este ușor de omis, și nici multe tutoriale video nu îl menționează – apăsați Purge Cache. Am menționat mai devreme avantajul cache-ului (începând cu versiunea 2.5): când se modifică doar o parte din parametri, WBPP rulează doar porțiunile schimbate, restul fiind preluat din cache. Dar, invers, atunci când pachetul a fost deja rulat și acel conținut din cache nu mai este necesar, trebuie șters în întregime, altfel, la rularea unor fișiere noi, conținutul duplicat din cache poate provoca erori imprevizibile.

Configurarea prealabilă a mediului pentru utilizatorii Windows

Dacă WBPP rulează sub Windows, este bine ca două setări de mediu să fie rezolvate încă de la început, ceea ce evită o mulțime de erori inexplicabile mai târziu (pentru mesajele de eroare aferente și diagnosticare, a se vedea articolul „WBPP Troubleshooting”):

Activarea suportului pentru căi lungi. După o anumită actualizare, WBPP pe Windows afișa frecvent un avertisment privind căile lungi, indicând imposibilitatea generării unei căi de peste 256 de caractere. Mi s-a întâmplat chiar ca, din cauza unei căi prea lungi, fișierele produse de WBPP să fie deteriorate (pentru că nu se puteau salva). Soluția este căutarea regedit în bara de activități pentru a deschide Registry Editor, găsirea locației corespunzătoare și schimbarea valorii LongPathsEnabled în 1; după repornirea PixInsight, acest avertisment nu mai apare.

Evitarea căilor cu caractere din afara setului ASCII (de exemplu chinezești). Acesta este și motivul pentru care nu recomand folosirea unor caractere chinezești în calea fișierelor. Sub Windows, dacă programul implicit de deschidere este PI, dublu-clic pe un fișier cu o cale care conține caractere chinezești declanșează un mesaj de eroare, în care acele caractere ilizibile sunt tocmai textul chinezesc. Soluția de ocolire: fără a modifica calea, fișierul este tras direct în PI prin drag and drop, iar acesta se va deschide.

---

Punând cap la cap toate acestea, imaginea de ansamblu devine clară: WBPP este un motor de preprocesare automatizat și puternic, dar trebuie reținut că rezultatul lui de stacking este doar o previzualizare, că trebuie știut cum se grupează cadrele de calibrare, cum se folosește eficient cache-ul și ce anume trebuie golit, ce mediu trebuie configurat înainte de începerea lucrului. Odată ce conceptele sunt corecte, tot ce rămâne este o chestiune de exersare.