3. August 2026  ·  🔭 Astronomie

Passt eigentlich meine Kamera zum Teleskop? Über- und Untersampling – und was Drizzle wirklich bringt

Mein Rig in Texas habe ich gebraucht übernommen, und beim Einarbeiten stolperte ich über eine Stacking-Option namens Drizzle: ein Verfahren, das aus vielen leicht gegeneinander versetzten Aufnahmen (Dithering) ein feineres Bild rechnet, als jede einzelne davon hergibt. Nachgelesen – und darüber beim Thema Sampling gelandet. Denn Drizzle hilft nur, wenn man untersampled ist – und damit stand eine Frage im Raum, die ich mir nie gestellt hatte.

Passt die Pixelgröße meiner Kamera eigentlich zur Brennweite meines Teleskops?

Ich rechne es hier für mein Rig durch (William GT81 blue + 0,8×-Reducer + Ares-M Pro mit IMX533, Standort Starfront in Texas) und komme dann zurück zu Drizzle.

Zwei Zahlen – und ihr Verhältnis

Das ganze Thema hängt an zwei Größen.

Die erste: Wie viel Himmel sieht ein einzelnes Pixel? Das sagt der Abbildungsmaßstab in Bogensekunden pro Pixel (″/px). Zur Größenordnung: Der Vollmond ist rund 1800 Bogensekunden breit – bei 2 ″/px reicht er also über 900 Pixel.

Die krumme Konstante ist reine Einheitenumrechnung: Pixelgröße geteilt durch Brennweite ergibt einen Winkel im Bogenmaß, und ein Bogenmaß sind 206 265 Bogensekunden – noch durch 1000 geteilt, weil Mikrometer gegen Millimeter stehen.

Die zweite: Wie breit ist ein Stern im Bild? Ein Stern ist so weit weg, dass er eigentlich ein reiner Punkt sein müsste. Im Bild wird trotzdem ein kleines Scheibchen daraus, weil drei Dinge ihn verschmieren: die Luftunruhe (Seeing), Ungenauigkeiten der Nachführung (Guiding) und die Optik selbst. Die Breite dieses Scheibchens misst man als FWHM – Full Width at Half Maximum, also die Breite auf halber Höhe: Man schaut, wo der Stern nur noch halb so hell ist wie in seiner Mitte, und misst dort seinen Durchmesser. Das ist robuster, als den Rand zu suchen, denn der verläuft ohnehin ins Nichts.

Sampling ist das Verhältnis dieser beiden Zahlen: Man teilt die Sternbreite durch den Abbildungsmaßstab und weiß, über wie viele Pixel sich ein Stern erstreckt. Und hier wird es eng: Der Vollmond von eben füllt 900 Pixel – ein Stern ist dagegen nur wenige Bogensekunden breit. Bei typischen 3″ und 2 ″/px bleiben ganze anderthalb Pixel.

Drei Fälle

• Ein bis zwei Pixel pro Sternbreite – untersampled. Der Stern fällt auf so wenige Pixel, dass seine Form gar nicht mehr abgebildet wird. Feine Details gehen verloren, obwohl das Teleskop sie geliefert hätte.
• Zwei bis drei Pixel – der Sweetspot. Genug Messpunkte, um die Sternform sauber wiederzugeben, ohne das Licht unnötig zu verteilen.
• Deutlich mehr – übersampled. Schärfer wird das Bild dadurch nicht, denn die Grenze liegt längst woanders: bei Seeing und Optik, nicht beim Pixelraster. Dasselbe Licht verteilt sich nur auf mehr Pixel – jedes einzelne bekommt weniger ab, und man muss länger belichten.

Wie viele Pixel genau? Darüber wird gestritten

Am häufigsten zitiert wird Nyquist: zwei Pixel pro Sternbreite. Bei starker Vergrößerung sieht man dabei allerdings noch die Pixeltreppen am Sternrand; für ein glattes Profil werden eher drei bis dreieinhalb empfohlen. Mit der Rundheit eines Sterns hat das übrigens nichts zu tun – die entscheiden Fokus und Guiding.

Dagegen steht eine ernstzunehmende Gegenposition: Wer bewusst untersampelt bleibt, sammelt dasselbe Licht auf weniger Pixeln und verbessert damit das Signal-Rausch-Verhältnis. Übersampling kostet umgekehrt Signal, ohne jenseits der Seeing-Grenze Auflösung zu bringen.

Kurz gesagt: Zwei Pixel sind das Minimum, drei sind komfortabel – und wer auf Signal optimiert, darf bewusst darunter bleiben. Das ist kein Grenzwert, den man einhalten muss, sondern eine Entscheidung.

Mein Beispiel: William GT81 blue + 0,8×-Reducer + Ares-M Pro

Rechnen wir's konkret:

• William GT81 blue nativ 478 mm, mit 0,8×-Reducer-Flattener → 382 mm (f/4,72).
• Ares-M Pro / IMX533: Pixelgröße 3,76 µm.
• Abbildungsmaßstab = 206,265 × 3,76 ÷ 382 = 2,03 ″/px.
• Bildfeld: 3008 Pixel × 2,03 ″/px = 6110″ → rund 1,7° × 1,7°.

Und wo lande ich damit? Starfront in Texas ist extrem dunkel (Bortle 1, SQM 21–22) und seeing-technisch gut – meist 1,5 bis 2,5″, an Top-Nächten bis etwa 1″. Dazu kommen die Nachführung und die Beugungsgrenze meiner 81-mm-Öffnung – die physikalische Untergrenze, die jede Optik hat und die bei dieser Größe allein schon rund 1,4″ ausmacht. Solche Unschärfen addieren sich allerdings nicht einfach, sondern quadratisch: Der größte Beitrag dominiert, kleinere fallen kaum ins Gewicht. Unterm Strich komme ich auf eine gelieferte Sternbreite von geschätzt 2,3 bis 3″ – geteilt durch 2,03 ″/px also 1,1 bis 1,5 Pixel. Für zwei Pixel bräuchte ich 4,06″.

Die Messung, die bisher fehlte

Alles bisher Gerechnete steht auf einer geschätzten Zahl: dem Seeing. „1,5 bis 2,5 Bogensekunden in Texas“ ist eine Standortangabe, keine Messung an meinem Bild. Solange ich die gelieferte Sternbreite nicht kenne, bleibt mein „untersampled“ eine Vermutung.

Also messe ich nach. Dafür braucht es einzelne Subs, also einzelne Rohaufnahmen – nicht das gestackte Endergebnis, denn Stacken und Ausrichten verändern die Sternform. Am besten Luminanz – der Klarfilter meiner Mono-Kamera, weil darauf die meisten Sterne zu sehen sind –, bei hohem Objektstand und direkt nach einem Autofokus-Lauf. Und den Median über viele saubere Sterne: Gesättigte messen sich zu breit, schwache zu unsicher, eng beieinanderstehende verfälschen sich gegenseitig.

Gesucht ist am Ende eine einzige Zahl: Pixel pro Sternbreite. Rund 2 hieße Sweetspot, deutlich darunter untersampled.

Bleibt die Frage, wie man die Sternbreite überhaupt bestimmt. Das klingt nach dem einfachsten Teil der Übung. Es war der schwierigste.

Das Ergebnis

In der Nacht auf den 3. August habe ich zwei Aufnahmen gemacht – bewusst zwei, weil eine einzelne nur eine Stichprobe wäre. Beide 15 Sekunden Luminanz, jeweils direkt nach einem Autofokus-Lauf, kein Stacking, keine Bearbeitung:

• 04:04 Uhr – NGC 7243, ein offener Sternhaufen in der Eidechse, mitten in der Milchstraße, 68,5° hoch.
• 05:43 Uhr – NGC 7789, „Caroline's Rose“ in der Cassiopeia, anderthalb Stunden später und mit 63,0° etwas tiefer.

Die Richtung sieht man schon in den nackten Zahlen – die genaue Zahl war dann die eigentliche Arbeit. Zunächst also ein einzelner heller Stern aus der ersten Aufnahme, Pixel für Pixel:

Die mittleren fünf Werte der zentralen Zeile lauten 3 % – 33 % – 100 % – 33 % – 8 %. Ein Pixel neben der Mitte ist der Stern auf ein Drittel abgefallen, zwei Pixel weiter ist er so gut wie weg. Senkrecht durch dieselbe Mitte steht fast dasselbe: 4 % – 36 % – 100 % – 41 % – 8 %. Der ganze Stern steckt also in einem Block von rund 3×3 Pixeln.

Das Balkendiagramm rechts zeigt dieselbe Zeile als Profil, mit der roten Linie beim halben Maximum – dort wird die FWHM gemessen. Und hier sieht man das Problem: Nur ein einziger Balken ragt über diese Linie. Die ganze Sternbreite wird von einem Messpunkt getragen.

Daraus lässt sich eine Kennzahl bilden, und der Gedanke dahinter ist simpel: Ein schmaler Stern drängt sein Licht in wenige Pixel, ein breiter verteilt es auf viele. Wie viel Licht im hellsten Pixel landet, verrät also, wie breit der Stern ist.

Für diesen Stern rechnet sich das so: die 7×7 Pixel aus der Grafik nehmen, den Himmelshintergrund abziehen, alle Werte addieren – das ist sein gesamtes Licht. Auf das hellste Pixel in der Mitte entfallen davon 26 %. Im Median über alle Sterne des Bildes sind es 25,8 %.

Wer nachrechnen will, kann das direkt an der Grafik oben tun: Die 49 abgedruckten Prozentwerte summieren sich auf 386 – und 100 davon sind eben jene 26 %.

Eine einzelne Nacht kann natürlich zufällig gutes Seeing erwischen. Deshalb dieselbe Auswertung noch einmal für Bild 2, anderthalb Stunden später:

Die mittlere Zeile lautet hier 2 % – 20 % – 100 % – 29 % – 6 %, im hellsten Pixel stecken 28,9 % des Lichts statt 25,8 %.

Damit liegen zwei Messwerte vor. Was fehlt, ist die Übersetzung in Pixel – und die stammt nicht aus meinen Bildern, sondern aus der Rechnung: Weil ein Stern näherungsweise dasselbe glockenförmige Profil hat, gehört zu jeder Breite genau ein Anteil. Eine Glockenkurve über ein Pixelraster gelegt, für jede Kamera und jedes Teleskop gleich:

Aus den 25,8 % von Bild 1 werden so 1,71 Pixel, aus den 28,9 % von Bild 2 werden 1,60. Ohne Kurvenanpassung, nur mit addierten Pixelwerten.

Und damit steht auch fest, was der kleine Unterschied zwischen den beiden Nächten bedeutet – man liest ihn erst einmal falsch herum: Mehr Licht im Zentralpixel heißt schmalerer Stern. Bild 2 ist also die schärfere Aufnahme, und damit die noch stärker untersampelte.

Zwei Einschränkungen hat die Methode. Erstens muss der Stern ungefähr mittig auf einem Pixel sitzen. Trifft er die Grenze zwischen zwei Pixeln, teilt sich sein Licht und der Anteil fällt zu klein aus – bei meinen Sternbreiten 17 statt 26 %. Deshalb messe ich nur an mittig sitzenden Sternen; bei 700 bis 800 auswertbaren Sternen pro Bild finden sich davon reichlich.

Zweitens steckt in der Umrechnungskurve doch eine Annahme, nämlich das Gauß-Profil – und das trifft eben nur näherungsweise zu. Vergrößere ich das Messfenster von 7×7 auf 17×17 Pixel, sinkt der Zentralanteil von 25 auf 22 %, und die errechnete Sternbreite steigt von 1,74 auf 1,90 Pixel. Bei einem echten Gauß-Profil dürfte sich da gar nichts ändern, denn außerhalb von 7×7 läge ohnehin kein Licht mehr. Meine Methode ist also nicht ganz unabhängig von der Messapertur – nur deutlich weniger empfindlich als der HFR, auf den ich weiter unten komme. Am Befund ändert das nichts: Alle Werte bleiben unter zwei Pixeln.

Der Gegencheck: vier Verfahren im Vergleich

Auf eine selbstgebaute Methode allein wollte ich mich nicht verlassen. Also habe ich beide Bilder zusätzlich mit vier gängigen Verfahren durchgerechnet, über 811 beziehungsweise 718 Sterne. Die Namen muss man nicht kennen – entscheidend ist nur, dass alle vier dieselbe Größe messen sollen:

Drei Verfahren landen dicht beieinander, das vierte liegt rund 50 % darüber – und zwar in beiden Bildern gleich. Das ist kein Rechenfehler, sondern verrät etwas über den Stern: Gauß-Momente gewichten weit außen liegende Flügel stark, und mein Profil hat davon reichlich. Die Methode misst also mehr den Halo als den Kern.

Bleibt die Frage, welchem Wert man glauben soll – und da ist der Gegencheck eindeutig: Die drei übereinstimmenden Verfahren liefern für Bild 1 zwischen 1,58 und 1,66 Pixel, meine Zentralpixel-Methode 1,71. Nah genug beieinander, um sich gegenseitig zu stützen. Und keiner der Werte kommt an zwei Pixel heran.

Das Gesamtergebnis

Median über alle hellen, pixelzentrierten Sterne beider Aufnahmen:

Zwei verschiedene Objekte, unterschiedliche Höhe, anderthalb Stunden Abstand – und nur 6 Prozent Unterschied.

Damit ist die Frage beantwortet: Ich bin untersampled. Auf eine Sternbreite kommen bei mir 1,6 bis 1,7 Pixel – das 2-Pixel-Minimum ist unterschritten. Von den drei Fällen am Anfang ist das der linke – allerdings an dessen oberem Rand, nicht dort, wo Sterne zu Quadraten werden.

Und dieser Wert ist noch der günstige. Die Rechnung von oben hatte 2,3 bis 3″ vorhergesagt, gemessen sind es 3,3 bis 3,5″. Der Grund steht im Protokoll meiner Guiding-Software PHD2, die den Nachführfehler sekündlich mitschreibt: Zum Zeitpunkt der beiden Aufnahmen lag er bei 0,62″ RMS in Rektaszension und 0,32″ in Deklination. Und hier lauert eine Falle, in die man leicht tappt – ein Zittern mit dem RMS σ verbreitert den Stern nicht um σ, sondern um etwa 2,4 × σ. Aus diesen Werten wird also ein FWHM-Beitrag von rund 1,2″.

Damit lässt sich das Fehlerbudget vollständig aufmachen: 3,48″ geliefert, davon 1,43″ Beugung und 1,2″ Nachführung – bleiben rund 2,9″ Seeing. Der Standort wird mit 1,5 bis 2,5″ angegeben. Nicht die Rechnung war also falsch, sondern die Nacht war schlicht keine gute.

Und das Budget lässt sich prüfen: Weil die Nachführung in Rektaszension doppelt so unruhig war wie in Deklination, müssten die Sterne minimal in eine Richtung gedehnt sein – rechnerisch um 6 %. Gemessen sind es 6 %.

Das heißt aber auch: In einer wirklich guten Nacht wird es schlimmer, nicht besser. Bei 1,5″ Seeing kämen nur noch 2,4″ Sternbreite an – 1,18 Pixel. Je ruhiger die Luft, desto weniger von dem, was sie hergibt, kann mein Rig noch abbilden.

Zwei Messungen sind noch keine Verteilung, und das Seeing schwankt von Nacht zu Nacht stärker als alles andere an meinem Rig. Aber die Richtung ist eindeutig genug, um sie nicht weiter anzuzweifeln.

Was das praktisch heißt

Wie weit ist das vom Ideal entfernt?

„Untersampled“ klingt nach einem größeren Problem, als es ist. Für zwei Pixel pro Sternbreite bräuchte ich 446 mm Brennweite – gerade einmal 64 mm mehr als jetzt. Und die habe ich längst: Ohne den 0,8×-Reducer hat der William GT81 blue seine nativen 478 mm. Es ginge also nur darum, ein Bauteil abzuschrauben:

Und was ist mit dem HFR, den N.I.N.A. anzeigt?

Meine Aufnahmesoftware N.I.N.A. zeigt nach jedem Bild einen HFR an – Half Flux Radius, also den Radius, in dem die Hälfte des Sternlichts steckt. Für Bild 1 sind das 1,50, für Bild 2 1,47. Nach der verbreiteten Faustformel „FWHM = 2 × HFR“ wären das 3,0 Pixel – ich wäre also gar nicht untersampled.

Die Formel gilt aber nur für ein reines Gauß-Profil, und meine Sterne haben deutlich breitere Flügel: Beim doppelten FWHM-Abstand liegt noch rund 1 % Restlicht an statt 0,002 %. Das bläht den HFR auf, ohne den Kern zu verbreitern. Entsprechend liegt das Verhältnis von HFR zu FWHM bei beiden Bildern bei rund 1,1 statt 2,0 – kein Zufallswert, sondern die Signatur meines Sternprofils. In der Richtung sind sich beide Verfahren übrigens einig: Bild 2 ist das schärfere.

Kurz: HFR ist ein hervorragender Fokus-Indikator, aber kein FWHM-Ersatz.

Was die Messung sonst noch verraten hat

Zwei Dinge fallen nebenbei ab, und beide stützen den Befund:

• Die Sterne sind rund (Elongation 0,06 und 0,08). Grobe Fehler sind damit ausgeschlossen: keine Drift, kein Backlash, kein Wind. Nicht ausgeschlossen ist ein symmetrisches Nachführzittern – das verbreitert den Stern, ohne ihn zu verziehen, und steckt in meinen 3,48″ mit drin. Wichtiger ist die Entwarnung, die daraus folgt: Untersampled heißt nicht, dass die Sterne schlecht aussehen. Wie rund und knackig sie sind, entscheiden Fokus, Guiding und Optik. Das Sampling begrenzt nur, wie viel Detail überhaupt ins Bild kommt.
• Das Feld ist gleichmäßig. Vom Zentrum zu den Rändern wächst die Sternbreite nur um 7 bis 14 % – kein Hinweis auf Sensorverkippung oder falschen Backfocus. Damit ist es zulässig, über das ganze Feld zu mitteln.

Drizzle: was es bringt – und was es dafür braucht

Wer untersampled ist, hat ein Werkzeug: Drizzle. Und es ist kein Amateur-Trick, sondern eine Notlösung der Profis: Hubbles Weitfeldkamera ist selbst untersampled, und Andrew Fruchter und Richard Hook entwickelten das Verfahren genau dafür.

Die Idee steckt im Namen. Aus vielen leicht gegeneinander versetzten Aufnahmen wird ein feineres Raster gebaut: Die Original-Pixel werden verkleinert und auf ein neues, engeres Gitter projiziert – die Helligkeitswerte „rieseln“ (englisch drizzle) entsprechend ihrer Überlappung auf die neuen Pixel und werden über alle Bilder gemittelt. Weil jede Aufnahme den Stern an einer minimal anderen Subpixel-Position zeigt, füllt sich das feinere Raster nach und nach.

Was es bringt: effektiv feineres Sampling, ohne die Optik zu tauschen – ein Teil des Details, das im groben Raster untergeht, kommt zurück. Bei stark untersampelten Bildern glättet es zusätzlich die eckig wirkenden Sterne.

Was es nicht kann: Detail erzeugen, das der Sensor nie eingefangen hat. Es überwindet nicht die Grenze von Seeing und Optik, und es macht keine defokussierten oder verzogenen Sterne rund.

Die Voraussetzungen – ohne die bringt Drizzle nichts oder verschlechtert sogar:

1. Du musst untersampled sein. Bei kritischer oder übersampelter Abtastung bringt Drizzle keinen Gewinn. Als grobe Grenze gilt: Ab etwa zwei Pixeln pro Sternbreite lohnt es sich kaum noch. In Foren liest man dieselbe Regel oft als „unter 1,5 ″/px“ – das ist bei durchschnittlichem Seeing dasselbe.
2. Dithering zwischen den Subs (Subpixel-Versatz). Das ist die Grundvoraussetzung – ohne Dither gibt es keine Sub-Positionen zum Rekonstruieren. Zum Glück dithert man ohnehin, um Hotpixel loszuwerden.
3. Viele Subs. Du verteilst das Licht auf ein feineres Raster; ohne genug Aufnahmen bleiben Lücken darin stehen. In meinem eigenen Stacking-Skript habe ich die Schwelle bei 40 geditherten Subs gezogen – darunter warnt es, weil das feinere Gitter dann ungleichmäßig gefüllt bleibt und das Ergebnis rauschiger wird als ein normaler Stack.
4. Gutes SNR. Drizzle erhöht das Rauschen (weniger Photonen pro Ausgabepixel). Bei dünnem Signal wird das Bild schlechter, nicht besser.

Und zwei Regler, nicht einer. Der bekannte ist der Skalierungsfaktor – üblich und empfohlen ist 2×; höher treibt die nötige Bildanzahl schnell ins Unrealistische. Der zweite heißt pixfrac (Tropfengröße): wie stark die Original-Pixel vor dem Projizieren geschrumpft werden. Zu groß, und das alte grobe Raster bleibt im Ergebnis sichtbar; zu klein, und es entstehen Löcher, weil nicht jedes Ausgabepixel getroffen wird. In meinem Siril-Skript steht pixfrac=1.0, also der volle Pixel – die sichere Variante: garantiert keine Löcher, dafür ein kleinerer Schärfegewinn. Heruntergehen lohnt erst, wenn viele und gut gestreute Dither-Positionen vorliegen.

Der Stolperstein, über den man liest: Drizzle verträgt sich klassischerweise nicht mit Ausreißer-Verwerfung beim Stacken (Sigma- oder Median-Clipping). Grund: Im feineren Raster werden Pixel nur abwechselnd mit Werten befüllt – für den Verwerfungs-Algorithmus sieht eine solche Lücke aus wie ein Störpixel, und er wirft sie weg. In älteren Programmen musste man sich deshalb entscheiden.

Als ich das las, habe ich in mein eigenes Stacking-Skript geschaut – und festgestellt, dass sich die Frage dort gar nicht stellt. Siril drizzelt bei der Registrierung, nicht beim Stacken: Der Skalierungsfaktor und pixfrac hängen am seqapplyreg-Aufruf, gestapelt wird anschließend die bereits gedrizzelte Sequenz. Die Verwerfung arbeitet also auf fertig projizierten Bildern und sieht keine Lücken. Die verbreitete Warnung stammt aus einer älteren Bauweise des Verfahrens.

Womit ich wieder bei meinem Lieblingsthema wäre: Man kann sich das aus Foren zusammenreimen – oder einmal im eigenen Werkzeug nachsehen und es wissen.

Drei der vier Punkte sind bei mir erfüllt: Die Messung hat 1,6 bis 1,7 Pixel pro Sternbreite ergeben – untersampled. Ich dithere ohnehin, und der dunkle Himmel liefert gutes SNR.

Bleibt die Bildanzahl, und die entscheidet sich pro Kanal: Bei SH2-129 hatte ich 21 Subs in Hα und 56 in OIII. Nach meiner eigenen 40er-Schwelle hätte Drizzle dort also für OIII gelohnt, für Hα nicht.

Fazit für mein Rig: Drizzle 2× ist begründet. In der Messnacht mit ihren 1,7 Pixeln wäre der Gewinn überschaubar geblieben – in guten Nächten mit 1,1 bis 1,3 Pixeln ist er es nicht. Ausgerechnet die Aufnahmen, auf die es ankommt, profitieren am meisten. Brennweite ersetzt es trotzdem nicht.

Fazit

Die Antwort auf die Frage aus der Überschrift lautet: nicht perfekt, aber passend. 1,6 bis 1,7 Pixel pro Sternbreite – unter dem Minimum, das üblicherweise angesetzt wird, und in ruhigen Nächten noch deutlich darunter. Was ich dafür bekomme, ist ein 1,7° großes Bildfeld und eine schnelle Optik. Für Weitfeld-Nebel im Schmalband ist das genau der Tausch, den ich machen will: Der Reducer bleibt dran.

Gelernt habe ich vor allem etwas über die Frage selbst. Pixelgröße durch Brennweite ist in zehn Sekunden gerechnet und beantwortet die halbe Sache: Der Abbildungsmaßstab ist Geometrie und steht ein für alle Mal fest – wie breit die Sterne tatsächlich ankommen, entscheidet jede Nacht neu. Zwei Aufnahmen à 15 Sekunden haben gereicht, um daraus eine Messung statt einer Annahme zu machen. Der Aufwand steht in keinem Verhältnis dazu, wie lange ich vorher darüber gerätselt hatte.

Am meisten gelernt habe ich an der Stelle, an der es zunächst schiefging: Vier gängige Messverfahren lieferten auf demselben Bild Werte, die um die Hälfte auseinanderlagen. Das war kein Fehler in meiner Rechnerei, sondern die Diagnose selbst – bei so wenigen Pixeln pro Stern hat kein Verfahren mehr genug Anhaltspunkte. Wer untersampled ist, merkt es auch daran, dass die Messgeräte anfangen zu streiten.