Problem mit N.I.N.A., SIRIL und "künstlichen Bias"

[ubit]

Hi zusammen,

ich habe jetzt eine ganze Weile gebraucht um meinen Workflow mit Siril korrekt zusammen zu bekommen. Da meine Omegon VETEC533C völlig unauffällig bei den Darks und Bias ist habe ich mich entschlossen nur mit Lights und Flats zu arbeiten. Das spart Zeit und vermeidet eine Quelle für (geringes) Bildrauschen welches durch die Darks und Bias immer "eingemischt" werden.
Wenn ich die Bilder aber nun mit Siril gestackt habe, wurden die Flats immer überkorrigiert. Habe ich stattdessen Bias und Darks verwendet wurde alles perfekt kalibriert. Aber wenn ich ohne Bias und Darks gearbeitet habe hat es halt nicht funktioniert.

Meine Vorgehensweise nur mit Lights und Flats in Siril:
1. Konvertieren der Flats mit DeBayering
2. Preprocessing mit Offset. Im Feld "Offset" habe ich dann z.B. =100 eingetragen (weil ich bei der Aufnahme einen Offset von 100 eingestellt hatte)
3. Stacking (Median, Multiplikativ)
4. Konvertieren der Lights mit DeBayering
5. Preprocessing mit Offset (siehe oben) und dem in Schritt 3 erstellten Master-Flat
6. Registrieren
7. Stacken - z.B. Additiv mit Rejection

Wie gesagt: Die Flats haben immer überkorrigiert...

Jetzt habe ich herausgefunden woran es lag: Die Kamera hat nur 14 Bit. Das habe ich auch so in N.I.N.A. eingetragen (Options->Equipment->Camera). Allerdings war in N.I.N.A. auch unter den "Advanced Settings" auch "Enable bit scaling" aktiviert. Ich glaube das ist die Defaulteinstellung.... Was ist nun dabei passiert? Mit dem Bit-Scaling wird in meinem Fall jeder ADU-Wert den die Kamera liefert mit 4 multipliziert um von 14 Bit auf 16 Bit zu skalieren. In den ADU-Werten der Kamera steckt aber ja auch der eingestellte Offsetwert drin. Jeder ADU-Wert von der Kamera ist also um 100 ADU höher als "eigentlich" gemessen wurde - das ist ja die Funktion des Offsets. Durch die Skalierung sind es dann aber eben keine 100 ADU mehr sondern 400 ADU, weil ja jeder Pixelwert mit 4 multipliziert wird.

Wenn ich obigen Workflow mit dem korrigierten Offset 400 durchführe, klappt es (natürlich....) einwandfrei. Problem ist dabei halt: Der tatsächliche Offset bzw. die Info darüber ob die Kameradaten skaliert wurden findet sich nirgendwo in den Bilddaten. Im Gegenteil: Im FITS-Header trägt N.I.N.A. den eingestellten Offset 100 ein. Arbeitet man mit Bias und Darks ist das kein Problem - hier wird der Offset-Wert ja im Workflow gar nicht genutzt - es kommt nur darauf an alle Bilder mit den selben Einstellungen für Gain und Offset aufzunehmen. Der Offset "kalibriert" sich automatisch heraus, weil nicht sein Zahlenwert sondern sein "Ergebnis" in den Bias bzw. Darks beim Kalibrieren genutzt wird. Arbeitet man aber mit synthetischem Bias (wie ich halt), so braucht man den tatsächlichen Zahlenwert - und hier passt dann einfach der im FITS-Header stehende Wert nicht zu den Bilddaten. Man muss sich zusätzlich notieren ob Bit-Scaling aktiviert war (und ggf. welcher Skalierungsfaktor genutzt wurde). Problematisch, falls man das nicht notiert und in ein paar Monaten oder Jahren "alte Bilddaten" nochmal bearbeiten möchte. Meiner Meinung nach müsste N.I.N.A. den Offset im Fits-Header ebenfalls skalieren damit er zu den tatsächlich gespeicherten Bilddaten der FITS-Datei passt.

Also als Tipp, falls es noch bei Anderen Probleme mit der Kalibrierung ohne Bias/Darks gibt: Notiert bzw. ermittelt einen ggf. in der Aufnahmesoftware verwendeten Skalierungsfaktor und korrigiert den Offset bei der Bearbeitung entsprechend. Dann klappt das auch ohne Bias und Darks. Alternativ darauf achten, dass die Skalierung im N.I.N.A. deaktiviert ist.

Ciao, Udo

 

[steffens]

Hallo Udo,

Super, dass Du für Dich eine funktionierende Lösung gefunden hast.
Ich fürchte aber, in Wirklichkeit ist es noch ein wenig komplizierter:
Die "Offset" Einstellung, die Du bei der Aufnahme am Kameratreiber bzw. der Aufnahmesoftware angibst hat leider nichts mit dem direkten Offset in ADU in den aufgenommenen Bildern zu tun. Welche Einstellung zu welchem Offset in ADU führt hängt von der Kamera und dem Treiber ab.
Bei meiner ASI 2600mc erhalte ich bei "Offset 30" z.B. einen Median von 301,3 im Bias-Bild, d.h. der tatsächliche Offset ist dann wohl in etwa 300 oder 301.

Immerhin sollte der Zusammenhang linear sein, d.h. der tatsächliche Offset in ADU ist ein Vielfaches des eingestellten Offset.
Mit ein paar aufgenommenen Bias-Frames mit verschiedenen Offset-Einstellungen kann man den Zusammenhang leicht finden.
Siehe dazu auch das Siril-Tutorial zu Synthetic Biases.

Das die Flats ohne Korrektur des Offsets über-korrigieren ist übrigens völlig normal. Der Offset ist ein rein additiver Betrag, der nichts mit der Optik oder Lichtempfindlichkeit zu tun hat. Er muss erst abgezogen werden, bevor die Flat-Division funktioniert.

Grüße und CS,
Steffen

 

[joetaiga]

Meine Vorgehensweise nur mit Lights und Flats in Siril:
1. Konvertieren der Flats mit DeBayering
2. Preprocessing mit Offset. Im Feld "Offset" habe ich dann z.B. =100 eingetragen (weil ich bei der Aufnahme einen Offset von 100 eingestellt hatte)
3. Stacking (Median, Multiplikativ)
4. Konvertieren der Lights mit DeBayering
5. Preprocessing mit Offset (siehe oben) und dem in Schritt 3 erstellten Master-Flat
6. Registrieren
7. Stacken - z.B. Additiv mit Rejection

Hallo Udo,

immer erst kalibrieren, dann debayern. Das liefert das beste Ergebnis. Ich würde je nach Anzahl der Flats auch additiv stacken. Schon bei 25 Frames ist das Ergebnis deutlich besser als mit der Medianmethode.

Das spart Zeit und vermeidet eine Quelle für (geringes) Bildrauschen welches durch die Darks und Bias immer "eingemischt" werden.

Ich habe mir vor einiger Zeit die Mühe gemacht dem nachzugehen. Wenn ich z.B. 25 Bias mache, erhöht das theoretisch das Rauschen im Hintergrund um 8%. Aber nur wenn ich extrem kurz belichte, sodass der Hintergrund praktisch dem Bias entspricht. Wenn ich hintergrundlimitiert belichte, was bei den Sensoren normalerweise schnell der Fall ist, geht die Rauscherhöhung schnell in den Promillebereich.

NINA skaliert die Bilder auf 16bit hoch. Da der 533 einen 14bit ADC hat, ist der Faktor 4. Irgendwo gibt es aber auch eine Einstellung, die das steuert. Bei den Touptek Kameras skalieren Gain und Offset linear. D.h. das kann man im Prinzip einfach hochrechnen. Aber...

"Offset 30" z.B. einen Median von 301,3 im Bias-Bild, d.h. der tatsächliche Offset ist dann wohl in etwa 300 oder 301.

...der Unterschied liegt meiner Meinung daran, dass die Kameras im Bias leichtes Banding haben.

Von daher ist das synthetische Bias meiner Meinung nie so genau wie das echte. Außerdem muss man nochmal etwas länger belichten um in den Einzelbildern das Banding zu eliminieren, was den Rauscheintrag vom Masterbias nochmal reduziert.

Bias aufnehmen ist ja keine Sache. Das geht schnell, einfach und die gehen nicht kaputt. Ich verwende meine über Jahre. Da kann man auch mal ein paar mehr machen.

Ich verwende übrigens immer Flatdarks, da ich die Erfahrung gemacht habe, dass immer etwas Licht rein kommt und es einen sichtbaren Unterschied gibt im Vergleich zur Kalibration mit dem Bias.

Grüße,
Joachim

 

[ubit]

Zumindest bei meiner ToupTek Clone Omegon ist der Zusammenhang aber wie beschrieben. Der eingestellte Offset taucht in Bias-Frames mit sehr kurzer Belichtungszeit (und damit kaum andere Signal- oder Rauschquellen) praktisch 1:1 als Mean/Median auf.

Der Zusammenhang Offset/Bias bei der Flats-Korrektur war mir natürlich auch bekannt. Zusammen mit meinem "Wissen" um die direkte Interpretation des eingestellten Offsets im Omegon/Touptek-Treiber (nativ) hatte ich vorher mit Astroberry auch nie Probleme. Erst beim Umstieg auf N.I.N.A. begann das Elend ;-) Lag halt daran, dass N.I.N.A. wohl defaultmäßig die 14Bit-Werte der Kamera auf 16 Bit skaliert. Die Checkbox war jedenfalls eingeschaltet. In meinem Fall also "mal 4" für alle Werte. Damit wird halt auch der in den Bilddaten enthaltene, tatsächliche Offset-Wert viermal höher und ich muss entsprechend als synthetischen Bias-Wert dann diesen 4fachen Wert nutzen. Das war das einzige "Problem" ;-) Bin ich halt erst nach ewigen Versuchen drauf gekommen. Erst habe ich an fehlerhafte Flats gedacht. Dann doch mal mit Darks/Bias kalibriert - das ging, also waren die Flats offenbar OK. Dann mal testweise andere Werte für den synthetischen Bias genommen. Ein paar Werte durchprobiert und bei 400 (Offset bei der Aufnahme war 100) klappte es dann. Etwas weiter gesucht und nachgedacht und den "Übeltäter" halt in der Bit-Skalierung in N.I.N.A. gefunden. N.I.N.A. macht das wohl, weil einige Stacking-Programme mit Bittiefen ungleich 8/16/32 nicht richtig klar kommen. Es ist auch nachvollziehbar warum z.B. im FITS-Header der eingestellte Offset eingetragen wird und nicht der skalierte Wert (entsprechend auch im Dateinamen). Das macht den Fehler ja so unhandlich.... Man kennt seine Kamera, weiß wie der Offset funktioniert - und trotzdem klappt es nicht weil N.I.N.A. die Bilddaten "manipuliert" (halt skaliert). Bei Kameras mit 16 Bit taucht das Problem nicht auf weil nicht skaliert wird. Arbeitet man lehrbuchmäßig mit Lights, Bias, Darks und Flats taucht es auch nicht auf, da der skalierte Offset in allen Kalibrierungsframes identisch vorhanden ist. Nur wenn man mit eine synthetischen Bias arbeitet hat man das Problem. Und natürlich auch nur, wenn man den Offset nicht "empirisch" bestimmt sondern mit einem Touptek/Omegon-Treiber arbeitet und den "normalen" Zusammenhang zwischen Offset-Einstellung und tatsächlich verwendetem Offset in der Kamera kennt (Halt 1:1 bei ToupTek).

Doof ist halt, dass dieses "mal 4" eine Einstellung in der Aufnahmesoftware ist die nirgendwo in den Daten auftaucht. Man kann also "Jahre später" nicht mehr aus den Daten bestimmen ob das Bit-Scaling aktiv war oder nicht (OK: Man kann schon, aber nicht "einfach"). Man sieht es, wenn man in der Statistik die Max-ADU-Werte anschaut und (ausnahmsweise mal hilfreiche) Hot-Pixel oder überstrahlte Sterne im Bild hat. Steht da dann 65535 war Bit-Scaling aktiv, steht da 16383 war Bit-Scaling inaktiv. Oder man schaut sich die unteren 2 Bit in den Bilddaten an (nicht ganz so trivial). Sind die unteren 2 Bit immer 0, war Bit-Scaling aktiv.

Der Beitrag oben ist ja auch nur als Hinweis gedacht. Ich jedenfalls habe Stunden gebraucht bis ich auf die Fehlerursache gekommen bin - das wollte ich für Andere vermeidbar machen ;-) Die Einstellung zum Bit-Scaling "versteckt" sich in N.I.N.A. ja auch in den "Advanced options" und ist nicht sofort sichtbar. Insofern: Vielleicht ist das für den Einen oder Anderen doch hilfreich zu wissen. Falsch korrigierende Flats kommen ja in den Foren immer mal wieder auf - und das hier ist halt EINE von vielen Möglichkeiten wie es dazu kommen kann.

Ciao, Udo

 

[ubit]

@joachim: Die Zusammenhänge sind mir schon klar - wobei ich keinen wirklichen Unterschied sehe wenn ich beim konvertieren oder später deBayere.

Und natürlich ist der Eintrag durch das Rauschen mit den Bias-Frames nicht sooo groß. Darks sind da schon "schlimmer" - aber auch verkraftbar. Sieht man ja auch an den Bildern die auf diese Weise gemacht werden. Trotzdem: Wir kämpfen um jedes bisschen SNR - und die Sensoren werden immer besser. Wir nähern uns der "idealen Kamera": Kein Ausleserauschen, kein thermisches Rauschen, kein Amp-Glow, keine statischen oder wandernden Pattern. Mittlerweile sind einige Sensoren da schon ziemlich dicht dran. Dann machen Bias und Darks halt keinen wirklichen Sinn mehr und ein synthetischer Bias ist halt trotzdem einfacher.

Ein synthetischer Bias ist natürlich nicht "so genau" weil er eben minimale Unterschiede der Pixel in der Kamera nicht "kennt". Aber dafür rauscht er halt auch überhaupt nicht. Was letztendlich "besser" ist hängt halt davon ab wie "eben" der Sensor tatsächlich ist. Wenn es wirklich keinerlei Banding, keine statischen Muster und kein Verstärkerglühen gibt, ist ein synthetischer Bias "besser". Wenn ich 200 Bias-Frames stacke, habe ich in der Statistik eine AvgDev von 0,3 ADU. Das ist schon ziemlich "flach". Der Unterschied zwischen Min und Max liegt überall im Bild unter 5 ADU. Das Rauschen in den lights ist bei mir (Bortle 5-6) selbst bei Aufnahmen von 15s deutlisch "höher". Da ja die Einzelbilder mit dem Bias korrigiert werden ist der Nutzen von "echten" Bias-Frames bei meinem Himmel sehr, sehr begrenzt.

Ciao, Udo

BTW: Mittlerweile habe ich auch festgestellt dass es Lichtlecks gibt ;-) Ganz lichtdicht wird man den Image-Train wohl auch nie bekommen. Wenn ich mit einer hellen Taschenlampe in die Lüftungsschlitze der Kamera leuchte kann ich das im Bild sehen. Der OAZ ist auch nicht wirklich dicht (der bewegliche Teil in der Führung - die Basis habe ich bereits abgedichtet). Etwas Licht kommt immer irgendwo her. Insofern werde ich demnächst auch mal Flatdarks probieren.

 

[joetaiga]

wobei ich keinen wirklichen Unterschied sehe wenn ich beim konvertieren oder später deBayere.

Beim Debayern werden die Farbinformationen bei den fehlenden Pixeln aus einer Farbe aus den umliegenden Pixeln interpoliert. Flats können ja zwei Dinge tun: Verunreinigungen und Vignette ausgleichen und die kleinen Unterschiedliche in der Empfindlichkeit der Pixel ausgleichen. Ersteres geht auch wenn man vor der Kalibration debayert, letzteres nicht.

Das sind natürlich Feinheiten. Ich denke halt, wenn man sich bei einem Aspekt für die Feinheiten entscheidet, dann macht das nur Sinn, wenn man das komplett durchzieht. Das sind ja statistische Prozesse, d.h. Fehler addieren sich nicht linear sondern quadratisch.

Wo die Geschichte mit dem synthetischen Bias interessanter wird, ist bei einer DSLM. Die neueren haben praktisch schon ein synthetisches Bias. Das wird von der Kamera komplett glatt gezogen. Bei meiner Canon R hat das Bias immer 2048 ADU. Das Dark auch. Egal wie lange ich belichte. Es ändert sich nur der Rauschpegel. Da kann man das gleich synthetisieren und sich die Auslösungen sparen, die bei der Canon R schon eine Weile dauern. Die Rohbilder aus der DSLM skaliert NINA übrigens nicht hoch. 14bit bleiben 14bit und werden im Kamerarohformat gespeichert. Firecapture macht das generell nicht. Das hat allerdings nur begrenzte Deepsky Funktionen.