Die Dreiecksgalaxie M33 in LRGB und Hα

M33, die Dreiecksgalaxie, in LRGB mit Hα: 9 Stunden aus vier Nächten im Oktober 2026

Anfang Oktober gab es ein paar mehr oder weniger klare Nächte. Die wollte ich nutzen, um weiter zu üben, wie man Aufnahmesessions mit Ekos plant und durchführt. Für die erste dieser Nächte sah es auf clearoutside.com so aus, als hätte ich vielleicht zwei Stunden klaren Himmel, und ich dachte, ich könnte ja nochmal M33, die Dreiecksgalaxie, fotografieren. Die habe ich 2024 relativ am Anfang meiner Astrofotografie schon mal fotografiert, und 2025 hatte ich schon einmal ein Hα-Layer hinzugefügt. Die Idee für die zwei Stunden der ersten Nacht war also, ein bisschen Luminanz aufzunehmen, etwas Hα und ein bisschen Farbe. Luminanz heißt dabei, dass alle Farben des sichtbaren Lichtes gleichzeitig aufgenommen werden. Das kann man mit den Stäbchen im Auge vergleichen. Eine Schwarzweißkamera, wie ich sie jetzt einsetze, sieht im Wesentlichen alle Farben gleich gut, und Luminanz ist dann die Aufnahme, bei der man die Gesamthelligkeit fotografiert. Dabei trifft deutlich mehr Licht auf die Kamera, als wenn man einen Farbfilter davorsetzt, und somit ist das Bildsignal deutlich besser im Verhältnis zu allen Rauschquellen. Aber ein Schwarzweißbild will ich ja auch nicht haben, daher gibt es auch Aufnahmen mit den drei üblichen Farbfiltern, also Rot, Grün und Blau. Die Gesamtleuchtkraft des Objektes in dem finalen Bild kommt dann also von der Luminanz, die Farbe von den jeweils mit Filtern durchgeführten Aufnahmen. Zusätzlich dazu habe ich aber auch ein paar Bilder mit Hα-Filter aufgenommen. Dieser Filter ist ja vor allem für das Licht des ionisierten Wasserstoffgases da, das man dann im finalen Bild zusätzlich sichtbar machen kann.

Nacht 1 – 02./03.10.

In der ersten Nacht rechnete ich mit ca. 2 Stunden, bevor es zuzieht. Die Idee war dann, die Aufnahmen in zwei Blöcke aufzuteilen. Einmal für die Zeit ohne Mond, und dann für die Zeit mit Mond. Geklappt hat hierbei nur der Block mit Mond, da M33 erst ab ca. halb 10 hinter dem Gebäude hervorkam. Eine Aufnahmesequenz bestand aus 3 L, je 1 R/G/B und 3 Hα. Es gab immer wieder durchziehende Wolken.

Am Ende gab es 26 Subs (9 L, 9 Hα, 3 R, 2 G, 3 B). Ecken-FWHM 4,6–4,9″.

Nacht 2 – 03./04.10.

In der zweiten Nacht waren 100 % Wolkenbedeckung gemeldet, aber für die hohen Wolken, also Cirrus. Und diese Wolken waren überraschend transparent. Die Frage war also: Lohnt trotz Cirrus ein Versuch? Da beim Zusammenrechnen (Stacken) der Bilder die Einzelaufnahmen nach der Qualität des Einzelbildes gewichtet werden, dachte ich, es lohnt sich, einfach weiter Bilder zu sammeln und zu gucken, was am Ende herauskommt. Es gab wieder zwei Blöcke, einmal „M33 Dunkel“ (Sequenz 2 L, je 1 R/G/B, 1 Hα) und „M33 mit Mond“ ab ca. 23 Uhr (je 1 L/R/G/B, 3 Hα).

Dabei war bis 23:00 der Himmel 1,4–1,9× heller als in der Vornacht. Zwischen 00:00 und 02:30 war der Himmel am klarsten, danach war es aber durchgehend bewölkt. In Ekos habe ich dann versucht, die Einstellungen des Rotationsmoduls so vorzunehmen, dass die Kamera nur die 180°-Rotation machen kann, bei der das Filterrad möglichst weit vom Stativ wegbleibt. Dabei musste ich den Rotator erst mal so weit per Hand drehen, dass der Nullpunkt vom Rotationsmodul an der richtigen Stelle ist. Der Rotator wollte nämlich von 270° auf 90° immer über 180° hinweg drehen, was in meinem Fall die falsche Richtung gewesen ist. Den Weg erst über 360° und dann weiter zu 90° mag der Rotator nicht. Also habe ich den Rotator so gedreht, dass zwischen 0° und 180° die Positionen liegen, die sicher angefahren werden können. In INDI ließ sich der CAA-Treiber so einstellen, dass Werte zwischen 210° und 360° nicht mehr angefahren werden dürfen. Wichtig bei einer Aufnahme über mehrere Nächte ist schließlich, dass die Kamera auch immer gleich rotiert ist. Um zu verhindern, dass der Ekos-Scheduler dann um 180° rotiert, weil zum Beispiel nach einem Meridianflip sich das Bild um 180° gedreht hat, wird der zweite Job der Nacht mit einem Rotationswinkel von -181 gestartet. Die -181 steht dabei für NA bzw. --, also dass keine Prüfung des Rotationswinkels stattfinden soll. Dabei finde ich es sehr verwirrend, dass im UI das Löschen der Zahl im Feld für den Rotationswinkel dazu führt, dass es mit 0 aufgefüllt wird, statt dass NA bzw. -- genommen wird. Auf die -181 muss man dafür auch erst mal kommen. Da ich das vor dieser Aufnahmesession nicht wusste, war für den zweiten Job das Align abgeschaltet, damit nicht die Kamera auf eine ungünstige Position gedreht wird. Das wiederum führte dann dazu, dass auch das Neuanfahren des Ziels an einem Punkt scheiterte und ein Großteil der Fotos gar nicht die Dreiecksgalaxie zeigte. In Zukunft stelle ich im Scheduler also wieder für jeden Job das Align ein. Die Rotation wird nur im ersten Job vorgegeben und in den folgenden auf -- gesetzt.

Nacht 3 – 04./05.10.

Aus den Erkenntnissen der ersten beiden Nächte folgte, dass es ein Problem mit dem Autofokus gab, aber es war noch nicht so richtig klar, worin das Problem genau bestand. Jeder Filter hat eine leicht unterschiedliche optische Dicke, daher braucht auch jeder Filter eine leicht andere Position, um die Kamera in den Fokus zu bekommen. Dafür gibt es das Konzept der Filter-Offsets. Also eine gespeicherte Information, wie stark jeder Filter die Fokusposition verschiebt, sodass der Fokusmotor das automatisch ausgleichen kann. Ekos hat dafür eine Funktion Build Filter Offsets. Rot und Hα hatten in der Nacht zuvor nicht so richtig scharfe Aufnahmen, daher ließ ich die Filter-Offsets neu ermitteln. Dazu führt Ekos für jeden Filter fünfmal die Autofokusroutine durch, um einfach ein bisschen Statistik zu haben. Dieser Prozess dauerte ziemlich lange, also etwa 1,5 h. Das lag auch daran, dass Ekos einige Autofokusläufe mehrfach wiederholt hatte, also gar nicht unbedingt nur 5 gemacht hatte, sondern mehr. Das kam daher, dass Ekos nach einem Autofokuslauf die Fokusposition anfährt und nochmal nachschaut, ob das auch wirklich die Fokusposition ist. Und offenbar gab es ein Problem mit dem Fokussierer, was dazu führte, dass am Ende vom Autofokus die angefahrene Position nicht stimmte. Daher kamen mehrere Wiederholungen. Da das Ganze so lange dauerte, habe ich den Build Filter Offsets-Schritt irgendwann abgebrochen, da ich auch gerne aufnehmen wollte. Dabei stieß ich auf einen Bug, den ich irgendwann mal im Simulator nachstellen sollte: Das Abbrechen des Build Filter Offsets schließt das Fenster. Ich kann also nicht abbrechen und dann die gefundenen Werte einfach übernehmen und nur ignorieren, was noch nicht fertig war. Die konnte ich aber nachgucken. Das größere Problem ist gewesen, dass Abbrechen offenbar nur das Fenster geschlossen hat, aber Build Filter Offsets im Hintergrund weiterlief. Beim Versuch, die Aufnahmesession zu starten, haben dann beide Prozesse in Ekos miteinander konkurriert und sich die Aufnahmen weggenommen und die Filter verstellt. Ich musste also einmal alles neu starten. Aufgrund des Problems, dass nach einem Autofokus nicht immer die korrekte Fokusposition getroffen wurde, habe ich sie einmal manuell angefahren und mich den Rest der Nacht auf die Filter-Offsets verlassen.

Die Sequenzen der Blöcke waren dabei „M33 Dunkel“ mit 6 L, je 2 R/G/B, 1 Hα, und „M33 mit Mond“ mit 4 L, 2 G, je 1 R/B und 2 Hα. L und B liegen bewusst vor allem im dunklen Teil der Nacht.

Der Jobwechsel lief diesmal sauber durch, der Meridianflip lief dann auch korrekt und Ekos hat die Dreiecksgalaxie dann wiedergefunden und die Kamera dabei nicht rotiert.

Nacht 4 – 05./06.10.

In dieser Nacht wollte ich endlich genug Bilder sammeln, um das Bild fertigstellen zu können. Dazu musste ich erst mal das Autofokusproblem lösen. Beim Build Filter Offsets gab es ja das Problem, dass manchmal nicht der korrekte Fokuspunkt angefahren wurde. Wenn das mehrfach hintereinander nicht geklappt hat, wertet Ekos das als Autofokus POOR, nimmt die Werte aber in seine Tabelle auf. Ich habe das Problem über ein paar Testläufe analysiert. Dazu habe ich mit einem Messschieber gemessen, wie weit sich die Kamera nach verschiedenen Autofokusläufen relativ zum Teleskop bewegt hat. Dabei hat sich gezeigt, dass unter 300 Schritten vom Autofokus alles ganz okay aussah, aber bei größeren Fahrwegen ein Versatz entstand. Ich hatte die Schrittweite in der vorigen Nacht für jeden Autofokuspunkt von 20 auf 40 Schritte erhöht, dadurch kam es offenbar nach dem Autofokus zu größeren Fahrten als die 300, die dann in einen Versatz mündeten. Eingestellt war in Ekos ein Treiber-Backlash von 158, den ich voriges Jahr mal gemessen hatte. Ekos macht aber zusätzlich ein Überfahren des Ziels um 100 Schritte, um danach immer wieder in die gleiche Richtung gefahren zu sein. Es waren also zwei Backlash-Kompensationsmechanismen aktiv. Und offenbar führte der eingestellte Backlash von 158 dazu, dass sich bei größeren Fahrten der Abstand von Kamera zu Teleskop veränderte, obwohl der Fokussierer immer dieselbe Position gemeldet hatte. Mir ist nicht ganz klar, warum das nur bei größeren Fahrten zu Inkonsistenzen führt, aber den Backlash auf 0 zu stellen, hat geholfen. Das hat nicht nur dazu geführt, dass jeder Autofokuslauf am Ende in der Fokusposition ankam, sondern auch, dass die Fokuskurve deutlich sauberer aussieht und der Autofokus schneller läuft.

Der erste Job „M33 Dunkel“, der diesmal deutlich länger lief (bis halb 2), sah so aus: 3 L, 3 B, 2 G, 1 R, 1 Hα. Und „M33 mit Mond“ sollte den Rest der Nacht laufen, mit 4 Hα, 2 L, 2 R, 1 G, 1 B. Build Filter Offsets habe ich nochmal laufen lassen, es lief deutlich schneller, die Streuung betrug diesmal nur noch 1 bis 6 Schritte vom Fokusmotor, die Nacht davor waren es eher so 20 Schritte. Der erste Job lief dann durch, der Jobwechsel lief auch sauber und der Meridianflip tat, was er sollte. Nachts bin ich einmal wach geworden und habe nur gesehen, dass es gerade bewölkt war, und habe daher den Job beendet und die Montierung geparkt. Dann habe ich aber im Wolkenradar gesehen, dass es nach einer Stunde wieder aufklaren sollte, und habe den Job so eingestellt, dass er eine Stunde später neu startet. Das hat dann nicht geklappt. Der Scheduler hat den Goto zweimal im Abstand von 1 s gesendet, weil nach dem ersten Senden nicht genug Zeit vergangen war, damit der EQMod-Treiber sagen konnte: Ich fahre gerade. Den zweiten Goto-Befehl hat EQMod aber abgelehnt, weil es ja gerade zum Ziel gefahren ist. Das führte dann dazu, dass Ekos den Job auf ERROR gesetzt hat. Laut KStars-Quelltext eine klassische Race Condition zwischen Scheduler-Prüfung und EQMod-Takt. Das ist der zweite Bug, der mir während meiner M33-Sessions aufgefallen ist und den ich noch reporten muss.

Was sich durch alle Nächte zog

Wetter

Keine Nacht war durchgehend klar. Nutzbar waren je etwa 2–4 h. Am dunkelsten war es jeweils um und nach Mitternacht, vorher stand M33 noch relativ tief und da stört der Dunst in der Atmosphäre am meisten.

Ekos

Jede Nacht gab es irgendeine Kleinigkeit in der Bedienung von Ekos, die Probleme bereitete. Einzelne davon lassen sich mit Wissen lösen, andere sind Bugs, die ich nochmal nachstellen und berichten sollte.

Das Ergebnis

Das Ergebnis ist mein erstes echtes LRGB-Bild, in Kombination mit etwas Hα. Dazu musste ich erst mal lernen, wie ich in PixInsight die L-Aufnahmen mit einem RGB-Bild kombinieren kann, aber am Ende war das gar nicht so schwer.

M33, die Dreiecksgalaxie, in LRGB mit Hα: 9 Stunden aus vier Nächten im Oktober 2026

Aufgenommen wurde es mit mehr drumherum. Rotiert und zugeschnitten habe ich es vor allem, damit es etwas interessanter aussieht und besser mit den alten Aufnahmen vergleichbar ist. So sieht das ganze Bildfeld aus:

Das ganze Bildfeld, nicht rotiert

Integrationszeiten

In das Bild sind 180 Einzelaufnahmen mit je 180 s eingegangen, zusammen also genau 9 Stunden. Der größte Teil davon ist Luminanz, bei den Farben liegt Blau vorne, weil ich L und B bevorzugt in die dunklen Stunden ohne Mond gelegt habe.

„Gewichtet effektiv“ ist die Zeit, die PixInsight nach der Gewichtung der Einzelbilder ausrechnet. Aufnahmen durch Cirrus oder bei hellem Mond zählen beim Stacken weniger als die aus den klaren, dunklen Stunden. Von den 9 Stunden bleiben so knapp 5 übrig, also gut die Hälfte. Die Nächte mit Schleierwolken haben sich damit gelohnt, aber eben nur etwa zur Hälfte. Das Rauschen ist die Schätzung von PixInsight für das gestackte Bild des jeweiligen Filters, kleiner ist besser. Luminanz hat mit Abstand den niedrigsten Wert, Hα den höchsten.

Vergleich mit 2024 und 2025

M33 habe ich mit demselben Teleskop und derselben Montierung schon einmal fotografiert, damals aber noch mit der Nikon Z30, also einer normalen Farbkamera. Das erste Bild ist vom November 2024 und besteht aus 54 Aufnahmen mit je 300 s:

Die erste Aufnahme vom November 2024: 54 × 300 s mit der Nikon Z30

2025 habe ich dann ein Hα-Layer aus 50 Aufnahmen mit je 300 s hinzugefügt, aufgenommen durch einen Dualband-Filter (DNB) mit 3 nm:

Die Fassung von 2025 mit zusätzlichem Hα: weitere 50 × 300 s durch einen Dualband-Filter (3 nm)

Die Gesamtbelichtungszeit ist also fast die gleiche, 8 h 40 min damals gegen 9 h jetzt. Trotzdem zeigt das neue Bild deutlich mehr: Die Spiralarme lassen sich viel weiter nach außen verfolgen, im Zentrum sind die dunklen Staubbänder zu erkennen, und die Wasserstoffnebel sind nicht mehr nur rote Flecken, sondern haben Struktur. Bei meinem Hα-Bild von letztem Jahr habe ich den Eindruck, dass das Rot zwar intensiver ist, aber sich nicht so richtig gut in das Farbbild integriert hat.

Der wichtigste Unterschied ist die Kamera. Bei der Farbkamera sitzt vor jedem Pixel ein fester Farbfilter, jedes Pixel sieht also nur Rot, Grün oder Blau. Die Schwarzweißkamera nutzt für jeden Filter alle Pixel, und die Luminanzaufnahmen sammeln das ganze sichtbare Licht auf einmal. Besonders deutlich ist das bei Hα: Auch durch den Dualband-Filter landet das Hα-Licht bei der Farbkamera nur auf jedem vierten Pixel, da das rote Hα-Licht bei den grünen und blauen Pixeln nicht ankommt. Deshalb komme ich jetzt mit rund einem Drittel der Hα-Zeit aus. Dazu kommen die etwas kleineren Pixel, also eine etwas feinere Auflösung bei gleich großem Bildfeld.

Abgesehen von dem Unterschied in der Kamera hat sich auch die Bearbeitung verändert. Das Bild von 2024 habe ich noch mit Siril und GIMP gemacht, und von den 9 Stunden Gesamtbelichtungszeit diesmal zählen wegen Wolken und Mond effektiv nur knapp 5. Dass das Ergebnis trotzdem so viel besser geworden ist, spricht für die Monochromkamera, aber auch für zwei Jahre mehr Übung.