25. Juli 2026  ·  🔭 Astronomie 🖥️ Technologie

Sieben Filter, ein Knopfdruck – wie ich Mono-Bildbearbeitung mit einem eigenen Siril-Skript gelernt habe

Warum eine Farbkamera einfach ist – und eine Mono-Kamera nicht

Eine normale Astrokamera, eine sogenannte OSC (One Shot Color), macht es einem leicht. Über ihrem Sensor sitzt ein winziges Farbfiltermuster, die Bayer-Matrix: Jedes Pixel bekommt fest zugeteilt, ob es Rot, Grün oder Blau sieht. Eine Aufnahme, alle Farben drin, fertig. Genau so funktioniert das Seestar – und genau deshalb ist es so ein wunderbares Einsteigergerät.

Der Preis dafür: Jedes Pixel sieht nur ein Drittel der Farbinformation, den Rest muss die Software interpolieren. Eine Monochrom-Kamera hat dieses Muster nicht. Sie sieht schlicht Helligkeit – dafür aber mit jedem einzelnen Pixel und in voller Auflösung. Die Farbe kommt stattdessen von außen: durch ein Filterrad, das nacheinander verschiedene Filter vor den Sensor dreht.

Das ist optisch die sauberere Lösung. Es bedeutet aber auch: Man fährt nicht mehr einen Datensatz nach Hause, sondern mehrere. Einen pro Filter. Und die müssen am Ende pixelgenau übereinanderliegen, sonst hat das fertige Bild Farbsäume.

Sieben Filter, und die Rechnung wird unangenehm

In meinem Rig in Texas sitzt eine Player One Ares-M Pro – ein IMX533 in Mono – hinter einem ZWO-Filterrad mit acht Plätzen. Belegt sind sieben: das Schmalband-Trio SII, Ha und OIII von Antlia mit 4,5 nm Bandbreite, dazu Luminanz, Rot, Grün und Blau.

Sieben Filter bedeuten: verdammt viele verschiedene Stapel Rohbilder aus einer einzigen Nacht. Jeder davon will kalibriert werden – mit den passenden Darks, Flats und Bias. Jeder will registriert und gestackt werden. Danach müssen die fertigen Master untereinander ausgerichtet werden, denn zwischen dem Ha-Stack und dem OIII-Stack liegen Stunden, in denen sich das Feld leicht verschoben hat. Erst dann kann man drei davon zu einem Farbbild kombinieren. Und dann sollte man das Ergebnis noch farbkalibrieren, damit die Farben nicht geraten sind, sondern gemessen.

Ich habe das nicht durch schmerzhafte Erfahrung gelernt. Ich habe es beim Lesen gelernt. Ich saß vor einer dieser gründlichen How-to-Anleitungen, wie man das in Siril macht, bin die Schritte durchgegangen – und irgendwann wurde mir klar, wie viele Menüs, Dialoge und Klicks das pro Nacht sind. Multipliziert mit sieben Kanälen. Bei jedem einzelnen davon kann man etwas vergessen oder vertauschen.

An dieser Stelle sollte ich etwas über mich sagen: Ich bin ungeduldig. Ich will Dinge auf Knopfdruck, und wenn etwas mehr als zweimal gleich abläuft, denke ich unwillkürlich darüber nach, wie man es automatisiert. Das ist beruflich eine nützliche Eigenschaft und im Hobby manchmal eine anstrengende.

Der ungewöhnliche Umweg: erst programmieren, dann verstehen

Der normale Weg wäre gewesen: Anleitung schmökern, ein paar Nächte durchklicken, Routine aufbauen, irgendwann versteht man es. Ich bin einen anderen gegangen – und zwar nicht aus Angeberei, sondern weil ich so nun mal lerne.

Wenn ich etwas programmiere, muss ich es vollständig verstanden haben. Beim Klicken kann man einem Menüpunkt folgen, ohne zu wissen, warum. Beim Programmieren geht das nicht: Man muss entscheiden, wann welcher Rejection-Algorithmus der richtige ist, welche Kalibrierungsdatei zu welchem Frame passt, was passieren soll, wenn etwas fehlt. Jede dieser Entscheidungen zwingt einen, das Thema wirklich zu durchdringen.

Also habe ich mir mein Werkzeug selbst gebaut: Svenesis ImageMono Train. Ein Python-Skript für Siril, das eine komplette Nacht Mono-Daten von der Rohaufnahme bis zum farbkalibrierten Bild bringt. Und dabei jeden Schritt protokolliert – nicht zuletzt, damit ich selbst nachlesen kann, was da eigentlich passiert ist.

Drei Dinge, die ich dabei wirklich gelernt habe

Aus dem, was das Skript heute tut, greife ich drei Punkte heraus – weil ich an genau diesen drei Stellen am meisten verstanden habe.

1. Es gibt nicht den einen richtigen Stacking-Algorithmus. Beim Stacken muss man Ausreißer verwerfen – Satellitenspuren, kosmische Strahlung, ein Flugzeug. Dafür gibt es verschiedene Verfahren, und ich dachte anfangs, man sucht sich eines aus und bleibt dabei. Falsch. Die Verfahren brauchen unterschiedlich viele Bilder, um überhaupt sinnvoll zu funktionieren: Bei vier Bildern ist ein Sigma-Verfahren statistisch blind, bei fünfzig ist ein simples Verfahren Verschwendung. Mein Skript entscheidet das deshalb pro Filter – Percentile Clipping bei bis zu vier Frames, Winsorized Sigma bis zwanzig, Linear Fit bis knapp fünfzig, darüber GESDT. Und – das ist der Teil, der mich am meisten Nachdenken gekostet hat – es zählt dabei die tatsächlich brauchbaren Frames, nicht die aufgenommenen. Ein Kanal, dem Wolken die Hälfte weggefressen haben, ist eben ein kleiner Stack, auch wenn ursprünglich vierzig Bilder da waren.

Wie praxisnah das ist, zeigte sich gleich in der Nacht auf M 16, den Adlernebel: Ha lieferte sechs brauchbare Bilder und bekam Winsorized Sigma. Bei OIII scheiterte die Registrierung an drei von sechs Bildern – zu wenige erkennbare Sterne, Wolken oder Dunst. Übrig blieben drei. Das Skript hat daraufhin für diesen einen Kanal auf Percentile Clipping umgeschaltet und im Bericht dazugeschrieben, dass drei Bilder für eine sinnvolle Ausreißer-Erkennung eigentlich zu wenig sind und der Kanal als vorläufig zu behandeln ist. Genau diese Art Hinweis hätte ich mir beim Klicken selbst nie gegeben.

2. Farbsäume entstehen nicht bei der Farbe, sondern beim Ausrichten. Das war meine erste echte Nervenprobe beim Bauen. Jeder Kanal wird für sich gestackt – und jeder landet dabei auf einem minimal anderen Pixelraster, weil sich das Feld zwischen den Aufnahmereihen gedreht und verschoben hat. Kombiniert man die drei Master naiv, bekommt man bunte Ränder an jedem Stern. Die Lösung ist, alle Master noch einmal gemeinsam zu registrieren und auf die gemeinsame Schnittmenge zu projizieren – in Siril mit -framing=min. Klingt nach einer Zeile, hat mich aber lange beschäftigt: Weil dabei zugeschnitten wird, passen später erzeugte Master nicht mehr zu früheren. Mein Skript erkennt das inzwischen und verweigert das Mischen, statt ein kaputtes Bild zu produzieren.

3. Farbkalibrierung ist Physik, keine Geschmackssache. Sirils Spectrophotometric Color Calibration vergleicht die Sterne im Bild mit einem Katalog und rechnet die echten Farben aus. Damit das funktioniert, muss sie wissen, wie empfindlich der Sensor bei welcher Wellenlänge ist und was die Filter durchlassen. Hier lauert eine Falle, die mich eine gute Stunde gekostet hat: Mein IMX533 taucht in Sirils Sensorliste nur als Farbversion auf. Die Mono-Variante steht dort unter einem ganz anderen Namen, zusammengefasst mit verwandten Sensoren. Trug man den falschen ein, lief alles durch – nur die Farben stimmten nicht. Deshalb prüft mein Skript den Namen heute vor dem Lauf und sagt Bescheid, statt einen still danebenliegen zu lassen. Bei Schmalband rechnet es mit den echten Emissionslinien: Ha bei 656,3 nm, OIII bei 500,7 nm, SII bei 671,6 nm.

Was am Ende herauskommt

Man zeigt dem Skript einen Ordner – bei mir landen die Daten dort automatisch, weil der Rig-PC in Texas sie per Dropbox nach Hause schiebt. Das Skript liest alle FITS-Header, gruppiert die Bilder nach Filtern, zeigt einen Bericht, was es gefunden hat, und legt dann los. Am Ende liegen die ausgerichteten Master pro Kanal da, dazu das fertige Farbkomposit – wahlweise als LRGB, SHO, HOO oder HaRGB.

Zwei Dateien sind mir dabei besonders wichtig geworden. In output.md steht, was tatsächlich passiert ist: welcher Kanal welchen Algorithmus bekommen hat, welche Kalibrierung angewendet wurde, wo etwas übersprungen wurde und warum. In todo.md steht, was ich jetzt von Hand tun sollte – mit den konkreten Menüpfaden in Siril.

Diese Berichte sind absichtlich unbestechlich. Sie beschreiben nicht den Normalfall, sondern den echten Fall. Wenn ein Filter übersprungen wurde, steht das da. Wenn die Farbkalibrierung auf eine schlechtere Methode zurückgefallen ist, steht das da. Wenn ein Kanal die Hälfte seiner Bilder verloren hat, steht das da – im M-16-Bericht etwa als nüchterne Tabellenzeile: OIII, 6 gefunden, 3 gestackt, 15 Minuten Integration. Nichts wird schöngerechnet – ich will schließlich lernen und nicht getröstet werden.

Dass die Berichte so sind, war übrigens Arbeit. Ein ganzer Schwung Änderungen der aktuellen Version betraf ausschließlich diesen Punkt: Ein Lauf ohne fertiges Komposit liest sich nicht mehr, als hätte er eines. Eine übersprungene Kalibrierung heißt nicht mehr „kalibriert“. Und es wird nie zu einer Einstellung geraten, die gar nicht die Ursache war. Ein Bericht, dem man nicht trauen kann, ist nämlich schlimmer als gar keiner – dann sucht man den Fehler an der falschen Stelle.

Zwei Tage, 7.000 Zeilen – und ein KI-Gespräch

Jetzt der Teil, den ich nicht verschweigen will: Ich habe das nicht allein geschrieben. Das Skript ist mit Claude Code entstanden, in einem langen, iterativen Dialog – genau wie beim Guiding-Debugging neulich, nur diesmal über zwei volle Tage.

Das Grundgerüst stand nach zehn Minuten. Das lag weniger an der KI als daran, dass ich vorher schon eine ganze Reihe anderer Siril-Skripte gebaut hatte – die Struktur, die Anbindung an Siril, das Oberflächengerüst, all das war eingespielt. Die restlichen knapp zwei Tage waren nicht Tippen, sondern Denken und Testen: echte Daten durchlaufen lassen, sehen, was schiefgeht, verstehen warum, reparieren. Wieder und wieder.

Herausgekommen sind rund 7.300 Zeilen Python. Das hätte ich allein nicht in zwei Tagen geschafft – vermutlich in Wochen nicht, weil ich an vielen Stellen erst hätte recherchieren müssen, was Siril überhaupt anbietet. Die KI war dabei genau das, was sie schon beim Guiding war: kein Orakel, sondern ein sehr geduldiger Gesprächspartner, der erklärt und vorschlägt. Entschieden habe ich. Und getestet auch – das nimmt einem niemand ab.

Der eigentliche Ertrag

Das Skript nimmt mir jetzt das ganze Geklicke ab – eine Nacht Daten, ein Knopfdruck, und der Rechner erledigt den Rest, während ich etwas anderes mache. Aber das ist nicht der Teil, über den ich mich am meisten freue.

Der eigentliche Ertrag ist, dass ich Mono-Bildbearbeitung inzwischen verstehe. Ich weiß, warum ein kleiner Stack ein anderes Rejection-Verfahren braucht. Ich weiß, woher Farbsäume kommen und warum sie kein Farbproblem sind. Ich weiß, was eine Farbkalibrierung eigentlich misst. Nichts davon habe ich gelernt, weil ich es nachgeklickt hätte – sondern weil ich es einem Computer erklären musste.

Das ist, glaube ich, der unterbewertete Nebeneffekt vom Automatisieren: Man muss ein Thema erst wirklich durchdringen, bevor man es abgeben kann. Wer sich das Klicken spart, hat nichts gelernt. Wer sich das Klicken wegprogrammiert, hat es zwangsläufig verstanden.

Und das nächste Mal, wenn eine Nacht aus Texas ankommt, drücke ich einfach auf den Knopf.