17. August 2026 · 🔭 Astronomie
Warum belichte ich eigentlich meistens 300 Sekunden? – die optimale Sub-Länge, gemessen und gerechnet
300 Sekunden pro Einzelaufnahme. Die Zahl stand im übernommenen Profil, sie taucht in fast jedem meiner Artikel auf – Filter, Dithering, Kalibrierung –, und begründet habe ich sie nie. Das passt schlecht zu meinem eigenen Grundsatz, dass eine übernommene Zahl noch keine geprüfte Zahl ist.
Heute Morgen kam ich endlich dazu. Ferienhaus in Dänemark, der Sohn schläft noch, meine Frau ist walken, ich sitze mit dem Rechner am Esstisch – und in Texas ist tiefste Nacht. Sieben Zeitzonen sind für einmal ein Vorteil: Was hier der Vormittag vor dem Frühstück ist, ist dort die beste Stunde der Nacht. Mit der Vollversion von SharpCap habe ich in zwei Sitzungen die Messungen nachgeholt, die dieser Rechnung fehlten.
Das Ergebnis vorweg: Eine einzige Zahl für alle Filter ist falsch. Für Luminanz sind 300 Sekunden großzügig, 60 täten es auch. Für R, G und B passen sie, 180 wären der bessere Kompromiss. Im Schmalband dagegen sind sie zu kurz – mit 600 Sekunden hole ich aus derselben Nacht so viel heraus, wie mir sonst eine um ein Viertel längere Nacht bringen würde.
Worum es geht
Die Gesamtzeit ist nicht die Frage. Fünf Stunden bleiben fünf Stunden, ob in 60 Aufnahmen à 5 Minuten oder in 10 à 30. Unterschiedlich ist nur das Ausleserauschen: Es fällt bei jedem Auslesevorgang neu an, unabhängig von der Belichtungsdauer. 60 Subs bedeuten 60 Portionen davon, 10 Subs nur 10.
Daraus folgt: Länger ist besser. Immer. Die Frage ist nur, ab wann es sich nicht mehr lohnt – nämlich sobald das Photonenrauschen des Himmelshintergrunds das Ausleserauschen überdeckt. Der Himmel rauscht ja auch: Licht kommt nicht als gleichmäßiger Strom an, sondern als abzählbare Photonen. Zählt ein Pixel im Mittel N davon, schwankt die Zahl um √N. Ist dieses Rauschen erst größer als das der Elektronik, ist es gleichgültig, ob man noch etwas Elektronikrauschen dazulegt.
Robin Glover, der Autor von SharpCap, hat das in eine Gleichung gegossen, die man sich merken kann:
t = C · R² / P
t ist die optimale Sub-Länge, R das Ausleserauschen in Elektronen, P die Rate, mit der der Himmel Elektronen pro Pixel und Sekunde liefert.
C hängt nur davon ab, wie viel zusätzliches Rauschen man akzeptiert: C = 1/((1+E)²−1). Bei fünf Prozent sind das 1/(1,05²−1) = 9,75, bei zehn Prozent 4,76.
Zwei Dinge stecken darin. Das Ausleserauschen geht quadratisch ein – halb so viel Rauschen, ein Viertel der Zeit. Und der Himmel geht linear ein – ein dunkler Himmel verlangt längere Subs, ein Schmalbandfilter macht daraus den Extremfall.
Bleiben also zwei Zahlen zu beschaffen.
R – das Ausleserauschen meiner Kamera
Das musste ich nicht schätzen. SharpCap hat eine Sensoranalyse eingebaut, die aus rund 900 Aufnahmen gegen eine gleichmäßig beleuchtete Fläche die ganze Kennlinie vermisst. Mein Flat-Panel ist dafür ideal: Klappe zu mit Licht für die Hellmessungen, Klappe zu ohne Licht für die Darks, und die Helligkeit ist in 4096 Stufen regelbar.
2,80 Elektronen auf 1,395 – Faktor 2,01, ein einziger Schritt. Das ist der High-Conversion-Gain-Umschaltpunkt des IMX533. Ich fahre Gain 125 ohnehin, aus anderen Gründen; dass diese eine Einstellung wegen des Quadrats die nötige Sub-Länge auf ein Viertel drückt, hatte ich dort nie ausgerechnet.
Nebenbei ist damit auch Gain 124 als schlechteste Einstellung der ganzen Kennlinie entlarvt: höchstes Rauschen unmittelbar vor dem Sprung und der niedrigste Dynamikumfang überhaupt. Ein Schritt daneben kostet doppelt. Die vollständige Tabelle steht im Anhang.
Ich rechne im Folgenden mit R = 1,395 e⁻. Das ist der Wert im Auslesemodus Low Noise, in dem meine Kamera steht – ob dieser Modus überhaupt etwas bringt, war eine eigene Untersuchung wert und steht ebenfalls im Anhang.
P – mein Himmel
Das war lange die schwache Stelle der Rechnung. Im Flat-Panel-Artikel hatte ich 0,8 Elektronen pro Pixel und Sekunde im Luminanzfilter abgeschätzt, hergeleitet aus SQM 21,9, 81 mm Öffnung und 2,03 ″/px – und für Schmalband durch siebzig geteilt, weil die 4,5-nm-Filter etwa so viel weniger durchlassen.
Inzwischen ist es gemessen. SharpCaps Smart Histogram liefert die Rate direkt, in einer Nacht für alle sieben Filter:
| Filter | Himmelsrate |
|---|---|
| L | 0,68 e⁻/px/s |
| B | 0,19 |
| G | 0,16 |
| R | 0,14 |
| Hα · OIII · SII | 0,01 |
Zwei Dinge fallen daran auf.
Meine Schätzung war brauchbar. 0,68 statt 0,8 im Luminanzfilter – fünfzehn Prozent daneben für eine Zahl, die aus SQM-Wert und Öffnung hergeleitet war.
Und der Faktor 70 stimmt. 0,68 geteilt durch 0,01 sind 68. Genau das hatte ich angenommen, ohne es belegen zu können.
Eine Einschränkung bleibt: SharpCap gibt nur zwei Nachkommastellen aus, und im Schmalband ist damit Schluss. Alle drei Filter zeigen 0,01 – der wahre Wert liegt irgendwo zwischen 0,005 und 0,015, und Hα, OIII und SII lassen sich nicht auseinanderhalten. Was das für die Empfehlung bedeutet, steht weiter unten. Worauf es bei so einer Messung ankommt und wie man sie ohne SharpCap-Lizenz hinbekommt, steht im Anhang.
Das Ergebnis
Eingesetzt in t = 9,75 · R² / P:
| Filter | Himmelsrate | optimale Sub-Länge |
|---|---|---|
| Luminanz | 0,68 | 28 s |
| B | 0,19 | 100 s |
| G | 0,16 | 119 s |
| R | 0,14 | 136 s |
| Schmalband 4,5 nm | 0,01 | 32 min |
Von einer halben Minute bis zu einer halben Stunde – Faktor 68, genau das Verhältnis der Himmelsraten. Und die Farbfilter brauchen längere Aufnahmen als die Luminanz, weil durch sie nur etwa ein Viertel des Lichts kommt.
Luminanz: 99,5 Prozent des theoretisch Möglichen. Schon 60 Sekunden lägen bei 97,7. Hier ist nichts mehr zu gewinnen.
R, G, B: rund 98 Prozent. Auch da sind 300 Sekunden reichlich; 180 kämen noch auf 96 bis 97.
Schmalband: 77,9 Prozent. Das klingt nach wenig Verlust, ist aber die falsche Blickrichtung – und die Stelle, an der ich beim ersten Lesen selbst hängen blieb. Deshalb ausführlich.
Der Vergleichsmaßstab ist eine unendlich lange Aufnahme: Bei der fällt das Ausleserauschen nur ein einziges Mal an, besser geht es nicht. Mit 300-Sekunden-Subs erreiche ich davon 77,9 Prozent – bei gleicher Gesamtzeit. Und weil das Signal-Rausch-Verhältnis nur mit der Wurzel der Zeit wächst, kostet das Aufholen nicht 22 Prozent mehr Zeit, sondern das Quadrat davon: 1 ÷ 0,779² = 1,65.
An einer Nacht durchgerechnet:
| Ich sammle | 10 Stunden Hα in 300-Sekunden-Subs |
| Davon kommt an, was entspräche | 6,1 Stunden perfekter Belichtung |
| Für wirklich 10 Stunden bräuchte ich | 16,5 Stunden |
Knapp vierzig Prozent der Nacht sind also weg – nicht weil etwas kaputtgeht, sondern weil sich das Ausleserauschen von 120 Auslesevorgängen aufsummiert.
| Sub-Länge | % des Maximums | davon verschenkt | Mehrbedarf an Zeit |
|---|---|---|---|
| 300 s | 77,9 % | 39 % | +65 % |
| 600 s | 86,9 % | 25 % | +32 % |
| 900 s | 90,7 % | 18 % | +22 % |
| 1800 s | 95,0 % | 10 % | +11 % |
Und wenn die 0,01 daneben liegen? Sie können ja alles zwischen 0,005 und 0,015 bedeuten. Die Empfehlung hält trotzdem:
| tatsächliches P | Optimum | 300 s | 600 s |
|---|---|---|---|
| 0,005 | 63 min | 66 % | 78 % |
| 0,010 | 32 min | 78 % | 87 % |
| 0,015 | 21 min | 84 % | 91 % |
In allen drei Fällen bringt der Sprung von 300 auf 600 Sekunden zwölf bis dreizehn Prozentpunkte.
Warum ich trotzdem nicht auf 32 Minuten gehe
Die Formel kennt zwei Größen. Die Wirklichkeit kennt mehr, und die sprechen alle für kürzere Aufnahmen.
Der übliche Verdächtige ist die Montierung – je länger belichtet wird, desto mehr Gelegenheit für einen Nachführfehler, den kein Stacking mehr repariert. Das lässt sich prüfen: Ich habe das PHD2-Log der M16-Nacht genommen, 4.412 Frames, und in gleitende Fenster von fünf bis sechzig Minuten zerlegt. Wird das Guiding über die Zeit schlechter, muss man es hier sehen.
Der RMS ändert sich nicht – 0,78 Bogensekunden, ob das Fenster fünf Minuten oder eine Stunde umfasst. Nur die größte Einzelabweichung wächst, und über zweieinhalb Stunden gab es keinen einzigen Ausschlag über 3 Bogensekunden. Ein 30-Minuten-Sub wäre in dieser Nacht sogar gleichmäßiger geführt gewesen als das schlechteste Fünf-Minuten-Fenster.
Der übliche Verdächtige fällt damit aus. Was bleibt, sind drei andere Gründe:
Die Anzahl der Frames
Das ist der harte Einwand, und er kommt aus meinen eigenen Artikeln: Kappa-Sigma greift ab etwa zehn Bildern und wird jenseits von zwanzig zuverlässig. Mein Stacking-Skript schaltet erst ab 31 Frames auf GESDT, und für Drizzle verlangt es 40 geditherte Subs – was bei meinem Untersampling von 1,6 Pixeln pro Sternbreite kein Luxus ist. Bei 32-Minuten-Subs käme ich pro Kanal und Nacht auf drei.
Jeder verlorene Sub kostet mehr
Satellit, Böe, Wolke – bei fünf Minuten verliere ich fünf, bei dreißig eben dreißig. Nicht die Wahrscheinlichkeit ist das Problem, sondern der Einsatz.
Sternsättigung
Der Himmel füllt selbst bei 30 Minuten Schmalband nur ein Promille des Wells – die Sterne nicht.
Meine Entscheidung
60 s
Luminanz · bisher 300
180 s
R · G · B · bisher 300
600 s
Schmalband · bisher 300
Schmalband: 600 Sekunden. Der Verlust sinkt von knapp vierzig auf ein Viertel, und es bleiben noch genug Einzelbilder für die Ausreißerverwerfung. Weiter zu gehen bringt vier Prozentpunkte und kostet die Statistik.
Luminanz: kürzer, 60 Sekunden. Immer noch 97,7 Prozent, und weniger ausgebrannte Sterne sind ein Gewinn.
R, G, B: 180 Sekunden. Damit liege ich bei 96 bis 97 Prozent, bekomme aber zwei Drittel mehr Einzelbilder als mit 300 Sekunden – und ausgebrannte Sterne sind gerade in den Farbkanälen ärgerlich, weil sie die Sternfarben wegnehmen. Bei 60 Sekunden wären es nur noch 90 bis 92 Prozent, das wäre zu kurz.
Der theoretische Optimalwert ist nie die Antwort. Er ist die Obergrenze, gegen die man abwägt.
Nachtrag zu älteren Artikeln. Beim Nachrechnen sind mir vier Zahlen aufgefallen, die ich früher zu grob angegeben habe:
· Im CMOS-Artikel und im Gain-Artikel steht das Ausleserauschen im HCG-Modus als „etwa 1 Elektron“. Gemessen sind es 1,395 e⁻. Für die Formel oben ist das ein Faktor zwei in der Zeit.
· Im Flat-Panel-Artikel hatte ich Systemverstärkung und Sättigung aus der 73-ke-Angabe hergeleitet: 1,06 e⁻/ADU und 17.300 e⁻. Gemessen sind es 1,04 e⁻/ADU und 17.040 e⁻.
· Ebenfalls im Flat-Panel-Artikel steht die geschätzte Himmelsrate von 0,8 e⁻/px/s im Luminanzfilter. Gemessen sind es 0,68.
· Im Sampling-Artikel bin ich mit 0,62 ″ Guiding-RMS gerechnet. Die jetzt vermessene Nacht liegt bei 0,78 ″, der FWHM-Beitrag also bei 1,84 statt 1,2 Bogensekunden. Am Befund „untersampled“ ändert das nichts, an der Fehlerbilanz schon.
Durchgerechnet habe ich das, wie inzwischen üblich, gemeinsam mit Claude AI.
Anhang A – der zweite Auslesemodus: bringt er etwas?
Die Ares-Serie hat einen zweiten Sensormodus, „Low Noise“. Player One empfiehlt ihn im Handbuch ausdrücklich für Deep-Sky. Zu finden ist er hier:
| Nativer Treiber in N.I.N.A. | Options → Equipment → Camera → Readout mode → Low Noise |
| ASCOM-Treiber | Chooser → Properties → Sensor Mode → Low Noise mode |
Ob er etwas bringt, ist in den Foren umstritten: Mehrere Besitzer der baugleichen Ares-C Pro konnten keinen Unterschied nachmessen, Player One nannte das Ergebnis „very strange“ und lieferte nie eine Erklärung.
Das lässt sich entscheiden, denn SharpCap legt die Sensoranalyse je Auslesemodus getrennt ab – man sieht es am Dateinamen, …~MONO16~Low Noise.json neben …~MONO16~Normal.json. Zwei Läufe, eine Antwort:
| Gain | Low Noise | Normal | Vorteil |
|---|---|---|---|
| 0 | 4,25 e⁻ | 5,05 e⁻ | −15,7 % |
| 100 | 2,92 | 3,14 | −7,2 % |
| 124 | 2,80 | 3,07 | −8,8 % |
| 125 | 1,395 | 1,435 | −2,8 % |
| 200 | 1,288 | 1,287 | ±0 |
| 400 | 1,126 | 1,083 | +4,0 % |
| 500 | 1,064 | 1,003 | +5,7 % |
Der Modus tut etwas – aber vor allem dort, wo kaum jemand arbeitet. Unterhalb des HCG-Punkts bringt er sechs bis sechzehn Prozent. An meinem Arbeitspunkt sind es 2,8. Oberhalb von Gain 200 verschwindet der Vorteil, ab 400 ist Normal sogar leicht besser.
Damit ist auch der Forenstreit erklärt: Wer bei hohem Gain misst, findet keinen Unterschied, weil dort keiner ist. Wer bei niedrigem misst, findet einen deutlichen. Beide Lager hatten recht.
Ein Vorbehalt gehört dazu. Ich habe die Low-Noise-Analyse zweimal gefahren und einmal 1,37, einmal 1,395 Elektronen erhalten – 1,8 Prozent Streuung zwischen zwei Läufen derselben Kamera im selben Modus. Die Wiederholgenauigkeit ist damit fast so groß wie der Vorteil, den sie bei Gain 125 messen soll. An meinem Arbeitspunkt ist der Auslesemodus also kein relevanter Faktor. Ich lasse ihn auf Low Noise, weil er nichts kostet.
Anhang B – die vollständige Sensoranalyse
SharpCap Sensor Analysis, 14.08.2026, gegen das Flat-Panel, Sensor bei −10 °C. Die Werte stammen direkt aus den beiden JSON-Dateien, die SharpCap unter %APPDATA%\SharpCap\SensorCharacteristics ablegt – mit Pro-Lizenz im Klartext lesbar.
| Gain | e⁻/ADU (LN) | Rauschen LN | Sättigung LN | Rauschen Normal | Sättigung Normal | Dynamik LN |
|---|---|---|---|---|---|---|
| 0 | 4,5729 | 4,253 | 74.918 | 5,045 | 73.425 | 14,105 |
| 50 | 2,5226 | 3,220 | 41.328 | 3,438 | 40.504 | 13,648 |
| 100 | 1,4284 | 2,917 | 23.401 | 3,142 | 22.939 | 12,970 |
| 124 | 1,0833 | 2,803 | 17.747 | 3,072 | 17.400 | 12,628 |
| 125 | 1,0401 | 1,395 | 17.040 | 1,435 | 16.761 | 13,577 |
| 150 | 0,7846 | 1,351 | 12.854 | 1,411 | 12.639 | 13,216 |
| 200 | 0,4370 | 1,288 | 7.159 | 1,287 | 7.045 | 12,440 |
| 250 | 0,2488 | 1,233 | 4.076 | 1,272 | 4.007 | 11,691 |
| 300 | 0,1384 | 1,174 | 2.267 | 1,171 | 2.230 | 10,916 |
| 350 | 0,0787 | 1,156 | 1.290 | 1,147 | 1.268 | 10,124 |
| 400 | 0,0437 | 1,126 | 716 | 1,083 | 705 | 9,313 |
| 450 | 0,0249 | 1,069 | 408 | 1,072 | 403 | 8,577 |
| 500 | 0,0141 | 1,064 | 231 | 1,003 | 225 | 7,760 |
Gemessene Bittiefe 14 in beiden Modi · linear bis 99,7 Prozent (Low Noise) beziehungsweise 99,6 (Normal).
Der Dynamikumfang steigt beim HCG-Sprung. Von 124 auf 125 wächst er um fast eine volle Blendenstufe, obwohl der Full Well kleiner wird: 6.331 : 1 auf 12.215 : 1. Mehr Gain kostet hier keine Dynamik, sondern bringt sie. Nach oben lohnt es dann nicht mehr – Gain 150 spart 0,04 Elektronen Rauschen und kostet 4.000 Elektronen Sättigungskapazität.
Die Sättigungsspalte ist keine Messung, sondern eine Umrechnung: Jeder Wert ist genau e⁻/ADU × 16.383, also die Spanne des Wandlers in Elektronen. Was das Pixel wirklich fasst, steht da nicht. Die 74.918 Elektronen bei Gain 0 sind deshalb kein Beleg gegen ZWOs Angabe von 50 ke für den IMX533 – die 99,7 Prozent Linearität sind ein Hinweis in diese Richtung, mehr nicht.
Ein Nebenbefund, den ich sonst nirgends bekommen hätte: Die JSON-Dateien enthalten auch die Offset-Kennlinie. Bei Gain 125 entspricht Offset 150 exakt 600 ADU, also vier ADU je Offset-Schritt. Mein Offset 50 ergibt damit 200 ADU Sockel bei 5,4 ADU Rauschen – siebenunddreißig Sigma Abstand zur Null, da wird nichts abgeschnitten. Bei Offset 0 dagegen steht der Median exakt auf 0,0, dort würde geclippt.
Anhang C – wie man die Himmelsrate misst
Mit SharpCap Pro ist es ein Knopf: Smart Histogram → Measure. Voraussetzung ist eine Sensoranalyse derselben Kamera im selben Auslesemodus. Das Programm dreht den Gain aufs Maximum, macht eine Reihe immer längerer Belichtungen und sucht sich die dunkelste Stelle im Bildfeld. Gemessen wird pro Filter einzeln, denn genau der Filter senkt ja den Hintergrund.
So sah meine Messreihe aus – leeres Feld im Pegasus-Quadrat, Neumondwoche, Mond seit drei Stunden unten:
| Filter | Rate | meine Zeit | Texas | Sonne | Zielhöhe |
|---|---|---|---|---|---|
| Hα | 0,01 | 10:33 | 03:33 | −38,1° | 75,0° |
| OIII | 0,01 | 11:01 | 04:01 | −34,3° | 69,7° |
| SII | 0,01 | 11:29 | 04:29 | −30,1° | 63,9° |
| L | 0,68 | 11:31 | 04:31 | −29,7° | 63,5° |
| R | 0,14 | 11:34 | 04:34 | −29,3° | 62,9° |
| G | 0,16 | 11:36 | 04:36 | −28,9° | 62,5° |
| B | 0,19 | 11:39 | 04:39 | −28,4° | 61,8° |
Vier Bedingungen entscheiden, ob dabei etwas Brauchbares herauskommt:
Die Uhrzeit. Sonne unter −18 Grad. Das ist der Punkt, an dem es bei einem Remote-Rig leicht schiefgeht: Zwischen meinem Schreibtisch und Texas liegen sieben Stunden, und was hier ein normaler Vormittag ist, ist dort die Stunde vor Sonnenaufgang. Ein halbes Grad Dämmerung genügt, um alle Werte anzuheben.
Ein leeres Feld über 60 Grad. Abseits des Milchstraßenbandes, ohne ausgedehnten Nebel – sonst misst man ihn mit.
Schmalband zuerst, solange das Feld am höchsten steht. Und Max Exposure auf 30 Minuten, sonst meldet SharpCap für Hα nur „No Solution below 600s“ und weicht auf einen höheren Gain aus.
Und der beste Prüfstein sind die Zeitstempel. Hα, OIII und SII brauchten je 28 Minuten, die vier Breitbandfilter zwei bis drei. Eine Schmalbandmessung, die nach zwei Minuten fertig ist, hat vorzeitig abgebrochen und liefert einen viel zu hohen Wert.
Ohne Lizenz geht es auch, mit Material, das ohnehin entsteht:
Zwei Aufnahmen unterschiedlicher Länge in derselben Nacht, etwa 60 und 300 Sekunden.
P = (Median₃₀₀ − Median₆₀) × e⁻/ADU ÷ (300 s − 60 s)
Median statt Mittelwert, damit die Sterne nicht mitzählen. Der elektronische Sockel kürzt sich heraus, man braucht also kein Dark. Der Fallstrick: Der Treiber skaliert die 14 Bit des Wandlers auf 16 Bit hoch – erkennbar daran, dass alle Pixelwerte durch vier teilbar sind. Dann rechnet man mit 1,04/4 = 0,26 e⁻/ADU.
Es gelten dieselben Bedingungen wie oben. Meine 77 Schmalbandaufnahmen von SH2-129 taugen dafür zum Beispiel ausdrücklich nicht: Cepheus liegt mitten in der Milchstraße, und der Nebel füllt das Bild.
Damit ist keine Zahl in diesem Artikel mehr geschätzt. Was offen bleibt, ist nur noch die Auflösung im Schmalband: Zwei Nachkommastellen reichen dort nicht, um Hα, OIII und SII zu unterscheiden. Wer es genauer braucht, kann sich behelfen – die angezeigte Optimal Exposure hat eine Nachkommastelle und geht mit 1/P. Aus den Breitbandmessungen ergibt sich SharpCaps interne Konstante zu P × t ≈ 17,4, und damit lässt sich P aus der Belichtungsempfehlung rückrechnen.
Quellen
Eigene Messungen: SharpCap Sensor Analysis in beiden Auslesemodi, 14.08.2026 – Rohdaten in Ares-M PRO (IMX533)~MONO16~Low Noise.json und …~Normal.json
Eigene Messung: SharpCap Smart Histogram, Himmelsrate für alle sieben Filter, 17.08.2026, 03:33–04:39 Ortszeit
Player One – Ares-M Pro · Handbuch (PDF)
Robin Glover – Deep Sky Astrophotography with CMOS Cameras (Practical Astronomy Show 2019) · SharpCap-Belichtungsrechner
Player One – Professional Cooled Camera Manual (PDF) – Sensor Mode im ASCOM-Dialog, Empfehlung „Low Noise für DSO“
Cloudy Nights – Sensoranalyse einer Ares-C Pro – die Zweifel am Low-Noise-Modus
PHD2-Guide-Log der Nacht vom 12. August 2026: PHD2_GuideLog_2026-08-12_142244.txt
🔭 Warum Gain 125: Gain und Offset · Woher die Schätzung der Himmelsrate kam: Ein Deckel, der leuchtet · Warum ich Frames brauche: Sampling und Drizzle · Dithering