WBPP-Fehlerbehebung: Häufige Fehler und bekannte Bugs
Dieser Artikel ist aus Notizen der Jahre 2022–2025 zusammengestellt; einige Werkzeuge oder Arbeitsabläufe wurden inzwischen aktualisiert, behalte das beim Lesen also im Hinterkopf. Die im Text genannten Fehlermeldungen und versionsspezifischen Verhaltensweisen sind alle so festgehalten, wie sie damals waren. Für die Oberfläche von WBPP, die Master-Kalibrierungsframes und den normalen Ablauf sieh bitte im Schwesterartikel „WBPP – der komplette Leitfaden“ nach.
WBPP mit einem einzigen Klick von Anfang bis Ende durchlaufen zu lassen ist zwar ein Genuss, aber sobald man es wirklich einsetzt, stößt man immer wieder auf Situationen, in denen es hängen bleibt, Fehler wirft oder Ergebnisse liefert, die einfach nicht stimmen. Dieser Artikel fasst die Kategorien von WBPP-Problemen, die mir in den letzten Jahren begegnet sind – und nach denen ich am häufigsten gefragt werde –, zu einem Handbuch für die Fehlersuche zusammen: von der Diagnose-Denkweise bis hin zu ein paar konkreten bekannten Bugs.
Erster Schritt der Fehlersuche: zuerst die Process Console ansehen
Wenn bei der Verarbeitung in PixInsight etwas schiefgeht, ist das Erste, woran du immer denken solltest, einen Blick in die Process Console zu werfen. Sie sagt dir, wo der Fehler aufgetreten ist und um welche Art von Fehler es sich handelt; sie ist der Ausgangspunkt jeder Diagnose.
WBPP ist allerdings ein Skript, und solange das Skript nicht läuft, wird die Console eingeklappt und lässt sich nicht auswählen. Um die Console zu sehen, musst du daher oft zuerst WBPP schließen. Das klingt umständlich, ist aber bei vielen Problemen die einzige Quelle für Hinweise – die Lösungen für einige der folgenden Bugs begannen allesamt mit jener einen Zeile roten Textes in der Console.
Fehlschläge und Bugs in der Kalibrierungsphase
Kalibrierung fehlgeschlagen (failed) – schließe zuerst PI und öffne es neu. Wenn beim Ausführen von WBPP schon die erste Kalibrierung (mit den Master-Kalibrierungsframes) sofort fehlschlägt und der Status ein rotes „failed“ zeigt, kannst du den ganzen Ablauf anhalten, PI schließen, WBPP erneut öffnen und noch einmal ausführen; dieser Kalibrierungsfehler verschwindet dann meist. Bei der Verarbeitung von OSC-Bildern bin ich diesem Bug mindestens vier Mal begegnet, und jedes Mal habe ich ihn mit diesem Trick gelöst.
Flats scheitern ständig an der Kalibrierung – zurück zur manuellen, schrittweisen Verarbeitung. Manche Versionen von WBPP haben einen Bug, der die Flat-Kalibrierung immer wieder fehlschlagen lässt. In solchen Fällen wird es wichtig, dass man die Dinge selbst Schritt für Schritt manuell verarbeiten kann. Wiederholen wir bei dieser Gelegenheit gleich die Schritte des Pre-Process:
- Calibration:
light − dark / ((flat − flat dark) * med(flat)) - Cosmetic Correction
- Debayer: über die Bayer-Matrix interpolieren
- Star Alignment
- NSG
- Integration
Wenn man sich auf die Automatik nicht verlassen kann, lässt sich durch das Zerlegen des Ablaufs und manuelles Durchlaufen sogar leichter feststellen, in welchem Schritt das Problem steckt.
Pfadprobleme: zwei mögliche Ursachen für einen File I/O Error
Wenn beim Einsatz von WBPP unter Windows in der Kalibrierungsphase (calibration) ein File I/O Error auftaucht, liegt das meist an einer dieser beiden Ursachen:
- Der Dateipfad plus Dateiname ist zu lang und überschreitet das Systemlimit, muss also gekürzt werden.
- In den Zielordner kann nicht geschrieben werden, etwa wenn du die Ausgabe in einen Systemordner legst.
Die erste ist die häufigste. Um „Pfad zu lang“ dauerhaft zu beheben, kannst du unter Windows die Unterstützung langer Pfade aktivieren (im Registrierungs-Editor LongPathsEnabled auf 1 setzen); außerdem ist es ratsam, Pfade mit nicht-westeuropäischen (etwa chinesischen) Zeichen zu vermeiden. Die genauen Schritte für diese beiden Umgebungs-Voraussetzungen habe ich im Abschnitt zur Windows-Umgebungseinrichtung von „WBPP – der komplette Leitfaden“ beschrieben, deshalb wiederhole ich sie hier nicht.
Der RA/DEC-Koordinaten-Bug „60 Sekunden nicht übertragen“
Das ist das kniffligste Problem und zugleich dasjenige, das es am meisten wert ist, gesondert behandelt zu werden, denn seine Symptome sind höchst unterschiedlich, die Grundursache aber ist stets dieselbe: Im FITS-Header hat die Rektaszensions-/Deklinationskoordinate einen Sekundenwert von „60“, der nie in die nächste Stelle übertragen wurde.
Ich bin ihm zweimal begegnet, jedes Mal mit anderem Erscheinungsbild.
Das erste Mal: WBPP konnte die Datei nicht laden. Ich schloss WBPP und sah in die Process Console, und fand, dass irgendeine Zeile eines js-Skripts „invalid coordinates“ meldete. Damals nahm ich an, es sei ein Bug von WBPP, nahm die Fehlermeldung und suchte online danach, und erst dann fand ich im PixInsight Forum mehrere identische Fehlermeldungen – es stellte sich heraus, dass das Koordinatenproblem das Laden des Bildes in WBPP verhinderte. Mit einer Richtung im Kopf brauchte ich trotzdem eine Stunde, um mich durch mehrere Hundert Light-Frames zu wühlen, bis ich das problematische Bild aufspürte: Seine OBJCTDEC-Koordinate war falsch. Ich öffnete in PI den FITSHeader-Prozess, scrollte zu OBJCTDEC und änderte den Wert, der „hätte übertragen werden müssen, es aber nicht wurde“ – in diesem Beispiel änderte ich -69 26 60 zu -69 27 0 –, und dieser Frame lud dann problemlos, und die nachfolgenden Dateien wurden nicht länger von ihm aufgehalten.
Das zweite Mal: Dateien ließen sich nicht hinzufügen, und die Console meldete too much recursion. Später stieß ich erneut darauf: Beim Hinzufügen von Dateien zu WBPP fror die Software ein, und am Ende wurde überhaupt keine Datei hinzugefügt. Ich schloss WBPP und sah in die Console, und da stand ein rotes InternalError: too much recursion. Nach dem Neuöffnen von WBPP stellte ich fest, dass ein Teil der Dateien geladen war und ein Teil nicht; als ich die nicht geladenen prüfte, war es tatsächlich wieder eine FITS-Header-Anomalie – diesmal zeigte DEC -46 01 60, wobei die Sekunden „60“ zu -46 02 00 hätten übertragen werden müssen. Sobald WBPP einen solchen fehlerhaften Wert liest, friert es ein und reißt zudem alle nachfolgenden Bilder mit, sodass auch sie nicht mehr laden. Ich öffnete wieder den FITS-Header, übertrug die Sekunden manuell, und nachdem ich das behoben hatte, fügte ich die Dateien erneut hinzu und es funktionierte. Wenn alle Dateien erfolgreich laden, blendet WBPP automatisch eine Diagnosemeldung ein, zum Beispiel „60 of 60 light frames were added“.
Eine gemeinsame Schlussfolgerung: Dieses Problem, dass Koordinaten nicht automatisch übertragen werden, ist in fast allen Fällen, die ich bisher gesehen habe, aufgetreten, wenn MDL (Fernsteuerung) die Aufnahmesoftware war, wobei ich nicht ausschließen kann, dass andere Aufnahmesoftware denselben Fehler hat. Wann immer WBPP also einfriert und sich keine Dateien hinzufügen lassen, prüfe zuerst in der Process Console die Art des Fehlers und kontrolliere dann, ob der RA/DEC-Header den Bug „60 Sekunden nicht übertragen“ aufweist; nach einer manuellen Korrektur ist es meist behoben.
Leistung: warum das große Komplettpaket so lange braucht
Zum Schluss ein Problem, das streng genommen kein „Fehler“ ist, aber dennoch quälend – das große WBPP-Komplettpaket ist schlicht zu langsam. Ich habe einmal das Komplettpaket ganze vier Stunden für fünf Bilder laufen lassen, aus denen ich ein HDR machen wollte (die Maschine war damals ein AMD R5-4650G, DDR4 3200 32GB, Gen4 SSD, bei 24-Megapixel-Bildern; bei so einer Wartezeit will man wirklich einen neuen Rechner kaufen).
Zwei Stellen fressen dabei besonders viel Zeit:
- Separated RGB: Die RGB-Kanäle eines Farbfotos werden getrennt verarbeitet, um chromatische Aberration zu beseitigen.
- Local Normalization: Man wählt die besten paar Bilder als Referenz und führt an den übrigen eine Local Normalization durch.
Wenn du diese beiden deaktivierst, wird WBPP sehr viel schneller. Ob es sich lohnt, diese beiden für die Geschwindigkeit zu opfern, hängt von deinen Ansprüchen an das Endergebnis ab – für konkrete Messungen dazu, „welche Schritte man abschaltet, wie viel Zeit man spart und wie viel Qualität man verliert“, habe ich in „WBPP – der komplette Leitfaden“ einen Datensatz, der eine 7- bis 8-fache Beschleunigung zeigt und auf den du zurückgreifen kannst.
Fassen wir die Denkweise dieses Fehlersuche-Handbuchs zusammen: Wenn etwas schiefgeht, sieh zuerst in die Process Console; schlägt die Kalibrierung fehl, schließe PI und öffne es neu; scheitern die Flats ständig an der Kalibrierung, geh zurück zur manuellen, schrittweisen Verarbeitung; ein File I/O Error ist meist ein zu langer Pfad oder ein Ordner, in den nicht geschrieben werden kann; und wenn Dinge nicht laden, einfrieren oder recursion melden, kontrolliere, ob RA/DEC im FITS-Header einen Sekundenwert von 60 hat, der nicht übertragen wurde. Beherrschst du diese paar Kniffe, wirst du mit den meisten Launen von WBPP fertig.