WBPP-probleemoplossing: veelvoorkomende fouten en bekende bugs
Dit artikel is samengesteld uit aantekeningen uit de jaren 2022–2025; sommige gereedschappen of workflows zijn intussen bijgewerkt, dus houd daar rekening mee tijdens het lezen; de foutmeldingen en versiespecifieke gedragingen in de tekst zijn allemaal vastgelegd zoals ze destijds waren. Voor de interface van WBPP, de master-kalibratieframes en het normale uitvoeringsproces verwijs ik u naar het andere artikel “De complete gids voor WBPP”.
WBPP met één klik van begin tot eind laten lopen is beslist een genot, maar wanneer u het echt gebruikt, stuit u altijd op situaties waarin het vastloopt, fouten geeft of resultaten oplevert die gewoonweg niet kloppen. Dit artikel bundelt de categorieën WBPP-problemen die ik de afgelopen jaren ben tegengekomen — en waarover mij het vaakst wordt gevraagd — in een handboek voor foutopsporing, van de diagnostische denkwijze tot een paar concrete bekende bugs.
Eerste stap bij foutopsporing: kijk eerst in de Process Console
Wanneer er iets misgaat bij de verwerking in PixInsight, is het eerste waaraan u altijd moet denken de Process Console bekijken. Die vertelt u waar de fout is opgetreden en om wat voor soort fout het gaat; het is het startpunt van elke diagnose.
WBPP is echter een script, en zolang het script niet draait, wordt de console ingeklapt en kan die niet worden geselecteerd. Om de console te zien, moet u daarom vaak eerst WBPP sluiten. Dat klinkt omslachtig, maar voor veel problemen is het de enige bron van aanwijzingen — de oplossing van enkele van de onderstaande bugs begon telkens bij die ene regel rode tekst in de console.
Mislukkingen en bugs in de kalibratiefase
Kalibratie mislukt (failed) — sluit eerst PI en open het opnieuw. Als bij het uitvoeren van WBPP de eerste kalibratie (die de master-kalibratieframes gebruikt) meteen mislukt en de status een rood “failed” toont, kunt u het hele proces pauzeren, PI sluiten, WBPP opnieuw openen en het nog een keer uitvoeren; deze kalibratiefout verdwijnt dan meestal. Bij het verwerken van OSC-beelden ben ik deze bug minstens vier keer tegengekomen, en elke keer heb ik hem met deze truc opgelost.
Bij flats blijft de kalibratie steeds mislukken — ga terug naar handmatige, stapsgewijze verwerking. Sommige versies van WBPP hebben een bug die de kalibratie van de flats keer op keer laat mislukken. In dergelijke gevallen wordt het belangrijk dat u de zaken zelf stap voor stap handmatig kunt verwerken. Laten we van de gelegenheid gebruikmaken om de stappen van de Pre-Process nog eens door te nemen:
- Calibration:
light − dark / ((flat − flat dark) * med(flat)) - Cosmetic Correction
- Debayer: interpoleren over de Bayer-matrix
- Star Alignment
- NSG
- Integration
Wanneer u niet op de automatisering kunt vertrouwen, maakt het opdelen van het proces en het handmatig uitvoeren ervan het juist gemakkelijker om vast te stellen in welke stap het probleem zit.
Padproblemen: twee mogelijke oorzaken van een File I/O Error
Als bij het gebruik van WBPP onder Windows de kalibratiefase (calibration) een File I/O Error oplevert, ligt dat meestal aan een van deze twee oorzaken:
- Het bestandspad plus de bestandsnaam is te lang en overschrijdt de systeemlimiet, dus het moet worden ingekort.
- Naar de doelmap kan niet worden geschreven, bijvoorbeeld als u de uitvoer in een systeemmap instelt.
De eerste is de meest voorkomende. Om “pad te lang” bij de wortel te verhelpen, kunt u onder Windows de ondersteuning voor lange paden inschakelen (zet in regedit LongPathsEnabled op 1); daarnaast is het raadzaam paden met niet-ASCII-tekens (bijvoorbeeld Chinese) te vermijden. De gedetailleerde handelingen voor deze twee omgevingsvoorwaarden heb ik beschreven in de sectie over de Windows-omgevingsinstellingen van “De complete gids voor WBPP”, dus ik herhaal ze hier niet.
De RA/DEC-coördinatenbug “60 seconden niet overgedragen”
Dit is het meest lastige probleem, en tegelijk het probleem dat het meest de moeite waard is om apart te behandelen, want de symptomen zijn buitengewoon uiteenlopend, maar de grondoorzaak is steeds dezelfde: in de FITS Header hebben de coördinaten voor rechte klimming / declinatie een secondewaarde van “60” die nooit naar de volgende plaats is overgedragen.
Ik ben het twee keer tegengekomen, elke keer met een andere verschijningsvorm.
De eerste keer: WBPP kon het bestand niet laden. Ik sloot WBPP en ging in de Process Console kijken, en ontdekte dat een bepaalde regel van een js-script “invalid coordinates” meldde. Op dat moment dacht ik dat het een bug van WBPP was; ik nam de foutmelding en zocht die op internet op, en pas toen vond ik op het PixInsight Forum enkele identieke foutmeldingen — het bleek dat het coördinatenprobleem verhinderde dat de foto in WBPP werd geladen. Met een richting om te volgen kostte het me toch een uur om enkele honderden lights (lichtframes) door te spitten voordat ik de problematische foto opspoorde: de OBJCTDEC-coördinaat ervan klopte niet. Ik opende in PI het FITSHeader-proces, scrolde naar OBJCTDEC en wijzigde de waarde die “overgedragen had moeten worden maar dat niet was” — in dit voorbeeld veranderde ik -69 26 60 in -69 27 0 — en dit frame laadde toen probleemloos, en de bestanden erachter werden er niet langer door opgehouden.
De tweede keer: bestanden lieten zich niet toevoegen en de console meldde too much recursion. Later stuitte ik er opnieuw op: bij het toevoegen van bestanden aan WBPP liep de software vast en werd uiteindelijk helemaal geen bestand toegevoegd. Ik sloot WBPP en zag, toen ik in de Console keek, een rode InternalError: too much recursion. Nadat ik WBPP opnieuw had geopend, merkte ik dat een deel van de bestanden al was geladen en een deel niet; toen ik de niet-geladen bestanden controleerde, was het inderdaad opnieuw een FITS Header-afwijking — deze keer toonde DEC -46 01 60, waarbij de seconden “60” hadden moeten worden overgedragen naar -46 02 00. Zodra WBPP zo’n afwijkende waarde leest, loopt het vast, en bovendien sleept het alle volgende beelden mee, zodat ook die niet meer kunnen laden. Op dezelfde manier opende ik de FITS Header en droeg ik de seconden met de hand over; nadat ik dit had gecorrigeerd, voegde ik de bestanden opnieuw toe en werkte het. Wanneer alle bestanden met succes laden, laat WBPP automatisch een diagnostisch bericht verschijnen, bijvoorbeeld “60 of 60 light frames were added”.
Een gemeenschappelijke conclusie: dit probleem dat coördinaten niet automatisch worden overgedragen, heeft zich in vrijwel alle gevallen die ik tot nu toe heb gezien voorgedaan wanneer MDL (afstandsbediening) de opnamesoftware was, al kan ik niet uitsluiten dat andere opnamesoftware hetzelfde gebrek vertoont. Dus telkens wanneer WBPP vastloopt en bestanden zich niet laten toevoegen, raadpleeg eerst de Process Console om het type fout vast te stellen en controleer daarna of de RA/DEC-Header de bug “60 seconden niet overgedragen” vertoont; na een handmatige correctie is het meestal opgelost.
Prestaties: waarom het grote complete pakket zo lang duurt
Tot slot een probleem dat strikt genomen geen “fout” is, maar niettemin een kwelling — het grote complete pakket van WBPP is simpelweg te traag. Ik heb ooit het complete pakket wel vier volle uren laten draaien voor vijf beelden waarvan ik een HDR wilde maken (de machine was destijds een AMD R5-4650G, DDR4 3200 32GB, Gen4 SSD, met beelden van 24 megapixel; zo’n wachttijd geeft je echt zin om een nieuwe computer te kopen).
Twee plekken slokken daarbij vooral tijd op:
- Separated RGB: de RGB-kanalen van een kleurenfoto apart verwerken om chromatische aberratie te elimineren.
- Local Normalization: de beste paar beelden als referentie kiezen en op de overige beelden Local Normalization toepassen.
Als u deze twee uitschakelt, wordt WBPP veel sneller. Of het de moeite waard is deze twee voor de snelheid op te offeren, hangt af van uw eisen aan het eindresultaat — over de concrete metingen van “welke stappen uit te schakelen, hoeveel tijd u bespaart en hoeveel kwaliteit u verliest” heb ik in “De complete gids voor WBPP” een set gegevens die een versnelling van 7 tot 8 keer laat zien en waarnaar u kunt verwijzen.
Laten we de denkwijze van dit handboek voor foutopsporing samenvatten: als er iets misgaat, kijk eerst in de Process Console; mislukt de kalibratie (failed), sluit dan PI en open het opnieuw; blijven de flats de kalibratie mislukken, ga dan terug naar handmatige, stapsgewijze verwerking; een File I/O Error is meestal een te lang pad of een map waarin niet kan worden geschreven; en als dingen niet laden, vastlopen of recursion melden, ga dan controleren of de RA/DEC in de FITS Header een secondewaarde van 60 heeft die niet is overgedragen. Beheerst u deze paar trucs goed, dan kunt u de meeste kuren van WBPP aan.