De complete WBPP-gids: interface, master-kalibratieframes en de uitvoeringspipeline
Dit artikel is samengesteld uit aantekeningen van 2021–2024. Sommige gereedschappen of workflows zijn sindsdien bijgewerkt, dus houd daar rekening mee tijdens het lezen; de interfaces, opties en versiegebonden gedragingen die hier worden genoemd (bijvoorbeeld versie 2.1.2 en 2.5) geven telkens de toenmalige stand van zaken weer. Wat betreft de fouten en bekende bugs die u tijdens de uitvoering tegenkomt, zie het aparte artikel “WBPP-probleemoplossing”.
WBPP (WeightedBatchPreprocessing) is het PixInsight-script dat “kalibratie, uitlijning en integratie” van begin tot eind volautomatisch afwerkt, en het is verbazingwekkend handig. De afgelopen jaren is het vaak herzien, en ik heb er gaandeweg heel wat verspreide aantekeningen over geschreven; dit artikel brengt ze samen tot een tamelijk volledige uitleg, opgedeeld in drie lagen: de kernbegrippen die met de versies nauwelijks veranderen, de huidige uitvoeringspipeline, en enkele belangrijke veranderingen door de jaren en versies heen. Welke versie u ook gebruikt: als u eerst de begrippen stevig in de vingers hebt, raakt u niet in paniek, hoe de interface ook verandert.
Kernbegrip 1: het door WBPP geïntegreerde eindresultaat is slechts een voorvertoning
Dit is het punt dat ik het liefst als eerste wil maken, en tegelijk het punt dat de meeste mensen over het hoofd zien.
Ik ben er zelf ingetuind: nadat ik een keer Drizzle Integration had gebruikt, merkte ik dat de kern van de sterren (de oververzadigde plekken) zowaar zwart was geworden. Toen ik het uitzocht, bleek de boosdoener het gebruik van WBPP voor de integratie te zijn.
Hoe handig WBPP ook is, over de master light die het automatisch integreert is het officiële standpunt zeer duidelijk — het is slechts een handige voorvertoning van “het haalbare resultaat”, die u na gebruik zou moeten weggooien, en die u nooit als eindproduct mag behandelen. Ik citeer hieronder het relevante antwoord dat de makers op het forum gaven:
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.
De makers zeiden zelfs half voor de grap dat ze deze zin wel “n+1 keer wilden herhalen, waarbij n al de oneindigheid nadert”: de master light die WBPP produceert mag niet voor serieus gebruik worden ingezet, het is slechts een voorvertoning, en het beste resultaat is pas te verkrijgen via een handmatige Image Integration die de pixel rejection en de signaal-ruisverhouding optimaliseert.
Daarom is mijn gewoonte: WBPP zet ik hoogstens in tot en met de stap “sterren uitlijnen”; de echte integratie geef ik weer terug aan een handmatige Image Integration. De correcte, in afzonderlijke procedures opgesplitste aanpak — kalibratie (aan WBPP overgelaten), uitlijning (Star Alignment) en integratie (Image Integration) — kost weliswaar een paar stappen extra, maar zodra er iets misgaat, is veel gemakkelijker te achterhalen welke schakel in de keten kapot is. Dit werd naderhand mijn vaste overtuiging. Ook die twee zeer gedetailleerde WBPP-lesvideo’s van Japanse liefhebbers uit de begintijd raad ik van harte aan, maar daar moet dezelfde kanttekening bij: beschouw het integratieresultaat alleen als referentie.
Kernbegrip 2: onderscheid welke bestanden in de Master-map de eindproducten zijn
Na een volledige WBPP-run ligt er onder de standaard Master-map een hoop bestanden, en veel mensen kunnen niet onderscheiden welk bestand nu het bestand is dat ze eigenlijk willen. Even ter verduidelijking:
- Het beeld in het rode kader is de geïntegreerde, voltooide master light die u wilt.
- Het beeld in het gele kader is het referentiebeeld (Ref) voor de Local Normalization, niet de master light — verwar de twee niet.
- De beelden zonder kader zijn de master-kalibratieframes; daartoe behoren hier de master flat, de master bias en de master dark.
(Zoals in de vorige paragraaf gezegd, blijft deze “master light” echter voorvertoningsmateriaal van WBPP; als u het nauw neemt, moet u hem toch zelf nog een keer opnieuw integreren.)
De huidige pipeline: het volledige programma voor een kleurencamera
WBPP loopt met één klik helemaal door, maar achter de schermen is het in werkelijkheid een lange reeks geautomatiseerde processen die op volgorde worden uitgevoerd. Met een kleurencamera (OSC) als voorbeeld ziet de volledige uitvoeringsvolgorde er als volgt uit:
- Calibration File Integration: de master-kalibratieframes maken
- Calibration: de lights kalibreren
- Cosmetic Correction: hete pixels of slechte lijnen verwijderen
- Debayer: debayeren (RGB scheiden)
- Measurements: de lights meten en gewichten toekennen
- Reference frame selection: het referentiebeeld voor de uitlijning kiezen
- Plate solving reference frames: de referentieframes plate solven (astrometrische positiebepaling)
- Registration: de sterren uitlijnen
- LN reference generation: het referentiebeeld voor de Local Normalization genereren
- Local Normalization: Local Normalization uitvoeren
- Integration: de lights integreren
- RGB Combination: de drie RGB-kanalen opnieuw samenvoegen
In beknoptere bewoordingen valt het ook samen te vatten in acht stappen: de kalibratiebeeldbestanden maken → beeldkalibratie → Cosmetic Correction → debayeren (de drie RGB-kanalen scheiden) → sterren uitlijnen → Local Normalization → beeldintegratie → samenvoegen van de drie RGB-kanalen.
Twee van deze stappen verdienen een paar woorden meer: de RGB-scheiding dient om atmosferische dispersie te overwinnen (waarbij de randen van sterren aan weerszijden een andere kleur lijken te hebben), ten koste van extra rekentijd; en Drizzle Integration heeft, als u het gebruikt, hier niet tot doel het beeld te vergroten, maar om artefacten te vermijden, en het is dus pas zinvol wanneer u genoeg geditherde frames hebt — over het algemeen kunt u het bij minder dan 50 frames eigenlijk achterwege laten. Terzijde iets over hoe de tijd feitelijk aanvoelt: ik heb ooit 360 frames van negen megapixel van de kalibratie helemaal tot Drizzle Integration 1x doorlopen, en dat kostte ook ruim een uur; een hogere resolutie maakt het alleen maar “spannender”.
Master-kalibratieframes: waar WBPP slim is
WBPP verbergt in de manier waarop het kalibratieframes (flats, darks, biases enzovoort) verwerkt heel wat attente vondsten — genoeg om er een aparte paragraaf aan te wijden.
Kalibratieframes kunt u het best binnen WBPP opnieuw vanuit de ruwe bestanden opbouwen. Nogal wat mensen ontdekken na de kalibratie dat er iets mis is met hun lights, en de voornaamste oorzaak is vaak dat ze “Master-bestanden gemaakt door andere software of processen” (master flat/bias/dark) hebben toegepast. De veiligste aanpak is de ruwe kalibratiebestanden in WBPP te gooien en het de Masters opnieuw laten maken.
Een kleine afwijking in de belichtingstijd? Laat dat aan Exposure tolerance over. Een medeliefhebber vroeg ooit in de groep: hij nam darks op met signaalsturing via Eqmod, en door vertragingsproblemen konden zijn darks van 5 seconden in werkelijkheid ergens tussen 4,980 en 5,02 seconden uitkomen, dus hij wilde overstappen op opnemen met NINA. WBPP had daar in feite allang op geanticipeerd: kalibratieframes binnen een bepaald tijdsverschil kunnen als dezelfde groep worden aangewezen, en WBPP voert voor de kalibratieframes in dezelfde groep automatisch de vereiste verwerking uit en koppelt ze automatisch aan de lights. Die tolerantiewaarde is Exposure tolerance.
Beelden die op verschillende dagen zijn opgenomen? Regel ze in één keer met Grouping Keywords. Na een herziening kreeg WBPP een groeperingsfunctie, zodat zelfs beelden die op verschillende data zijn opgenomen allemaal in één keer erin kunnen en samen worden verwerkt — zolang u ze in Grouping Keywords met een trefwoord (bijvoorbeeld de datum) indeelt. Neem mijn set bestanden: de flats verschilden van dag tot dag, en toch kon WBPP ze automatisch per datum apart kalibreren, zonder dat ik voor elke afzonderlijke datum de koppeling van lights en flats met de hand hoefde in te stellen. Uiterst handig.
Alleen master-kalibratieframes maken? Dan hoeft u geen lights toe te voegen. Dit is een gebruik dat veel mensen niet kennen: gooi zonder lights uw darks, bias, flats en dark flats in WBPP, en het maakt van deze kalibratieframes op slimme wijze, volgens de juiste stappen, master-kalibratieframes, die het naar de door u opgegeven map uitvoert — dat bespaart u de moeite om ze met de hand via allerlei verschillende processen te maken.
Opties op de Light-pagina en versnellingstrucs
De Light-pagina van WBPP heeft een rij opties die u naar behoefte kunt aanvinken. Standaard is alles behalve subframe weighting uitgevinkt.
Aangezien deze stappen aan of uit kunnen, roept dat een praktische vraag op: hoeveel tijd bespaart u door de verwerking die u niet nodig hebt uit te schakelen? Ik heb een echte test gedaan met een set vrij te downloaden data uit het buitenland — in totaal 372 frames van zestien megapixel — en nadat ik de overbodige verwerking eruit had gehaald, liep het ongeveer 7 tot 8 keer sneller (25 min 03 s vs. 03 min 30 s), terwijl de beeldkwaliteit slechts een lichte terugval kende — op mijn eigen machine ongeveer 15% verschil, en na compressie en verzending over het net vrijwel niet te onderscheiden. Voor situaties waarin u een deadline najaagt of eerst even een grove indruk wilt, is deze afweging zeer de moeite waard.
Welke stappen de meeste tijd opslokken en welke het effectiefst zijn om uit te schakelen, bespreek ik verder in het artikel “WBPP-probleemoplossing”.
Versieveranderingen: deze kwamen er pas later bij
WBPP heeft in de loop der jaren heel wat toegevoegd; ik zet een paar belangrijke mijlpalen op een rij, zodat u ze gemakkelijk kunt vergelijken met de versie die u in handen hebt:
Een paar dingen uit versie 2.1.2. Vanaf deze versie zijn drie punten het opmerken waard: ten eerste komen problemen met lights na de kalibratie vaak doordat extern gemaakte Master-bestanden erdoorheen zijn geraakt (zie hierboven); ten tweede wordt Dark frame optimization vooral gebruikt wanneer de lengtes van lights en darks niet op elkaar aansluiten (bijvoorbeeld een light van 20 minuten gekoppeld aan een dark van 30 minuten), werkt het het best bij lange belichtingen met meerdere frames, en verschijnt de optie pas wanneer u op een light-bestand klikt; ten derde ontwikkelen mensen die een CCD gebruiken gaandeweg defects, in het bijzonder column defects — vroeger moest u die met een defect map verwijderen, wat zeer tijdrovend was, en WBPP heeft Linear Pattern Subtraction geïntroduceerd om daarbij te helpen.
Execution Monitor (het uitvoeringsvenster). Na het bijwerken naar een nieuwere versie laat WBPP tijdens de uitvoering een venster WBPP Execution Monitor verschijnen dat u vertelt bij welke stap het op dat moment is en welk werk het heeft verricht; u kunt de inhoud zelfs op en neer scrollen en slepen. In oudere versies had de gebruiker, afgezien van het staren naar de huidige console, geen enkele manier om de voortgang te weten — u kon alleen wachten tot alles klaar was, of tot het bij een fout stopte, voordat u iets via de console kon bevestigen.
De cache-functie (vanaf versie 2.5). Dit is een zeer cruciale verbetering. Als u na een run van het volledige programma een fout of iets tegenvallends ontdekt en enkele instellingen wijzigt, moet u dan werkelijk de hele boel opnieuw draaien? Nee. De cache van WBPP maakt de afweging: zolang de gewijzigde instellingen de beelden niet beïnvloeden, hergebruikt het gewoon de cacheresultaten van de vorige keer; alleen het deel van de beelden dat werkelijk wordt beïnvloed, wordt opnieuw verwerkt, waardoor de tijd van de tweede uitvoering drastisch korter wordt.
Het reproduceerbare script in de log-map. Na uitvoering bewaart de nieuwste WBPP in de log-map een gedetailleerd log en een uitvoeringsscript. Zodra u het script met de Script Editor van PI inleest, compileert en uitvoert, verschijnt er een Process Container met alle proces-ICON’s uit het submenu Pipeline van het WBPP-hoofdvenster, die u elk afzonderlijk in PI kunt openen. Dit is uiterst handig voor het debuggen — wilt u bijvoorbeeld uitzoeken waarom de Cosmetic Correction niet correct is uitgevoerd of geen effect had, dan kunt u die stap hiervandaan openen en nagaan of het een parameterkwestie is of een bug in de code. Een ander gebruik: wie niet vertrouwd is met de voorbewerking, kan op deze manier elke procedurele stap en elke parameter die WBPP heeft gebruikt uitlezen, om als referentiesjabloon te dienen wanneer men het zelf handmatig uitvoert.
De eerste stap bij het openen van WBPP is eigenlijk niet het laden van bestanden
Tot slot terug naar het meest elementaire — en tegelijk het gemakkelijkst verkeerd te doen — punt. De eerste stap na het openen van WBPP is niet om overhaast “de light-, dark-, flat- en bias-bestanden te laden”.
WBPP is een van de weinige scripts die de inhoud van het vorige gebruik bewaren. Hebt u het eerder gebruikt, dan staan al uw instellingen er nog. De eerste stap zou dus moeten zijn om de bestandenlijst te wissen; of u de overige parameters meteen mee wist, hangt af van uw behoefte.
En de tweede stap wordt gemakkelijk overgeslagen, veel lesvideo’s vermelden hem ook niet — druk op Purge Cache. Ik noemde eerder het voordeel van de cache (vanaf versie 2.5): wanneer u slechts een deel van de parameters wijzigt, draait WBPP alleen de gewijzigde onderdelen en hergebruikt het voor de rest de cache. Maar omgekeerd geldt: wanneer u al een run hebt gedaan en die cache-inhoud niet meer nodig hebt, moet u die volledig wissen, anders kan het uitvoeren van nieuwe bestanden door dubbele cache-inhoud onvoorspelbare fouten veroorzaken.
Voorbereidende omgevingsinstellingen voor Windows-gebruikers
Als u WBPP onder Windows draait, zijn er twee omgevingsinstellingen die u het best meteen aan het begin in orde brengt; ze besparen u later een hele reeks onverklaarbare fouten (voor de bijbehorende foutmeldingen en diagnose, zie uitvoerig “WBPP-probleemoplossing”):
Schakel ondersteuning voor lange paden in. Na een bepaalde update wierp WBPP op Windows vaak een waarschuwing over lange paden op, met de melding dat het geen pad van meer dan 256 tekens kon genereren. Ik heb zelf meegemaakt dat de door WBPP uitgevoerde bestanden beschadigd uitkwamen doordat het pad te lang was (omdat het bestand niet kon worden opgeslagen). De oplossing is om in de taakbalk naar regedit te zoeken om de Register-editor te openen, de betreffende plek op te zoeken en de waarde van LongPathsEnabled in 1 te veranderen; na een herstart van PixInsight verschijnt deze waarschuwing niet meer.
Vermijd paden met niet-ASCII-tekens (bijvoorbeeld Chinese). Dit is ook de reden waarom ik afraad om niet-ASCII-tekens, zoals Chinese, in bestandspaden te gebruiken. Als onder Windows het standaardprogramma om een bestand te openen PI is, verschijnt er al bij een dubbelklik op een bestand met een pad dat niet-ASCII-tekens bevat een foutmelding — die onleesbare tekens daarin zijn in werkelijkheid de Chinese tekst. De uitweg is: sleep het bestand, zonder het pad te wijzigen, gewoon rechtstreeks naar PI toe, en het opent.
Als u het bovenstaande aan elkaar legt, wordt het volledige beeld van WBPP grotendeels duidelijk: het is een krachtige geautomatiseerde voorbewerkingsmotor, maar u moet onthouden dat het integratieresultaat slechts een voorvertoning is, weten hoe u de kalibratie groepeert, hoe u de cache goed benut, en wat u moet wissen en welke omgeving u moet instellen voordat u begint. Met de juiste begrippen is de rest slechts een kwestie van routine.