Astronomie Software KStars

Gehört zu: Astro-Software
Siehe auch: INDI, StellarMate, ASIair, Polar Alignment, Go to, Fokussieren, N.I.N.A.
Stand: 21.12.2024

Warnung / Disclaimer

Diesen Blog-Artikel schreibe ich ausschließlich zu meiner persönlichen Dokumentation; quasi als mein elektronisches persönliches Notizbuch.
Wenn es Andere nützlich finden, freue ich mich, übernehme aber kleinerlei Garantie für die Richtigkeit bzw. die Fehlerfreiheit meiner Notizen. Insbesondere weise ich darauf hin, dass jeder, der diese meine Notizen nutzt, das auf eigene Gefahr tut.
Wenn Podukteigenschaften beschrieben werden, sind dies ausschließlich meine persönlichen Erfahrungen als Laie mit dem einen Gerät, welches ich bekommen habe.

Astronomie-Software KStars – was ist das?

KStars ist eine Astronomie-Software, die einerseits als schönes Planetarium-Programm fungiert, andererseits die astronomischen Geräte (Montierung, Kameras, …) steuern kann und dabei diverse nützliche Zusatz-Funktionen hat, wie beispielsweise

Zu diesem Behufe enthält KStars ein Module names Ekos, welche als INDI-Client mit einem INDI-Server spechen kann.

KStars gibt es für Windows, MacOS und Linux.

Die aktuelle Version von KStars ist 3.7.5 (Dez 2024).

Quellen: Youtube-Video von GalaxyGazer: “Die Alternative zum Laptop KStars & Ekos”

Installation von KStars

KStars gibt es für verschiedene Betriebssysteme (Plattformen): Android, Windows, Linux, MacOS

Download bei: https://edu.kde.org/kstars/

Die aktuelle Version (2024) ist: 3.7.5

Installation unter Windows

Download: https://edu.kde.org/kstars/

Allerdings gibt es einen “lokalen” INDI-Server unter Windows, das geht also nur mit einem zweiten Rechner z.B. Remote oder auch als Virtuelle Maschine.

Installation unter Linux – Ubuntu

Wenn wir KStars auf unserem Linux Ubuntu installieren, können wir leicht mit Ekos kontrollieren, ob der INDI-Server dort auch läuft.

Zur Installation geben wir im Terminal-Fenster ein:

sudo apt-add-repository ppa:mutlaqja/ppa
sudo apt-get update
sudo apt-get install kstars-bleeding

Die Applikation "KStars" findet man danach unter: Menüleiste -> Applications -> Education -> KStars
Rechte Maustaste: Add this launcher to desktop

Erste Schritte mit KStars

Als Erstes soll man bei KStars den Standort einrichten.

Die Sprache von KStars ist manchmal komisch bis gewöhnungsbedüftig. Beispielsweise gibt es in der deutsche Version so etwas wie “STF” auf das ich mir so überhaupt keinen Reim machen konnte. Im Englischen heist das “FoV” – aha: “Field of View”, also “Gesichtsfeld”- aber KStars denkt “Sichtfeld”. abgekürzt “STF”.

Wie schalten wir die Sprachen bei KStars um?????

Große Frage – nicht bei den KStars-Einstellungen, sondern im Menü “Help -> Switch Application Language”

Menüleiste Einstellungen -> “KStars einrichten…”  (Kataloge etc.)

Menüleiste Extras:  Rechner, Himmelskalender, Sonnensystem, Was ist los heute

Erste Schritte mit Ekos

Eine wesentliche Funktion von KStars auf dem Windows-Computer ist ja, das Modul “Ekos” aufzurufen und damit das Astro-Equipment zu steuern. Der Aufruf geschieht in der KStars-Menüleiste: Extras -> Ekos   (englisch: Tools -> Ekos) oder über die Symbolleiste (Ecos-Symbol = Observatoriumsbild)

Das setzt voraus, das wir unsere Astro-Geräte mit einem INDI-Server verbunden haben. Der INDI-Server kann auch remote auf einem anderen Computer laufen z.B. einem Raspberry Pi mit Linux.

Ekos Profile

In Ekos haben wir dann sog. Profile, in denen der INDI-Server und die darüber die angeschlossenen Astro-Geräte zugeordnet werden.

Wir starten also Ekos und wählen ein Profil aus, starten Ekos/INDI und klicken dann auf “Connect”

Abbildung 1: Ekos Profile (Google Drive 20241221 Ekos.jpg)

Ekos Profil: INDI-Server

Wenn ich KStars (incl. Ekos) auf einem Linux-Rechner installiere bekomme ich automatisch einen lokalen INDI-Server mitinstalliert. Da kann ich also “localhost” als Namen meines INDI-Servers angeben.

Ekos Profil: Astrogeräte über INDI

Alle unsere Astro-INDI-Geräte werden nun in das Profil eingetragen.

Editieren (Bleistift-Symbol) kann man das Profil nur, wenn die INDI-Geräte “Disconnected” sind und der INDI-Server gestoppt wurde.

Bevor die einzelnen Astro-Geräte in das profil eingetragen werden, muss mann noch den “Mode” (Local oder Remote) angeben – das bezieht sich auf den INDI-Server. Danach muss man noch das Guiding angeben. “Internal” reicht.

Abbildung 2: Ekos Profil Editor (Google Drive: 20241222 Ekos.jpg)

Astro-Geräte steuern

Nachdem wir die im Profil genannten Geräte erfolgreich verbunden (connect) haben, erscheien im Ekos oben zusätzliche Reiter (“Ekos Modules”):

  • Kamera – CCD
  • Focus (mit Autofocus)
  • Mount (Find target, Go to, Parken)
  • Align (Plate Solving, Polar Alignment)
  • Guide (Auto Guiding, Dithering?)

Wenn wir auf einen der Reiter klicken, können wir Steuerungsfunktionen für das jeweilige Gerät ausführen.

Wichtig (und neu in Version 3.6.1) ist, dass wir zuerst einen “Optical Train” auswählen.

Abbildung 3: Beispiel: Ekos Modul Montierung (Google Drive: 20241221 Ekos)

KStars und Ekos unter VMware auf Windows

Zu bedenken ist, dass die per USB an die Host-Maschine angeschlossenen Astro-Geräte in einer Guest-Maschine (VM) erst verbunden werden müssen.

Astronomie Software: N.I.N.A. eine neue Software für die Astrofotografie

Gehört zu:  Astro-Software
Siehe auch: Fokussieren, Fotografieren mit N.I.N.A., Plate Solving mit N.I.N.A., Polar Alignment mit N.I.N.A., N.I.N.A. Advanced SequencerFlat Frames mit N.I.N.A., Mein Workflow mit N.I.N.A., INDI, KStars, APT, ASCOM, ASTAP,
Benutzt: Fotos aus Google Drive

Stand: 20.01.2024 (custom horizon)

Link:

Zusammenfassung / Quick Starter

N.I.N.A. ist eine Software für die Astrofotografie (ähnlich wie das etwas ältere APT). Das Konzept von N.I.N.A. ist möglicht viel (möglich alles) was der Astro-Foto-Mensch braucht unter einer einheitlichen und modern aussehenden Oberfläche anzubieten.

Da N.I.N.A. – ähnlich wie APT – sehr viel kann, ist es für den Anfänger nicht so leicht sich da zurechtzufinden…

Als Vorteile von N.I.N.A. könnte man sehen:

  • N.I.N.A. ist Open Source Software
  • Mit N.I.N.A. kann man sich quasi ein Cockpit für die Astrofotografie individuell konfigurieren (Imaging mit mehreren Panels und Reitern).
  • Mit N.I.N.A. kann man separat Ziele (Targets) beschreiben und diese später in automatisch ablaufende Sequenzen (aka APT Plan)  einbauen.
  • Mit N.I.N.A. Plugins kann man viele spezielle Erweiterungen integrieren.

Die vielen Funktionen realisiert N.I.N.A. auf verschiedenen Wegen:

  1. N.I.N.A. selbst hat “eingebaute” Funktionen (z.B. Kamerasteuerung, Montierungssteuerung, Sequencer,…)
  2. N.I.N.A. hat Schnittstellen zu externer Software (z.B. Platesolving, Autoguiding, Planetariumsprogramm,…)
  3. Für N.I.N.A. gibt es sog. Plugins ( z.B. Three Point Polar Alignment,…)

Da N.I.N.A. so fürchterlich viel kann, probiere ich Schritt für Schritt Teil-Funktionen aus, zu denen ich dann themenbezogene Einzel-Artikel geschrieben habe:

N.I.N.A. eine neue Software für die Astrofotografie

N.I.N.A. ist eine sog. Sequencing-Software; d.h. für die Astrofotografie können damit Sequenzen von Aktionen programmiert werden. Solche “Aktionen” können beispielsweise sein: Mache ein Foto, wechsele den Filter, mache ein Plate Solving, warte bis 3 Uhr morgens, bewege dich auf ein Target, mache ein Autofocussing u.v.a.m.

N.I.N.A. steht für “Nighttime Imaging ‘n’ Astronomy”

N.I.N.A. läuft unter Windows und ist kostenlos.

N.I.N.A. verbindet sich mit den Geräten über ASCOM oder per Native Driver.

Website: https://nighttime-imaging.eu/

N.I.N.A. arbeitet viel mit Platesolving und benutzt dazu externe Software wie:

Welcher externe Platesolver von N.I.N.A. eingesetzt wird, stellt man in der Konfiguration ein.

Gliederung dieses Artikels

  • Zusammenfassung (Quick Starter) s.o.
  • N.I.N.A. Download und Installation
  • N.I.N.A. Konfiguration
  • N.I.N.A. Benutzeroberfläche (Vertikale Leiste)
    • Equipment Tab
      • Verbindungen meiner Astro-Geräte mit N.I.N.A.
    • Sky Atlas Tab
    • Framing Tab
    • Flat Wizard Tab
    • Sequencing Tab
      • Legacy Sequencer
      • Advanced Sequencer
    • Imaging Tab: Customizing
    • Options Tab
    • Plugin Tab (neu ab N.I.N.A.Version2.00)
  • N.I.N.A. Konfigurations-Datei
  • Ein Praxis-Beispiel mit N.I.N.A.

N.I.N.A. Download und Installation

N.I.N.A. is an open source software released under the GNU General Public License v3.

N.I.N.A. – Versionen   

  • 1.09 vom 12. Oct. 2019
  • 1.10 BETA 16  (10. May 2020)
  • 1.10 HF3 (17. July 2020)
  • 1.11 Nightly Build (August 2021)
  • 2.00 BETA020 (27. Dec. 2021)
  • 2.00 vom 5. June 2022
  • 2.20 vom 26. March 2023
  • 2.30 HF2
  • 3.00 BETA

Download: https://nighttime-imaging.eu/download/

Eine Installation erfolgte auf:

Nach dem Download und der Installation von N.I.N.A. erfolgt der erste Aufruf und die Konfiguration.

N.I.N.A. Konfiguration (Einstellungen)

N.I.N.A.-Profile

Wenn man mehrere Teleskope hat und/oder an verschiedenen Standorten arbeitet, empfiehlt es sich mit sog. Profilen zu arbeiten.

Der Name des aktiven Profils wird in der N.I.N.A.-Titelleiste angezeigt.

SAVE Profile: so eine Funktion gibt es nicht – alle Änderungen am Profil werden sofort gespeichert

LOAD Profile: diese Funktion ist nur aktiv (Schaltfläche sonst ausgegraut), wenn keine Geräte connected sind.

Mit einem Profil werden von N.I.N.A. einige Einstellungen gespeichert:

  • Name des Profils
  • Der Standort mit seinen geografischen Koordinaten und ggf. dem “custom horizon” (unter “Options -> General ->Astrometry” sichtbar)
  • Brennweite des Teleskops
  • Der “Sky Atlas Image Folder” – dort wird der SkyAtlas installiert
  • Der “Image File Path” (unter Options -> Imaging -> File Settings)
  • Das “Image File Pattern” (unter Options -> Imaging -> File Settings)
  • Der “Default folder for sequence files” (unter Options -> Imaging -> Sequence)
  • Das ausgewählte Planetariums-Programm (Stellarium, Cartes du Ciel,…) (unter Options -> Equipment)

Die “Profiles” von N.I.N.A. werden in einem speziellen Ordner gespeichert.
In meinem Fall ist das der Pfad: c:\users\<name>\AppData\Local\NINA\profiles

Standorte und Horizont

Jedes N.I.N.A.-Profil bekommt einen Standort mit seinen geografischen Koordinaten. Das macht man unter Options -> General -> Astrometry.

Der an diesem Ort zu beachtende Horizont kann in der besonderen Horizont-Datei definiert werden, die wir in N.I.N.A. unter “Options -> General -> Astrometry -> Custom Horizon” angeben.

Abbildung 1: Horizont (Google Drive: NINA_Horizont-1.jpg)

Diese Horizont-Datei ist eine Text-Datei mit folgendem sehr einfachen Aufbau mit Azimut und Altitute Paaren:

Abbildung 2: Beispiel einer Horizont-Datei (Google Drive: NINA-Horizon-3.jpg.)

Was bewirkt so ein “custom horizon”?

Wenn wir so einen “custom horizon” eingestellt haben, gibt es zwei Effekte:

  1. In den Sichtbarkeits-Diagrammen wird dieser “custom horizon” zusätzlich angezeigt (z.B. Sky Atlas)
  2. Im Advanced Sequencer kann man auf diesen “custom horizon” Bezug nehmen z.B. “wait until above horizon”

Image File Path

Unter Options -> Imaging wird der File Path eingestellt (und auch der Path für “Targets” und “Templates”)

Image File Pattern

Unter Options -> Imaging wird eingestellt, aus welchen Teilen sich der Dateiname zusammenstzen soll

Planetariums-Programm

Unter Options -> Equipment wird auch das Planetariumsprogramm eingestellt.

  • Bei “Cartes du Ciel” als Planetariumsprogramm stelle ich in N.I.N.A. ein: Host “localhost” und Port “3292”.
  • Bei “Stellarium” als Planetariumsprogramm stelle ich in N.I.N.A. ein: Host “localhost” und Port “8090”.

Das Planetariumsprogramm wird lediglich dafür verwendet, um ein Target (also ein Beobachtungsobjekt mit die Rektaszension und Deklination) auszuwählen und an N.I.N.A. weiterzugeben.

Das Planetariumsprogramm (Cartes du Ciel oder Stellarium) wird nicht zur Telekopsteuerung (also nicht zum Goto) verwendet und muss also auch nicht mit dem Teleskop verbunden werden. Die Teleskopsteuerung wird von N.I.N.A. selbst durchgeführt (also Slew to Target, siehe unten: Einzel-Funktion Slew) auf Grund der von Planetariumsprogramm übernommenen Ziel-Koordinaten.

Das Planetariumsprogramm ist für N.I.N.A. so eine Art “Server” und muss natürlich gestartet werden bevor N.I.N.A. aufgerufen wird. Auch sind im jeweiligen Planetariumsprogramm (Cartes du Ciel oder Stellarium) einige Einstellungen erforderlich damit sie als “Server” funktionieren.

Sky Atlas Image Folder

Das Image Repository muss man erst herunterladen: Sky Atlas Image Repository von https://nighttime-imaging.eu/download/

Diesen Ordner entpacken und in N.I.N.A. im Tab Options->General einstellen bei “Sky Atlas Image Folder”: C:\Program Files\N.I.N.A. – Nighttime Imaging ‘N’ Astronomy\SkyAtlasImageRepository

Dann kann man den Tab “Sky Atlas” benutzen, um Targets auszusuchen und den Bildausschnitt einzustellen….

Plate Solving

Unter Options -> Plate Solving stellt man ein, welcher externe Platesolver von N.I.N.A. benutzt werden soll.
Wichtig für das Plate Solving sind auch die Einstellungen für “Pixel Size” und “Focal Length” (s.u.)
Beschreibung siehe: Plate Solving mit N.I.N.A.

Camera Pixel Size

Meine Kamera ZWO ASI294MC Pro hat eine Pixel Size von 4.63 µm.

In N.I.N.A. stelle ich das unter Options -> Equipment -> Camera ein.

Telescope focal length

Die Brennweite (focal length) der verwendeten Optik stelle ich in N.I.N.A. ein bei: Options -> Equipment -> Telescope

Auto Guiding (Verbindung)

Unter Equipment -> Guider stellt man eine Verbindung zu einer externen Software her, die von N.I.N.A. zum Auto Guiding benutzt werden soll.

Wenn ich da mit “PHD2 Guiding” verbinde, wird das automatisch aufgerufen mit dem aktuellen PHD2-Profil; d.h. die im PHD2-Profil genannten Geräte müssen dann auch schon verbunden sein.

Layouts von N.I.N.A.

Die Layouts von N.I.N.A. werden im gleichen Ordner wie die “Profiles”  (s.o.).
In meinem Fall ist das der Pfad: c:\users\<name>\AppData\Local\NINA\profiles

Für das gecustomizte Layout des Fenstes “Imaging” legt N.I.N.A. zu jeder Profile-Datei noch eine Layout-Datei mit dem Namensbestandtteil “dock” dort an.

Benutzeroberfläche: Linke vertikale Leiste

Wenn N.I.N.A. gestatet wird (Profile ignorieren) erscheint ganz links im Bild eine vertikale Leiste mit folgenden Tabs:

  • Equipment
  • Sky Atlas
  • Framing
  • Flat Wizzard
  • Sequencer
  • Imaging
  • Options
  • Plugins (neu seit N.I.N.A.-Version 2.00)

Zu den fett ausgezeichnenten Tabs (Equipment, Imaging, Options) habe ich weiter unten Einzelheiten beschrieben.

Equipment Tab: Verbindungen

Zuerst wollen wir unsere Geräte verbinden, das geht mit dem Equipment Tab.

Wenn wir den Equipment-Tab klicken, erscheit eine zweite vertikale Leiste mit folgenden Symbolen:

  • Camera
  • Filter Wheel
  • Focusser
  • Rotator
  • Telescope
  • Guider
  • Switch
  • Flat Panel
  • Weather
  • Dome
  • Safety Monitor

Hier kann (und muss) ich meine Astro-Geräte mit N.I.N.A. verbinden (“connect”).

Die wichtigsten Geräte im Equipment-Tab beschreibe ich weiter unten.

Sky Atlas Tab

Da muss man erst etwas herunterladen: Sky Atlas Image Repository von https://nighttime-imaging.eu/download/

Diesen Ordner entpacken und in N.I.N.A. im Tab Options->General einstellen bei “Sky Atlas Image Folder”: C:\Program Files\N.I.N.A. – Nighttime Imaging ‘N’ Astronomy\SkyAtlasImageRepository

Danach kann die Funktion benutzt werden; d.h. ich kann Beobachtungsobjekte in einem ausgewählten Sky Atlas suchen und bekomme dann Name, Himmelskoordinaten, Sichtbarkeits-Diagramm etc. des im Sky Atlas gefundenen Objekts angezeigt.
Mit so einem Objekt kann ich dann direkt in den Sequencer gehen oder erst einmal in den Framing Assistenten.

Abbildung 3: Sichtbarkeits-Diagramm mit Horizont (Google Drive: NINA_Horizon-2.jpg)

In den Sichtbarkeits-Diagrammen sieht man standadmäsig die nautische und die astronomische Dämmerung, sowie die astronomische Nacht.

Wenn wir einen “Custom Horizon” definiert haben, wir dieser zusätzlich angezeigt.

Framing Tab

Im Framing Tab kann ich für ein ausgewähltes Beobachtungsobjekt den gewünschten Bildausschnitt (“Frame”) genau einstellen. Dazu gehört ausser den Himmelkoordinaten der Bildmitte u.U. auch der Rotationswinkel und ggf. eine Mosaik-Definition.

Das Beobachtungsobjekt kann beispielsweise vom zuvor ausgeführten N.I.N.A. “Sky Atlas Tab” übergeben worden sein.

Als Beobachtungsobjekt kann ich auch ein im Planetariumsprogramm (z.B. Stellarium) ausgewähltes Himmelsobjekt übernehmen. Allerdings will der Framing Assistant ausser den Himmelskoordinaten auch noch das dazugehörige Foto laden, was eine Weile dauern kann. Schneller geht das, wenn oben im Faming Assistenten als “Image Source” die “Offline Sky Map” eingestellt ist.

Der so eingestellte Bildausschnitt (=Framing) des Beobachtungsobjekts kann dann als Target in den Sequencer übernommen werden.

Abbildung 4: Framinig Tab (Google Drive: NINA-Framing-02.jpg)


Im Sichtbarkeits-Diagramm sieht man, dass das Objekt (M45) vom gewählten Standort nur während der astronomischen Dämmerung sichtbar ist und dann hinter dem “Custom Horizon” (den Häuser) verschwindet.

Die Schaltfläche “Add target to sequence” würde den eingestellten Bildauschnitt (Frame) als “Target” in den Sequencer übergeben, wo wir Einzelheiten zum Fotografieren eintragen könnten…

Flat Wizard Tab

Den Flat Wizard habe ich ein einem separaten Blog-Artikel beschrieben.

Sequencer Tab

Hiermit kann man eine sog. einen “Target Set” festlegen.

Für jedes “Target” wird ein Beobachtungsobjekt angegeben und eine Sequenz von sog. “Sequence Entries” die alle nötigen Aktionen festlegen z.B. Wie viele Fotos, Belichtungszeiten, Filterwechsel etc.

Seit N.I.N.A.-Version 2.00 gibt es alternativ zum klassischen “Legacy Sequencer” einen sog. “Advanced Sequencer

Was der Legacy Sequencer nicht kann:

  1. Starten zu einer bestimmten Uhrzeit
  2. Einen “Custom Horizon” berücksichtigen

Ich brauche solche Funktionen, wenn ich ein bestimmtes Objekt fotografieren will, was bei meinem Horizot erst in der zweiten Nachthälfte sichtbar wird und ich zur dieser Zeit lieber im Bett liege…

Imaging Tab

Hiermit kann man Fotos machen. Die wichtigsten Einzelheiten zum Imaging-Tab beschreibe ich weiter unten.

Options Tab

Die wichtigsten Einzelheiten zum Options-Tab beschreibe ich weiter unten.

Plugins Tab (neu in Version 2.00)

Hier kann man sehen, welche Plugins für N.I.N.A. zur Verfügung stehen und welche Plugins tatsächlich installierten sind.
Interessant ist beispielsweise das Plugin zum Polar Alignment.

Equipment-Tab: Einzelheiten

Equipment: Camera verbinden

Wir gehen links auf den Equipment-Tab und dann auf Camera.

Aus dem Drop-Down kann ich meine Haupt-Kamera die ZWO ASI292MC Pro mit native driver auswählen (im Drop Down unter ZWOptical). Nur mit native driver funktioniert später der Live View. In N.I.N.A. Version 2.0 wurde der Live View entfernt.

Schießlich klicke ich oben auf die Schaltfläche “Connect”

Abblidung 3: N.I.N.A. Equipment – Camera  – Connect (Google Drive: NINA-Camera-Connect.jpg)


NINA-Camera-Connect

Equipment: Telescope verbinden

Wir gehen links auf den Equipment-Tab und dann links auf Telescope.

Aus dem Drop-down wähle ich “EQMOD ASCOM HEQ5/6” (nicht EQMOD HEQ5/6).

Schießlich klicke ich oben auf die Schaltfläche “Connect”

N.I.N.A. prüft nun, ob die geografischen Koordinaten des in N.I.N.A. eingestellten Beobachtungsorts mit denen des ASCOM-Treibers des Teleskops übereinstimmen. Im Falle einer Abweichung schlägt N.I.N.A. eine “Synchronisation” vor, wobei die Richtung entweder vom Teleskop zu N.I.N.A. oder von N.I.N.A. zum Teleskop vorgenommen werden kann. Das sollte man auf keinen Fall ignorieren. Bei mir war es nicht möglich von N.I.N.A. zum Teleskop zu synchronisieren, also war es unbedingt erforderlich eine Synchronisation vom Teleskop zu N.I.N.A. vorzunehmen.

Equipment: Guider verbinden

Wir gehen links auf den Equipment-Tab und dann links auf Guider.

Aus dem Drop Down wähle ich “PHD2” .

Schießlich klicke ich oben auf die Schaltfläche “Connect”   (vorher muss allerdings PHD2 Guiding gestartet sein)

Equipment: Focuser verbinden

Wir gehen links auf den Equipment-Tab und dann links auf Focusser.

Aus dem Drop Down wähle ich “Pegasus Astro Focus Controller” (weil ich als Controller für meinen Motor-Focusser immer noch den Pegasus nehme…). Aktuell habe ich den ZWO EAF an meinem Teleskop und den Astromechanics-Adapter für meine Canon-Fotoobjektive.

Schießlich klicke ich oben auf die Schaltfläche “Connect”

Equipment: Rotator verbinden

Wir gehen links auf den Equipment-Tab und dann links auf Rotator.

Im Drop Down kann ich manual auswählen, dann bestimmt das Plate Solving den Ist-Drehwinkel des Bildes und N.I.N.A. sagt mir wenn mein geplanter Drehwinkel ein anderer war und hilft bei der Korrektur.

Schießlich klicke ich oben auf die Schaltfläche “Connect”

Equipment: Filterwheel verbinden

Wir gehen links auf den Equipment-Tab und dann links auf Filter Wheel.

(habe ich nicht)

Imaging-Tab: Einzelheiten (Customizing the Imaging Tab)

Wenn wir in der ganz linken Leiste auf “Imaging” klicken, erscheint ein Fenster namens “Imaging”. Dieses kann ganz flexibel in Unter-Fenster aufgeteilt werden – je nach persönlichen Vorlieben.

Wie ich das mache habe ich in Fotografieren mit N.I.N.A. beschrieben.

Options Tab: Einzelheiten

Wenn wir auf den Options-Tab in der ganz linken Leiste klicken, erscheint links eine weitere Leiste:

  • General
  • Equipment
  • Autofocus
  • Dome
  • Imaging
  • Platesolving

Options: Equipment Tab – Planetariums-Software

Bein Erstellen einer Sequenz mit Hilfe des Framing-Assistenten können die Daten des gewünschen Beobachtungsobjekts vom Planetariums-Programm in N.I.N.A. übernommen werden.

Deshalb gehen wir links auf den Reiter “Options” und dann oben auf den Reiter “Equipment”.

Dort stellen wir im Bereich “Planetarium” im Drop Down “Preferred Planetarium Software” unser gewünschtes Planetariums-Programm ein (im Beispiel: Cartes du Ciel).

Abbildung 4: N.I.N.A. Planetarium (Google Drive: NINA_Planetarium_Software.jpg)

Options: Plate Solving Tab

Plate Solving wird von N.I.N.A. an mehreren Stellen im Ablauf automatisch benutzt. Deshalb ist es wichtig, das am Anfang einmal sorgfältig zu konfigurieren und zu testen (Siehe auch: Plate Solving mit N.I.N.A.)

Wir gehen links auf den Reiter Options und dann oben auf den Reiter Plate Solving.

Abbildung 5: N.I.N.A. Plate Solving Settings (Google Drive: NINA-PlateSolving-Settings)

Dort müsen wir nun einstellen welche Software wir als “Plate Solver” (im Beispiel ASTAP) einsetzen wollen und welche Software als “Blind Solver” (im Beispiel All Sky Plate Solver) eingesetzt werden soll.

Dabei meint N.I.N.A. hier mit “Plate Solver” einen “Near Solver”.

Die so ausgewählte Software muss natürlich auf dem Computer installiert sein. Die Dateipfade zu der zu Plate Solving  ausgewählten Software muss im unteren Bereich dann angegeben werden.

Da N.I.N.A. extrem viel mit Platesolving macht, müssen die Pfad-Einstellungen für die lokalen Platesolver gemacht werden und möglichst im Profil gespeichert sein – sonst: “Executable not found”

Options: Imaging Tab

Hier können wir diverse Einstellungen für unsere Imaging Session vornehmen. Dies ist gegliedert nach:

  • File Settings
  • Meridian Flip Settings
  • Image Options
  • Sequence
  • Layout

Konfigurationsdatei von N.I.N.A.

Es gibt eine Konfigurationsdatei NINA.exe.config (im Programm-Ordner), die u.a. sagt, wo die N.I.N.A.-Datenbank gespeichert ist.
In meinem Fall ist das der Pfad: c:\users\<name>\AppData\Local\NINA\NINA.sqlite

Abbildung 6: N.I.N.A. Konfigurationsdatei (Google Drive: NINA-Database.jpg)

Dies ist eine SQLite-Datenbank und ich kann sie mit den entsprechenden Tools bearbeiten (zuerst mal anschauen, später vielleicht ergänzen)…

In der SQLite-Datenbank befinden sich folgende Tabellen:

  • brightstars(name, ra, dec, magnitude, syncedfrom)
  • visualdescription
  • dsodetail(id, ra, dec, magnitude,…)
  • constellationstar
  • constellationboundaries
  • constellation
  • cataloguenr(dsodetailid, catalogue, designation)
  • earthrotationalparameters

Die Tabelle “cataloguenr” zeigt mit dem Fremdschlüssel “dsodetailid” auf den Primärschlüssel “id” in der Tabelle “dsodetail”.

Die Tabelle “brightstars” kann beispielsweise leicht um Objekte ergänzt werden, die man in der N.I.N.A.-Funktion “Manual Focus Tragets” haben möchte. In dieser Funktion ist dann ein “Slew” möglich…

Z.B. Alpha Cephei “Alderamin” RA=319,646 Dekl=62,5850    (Achtung es muss tatsächlich in Grad und mit Dezimalstellen eingegeben werden!!!)

Die Sterne in dieser Tabelle können bei “Manual Focus Targets”  (diesen Reiter aktivieren durch Klicken auf das Symbol “Stern” oben rechts)…

 

N.I.N.A. Praxisbeispiel: M92

N.I.N.A. Einzelfunktion: Framing

Nachdem wir nun N.I.N.A. installiert und eingerichtet haben, können wir nun endlich ein echtes Astro-Objekt fotografieren. Dazu wollen wir zuerst für das ausgewählte Astro-Objekt den genauen Bildausschnitt festlegen (“Framing”) und das dann als sog. “Sequence” abspeichern.

Wir wählen also ein Astro-Objekt (im Beispiel M92) in unserer Planetariums-Software (im Beispiel ist das Cartes du Ciel) aus.

Dann gehen wir in N.I.N.A. auf den Reiter “Framing”.

Wenn wir im Bereich “Coordinates” auf das Symbol neben dem Wort “Coordinates” klicken, wird das Objekt aus der Planetariums-Software mit seinen Koordinaten in N.I.N.A. übernommen. Alternativ können wir auch den Namen eines Astro-Objekts im Feld “Name” direkt eingeben und die Koordinaten werden übernommen.

Wir können auch auf die Schaltfläche “Load Image” klicken. Dann wird rechts im Hauptfenster ein Foto des Objekts angezeigt, wobei das Bild sogroß wird, wie im Feld “Field Of View” angegeben.

Der Bildauschnitt wird bei gegebener Sensorgröße bestimmt durch die Brennweite; diese sollten wir kontrollieren und ggf. hier richtig eingeben. Dann erscheint ein Kästchen, das den Bildausschnutt zeigt. Dieses Kästchen können wir noch ein bisschen hin und her schieben. Mit dem Mausrad (oder den Symbolen oben) kann man auch in das Bild hineinzoomen oder herauszoomen.

Abbildung 7: N.I.N.A. Framing on Target M92 (Google Drive: NINA-Framing-01.jpg)

Am Ende speichern wir da Ganze als sog. “Sequenz” ab (“Replace as”), dabei werden die Koordinaten des Frame-Mittelpunkts an die Sequence übergeben.

N.I.N.A. Einzel-Funktion Sequence

Nachdem wir mit hilfe des Framing-Assitenmten (s.o.) eine “Sequence” erstellt haben, können wir nun diese Sequence noch ein wenig bearbeiten und dann speichern (oder gleich ausführen).

In unserer Sequence haben wir ein “Target” wofür wir jetzt noch Einzelheiten (z.B. Anzahl Einzelbilder, Belichtungszeit, Gain,…) festlegen können.

Ich schalte auch “Slew to target” und “Center target” an. Dann wird das Teleskop vor der ersten Aufnahme auf das Beobachtungsobjekt (“Target”) geschwenkt (= Goto) und genau auf den Bildmittelpunkt eingestellt (“Center”). Für letzteres wird – ohne das man irgendetwas tun muss – Plate Solving eingesetzt.

Abbildung 8: N.I.N.A. Sequence (Google Drive: NINA-05.jpg)

Wenn man eine “Sequence” testweise durchgeführt hat und danach etwas ändern will und die Sequence nocheinmal ausführen will, so geht das ersteinmal nicht. Die Sequence muss erst wieder “aktiv” gesetzt werden…

Abbildung 9: N.I.N.A. Sequence ausführen (Google Drive: NINA-06.jpg)

Astronomie: Computer StellarMate

Gehört zu: Astrofotografie
Siehe auch: Polar Alignment, ASIAir, INDI, KStars, Linux, RasperryPi
Benutzt: Fotos aus Google Drive

Stand: 1.1.2023

StellarMate: Ein kleiner Astrofotografie-Computer

Anstelle von ausgewachsenen Windows-Computern hört man in letzter Zeit (heute ist Juli 2019) immer öfter von kleinen Geräten, wie “StellarMate” (von der Firma Ikarus Technologies), die den “großen” Windows-Computer in der Astrofotografie ablösen sollen..

StellarMate ist eine kleine Kiste (ein Rasberry Pi Computer), den man an seine Montierung bzw. das Teleskop hängt, und der einiges kann…..

Ähnliche Produkte sind u.a.

StellarMate ist ein kleiner Computer, mit dem man ohne traditionelle Computer Astrofotografie betreiben können soll – das Ding wird als “Astrofotografie-Computer” bezeichnet.

Es geht ja um eine Lösung zur Astrofotografie, die aus Hardware und Software besteht. Zum Testen der Software verwende ich als ersteinmal in aller Ruhe eine Virtuelle Maschine mit Ubuntu MATE. Wenn das alles wirklich funktioniert, werde ich mich mit der Hardware-Plattform beschäftigen.

Am Ende meiner Weisheit (2020) bin ich reuemütig wieder bei einem kleinen Windows-Computer, der remote über WLAN bedient wird, gelandet.

Eigenschaften des StellarMate

  • Computer: Der StellarMate-Computer basiert auf einem Raspberry PI 3B+,
  • Betriebssystem: StellarMate OS auf der Basis von LINUX
  • Astro-Plattform: INDI   (nicht ASCOM)
  • Stromversorgung des StellarMate: 5 V
    USB: Der StellarMate hat 4 USB 2.0 Anschlüsse und fungiert so also auch als USB-Hub
  • 1 HDMI Anschluss
  • 1 Ethernet-Anschluss
  • WiFi/WLAN: StellarMate spannt einen WLAN Access Point auf, über den sich ein Tablet mit dem StellarMate verbinden kann. Auf dem Tablet läuft dann eine StellarMate-App.
    • StellarMate kann sich auch als WLAN-Client in ein vorhandenes WLAN einmelden.
  • Kameras: StellarMate unterstützt viele Astro-Kameras und auch DSLRs – letztere über INDI und USB
  • Montierungen: StellarMate unterstützt und viele gängige Montierungen (siehe INDI Driver).
  • Steuerung der primären Kamera (am Teleskop) z.B. DSLR Canon EOS 600D
    Speicherung der Fotos auf der SD-Karte der Canon
  • Plate Solving:
    • Welcher Platesolver soll benutzt werden: Einstellbar: “online” d.h. über das Internet auf astromertry.net bzw. Ansvr, “offline”d.h. der Solver auf MacOS oder LINUX oder “remote” d.h. der Solver auf dem StellarMate
    • Was soll nach einem erfolgreichen Platesolving gemacht werden? (wird “Solver Action” genannt): Einstellbar: SYNC, Slew to Target, Nothing
  • Polar Alignment: Das Polar Alignment konnte in früheren Versionen ausschließlich mit der “Main Camera” vorgenommen werden. Jetzt geht es auch mit der “Guide Camera”
  • Autoguiding wahlweise über ST4 oder Pulse Guiding  – mit den “internen Guider” oder auch einem externen…. (PHD2 Guiding???)
    Als Guiding-Kamera dient meine vorhandene Altair-Cam….
  • Motor Focusser: not supported

Erste Schritte mit StellarMate: Einrichten von Stellarmate

Heute am 18.1.2020 kam der StellarMate bei mir per DHL an.

Das StellarMate-Kästchen gehört lokal an das Teleskop; die Bedienung kann remote von einem Laptop über KStars und Ekos erfolgen.

  1. Einen Account eröffnen bei stellarmate.com   (mit E-Mail Verification)
  2. Das Stellarmate-Gerät registrieren: /support/licences.html (dazu muss man die Seriennummer des Geräts eingeben)
  3. KStars auf dem Windows-Computer aufrufen  (alternativ: StellarMate App auf Apple oder Android)
  4. Innerhalb von KStars Ekos aufrufen: KStars-Menüleiste: Tools -> Ekos
  5. Im Ekos ein Profil einrichten; dabei
    1. INDI-Server “remote host” und dann nicht “localhost”, sondert die IP-Adresse des Stellarmate-Geräts (bei mir: 192.168.1.140)
    2. Select Devices: ….
    3. Select Telescops: ….

Ekos zeigt immer diese drei Reiter: “Select Profile”, “Start & Stop Ekos” und “Connect & Disconnect Devices”.
Im Ersten Reiter “Select Profile” legen wir ein neues Ekos-Profil an, indem wir au das “+” klicken (s. Bild)

Abbildung 1: Software Ekos: Select Profile (Google Drive: Stellarmate-03.jpg)

Das neue Ekos-Profil bekommt einen Namen “HEQ5” unter dem wir es später abspeichern und danach aus dem Drop-Down einfach auswählen können.

Wichtig ist. dass wir als “Mode” “Remote Host” auswählen, wenn wir von einem Windows-Computer über das Netzwerk auf den StellarMate-Computer zugreifen wollen.

Weiterhin können wir in dem Profile unsere “Devices” und “Telescopes” angeben.

Abbildung 2: Software Ekos: Profile Editor (Google Drive: Stellarmate-04.jpg)

Nachdem wir Ekos-Profile eingerichtet haben, wählen wir eines aus, mit dem wir jetzt arbeiten wollen und klicken unter dem Reiter “Start & Stop Ekos” auf das Start-Symbol (Dreck mit Spitze nach rechts).

Abbildung 3: Software Ekos: Start (Google Drive: Stellarmate-05.jpg)

Jetzt versucht das Programm eine Verbindung zum INDI-Server auf dem StellarMate-Gerät herzustellen. Dazu muss das StellarMate über unser Netzwerk per TCP/IP erreichbar sein (Testen mit einem Ping) und der INDI-Server muss mit dem Ekos als INDI-Client über das INDI-Protokoll “sprechen” können (Test, ob der INDI-Server läuft).

Wie das Bild unten zeigt, funktioniert das leider nicht immer…   “Failed to connect to remote INDI server”

Abbildung 4: Software Ekos: Failed to connect (Google Drive: Stellarmate-06.jpg)

Nach vier Stunden probieren funktionierte es manchmal lokal (mit VNC sichtbar gemacht), aber “remote” ging niemals etwas; weder mit dem StellarMate als WLAN Access Point noch wenn der StellarMate sich in mein heimisches WLAN eingeloggt hatte.

Nun könnte man noch weitere Stunden herumprobieren z.B. mit einen Bildschirm über HDMI am StellarMate etc. etc. pp. oder….

Also RETOURE an astroshop.de

Astronomie: INDI

Gehört zu: Astro-Software
Siehe auch: ASCOM, KStars, Ekos, ASIair, StellarMate , N.I.N.A., Linux

Stand: 3.1.2022

Was ist INDI?

INDI ist eine Astro-Plattform, die alle möglichen astronomischen Geräte ansteuern kann und zur anderen Seite ein einheitliches Protokoll zum Zugriff durch Astro-Software auf diese Geräte bietet. In soweit ist INDI also vergleichbar mit ASCOM.

So ein INDI mit INDI-Server und INDI-Drivers (s.u.) läuft nicht unter Windows, sondern nur unter Linux oder MacOS. Für Windows gibt es einen Wrapper, der INDI über ASCOM realisiert; d.h. es werden nur ASCOM-Geräte unterstützt (also z.B. nicht Canon DSRLs) und auch immer nur über die ASCOM-Treiber…

Version: Für Ubuntu 18.04
Downlaod INDI Library: https://indilib.org/download.html

INDI Server

Kernstück von INDI ist der INDI-Server.

Ein INDI-Server kann zu einem oder mehreren INDI-Clients verbunden werden. Die Verbindung kann über das Netzwerk hergestellt werden (sog. Verbindungstyp “remote”).

Zur Kommunikation zwischen INDI-Server und INDI-Clients dient das sog. INDI-Protokoll.

Der INDI-Server verbindet sich dan andererseits mit den Astro-Geräten (z.B. Montierung, Kameras, Motor-Fokusser,…). So eine Verbindung zu einem Astro-Gerät wird mit Hilfe eines INDI-Drivers hergestellt.

INDI Library

INDI Library is an Open Source Architecture for Control & Automation of Astronomical Devices. Powered by the community for the community.

Unter der INDI-Library versteht man einen INDI-Server zusammen mit INDI-Drivern für die Astro-Geräte.

INIDI-Driver gibt es für viele Astro-Geräte, nicht nur solche, für die wir ASCOM-Treiber haben. Beispiel: DSLRs.

Platform für INDI Server / Library

INDI Lib gibt es für die Linux Distribtion:

  • Ubuntu (Debian based –> Package Manger)
  • Ubuntu Mate
  • Mint Cinnamon  (Verschiedene Desktops: Cinamon, Mate, XFCE,…)
  • Fedora
  • Gentoo
  • Rasberry Pi Linux  – astroberry
  • xyz

INDI Server/Library installieren

Auf dem Linux-Computer im Terminal:

1. INDI Library is available for Ubuntu 16.04 and higher. To install stable INDI Library, run the following commands:

sudo apt-add-repository ppa:mutlaqja/ppa
sudo apt-get update

2. To install INDI with all Third-Party-Drivers:

sudo apt-get install indi-full gsc

INDI Server/Library starten und stoppen

Das Starten des INDI-Servers geht so:

Nachdem INDI installiert ist müssen wir nur noch den INDI-Server starten…

cd /usr/bin
./indiserver indi_asi_ccd    (hat funktioniert mit ASI an USB 2.0)

oder:

./indiserver indi_altair_ccd    (hat funktioniert mit GP-CAM an USB 2.0)

Es wird der INDI-Server gestartet zusammen mit ein oder mehreren INDI-Drivern – es muss mindestens ein Driver sein.

Das Starten des INDI-Servers kann auch über den INDI-Web-Manager erfolgen.

Zum Starten und Stoppen es INDI-Servers gibt es auch ein kleines Hilfsprogramm names “indistarter” (unter Linux):

https://github.com/pchev/indistarter/wiki

Das Stoppen des INDI-Servers geht so:

xyz

Zusätzliche Astro Dienste

Für den Betrieb als Astro-Server sind ausser INDI noch einige andere Dienste erforderlich bzw. nützlich:

  • INDI Web Manager
  • Remote Desktop
  • Plate Solving

INDI Web Manager

Installieren auf Ubuntu Mate:

  • sudo apt-get install python3-pip
  • sudo -H pip3 install indiweb

Der Schritt2 dieser Installation hat unter Linux Mint nicht funktioniert. Ich bin dann auf Linux Mate gewechselt; dort hat diese Installation des INDI Web Managers geklappt.

Der INDI Web Manger ist offensichtlich ein Python Skript

Starten auf Ubuntu Mate

Der Start des INDI Web Managers kann ganz einfach manuell erfolgen:

/usr/local/bin/indi-web

Als Linux-Service (Linux-Jargon: Daemon) wird der INDI Web Service so gestartet:

sudo pluma /etc/systemd/system/indiwebmanager.service

Mit der Datei inidiwebmanager.service

[Unit]
Description=INDI Web Manager
After=multi-user.target

[Service]
Type=idle
User=astroberry
ExecStart=/usr/local/bin/indi-web -l /var/log/astroberry/indiwebmanager.log
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Als Startup Application

xyz

XXXXX

sudo cp indiwebmanager.service /etc/systemd/system/
sudo chmod 644 /etc/systemd/system/indiwebmanager.service
Now configure systemd to load the service file during boot:
sudo systemctl daemon-reload
sudo systemctl enable indiwebmanager.service

Finally, reboot the system for your changes to take effect:

sudo reboot

After startup, check the status of the INDI Web Manager service:

sudo systemctl status indiwebmanager.service

If all appears OK, you can start using the Web Application using any browser.

Remote Desktop

Auf AstroBerry wird Remote Desktop über den “noVNC Server” realisiert.

Installieren auf Ubuntu Mate:

  • sudo apt-get update -y
  • sudo apt-get install -y websockify

Starten auf Ubuntu Mate:

Das Starten des noVNC Servers kann einfach manuell erfolgen:

/usr/bin/websockify

Oder als Service (Linux: Daemon)

sudo pluma /ect/systemd/system/novnc.service

Mit der Datei novnc.service

[Unit]
Description=”noVNC”
After=multi-user.target vncserver-x11-serviced.service

[Service]
User=astroberry
ExecStart=/usr/bin/websockify –log-file=/var/log/astroberry/novnc.log –web=/var/www/novnc/ 8080 localhost:5900
ExecStop=/usr/bin/pkill websockify
Restart=on-failure
RestartSec=3

[Install]
WantedBy=multi-user.target

Plate Solving

xyz

INDI Clients

Mit einem INDI-Client wird der INI-Server über eine grafische Benutzeroberfläche (GUI) gesteuert.

Klassisch ist KStars mit dem eingebauten Ekos so ein INDI-Client, der auch auf Windows läuft.

Aber auch andere Astro-Programme haben INDI-Client-Fähigkeiten; beispielsweise PixInsight, Cartes du Ciel, Stellarium,…

Auch PHD2 Guiding kann für “INDI Kamera” und “INDI Montierung” konfiguriert werden.

KStars und Ekos

KStars ist eine Planetariums-Software, die auf vielen Plattformen läuft.

KStars enthält Ekos.

Ekos ist eine “Astro-Fotografie-Suite”, die sich als grafischer INDI-Client verhält; d.h. es wird ein INDI-Server benötigt, der typischerweise auf einem separaten kleinen Computer läuft (z.B. eine Rasberry Pi). Der INDI-Server kann aber auch auf dem gleichen Rechner laufen wie der INDI-Client, dann wird die Verbindung vom INDI-Server zum INDI-Client aber trotzdem als “remote” konfiguriert, selbst wenn der “remote” Computer einfach der lokale Computer ist.

Ekos Konfiguration als INDI-Client

Zuerst rufen wir KStars auf. Dort gehen wir zu Ekos.

Damit Ekos richtig als INDI-Client funktioniert, muss eine Verbindung zum INDI-Server hergestellt werden.

INDI Funktionen

Alle INDI-Funktionen werde über einen INDI-Client (z.B. Ekos) gesteuert. Das kann also in aller Regel “remote” erfolgen. Der INDI-Server ist an der Montierung, der INDI-Client ist “remote” z.B. im Auto oder im Wohnzimmer…

Polar Alignment

Fokussierung

Goto

Plate Solving läuft über astrometry.net …

Autoguiding

 

Astronomie: Extrasolare Planeten – Exoplaneten

Gehört zu: Astronomie
Siehe auch: Entwicklung des Teleskops

Exoplaneten – was ist das?

Exoplaneten sind Planeten, die andere Sterne (nicht die Sonne) umkreisen.

Bis Ende 2019 wurden ingesammt 4160 Exoplaneten entdeckt.

Historie

  • Gamma Cephei b: wurde bereits in 1989 Jahren als extrasolarer Planet entdeckt  –> später widerrufen –> später neu bestätigt
  • 1992 wurden drei Planeten, die den Pulsar PSR 1257-12 umkreisen entdeckt
  • 1994 wurde ein Planet, der den Pulsar PSR B1620-26 umkreist entdeckt
  • 1995 wurde der Exoplanet 51 Pegasi b entdeckt, der als erster Exoplanet einen sonnenähnlichen Stern umkreist  (keinen Pulsar)
  • 2019 wurden Michel Mayor und Didier Queloz für die Entdeckung des Exoplaneten 51 Pegasi b mit dem Nobelpreis für Physik ausgezeichnet

Entdeckungsmethoden

  • Radialgeschwindigkeits-Methode  (seit 1995)
  • Transit-Methode (seit 1999)
  • Direkte Beobachtung (seit 2004)
  • Astrometrische Methode  “Imaging”   (Positionbestimmungen bei Draufsicht –> bisher mit wenig Erfolg, wegen der erforderlichen hohen Genauigkeiten, Versuche mit dem Satelliten Gaja)
  • u.a.

Das Weltraumteleskop Kepler

Im Jahre 2009 wurde die äußerst erfolgreiche Kepler-Mission gestartet.

Bis 2013 wurden mit dem Weltraumteleskop Kepler über 2000 Exoplaneten entdeckt.

Die sog. “habitable Zone”

Unter anderem stellt man sich ja die Frage, ob es Leben auf Exoplaneten geben könnte.

Als habitable Zone bezeichnet man im Allgemeinen den Abstandsbereich, in dem sich ein Planet von seinem Zentralgestirn befinden muss, damit Wasser dauerhaft in flüssiger Form auf der Oberfläche vorliegen kann. Dies gilt als Voraussetzung für erdähnliches Leben.

Wenn sich ein Exoplanet also in einer solchen Entfernung von seinem Zentralgestrin befindet, könnte möglicherweise “erähnliches Leben” exisitieren, wäre damit alleine aber keineswegs nachgewiesen. Zusätzlich spielen ausser der Entfernung vom Zentralgestirn noch andere Parameter wie z.B. das Vorhandensein einer Atmosphäre eine Rolle. Ausserdem, könnte “Leben” ja auch in ganz anderer Form, als uns von der Erde bekannt, exisitieren….

Protoplanetare Scheiben – Sternentstehung

Wenn die Urwolke, aus der ein Stern entsteht, anfangs nur einen winzigen Drehimplus haben sollte, kann sich daraus eine sog. protoplanetare Scheibe bilden, aus der dann in der Folge Planeten (also Expoplaneten) entstehen.

Die ersten protoplanetaren Scheiben wurden 1994 von C. Robert O’Dell und Mitarbeitern mit dem Hubble-Weltraumteleskop im Orionnebel beobachtet; in diesem Sternentstehungsgebiet sind etwa 50% aller jungen Sterne von einer protoplanetaren Scheibe umgeben.

1998 wurde erstmals eine Scheibe um einen massiven Stern gefunden.

Mit Hilfe von Adaptiver Optik kann man von der Erdoberfläche (z.B. Chile) solche protoplanetaren Scheiben fotografieren.

Die Drake-Gleichnung

Die Drake-Gleichung dient zur Abschätzung der Anzahl der technischen, intelligenten Zivilisationen in unserer Galaxie, der Milchstraße. Sie wurde von Frank Drake, einem US-Astrophysiker, 1961 vorgestellt.

Die Formel wird häufig bei Überlegungen in Bezug auf die Suche nach extraterrestrischem Leben herangezogen. Es handelt sich bei der Gleichung um ein Produkt, von dem die meisten Faktoren unbekannt sind. Waren Drakes ursprüngliche Berechnungen sehr optimistisch, was die Möglichkeit von außerirdischem Leben angeht, so kommen jüngste Lösungen einer Abwandlung der Gleichung unter Einbeziehung von Wahrscheinlichkeitsverteilungen von Sandberg, Drexler und Ord (2018) zu ernüchternden Ergebnissen und legen eine nur geringe Wahrscheinlichkeit von außerirdischem Leben innerhalb und außerhalb der Milchstraße nahe.

wobei:

N die mögliche Anzahl der außerirdischen Zivilisationen in der Galaxis an, die in der Lage und gewillt wären, zu kommunizieren
R* mittlere Sternentstehungsrate pro Jahr in unserer Galaxie
fp Anteil an Sternen mit Planetensystem
ne durchschnittliche Anzahl der Planeten (pro Stern) innerhalb der Ökosphäre
fl Anteil an Planeten mit Leben
fi Anteil an Planeten mit intelligentem Leben
fc Anteil an Planeten mit Interesse an interstellarer Kommunikation
L Lebensdauer einer technischen Zivilisation in Jahren

 

Astronomie: Polar Alignment with AlignMaster

Gehört zu: Einordung “Polar Alignment
Siehe auch: Polar Alignment mit SharpCap

Polar Alignment mit der Software “AlignMaster”

AlignMaster ist eine Windows-Software, die das Einnorden/Einsüden (Polar Alignment) für ASCOM-Montierungen und LX200-kompatible unterstützt.

Die Software AlignMaster ist nur für Windows-Computer verfügbar.

Es ist keine freie Sicht auf den Himmelpol erforderlich. Die Software arbeitet mit einem 2-Star-Alignments zur präzisen Einstellung von Azimut und Pohlhöhe.

YouTube AstronomyShed: https://youtu.be/dNRFm3LtCrE

[embedyt] http://www.youtube.com/watch?v=dNRFm3LtCrE[/embedyt]

Download

Autor: Matthias Gazarolli

Kosten: 30 Tage Probe, dann XX Euro (?)

Version 1.7 vom xxx

Downloads:

Astronomie: Polar Alignment mit SharpCap

Gehört zu: Polar Alignment
Siehe auch: SharpCap, Polar Alignment mit QHY PoleMaster, ComputerFlachmann, PHD2 Guiding, Polar Alignment mit N.I.N.A.
Benutzt: Fotos aus Google Archiv

Stand: 09.12.2022

Methoden zum Polar Alignment – Einnorden – Einsüden

Wenn ich eine äquatoriale (parallaktische) Montierung habe, so muss diese “Eingenordet” werden, d.h. die Stundenachse der Montierung muss parallel zur Drehachse der Erde ausgerichtet werden.

Wenn die Montierung dauernd an einem festen Platz aufgestellt ist, d.h. “stationär“, muss man das vielleicht einmal im Jahr machen und es macht nichts aus, wenn das etwas dauert und evtl. auch einige Verrenkungen erfordert. Wenn die Montierung “mobil” ist, also Tag für Tag an wechselnden Orten neu aufgestellt wird, möchte man die Einnordung möglichst in kurzer Zeit und ohne körperliche Belastungen durchführen können.

Siehe hierzu auch: Meine mobilen Montierungen

Eine weitere Frage bei der Einnordung ist die anzustrebende Genauigkeit. Dabei wäre die Frage, welche Auswirkungen eine fehlerhafte Polausrichtung auf das geplante astronomische Vorhaben hätte.

  • Bei rein visueller Beobachtung muss die Genauigkeit nicht besonders groß sein.
  • Beim Fotografieren hängt die erforderliche Genauigkeit der Poljustierung von der Art der Nachführung (nur Rektaszension, auch Deklinaktion) der Genauigkeit der Nachführung durch die Montierung, sowie von Belichtungszeit, Brennweite, Pixelgröße, Sensor-Größe etc. ab.
    Beispiel: Ein Fehler in der Polausrichtung um 60 Bogenminuten ergibt für ein Objekt am Himmelsäquator (Dekl.=0 Grad) ohne Autoguiding nur mit dem Tracking der äquatorialen Motierung eine maximale mittlere Drift von 60 Bogenminuten in 6 Stunden; also 10 Bogensekunden pro Minute Belichtungszeit (bei anderen Deklinationen: Cosinus).

Die Genauigkeit der Nachführung durch die Montierung (nur Tracking, nicht Autoguiding) lässt sich mit dem Guiding Assistent von PHD2 Guding sehr schön visualisieren…

Einen Überblick über verschiedene Methoden zur Polausrichtung habe ich in einem separaten Beitrag versucht. Dort habe ich auch berechnet, welche Auswirkungen eine ungenaue Polausrichtung (also wie viele Bogenminuten zeigt die Drehachse meiner Montierung neben den Himmelspol) hat.

Begonnen habe ich mein Einnorden mit dem Polfernrohr meiner Montierung und der sog. Kochab-Methode, die ich von Hartwig Lüthen bei der GvA gelernt hatte.
Meine Montierung ist “mobil” und wird praktisch ausschließlich zur Astrofotografie benuzt. Deshalb muss die Genauigkeit meiner Polausrichtung schon recht gut sein (besser als 2′) und es sollte schnell und bequem gehen. Daher habe ich als zweiten Ansatz dann die Polausrichtung mit QHY PoleMaster gemacht – was hier im Norden sehr gut ging, aber teuer war.

Die QHY PoleMaster war nicht nur recht teuer, sondern beim Verfahren zur software-gestützten Polausrichtung musste man quasi manuell Sternmuster in der Polnähe erkennen – ein richtiges Plate Solving war das nicht. Als SharpCap mit einer echten Plate-Solving-Methode zum Polar Alignment heraus kam, habe ich das ausprobiert und bin jetzt dabei geblieben. Meinen QHY PoleMaster habe ich gebraucht verkauft.

Neuerdings gibt es ein Plugin für N.I.N.A. mit dem man auch ohne ein zusätzliches Guiding-Rohr und ohne notwending einen freien Blick auf en Himmelspol zu haben sehr gutes und schnelles Polar Alignment machen kann.

Polar Alignment mit SharpCap

Polar Alignment ist ein neues Feature in SharpCap 2.9. Die Idee war inspiriert durch PhotoPolarAlign, eine Software von Themos Tsikas. Themos war so freundlich, beim Testen zu helfen und machte auch Verbesserungsvorschläge während der Entwicklung des Polar Alignment Featrures von ShapCap.

Ich verwende jetzt (Dezember 2019) die Version SharpCap Pro. Diese ist kostenpflichtig mit Eur 12,– pro Jahr. Um das kostenlose SharpCap  auf das kostenpflichtige SharpCap Pro “aufzurüsten” muss man einen Lizenzschlüssel, den man nach der Bezahlung per E-Mail bekommt in SharpCap unter “Help” eingeben.

Mit der kostenlosen SharpCap-Version kann man das Polar Align “antesten” – für die Stufe “Final Step: Adjust Mount” (s.u.) ist dann aber die kostenpflichtige Lizenz erforderlich.

Wenn das Lizenz-Jahr abgelaufen ist, kann man seine Lizenz kostenpflichtig verlängern (dafür bekommt man in der Regel Freimonate) – ansonsten können die lizenzpflichtigen Features (wie Polar Alignment) nicht mehr benutzt werden.

Die kostenpflichtige Pro-Version hat ausser der Funktion “Polar Align” noch andere zusätzliche Funktionen, die für den Einen oder Anderen interessant sein könnten.

Link: http://www.sharpcap.co.uk/sharpcap/polar-alignment

Was benötigt man für Polar Alignment mit SharpCap?

  • kostenpflichtige Version der Software SharpCap Pro
  • einen Computer, auf dem SharpCap läuft –> ich nehme dafür meinen Windows Laptop
  • Äquatoriale Montierung (Goto nicht notwendig) –> Ich habe die HEQ5 Pro, die Star Adventurer Mini
    und den Sky Watcher AZ-GTi
  • Optik mit Brennweite f=200mm –> nehme da mein Guiding-Rohr GuideScope50
  • Kamera mit einem Gesichtsfeld (FoV) zwischen 1 Grad und etwa 5 Grad –> meine GPCAM hat ein FoV von 1,54 x 1,16 Grad
  • Grobes Polar Alignment der Montierung auf plus-minus 5 Grad
  • Etwa 10-15 Sterne im Gesichtsfeld der Kamera zu sehen (erforderlich ist also eine freie Sicht auf die Gegend des Himmelspols)
  • SharpCap mit eingerichtetem PlateSolving (die Funktion “Polar Alignment” sollte sogar ohne dieses allgemeine Plate Solving gehen)

In welchen Schritten läuft das Polar Alignment mit SharpCap ab?

Schritt 0: Montierung aufstellen

Die Montierung sollte schön waagerecht aufgestellt sein, dann würde nämlich die Azimut-Schraube wirklich nur das Azimut bewegen und nicht auch noch so nebenbei die Polhöhe…
Teleskop in “Home”-Position d.h. Gegengewicht nach unten, Teleskop nach oben, Deklination 90 Grad.
Eine grobe Ausrichtung (5 Grad genau) auf den Himmelspol sollte ebenfalls schon gemacht sein.

Das für die Polausrichtung verwendete kleine Teleskop (z.B. das Guiding-Rohr) muss nicht genau parallel zum Hauptrohr ausgerichtet sein. SharpCap verwendet ja die tatsächliche Rotationsachse der Montierung.

Schritt 1: SharpCap einrichten

Da SharpCap beim Polar Alignment ja ein funktionierendes Plate Solving voraussetzt, müssen wir dafür die richtigen Einstellungen überprüfen:

  • In der SharpCap-Menüleiste auf: “File –> SharpCap Settings” gehen.
  • Dort auf den Reiter “Plate Solving”
  • Dort unter “Options” die “Star Detection Noise Threshold” auf 10 oder kleiner einstellen.

Zur Sicherheit könnte man das Plate Solving mit SharpCap auch einmal so, also ohne Polar Alignment, ausprobieren.

Für das Polar Alingment benutzt SharpCap einen “eingebauten” Plate-Solving-Algorithmus, für den keine Internet-Verbindung und auch kein anderes Programm oder Datenbank installiert werden muss.

Abbildung 1: SharpCap-Menüleiste -> File -> Settings (Google Drive: Sharpcap-Settings-01)

In den Einstellungen (Settings) von SharpCap sollten als Erstes die Einstellungen für “Polar Alignment” überprüft werden.

  • Correct for Atmospheric Refraction sollte bei Vergleichen mit anderer Software ausgestellt sein, weil Vergleichsoftware so eine Einstellung meist nicht hat.
  • Die “Obseving Location” sollte ordentlich eingestellt sein

Schritt 2: SharpCap-Menüleiste: Tools -> Polar Align

Abbildung 2: SharpCap Polar Align (Google Drive: SharpCap_PolarAlign00.jpg)

Schritt 3: Introduction und erstes Bild aufnehmen

Wenn ich im SharpCap-Menü auf “Tools -> Polar Align” gehe, bekomme ich eine Erklärung (Introduction) . Diese Introduction sollte man ruhig mal durchlesen…

Abbildung 3: SharpCap Polar Alignment: Introduction (Google Drive: SharpCap21.jpg)

Nachdem ich das alles gelesen habe klicke ich auf die Schaltfläche “Weiter” (Next).

Schritt 4: Erstes Bild aufnehmen

Bevor SharpCap die erste Aufnahme macht, sollten wir die Belichtungszeit und den Gain so gut einstellen, dass tatsächlich 10-15 Sterne im Gesichtsfeld zu sehen sind. Im Beispiel habe ich eingestellt: 3,5 Sekunden Belichtungszeit und den “Analogue Gain” auf Maximum.

Natürlich sollte die Kamera einigermassen im Fokus sein.

Nachdem wir bei der “Introduction” auf “Next” geklickt haben startet die erste Aufnahme und das Plate Solving.

Abbildung 4: SharpCap Capture First Image (Google Archiv: SharpCap23.jpg)

Hier im “Step 1 – Capture First Image” haben wir noch die Möglichkeit, einige Parameter für das Plate Solving einzustellen. Beispielsweise Minimum und Maximum Star Width.

Die im Bild erkannten Sterne markiert SharpCap mit einem Kästchen (“detected stars”). Dabei werden mit einem gelben Kästchen die Sterne markiert, die dann zum Plate Solving verwendet (“used stars”).

Die Kreisbögen im Bild sind Deklinationskreise um den Himmelspol.

Dieser Schritt ist erfolgreich zu Ende, wenn unter Status das Wort “Working” in “Solved” umspringt.
Dann klicken wir auf die Schaltfläche “Next”.

Schritt 5: Stundenachse drehen und zweites Bild aufnehmen

Nachdem im vorigen Schritt das erste Bild erfolgreich aufgenommen und “gesolved” wurde, hatten wir dort auf die Schaltfläche “Next” geklickt und SharpCap möchte nun ein zweites Bild aufnehmen.
Aber vorher soll man die Montierung um ca. 90 Grad in der Stundenachse drehen.
SharpCap macht dann die zweite Aufnahme und davon wiederum ein Plate Solving.

Abbildung 5: SharpCap Capture 2nd Image (Google Drive: SharpCap24.jpg)

Aus dem ersten und dem zweiten Foto errechnet SharpCap die Position der Drehachse der Montierung und damit wissen wir (bzw. SharpCap), wie weit wir noch weg sind vom Himmelspol (“Polar Align Error”). Danach klicken wir auf die Schaltfläche “Next”.

Schritt 6: Pol-Ausrichtung durch Drehen an den Azimut- und Polhöhen-Schrauben

Jetzt müssen wir die Montierung durch Drehen an den “Schräubchen” für Azimut und Polhöhe (Altitude) so einstellen, dass die Drehachse der Montierung (die Stundenachse) parallel zu Erdachse ausgerichtet ist.
Dabei hilft SharpCap mit einer Darstellung auf dem Bildschirm wo ein Stern mit einem gelben Pfeil gezeigt wird, der durch das Drehen an den “Schräubchen” der Montierung in das Zielkästchen auf dem Bildschirm gebracht werden muss.

Diese optische Hilfe ist quasi eine Projektion der errechneten erforderlichen Korrektur auf einen Stern im Gesichtsfeld. Wer es lieber in Zahlen hätte, kann sich auch nach den numerisch ausgeworfenen erforderlichen Korrekturen “Move Polar Axis: Left/Up” richten.

SharpCap macht dabei laufend Aufnahmen und berechnet durch Plate Solving die noch bestehende Abweichung vom Himmelspol. Ggf. müssen wir uns in mehreren Schritten der gewünschten Genauigkeit annähern.

Man kann das also nicht “remote” machen, sondern muss physisch an der Montierung stehen und einen guten Blick auf den Computer-Bildschirm haben…

Das schöne ist, dass die Genauigkeit der Polausrichtung (Abweichung vom Himmelspol) exakt ausgeworfen wird; im Beispiel unten schließlich 1 Bogenminute und 34 Bogensekunden, was mir dann bei meiner Montierung HEQ5 Pro reichte.

Wenn die Abweichung unter 2′ ist, wird das als “Good” angesehen, eine Abweichung von weniger als 1′ würde als “Excellent” bewertet.

Abbildung 6: SharpCap Polar Alignment: Fehler noch fast 10 Bogenminuten (Google Drive: SharpCap25.jpg)

Abbildung 7: Sharpcap Polar Alignment: Fehler nun weniger als 2 Bogenminuten (Google Drive: SharpCap26.jpg)

Astronomie: Computer in der Nacht: Notebook-Zelt

Gehört zu: Astronomie Geräteliste
Siehe auch: Remote Control, Rotlicht-Folie, Stromversorgung

Computer in der Nacht

Klassische Lösung: Windows Notebook

Wenn ich die Nacht über am Teleskop mit meinem Computer arbeiten (fotografieren) will, benötigt man ausser der Stromversorgung auch noch einen Schutz gegen Licht und Wetter.

Man kann zu diesem Zweck Plastikwannen verwenden, die man um 90 Grad dreht und in die man ein paar kleinere Löcher für Kabel schneidet.

Ich habe mir eine kommerzielle Lösung beschafft:

Das iCap hat zwar an den Seiten schöne Löcher für die Kabel, aber für die USB-Anschlüsse sind schon Winkelstecker sinnvoll.

Und wenn die Anzahl USB-Anschlüsse am Computer knapp werden kann, ist ein kleiner USB-Hub sinnvoll.

Alternative Lösungen: Klein-Computer

Alternativ zu einem Windows-Computer direkt an der Montierung werden heute auch Klein-Computer angeboten, die man auf sein Teleskop Huckpack (“Piggyback”) nehmen kann.

Beispiele:

 

Astronomie: Rotlicht-Folie Lee – Rotlichtlampen

Gehört zu: Meine Geräteliste
Siehe auch: Namibia

Rotlicht

Um Weisslicht aus diversen Quellen zu vermeiden, habe ich mir zum Abkleben des Weißlichts eine spezielle Rotlicht-Folie besorgt.

Um in dunkler Astro-Nacht, noch etwas sehen zu können, brauche ich eine Taschenlampe/Stirnlampe, aber bitte mit Rotlicht.

Lampen mit Rotlicht

Mit rotem Licht habe ich Taschenlampen und auch Stirnlampen

2.2.2014 Stirnlampe: Petzl Stirnlampe Zipka 2 grey  über Amzon bei Montana Bergsport

11.5.2015 Stirnlampe: Stirnlampe ZIPKA blau PETZL       bei www.all-batteries.de

6.8.2015 Rotlicht-Taschenlampe: Coast PX20 109 Lumen Dual Color LED Flashlights 19271  https://www.opticsplanet.com/coast-v2-6-chip-dual-color-tactical-torch-led-flashlight-tt7736d.html

 1.6.2017 Rolicht-Taschenlampe: Orion DualBeam LED Astro Flashlight  https://www.ebay.de/itm/231447316297

Rotlicht-Folien

Rotlichtfolie “Lee Colour 027 Medium Red”

Meine Bezugsquelle (am 12.8.2014):

Bogengröße [cm]: 25 x 123    Preis 5,50 zzgl. Versand

https://www.thomann.de/de/lee_farbfolie_nr_027_medium_red.htm

Weißlichter am Auto

Wenn ich zu einem Astro-Teleskop-Treffen fahre, muss ich sehr darauf achten, dass mein Auto kein Weißlicht produziert.

Deshalb habe ich z.B. für meine Teilnahme man Westhavelländer Astro Treffen (30.8.2014 WHAT in Gülpe) alle weissen Lampen in meinem Auto mit dieser roten Folie abgeklebt.

Weißlichter am Computer

In einer richtig dunklen Umgebung (z.B. Namibia) blenden selbst kleinere Lichter z.B. die LED links vorne an meinem Notebook-Computer. Die habe ich mit einem kleinen Stück Rotlicht-Folie abgeklebt.

Nach meinm ersten Astro-Aufenthalt in Namibia im 2017 habe ich dann noch eine Platte für den Computer-Bildschirm gebastelt: Um den ganzen Computer-Bildschirm auf Rotlicht zu bringen, habe ich mir eine Plexiglas-Scheibe in Grösse des Bildschirms (plus ein paar Millimeter) am 20.9.2017 schneiden lassen. Diese habe ich dann mit der Rotlicht-Folie “Lee Colour 027 Medium Red” beklebt.

Bezugsquelle (am 20.9.2017): ExpressZuschnitt.de:

2mm PLEXIGLAS® Zuschnitt nach Maß transparent

Art-Nr.:AXT-020-TRAEVO

Form : Rechteck
Stärke : 2.00 mm
Länge : 32.5 cm
Breite : 22 cm
Kante : Gesägt
Entgraten : Ja
Artikelgewicht : 0.17 kg
Versandgewicht : 1.32 kg
Gurtmass : 1167 mm
Stück:1 10,14 EUR
Paket
6,95 EUR
inkl. 19% MwSt. 2,73 EUR
Gesamtsumme: 17,09 EUR

 

Astrofotografie: Belichtungszeit, Lichtverschmutzung und Rauschen

Gehört zu: Astrofotografie
Siehe auch: Stacking, Nachführung Autoguiding, PHD2 Guiding, Lichtverschmutzung, SQM Sky Quality Meter, Hintergrundlimitiert, Fitswork, GeoGebra
Benötigt: WordPress Latex-Plugin , Fotos von Google Drive, Grafiken von Github

Stand: 12.10.2022 (GeoGebra)

Wie erziele ich gute Astro-Fotos?

Das hier betrachtete Qualitätskriterium ist das “Signal-Rausch-Verhältnis” (Signal to Noise Ratio = SNR). Die Qualität von Astro-Fotos wird generell von vielen Faktoren beeinflusst. Darunter sind beispielsweise:

  • CCD- oder CMOS-Kamera
  • Farb-Sensor oder Mono-Sensor
  • Geregelte Kühlung des Sensors   (DSLR oder Dedizierte Astro-Kamera oder WebCam oder ?)
  • Belichtungszeit
  • Lichtverschmutzung am Beobachtungsort
  • Fokussierung
  • Nachführung (z.B. keine, nur Tracking, Autoguiding,…)
  • Filter

Dieser Artikel beschäftigt sich schwerpunktmäßig mit den Belichtungszeiten bei DSO-Aufnahmen und der Frage, wie dafür das Signal-Rausch-Verhältnis verbessert werden kann.

Wie lange sollten die einzelnen Sub-Exposures belichtet werden?

Wir haben ja gelernt, dass wir sehr lange Belichtungszeiten für die so lichtschwachen Objekte (DSOs) der Astrofotografie brauchen.

Lange Belichtungszeit heisst hier aber nicht notwendig, dass ein einzelnes Foto lange belichtet werden muss, sondern wir können auch viele Einzelaufnahmen (Sub Exposures) machen und die dann aufaddieren (Stacken). Es kommt auf die Summe der Einzelbelichtungen an. Man sagt, die gesammte “Integrationszeit” ist das Wesentliche.

Diese Integrationszeit sollte in der Tat lang sein; d.h. mindestens 1 Stunde, besser 2 Stunden, besser 4 Stunden… Die Gesamtzeit (Integrationszeit) kann man ja Planen für die Bobachtungsnacht. Nehmen wir mal an, wir hätten 2 Stunden (also 120 Minuten) angesetzt. Die Frage wäre dann ja, wie lang man jedes Einzelfoto (Sub Exposure) belichten soll. Also ist 120 x 60 sec gut oder 720 x 10 sec oder 24 x 5 min oder… besser?

Quellen

Auf der “Practical Astronomy Show” am 9. März 2019 hat Dr. Robin Glover (SharpCap) dazu einen interessanten Vortrag gehalten. Der Titel des Vortrags war “Deep Sky CMOS Imaging” und er ist als Youtube-Video verfügbar. Youtube:

Chris van den Berge hat auf DSLR Astrophotography gepostet: http://dslr-astrophotography.com/long-exposures-multiple-shorter-exposures/

Ich versuche in diesem Artikel, den Vortrag von Robin Glover nachzuvollziehen und dann zu sehen, wie ich die Schlussfolgerungen auf meine persönliche Situation anpassen kann/muss. Aus diesem Grund bin ich etwas formaler und detaillierter in den Formeln…

Was ist beeinflussbar?

Wenn vieles als gegeben hingenommen werden muss, wie z.B. der Standort (und damit die Lichtverschmutzung), die Kamera (und damit das Kamera-Rauschen, die Kühlungsmöglichkeiten, die Pixelgröße etc.), die nutzbare Zeit am Abend (und damit die Gesamtbelichtungszeit), die Nachführung (keine, Tracking, Guiding,…),  dann bleibt als Einflussmöglichkeit im wesentlichen die Entscheidung für die Belichtungszeit der Einzelfotos (Sub Exposures), die zum Gesamtbild zusammengeführt werden sollen (“Stacking”).

Wir gehen die Thematik in folgenden Schritten an

  1. Grundlagen der digitalen Astrofotografie
  2. Was beeinflusst die Qualität von Einzelfotos (Sub Exposures) ?
  3. Wie ergibt sich die Qualität des Summenfotos (gestacktes Bild) ?
  4. Welche Schlussfolgerungen/Empfehlungen ergeben sich daraus für den “Standard Observer”?
  5. Welche Schlussfolgerungen/Empfehlungen ergeben sich daraus für meine persönlich präferierten Beobachtungsorte?

Grundlagen: Signal und Rauschen

Der digitale Sensor – schematisch

Abbildung 1: Elektronische Bauelemente für digitales Fotografieren (Github: dslr.svg)

dslr.svg

Signalstärke

Auf einem Astrofoto kommen verschiedene Signale zusammen:

  • Ein Signal vom eigentlichen Beobachtungsobjekt (Nutz-Signal)
  • Ein zusätzliches Signal vom Himmelshintergrund (Light Pollution)
  • Ein zusätzliches Signal durch den Dunkelstrom (abhängig von der Sensor-Temperatur)

Die Signalstärke ist eigentlich:  Anzahl Photonen pro Pixel pro Sekunde. Das menschliche Auge speichert die Lichtteilchen nicht, der Helligkeitseindruck (die physiologische Signalstärke) wird durch die Anzahl Lichtteilchen pro Zeiteinheit bestimmt. Das Auge hat dabei eine quasi konstante “Belichtungszeit” von so etwa 1/18 Sekunde.

Der Sensor in unserer Kamera hat im Gegensatz zum menschlichen Auge ein beträchtliches Speichervermögen. Daher ist die Belichtungszeit relevant. Die Photonen schlagen Elektronen aus dem Sensormaterial heraus und diese werden über die Belichtungszeit gesammelt. Die gesammelten Elektronen werden dann gemessen und von einem Analog to Digital Converter (ADC) in eine Zahl umgewandelt (ADU). Die Quantum Efficiency (QE) ist dabei der Prozentsatz von Photonen, der ein Elektron auslöst.

Die Signalstärke im Sensor ergibt sich aus der Signalrate und der Belichtungszeit. Wenn wir die Signalrate messen in  Anzahl Elektronen pro Pixel pro Sekunde (e-/Pixel/s), ergibt sich die Signalstärke als:

Signalstärke = Signalrate * Belichtungszeit

Jedes Signal ist mit einem Rauschen behaftet. Die Signale vom Himmelshintergrund und vom Dunkelstrom können wir abziehen; es bleibt das Rauschen von Himmelshintergrund und Dunkelstrom; diese können wir durch Stacking der Light-Frames und Dark-Frames (s.u.) bekämpfen.

Messen von Signal und Rauschen

Ein mit einem digitalen Sensor gemachtes Bild besteht aus vielen Pixeln und jeder Pixel hat einen Helligkeitswert (ADU), den der ADC für das jeweilige Pixel ausgegeben hat.

Als Signal kann man nun den Mittelwert und als Rauschen die Standardabweichung dieser ADU-Werte nehmen. Dies können wir z.B. mit der Software Fitswork folgendermassen messen:

  1. Wir öffnen das betreffende Foto in Fitswork
  2. Wir markieren den zu messenden Bereich durch ziehen mit der rechten Maustaste (bzw. wir messen das ganze Bild)
  3. Rechtsklick öffnet ein Kontextmenü, wo wir “Statistik für den Bereich” auswählen…

In der Astrofotografie definiert man nun das Signal to Noise Ratio (SNR) einfach als:

\(SNR = \Large \frac{Average(ADUs)}{Standard Deviation(ADUs)}\)

Rauschen

Es gibt mehrere Beiträge für Rauschen in den Light-Frames (Einzelfotos, Sub Exposures), die sich pro Einzelfoto in bestimmter Art addieren (s. unten):

  • Kamera-extern hat man
    • Rauschen im eigentlichen, externen Signal vom Beobachtungsobjekt das sog. Shot Noise (auch Photonenrauschen oder Schrotrauschen genannt)
    • Rauschen im Signal des Himmelshintergrunds (Lichtverschmutzung etc.)
  • Kamera-intern hat man (sog. Kamera-Rauschen):
    • Rauschen durch den Auslese-Vorgang (sog. Read Noise – nur Rauschen, kein Signal)
    • Rauschen durch Wärme im Sensor (sog. Thermisches Rauschen, also Rauschen im Dunkelstrom-Signal, deshalb auch Dunkelstrom-Rauschen genannt)
    • Quantisierungsrauschen durch den ADC (dieses ist so gering. dass wir es in dieser Betrachtung komplett ignorieren)

Rauschen bringt feine Details im Bild zum Verschwinden. Deshalb wollen wir das Rauschen insgesamt reduzieren.

Das Rauschen ist meistens zufällig (stochastisch) und kann also dadurch bekämpft werden, dass man viele Aufnahmen macht und die dann mittelt (siehe: Stacken).

Ausser in den Einzelfotos (Light Frames) hat man auch noch Rauschen:

  • Rauschen in den Dark-Frames
  • Rauschen in den Flat-Frames

Dieses betrachten wir zunächst ebenfalls nicht.

Zusammenfassung (Executive Summary)

Da die technischen Zusammenhänge doch sehr komplex und vielschichtig sind, hier die “wichtigsten” Erkenntnisse vorweg (für einen gegebenen Standort mit gegebener Lichtverschmutzung):

  • Die Gesamtbelichtungszeit (Integrationszeit) muss lang sein (z.B. 2 Stunden oder mehr)
  • Die Belichtungszeit eines Einzelfotos muss immer so gewählt werden, dass im Histogramm weder links noch rechts etwas abgeschnitten (“geclippt”) wird
  • Die Einzelbelichtungszeit muss nur so groß sein, dass das Einzelbild “hintergrundlimitiert” ist; d.h.
    • Unter lichtverschmutztem Himmel die Einzelfotos (Subs) kurz belichten (z.B. 30 sec), dann aber ganz viele machen (und man braucht vielleicht garkein Autoguiding)
    • Unter dunklerem Himmel können die Einzelfotos schon länger belichtet werden (z.B. 5 min), wenn das Guiding (oder: Autoguiding) das hergibt
  • Ruhig ISO bzw. Gain hochdrehen, dann wird das Ausleserauschen geringer (bei CMOS Sensoren) – aber der Dynamik-Umfang wird etwas sinken
  • Das thermische Rauschen ist häufig viel kleiner als Stör-Signale aus anderen Quellen. Deshalb ist extreme Kühlung manchmal garnicht so wichtig.

Folgende Rausch-Anteile werden wir im Folgenden ignorieren:

  • Das thermische Rauschen im Light-Frame: Durch ausreichende Kühlung des Sensors werden wir es auf 10% der Lichtverschmutzung begrenzen
  • Das Dunkelstrom-Rauschen im Dark-Frame: Wird reduziert durch das Stacken vieler Dark-Frames zu einem Masterdark

Die verbleibenden Rauschanteile wollen wir durch geeignete Wahl der Belichtungszeiten soweit reduzieren, dass sie unterhalb einer persönlichen Qualitätsgrenze liegen. Dabei werden wir die Größe der Lichtverschmutzung als Massstab nehmen.

  • Das Ausleserauschen (Read Noise) wird irrelevant, wenn wir die Subs so lange belichten, das sie quasi “hintergrundlimitiert” werden; soll heissen dass im gestackten Bild das Ausleserauschen maximal 5% der Lichtverschmutzung ausmacht.
  • Das  “Shot Noise” (Photonen-Rauschen) wird reduziert durch das Stacken vieler Light-Frames

Was bedeutet “hintergrundlimitiert” ?

Mit “Hintergrund” meint man die Himmelshelligkeit (Lichtverschmutzung,  Airglow etc.). Unter “limitiert” durch den Hintergrund meint man, dass man nicht länger belichten sollte da bei längerer Belichtung die Lichtverschmutzung dominieren würde.  Bleibt man knapp unter dieser Grenze so sind die anderen Rausch-Signale (Auslese-Rauschen und thermisches Rauschen) deutlich kleiner sind als das Signal vom Himmelshintergrund und sie können damit vernachlässigt werden. Effektiv ergibt also der Himmelshintergrund das Limit für die Belichtungszeit.

Wenn man sich nach der “optimalen” Belichtungszeit für die Subs fragt, reicht es, wenn man gerade so lange belichtet, dass die Subs hintergrundlimitiert sind. Dann wird durch noch längere Belichtungszeiten das Signal-Rausch-Verhhältnis im Stack (Summenbild) nicht mehr verbessert.

Signalkomponenten im Einzelfoto

Wir haben folgende Signalkomponeten in jedem Einzelfoto (Sub Exposure):

  • Signal vom eigentlichen Himmelsobjekt (ObjektSignal)
  • Signal vom Himmelshintergrund (LightPollutionSignal)
  • Signal vom Dunkelstrom

Wie addieren sich die Signalkomponenten im Einzelfoto?

Unahhängige Signale, die über die Zeit prinzipiell gleich bleiben, addieren sich “normal”.

\((1) \hspace{1 em} S_{1+2} =  S_1 + S_2 \)

Addieren wir alle Signale, die wir in unserem Einzelfotohaben kommen wir zu einem Gesamtsignal (ImageSignal) von:

\((2) \hspace{1 em} ImageSignal = ObjektSignal + LightPollutionSignal + DunkelstromSignal \)

Signal vom Himmelsobjekt

Das Himmelsobjekt, welches wir fotografieren, sendet einen Strom von Photonen, die über unsere Optik auf den Pixeln des Kamera-Sensors landen und dort als Elektronen über die Dauer unserer Belichtungszeit gesammelt werden. Durch die Ausleseelektronik der Kamera erhalten wir dann pro Pixel einen Zahlenwert für die Helligkeit.

\((3) \hspace{1 em} ObjektSignal = ObjektSignalRate * Belichtungszeit \)

Je nach anvisiertem Objekt kann die “ObjektSignalRate” ganz unterschiedlich sein. Beispiel: Wieviel Photonen fallen vom Andromedanebel pro Sekunde auf ein Pixel meiner Kamera? Vermutlich könnte man aus der Flächenhelligkeit eines Objekts diese “ObjektSignalRate” ermitteln – ähnlich wie im nächsten Abschnitt mit der Lichtverschmutzung…

Signal vom Himmelshintergrund

Die Helligkeit des Himmelshintergrunds hängt von der Lichtverschmutzung am Beobachtungsort ab. Hinzu kämen der Mond, möglicherweise Airglow u.a.
Die Signalrate, gemessen in Anzahl Elektronen per Pixel per Sekunde, hängt zusätzlich von der Optik (Öffnungsverhältnis) und dem Sensor (Mono/Colour, Pixelgröße, Quanteneffizienz) ab.

Wir definieren deshalb einen “Standard-Beobachter” (mit Standard Equipment), um zu vergleichbaren Zahlen zu kommen.

Der Standard-Beobacher sei definiert durch:

  • Sensor: CMOS, monochrom, 50% QE, Pixelgröße 3,75µ, Temperatur 25 Grad Celsius
  • Öffnungsverhältnis: f/6
  • Lichtverschmutzung:  Bortle 5
  • Gesamtbelichtungszeit: 60 Minuten

Die “LightPollutionRate” können wir mit dem “Sky Background Calculator” ermitteln. Link: https://tools.sharpcap.co.uk

Der Kniff dabei ist, die Himmelshelligkeit von Magnituden pro Quadratbogensekunde umzurechnen in Candela pro Quadratmeter (cd/m²). Dann haben wir einfache lineare Zusammenhänge. Die Umrechnung in cd/m² habe ich in meinem Blog-Artikel über SI-Einheiten beschrieben.

Tabelle 1: Signalrate aus Lichtverschmutzung in e- / Pixel /Sekunde (am 24.5.2021 der o.g. Website entnommen)

Bortle 9
16.0 mag
Inner City
Bortle 8
18.0 mag
City Sky
Bortle 7
18.3 mag
Urban
Bortle 6
18.8 mag
Bright Suburban
Bortle 5
19.8 mag
Suburban
Bortle 4
20.9 mag
Rural/Suburban
Bortle 3
21.4 mag
Rural
Bortle 2
21.6 mag
typical dark
Bortle 1
21.85 mag
Excellent Dark
f/4 175,25 27,78 21,07 13,29 5,29 1,92 1,21 1,01 0,80
f/5 112,16 17,78 13,48 8,51 3,39 1,23 0,78 0,65 0,51
f/6 77,89 12,34 9,36 5,91 2,35 0,85 0,54 0,45 0,36
f/7 57,23 9,07 6,88 4,34 1,73 0,63 0,41 0,33 0,26
f/10 28,04 4,44 3,37 2,13 0,85 0,31 0,19 0,16 0,13

Dies sind Daten für einen Mono-Sensor mit 50% Quantum Efficiency und 3,75μ Pixelgröße (für den sog.  Standard-Observer).
Für einen Colour-Sensor sind diese Zahlen durch 3 zu dividieren.

Unser Standard-Observer hat nach Tabelle 1 also eine Lichtverschmutzung von:

\((4) \hspace{1 em} LightPollutionRate = 2.35 \space Elektronen \space pro \space Pixel \space pro \space Sekunde \)

Das am Sensor gemessene Signal steigt mit der Belichtungszeit:

\((5) \hspace{1 em} LightPollutionSignal = 2.35 \cdot Belichtungszeit \)

Signal vom Dunkelstrom

Das Signal, was der Sensor ohne einkommende Photonen macht, – also “im Dunklen” – kann man sich in einem Dark-Frame betrachten. Darauf werden Hot Pixel und evtl. ein Amp Glow zu sehen sein…

Rauschkomponenten im Einzelfoto

Wir haben folgende Rauschkomponeten in jedem Einzelfoto (Sub Exposure):

  • Rauschen im Dunkelstrom (ThermalNoise)
  • Ausleserauschen (ReadNoise)
  • Schrot-Rauschen (ShotNoise)
  • Rauschen in der Lichtverschmutzung (SkyNoise)

Wie addieren sich Rauschkomponenten im Einzelfoto?

Unahhängige Rausch-Signale, die sich über die Zeit zufällig (stochastisch) verhalten, addieren sich mit einer “Quadratwurzel” ….    R1 + R2   = Wurzel aus (R1 Quadrat + R2 Quadrat)

\((6) \hspace{1 em} R_{1+2} =  \sqrt{ R_1^2 + R_2^2} \)

Wenn wir zwei zufällige und unabhängige Rauschsignale  R1=4 und R2=3 addieren, so erhalten wir R1 + R2 = 5
Das bedeutet, dass bei der Addition stark unterschiedlicher Rauschsignale man das schwächere “praktisch” vernachlässigen kann. Z.B. mit R1 = 10 und R2 =1 ergibt sich:

\((7) \hspace{1 em} R_{1+2} = \sqrt{ 10^2 + 1^2} = \sqrt{101} =  10,05 \\\ \)

Das Gesamtrauschen in einem Einzelfoto wäre also:

\((8) \hspace{1 em} ImageNoise = \sqrt{ThermalNoise^2 + ReadNoise^2 + ShotNoise^2 + SkyNoise^2} \)

Wir werden sehen, dass wir (unter bestimmten Bedingungen) das Thermische rauschen und das SkyNoise vernachlässigen können.

Thermal Noise (Dunkelstrom-Rauschen)

Im Sensor entstehen Elektronen nicht nur durch die ankommenden Photonen, sondern auch durch Wärme in der Kamera. Das nennt man “Dunkelstrom”. Dieser Dunkelstrom macht ein Dunkelstrom-Signal und ein Dunkelstrom-Rauschen (Thermal Noise). Das Dunkelstrom-Signal kann man durch Dark-Frames vom vom Nutzsignal (Light Frame) abziehen; das Dunkelstrom-Rauschen bleibt aber erhalten. Es ist von der Temperatur und der Dauer der Belichtung abhängig.

Dunkelstrom-Rauschen (Thermal Noise) verdoppelt sich ungefähr bei Temperaturerhöhung um 6,5 Grad Celsius.

Je nach Sensor ergeben sich unterschiedliche Kurven für dieses Thermal Noise (Copyright Dr. Robin Glover):

Abbildung 2: Dunkelstrom-Rauschen bei verschiedenen Temperaturen (Google Drive: RobinGlover-01.jpg)

Typisch für moderne CMOS-Sensoren wie Sony 294C sind 0,2 Elektronen pro Sekunde pro Pixel bei einer Sensor-Temperatur von 25 Grad Celsius. Wenn man diese Kurven sieht, erkennt man, dass ein Herunterkühlen von 25 Grad auf 15 Grad völlig ausreicht, um das thermische Rauschen bedeutungslos (von 0,2 auf 0,1 e/sec) zu machen.

Bekämpfung: Das thermische Rauschen bekämpfen wir durch Kühlung des Sensors.  Robin Glover empfiehlt, das thermische Rauschen auf 10% des Signals der Lichtverschmutzung zu limitieren. Bei besonders geringer Lichtverschmutzung wäre also eine entsprechende leichte Kühlung notwendig. Welche Signalstärke durch Lichtverschmutzung entsteht, ist unten beschrieben.

Erforderliche Kühlung

Um das “Thermal Noise” (das Dunkelstromrauschen) ignorieren zu könnnen, wollen wir dieses auf 10% der LightPollutionRate limitieren. Dazu müssen wir also wissen, wie stark die “LightPollutionRate” ist. Die Himmelshelligkeit an einen bestimmten Beobachtungsort messen wir mit dem Sky Quality Meter (SQM) in Magnituden pro Quadrat-Bogensekunde. Je nach Teleskop und Sensor ergibt sich daraus die “Light Pollution Rate” (in Elektronen pro Pixel pro Sekunde).

Erforderliche Kühlung beim Standard Observer

  • Light Pollution Rate = 2,35 e- /Pixel / s
  • Thermal Noise Limit (10%) = 0,235 e- /Pixel /s
  • Sensor: IMX294
  • Erforderliche Sensor Tempratur: 17-18 Grad Celsius

Read Noise (Auslese-Rauschen)

Durch den Vorgang des Auslesen der Pixel-Informationen aus dem Sensor ensteht auch ein zusätzliches Rauschen, das sog.  Auslese-Rauschen.

Wenn man statt ein paar wenigen Aufnahmen mit längerer Belichtung alternativ viele Aufnahmen mit kürzerer Belichtung macht, hat man auf jeder Einzelaufnahme das Ausleserauschen und das würde also bei “vielen kurzen Belichtungen” viel stärker ins Gewicht fallen. Allerdings ist das Auslese-Rauschen bei modernen CMOS-Kameras sehr gering, wenn man den Gain etwas hoch stellt, was die Dynamik evtl. herabsetzt.

Read Noise bei unterschiedlichem Gain bzw. ISO

Das Aufdrehen des “Gain” bei CMOS-Sensoren ist einfach eine Verstärkung aller Bildsignale.

Das Ausleserauschen (Read Noise) wird durch den Gain allerdings nicht verstärkt, da diese Verstärkung erst nach der Belichtung des Sensors stattfindet (wo genau entsteht das Ausleserauschen?).

Wichtige Kenngrößen des Sensors (Sony IMX294) sind also:

  • Ausleserauschen (bekommen wir durch Gain 120 auf unter 2.0 e/pix/sec)
  • Thermisches Rauschen (bei Kühlung auf -10 Grad praktisch Null)
  • Quantum Efficiency bei 75%

Abbildung 3: Read Noise in Abhängikeit vom Gain bei der ZWO ASI294MC Pro  (Google Drive: RobinGlover-02.jpg)

Bekämpfung des Ausleserauschens

  • Das Auslese-Rauschen können wir bei CMOS-Kameras bekämpfen durch Aufdrehen des Gains bis zu dem Punkt, wo das Ausleserauschen stark abfällt (Gain 120 im obigen Beispiel).
  • Andererseits ist das Ausleserauschen ja unabhängig von allen anderen Einstellungen und fällt eben genau einmal pro Einzelfoto an. Bei gegebener Gesamtbelichtungszeit sollten wir also mit möglicht wenigen Einzelfotos (Sub Exposures) auskommen. Die Belichtungszeit der Subs also soweit hochdrehen, bis “Hintergrundlimitierung” (s. Lichtverschmutzung unten) erreicht ist.

Schlussfolgerung für das Ausleserauschen

Das Ausleserauschen unseres Sensors pro Einzelbild ist ein unvermeidlicher Einflussfaktor; im Beispiel der ZWO ASI 294MC Pro:
R = 1,5 e-/pixel/sec

Shot Noise (Schrotrauschen)

Auch im eigentlichen Nutz-Signal haben wir ja ein Rauschen, das sog. “Shot Noise”  (im Deutschen auch “Schrotrauschen” genannt) – benannt nach Walter Schottky (1886-1976). Das Shot Noise haben wir weil die Photonen diskrete Teilchen sind, deren Ankommensrate auf einem Pixel zufällig ist und die man mit einer Poisson-Verteilung beschreiben kann.

Wenn wir länger belichten, kommen mehr Photonen auf den Sensor, wenn wir kürzer belichten, kommen weniger Photonen auf den Sensor. Bei einem schwächeren Signal ist das Shot Noise im Verhältnis zum Signal größer (Poisson-Verteilung). Umgekehrt: je länger wir belichten, desto geringer wird das Shot Noise im Verrhältnis zum Signal.

Shot Noise als Funktion des Signals

Das ShotNoise hängt von der Stärke des ObjektSignals ab, welches seinerseits durch die Helligkeit des Objekts und die Dauer der Belichtung gegeben ist.

\((9) \hspace{1 em}  ShotNoise =  \sqrt{ObjektSignal}  \)

Wobei die Stärke des ObjektSignals einfach die Anzahl Elektronen pro Pixel ist; was mit der Belichtungszeit ansteigen würde.

Siehe auch: GeoGebra

Abbildung 4: How Shot Noise varies with Brightness  (GitHub: Robin Glover Shot Noise 01.svg)

Robin Glover Shot Noise 01.svg

Shot Noise in Prozent des Signals

Absolut gesehen, steigt das Shot Noise mit der Signalstärke, also der Belichtungszeit.
Aber relativ zum Signal wird das Shot Noise (prozentual) immer geringer:

\((10) \hspace{1 em}  \Large  \frac{Shot Noise}{Signalstärke} = \Large \frac{ \sqrt{Signalstärke} }{Signalstärke} = \Large \frac{1}{\sqrt{Signalstärke}}  \)

Wobei auch hier die Signalstärke einfach die Anzahl Elektronen pro Pixel ist; was mit der Belichtungszeit ansteigen würde.

Siehe auch: GeoGebra

Abbildung 5: Shot Noise as a Percentage of Brightness (GitHub: Robin Glover Shot Noise 02.svg)

Robin Glover Shot Noise 02.svg

Shot Noise und Lichtverschmutzung

Das Shot Noise lässt die schwächsten (dunkelsten) Stellen im Bild quasi verschwinden. Das dunkelste im Bild ist aber das Signal der Lichtverschmutzung. Wir sollten das Shot Noise also in Relation zum Signal aus Lichtverschmutzung sehen. Unser “Standard Observer” hat (Gleichung (3)) eine Lichtverschmutzung von 2.35 Elektronen pro Pixel pro Sekunde.

In Abhängigkeit von der Belichtungszeit der Einzelaufnahme ergibt sich:

  • ShotNoise = Wurzel aus Nutzsignal = Wurzel aus (NutzsignalRate * Belichtungszeit)     (nach Gleichung (9) und (3))
  • LightPollutionSignal = 2.35 * Belichtungszeit                                                                       (nach Gleichung (5))

und damit

\( ShotNoisePercent = 100 \cdot \frac{ShotNoise}{LightPollutionSignal} = 100 \cdot \frac{\sqrt{Nutzsignal}}{2.35 \cdot Belichtungszeit} = 100 \cdot \frac{\sqrt{NutzsignalRate \cdot Belichtungszeit}}{2.35 \cdot Belichtungszeit} \)

und schließlich:

\( ShotNoisePercent = 100 \cdot \frac{\sqrt{NutzsignalRate}}{2.35 \cdot \sqrt{Belichtungszeit}} \)

Das ShotNoise selber hängt ja von der Stärke des Nutzsignals ab. Bei einer Nutzsignal-Rate von 243,36 Elektronen pro Pixel und Sekunde (243,36 = 15,62) kommen wir auf das gleiche Bild wie in Robin Glovers Präsentation.

Siehe auch: GeoGebra

Abbildung 6: Shot Noise in % der Lichtverschmutzung des Standard Observers (GitHub: Robin Glover Shot Noise 03.svg)

Robin Glover Shot Noise 02.svd

Dieses Bild sagt ja “Einzelbild länger belichten, ergibt weniger Rauschen”. Aber wenn wir das Stacken (s.u.) mit berücksichtigen, wird die Sache etwas anders.

Sky Noise (Rauschen in Lichtverschmutzung)

Das Rauschen in der Lichtverschmutzung ignorieren wir. Wohl aber ist die Stärke des Signals der Lichtverschmutzung ein wichtiger Massstab für die anderen Faktoren.

Summe des Rauschens im Einzelbild

Wenn wir, wie gesagt die Größe des Dunkelstrom-Rauschens (Thermal Noise) und das Rauschen in der Lichtverschmutzung (Sky Noise) vernachlässigen, da sie klein gegenüber den anderen Rauschkomponenten sind, bleibt also das Gesamt-Rauschsignal im Einzelbild, das “SingleFrameImageNoise” als Summe aus ReadNoise und ShotNoise:

\((11) \hspace{1 em}  SingleFrameImageNoise = \sqrt{ReadNoise^2 + ShotNoise^2} \)

Auch dieses Gesamtrauschen im Einzelbild wollen wir in Relation zum Signal aus Lichtverschmutzung (beim Standard Observer) sehen.

\( LightPollutionSignal = LightPollutionRate \cdot Belichtungszeit = 2.6 \cdot t \)

Dabei sehen wir den Einfluss des ReadNoise (Ausleserauschen) auf das Gesamtrauschen, nur bei kürzeren Belichtungszeiten. Bei längeren Belichtungszeiten verschwindet der Einfluss des ReadNoise ganz schnell. Um das in der Grafik sichtbar zu machen, müssen wir einen ganz anderen Massstab auf der x-Achse (Belichtungszeit) wählen.

Das ShotNoise ist \( ShotNoise = \sqrt{SignalRate} \cdot \sqrt{t} \)

Um das gleiche Bild wie in Robin Glovers Vortrag zu kommen, nehmen wir: SignalRate = 2 Elektronen per Pixel per Sekunde

Das ReadNoise hängt von der verwendeten Kamera ab. Wir nehmen für unsere Grafik mal ein paar typische Werte an:

  • typische CCD-Mono-Kamera habe ein Ausleserauschen (ReadNoise) von 7 Elektronen pro Pixel pro Sekunde
  • typische CMOS-Kamera habe ein Ausleserauschen (ReadNoise) von 2.5 Elektronen pro Pixel pro Sekunde
  • eine “ideale” Kamera ohne ReadNoise, also Null Elektronen pro Pixed pro Sekunde

Dann ist bei der typischen CCD-Mono-Kamera (R=7) und einer Belichtungszeit von t das Gesamtrauschen  im Einzelbild:

\( SingleFrameImageNoise = \sqrt{7^2 + 2 \cdot t} \)

Und als Prozent des Signals aus Lichtverschmutzung ergibt sich dann für den Standard Observer mit der CCD-Mono-Kamera:

\( ImageNoisePercent = 100 \cdot \frac{\sqrt{7^2 + 2 t}}{2.6 \cdot t} \)

Siehe auch: GeoGebra

Abbildung 7: Single Frame Noise als Prozentsatz vom Signal der Lichtverschmutzung (GitHub: Robin Glover Noise 04.svg)

Robin Glover Noise 04.svg

Stacking

In der Astrofotografie nehmen wir viele kürzer belichtete Fotos eines Objekts auf (sog. Sub Exposures oder Frames) und legen diese dann übereinander sog. Stacking, Dabei addieren sich die Signale in verschiedener Weise.

Signal und Rauschen beim Stacking

Beim Stacken von Einzelaufnahmen (Sub Exposures) verhalten sich Signal und Rauschen unterschiedlich.

Konstante Signale, bei denen sich die Signalstärke von Sub zu Sub eigentlich nicht ändert, addieren sich einfach.

\((12) \hspace{1 em} S =  S_1 + S_2 + S_3 + … \)

Rausch-Signale, die sich von Sub zu Sub zufällig (stochastisch) ändern, addieren sich mit der “Quadratwurzel”

\((13) \hspace{1 em} R =  \sqrt{ R_1^2 + R_2^2 + R_3^2 + …} \)

Mit zunehmender Anzahl Subs steigt also das Nutzsignal linear und das Rauschen “nur” mit der Quatradwurzel.

Wenn ich also n Subs mit einem Nutzsignal von S0 und einem Rauschsignal von R0 zu einem Summenbild stacke, erhalte ich ein Summenbild mit:

Nutzsignal \( S = n \cdot S_0 \)

Rauschsignal \( R = \sqrt{n \cdot R_0^2} \)

und damit eine Signal-Rauschverhältnis im Summenbild von:

\((14) \hspace{1 em}SNR = \frac{S}{R} = \frac{n \cdot S_0}{\sqrt{n \cdot R_0^2}} = \sqrt{n} \frac{S_0}{R_0} \)

Das ist die bekannte Aussage, dass bei einem Summenbild aus vier Subs das Signal-Rauschverhältnis sich verdoppelt etc.

Tabelle 2: Verbesserung des SNR durch Stacking

Spalte 1 Spalte 2 Spalte 3 Spalte 4
Anzahl Frames Multiplikator Rauschen Multiplikator Signal Multiplikator SNR
1 1,00 1 1
2 1,41 2 1,41
4 2,00 4 2,00
10 3,16 10 3,16
20 4,47 20 4,47
50 7,07 50 7,07
100 10 100 10

Wobei die Spalte 2 “Rauschen” noch detaillierter betrachtet werden muss, weil wir es mit mehren Rausch-Quellen zu tun haben, die sich addieren…

\( (15) \hspace{1 em} MultiplikatorRauschen = \sqrt{AnzahlFrames} \\  \\  \)

 

\( (16) \hspace{1 em}MultiplikatorSignal = AnzahlFrames   \\ \\ \)

 

\( (17) \hspace{1 em} MultiplikatorSNR = \frac{MultiplikatorSignal}{MultiplikatorRauschen}  = \frac{AnzahlFrames}{\sqrt{AnzahlFrames}}  = \sqrt{AnzahlFrames} \)

Effekt von Stacking auf den Speicherplatz

Andererseits nimmt bei zunehmendem Stacking (Anzahl Frames) der Speicherplatz für die Fotos auch linear zu. Beispielsweise bekomme ich eine Gesamtbelichtungszeit von 120 Minuten wenn ich 720 Fotos mit 10 Sekunden mache oder auch bei 60 Fotos mit 120 Sekunden; allerdings benötigt man in ersteren Fall 12 Mal so viel Speicher.

Die Schlußfolgerung für den Standard Observer

Wenn wir einfach einen gegebenen Ort, ein gegebenes Astro-Equipment und eine gegebene Zeit haben, was sollen wir machen?

Dafür gibt es eine Formel. Wobei wir folgende Symbole benutzen:

  • O = Object Signal Rate   in Electrons per Sekunde per Pixel  (abhängig von der Objekt-Helligkeit)
  • R  = Read Noise   (typisch bei CMOS-Sensoren: 0,2 e  pro Pixel)
  • T = Total Imaging Time
  • s = Sub Exposure Time
  • n = Number of Subs      \(  n = \frac{T}{s}  \)
  • P = Light Pollution Rate   in Electrons per Sekunde per Pixel     (typisch: 2,6 für unseren Standard Observer mit Bortle=5)

Noise im Single Frame

Wir wollen die Stärke des Rauschens im Einzelfoto ermitteln. Dafür gilt (Thermal Noise durch geeignete Kühlung vernachlässigt, SkyNoise vernachlässigt weil ganz gering):

\((18) \hspace{1 em} SingleFrameTotalNoise = \sqrt{SingleFrameReadNoise^2 + SingleFrameShotNoise^2}    \)

Das SingleFrameShotNoise hängt vom Objekt und von der Belichtungszeit ab:

\((19) \hspace{1 em}SingleFrameShotNoise = \sqrt{s \cdot O} \)

Wenn wir als Objekt einfach mal ein sehr dunkles Objekt nehmen, was eine ObjectSignalRate (O) hat, die genauso groß ist, wie die Rate der Lichtverschmutzung (P), dann ergibt sich:

\((20) \hspace{1 em}SingleFrameShotNoise = \sqrt{s \cdot P} \)

Wenn wir das oben in (18) einsetzen, erhalten wir das Gesamtrauschen im Einzelfoto (genau wie in Robin Glovers Vortrag) als:

\((21) \hspace{1 em} SingleFrameTotalNoise = \sqrt{R^2 + s \cdot P}    \)

Noise im Total Stack

Wenn wir jetzt “stacken”, haben wir (wenn wir wieder Thermal Noise und Sky Noise vernachlässigen) ein Gesamtrauschen (TotalStackNoise) von :

\((22) \hspace{1 em} TotalStackNoise = \sqrt{TotalStackReadNoise^2 + TotalStackShotNoise^2}    \)

Dabei ist das gesamte ReadNoise im gestackten BIld:

\((23) \hspace{1 em} TotalStackReadNoise = \sqrt{n \cdot R^2} \)

und das gesamte ShotNoise im gestackten Bild:

\((24) \hspace{1 em} TotalStackShotNoise = \sqrt{T \cdot O} \)

Wenn wir als Objekt einfach mal ein sehr dunkles Objekt nehmen, was eine ObjectSignalRate (O) hat, die genauso groß ist, wie die Rate der Lichtverschmutzung (P), dann ergibt sich:

\((25) \hspace{1 em} TotalStackShotNoise = \sqrt{T \cdot P} \)

Wenn wir das beides oben in (22) einsetzen, erhalten wir als Gesamtrauschen im gestackten Bild (genau wie in Robin Glovers Vortrag) als:

\((26) \hspace{1 em}TotalStackNoise = \sqrt{n \cdot R^2  + T \cdot P} \)

Wenn wir diese “trockene” Formel mal als Grafik darstellen, sehen wir besser, was da eigentlich passiert. Wir gehen von einer Gesamtbelichtungszeit von einer Stunde (3600 Sekunden) aus nehmen unseren “Standard Observer” und stellen dann die Werte für zwei Kameratypen (typische CCD mit 7.0 e Ausleserauschen und eine typische CMOS mit 2.5 e Ausleserauschen) dar:

Siehe auch: GeoGebra

Abbildung 8: Total Stack Noise in Abhängigkeit von der Einzel-Belichtungszeit

Robin Glover Noise 05.svg

 

Beim gesamten Störsignal (Rauschen) betrachten wir ja nur noch zwei Anteile: Ausleserauschen und Lichtverschmutzung.
Die Lichtverschmutzung hat an unserem Beobachtungsort eine gegebene konstante Rate. Die Lichtverschmutzung nimmt auf unseren Bildern also propotional der Belichtungszeit zu – dagegen können wir nichts machen.
Das Ausleserauschen haben wir einmal pro Einzelfoto. Also im Idealfall nur genau einmal. Wenn wir die Gesamtbelichtungszeit in mehrere Einzelfotos (Sub Exposures) aufteilen, haben wir das Ausleserauschen addiert für jedes Einzelfoto. Solange das Ausleserauschen sehr klein gegenüber er Lichtverschmutzung ist, können wir es (fast) vernachlässigen. Wenn wir zu sehr vielen Einzelfotos (d.h. sehr kurzen Belichtungszeiten) kommen wird irgendwann das Ausleserauschen relevant werden und schließlich auch deutlich mehr als die Lichtverschmutzung werden.

Wir sehen, dass sich das Total Stack Noise bei gegebener Gesamtbelichtungszeit (hier: 3600 Sekunden) jeweils einem Optimum (Minimum) annähert (im Beispiel: 96,8 bei CMOS und 97,0 bei CCD).

Die Kurven flachen sehr schnell ab, also können wir durchaus mit Sub Exposures arbeiten, die wesentlich kürzer sind und dabei das optimale (minimale) Rauschen nur ganz knapp erhöhen.

Das Minimum-Rauschen ist also für unseren Standard Observer (P=2.6) bei einer Stunde Gesamtbelichtungszeit:

\( (27) \hspace{1 em} TotalStackNoise_{min} = \sqrt{R^2 + T \cdot P} \)

Für unsere typische CMOS-Kameramit R=2.5 ergibt das:

Minimum-Rauschen CMOS = 96.8 e-/Pixel/s

Für unsere typische CCD-Kamera mit R=7 ergibt das:

Minimum-Rauschen CCD = 97.0 e-/Pixel/s

Wenn wir etwa ein 5% höheres Rauschen als das Minimum-Rauschen akzeptieren, landen wir bei Sub Exposures von: einer halben Minute bei CMOS und 3 Minuten bei CCD.

Im Beispiel sind das:

  • Standard-Beobachter CMOS 23 sec
  • Standard-Beobachter CCD 174 sec

Als tabellarische Darstellung haben wir:

Tabelle 3: Ergebnisse: Total Noise in the Stack Bortle=5

Spalte 1 Spalte 2 Spalte 3 Spalte 4 Spalte 5
Sub Exposure Length Total Stack Noise CMOS Total Stack   Noise
CCD
Total Stack Noise CMOS Total Stack Noise      CCD
[s] e/pixel/s e/pixel/s [%] [%]
1 178,5 431,0 184,4 444,3
2 143,6 312,3 148,3 322,0
5 117,7 211,3 121,6 217,8
10 107,7 164,3 111,3 169,4
23 101,6 130,0 105,0 134,0
30 100,5 123,5 103,9 127,3
60 98,7 110,9 101,9 114,3
100 97,9 105,5 101,2 108,7
174 97,4 101,9 100,7 105,0
1000 96,9 97,7 100,1 100,7
3600 96,8 97,0 100,0 100,0

Mit folgenden Annahmen

  • T = 3600 Sekunden
  • P = 2.6 e-/pixel/s
  • R CMOS = 2,5
  • R CCD = 7.0

ergibt sich Spalte 2

\( TotalStackNoiseCMOS = \sqrt{\frac{3600 \cdot R^2}{SubExposureLength} + 3600 \cdot P} \)

und Spalte 3:

\( TotalStackNoiseCCD = \sqrt{\frac{3600 \cdot R^2}{SubExposureLength} + 3600 \cdot P} \)

und Spalte 4:

Spalte 4 = Spalte 2 / Maximum von Spalte 2

und Spalte 5:

Spalte 5 = Spalte 3 / Maximum von Spalte 3

 

Optimale Sub Exposures

Die Idee ist nun, das Rauschen bei einer bestimmten (kürzeren) Belichtungszeit “s” in Relation zum erzielbaren Minimum (also ein lang belichtetes Foto) zu setzten.

Wenn man also einen bestimmten Prozentsatz zusätzlichen Rauschens im Bild akzeptieren will, kann man in der obigen Tabelle 3 für den “Standard Observer” ablesen, welche Einzelbelichtungszeiten dann im Minimum einzuhalten sind (damit das Ausleserauschen nicht zu groß wird). Beispielsweise bei 5% akzeptiertem Zusatzrauschen (also insgesamt 105%, entsprechend 1,05) hat man Einzelbelichtungszeiten von 23 bzw. 174 Sekunden.

Wir können das auch ausrechnen, indem wir unsere Formel nach s (Einzelbelichtungszeit) auflösen:

\( TotalStackNoisePercent(s) =100 \cdot \Large \frac{TotalStackNoise(s)}{TotalStackNoise(3600)} \\\\ \)

Eingesetzt ergibt das:

\( TotalStackNoisePercent(s) =100 \cdot \Large \frac{\sqrt{\frac{3600 \cdot R^2}{s} + 3600 \cdot P}}{\sqrt{R^2 + 3600 \cdot P}} \\\\ \)

Diese Gleichung lösen wir jetz nach s (Einzelbelichtungszeit) auf:

\( (TotalStackNoisePercent)^2 \cdot (R^2 + 3600 \cdot P) = \frac{3600 \cdot R^2}{s} + 3600 \cdot P \)

Wir bringen den Term mit s auf die linke Seite:

\(  \frac{3600 \cdot R^2}{s}  = (TotalStackNoisePercent)^2 \cdot (R^2 + 3600 \cdot P) – 3600 \cdot P  \)

und erhalten schließlich:

\(  s  = \frac{3600 \cdot R^2}{(TotalStackNoisePercent)^2 \cdot (R^2 + 3600 \cdot P) – 3600 \cdot P}  \)

Der Physiker in mir sagt, R (das Ausleserauschen) ist sehr klein. dann ist R2 erst recht klein und kann gegenüber 3600 * P ganz vernachlässigt werden. Wir können danach auch die 3600 herauskürzen und erhalten:

\( s = \frac{R^2}{(TotalStackNoisePercent)^2 \cdot P – P} \)

Wenn wir jetzt das TotalStackNoisePercent als “E” schreiben und P unten ausklammern, erhalten wir:

\( (28) \hspace{1 em} \Large s = \frac{1}{E^2 -1} \frac{R^2}{P}\)

Wenn wir 5% zusätzliches Rauschen akzeptieren, also E = 1,05 dann ist der Vorfaktor:

\(  \frac{1}{1,05^2 – 1} = 9,7561   \)

Bei E=5% erhalten wir die Formel:

\((29) \hspace{1 em}   S = 10 \cdot \frac{R^2}{P}   \)

Schlussfolgerungen für meine präferierten Beobachtungsorte

Meine präferierten Beobachtungsorte

An verschiedenen Orten haben wir ganz unterschiedliche Lichtverschmutzung:

  • Hamburg-Eimsbüttel: SQM 18,0 –> Bortle 8,0
  • Handeloh Aussensternwarte:  SQM 21,1 –> Bortle 3,6
  • Kiripotib, Namibia: SQM 21,9 –> Bortle 1
  • Elmshorn: SQM 20,5  –> Bortle 4,4

Meine Kamera

ZWO ASI294MC Pro

  • CMOS Colour
  • Pixelgröße: 4,63 μ
  • Quantum Efficiency: 75%
  • Ausleserauschen R = 1,5 e-/pixel/s

Quellen: https://astronomy-imaging-camera.com/product/asi294mc-pro-color

Meine Teleskope

  • Teleskop ED80/600 mit Reducer – Öffnungsverhältnis: f/6.4
  • Teleskop: APM APO 107/700 mit Reducer 0,75 – Öffnungsverhältnis: f/4,9

Meine Light Pollution Raten

An meinen Beobachtungsorten ist die Lichverschmutzung (in SQM) anders als beim angenommenen “Standard Observer” Bortle 5 (SQM=19,8 mag).
Auch habe ich andere Teleskope und andere Kameras bei mir zur Verfügung.

Tabelle 4: LightPollutioRate an meinen Standorten

Standort SQM Teleskop (f Ratio) Imager (Sensor) Imager (Pixelsize) Imager (QE) LightPollutionRate
Eimsbüttel 18,0 ED80/510 (f/6.375) Colour Canon EOS 600D (4.3μ) 41% 3,9
Eimsbüttel 18,0 ED80/510 (f/6.375) Colour ASI294MC Pro (4.63μ) 75% 8.27
Handeloh 21,1 ED80/510 (f/6.375) Colour Canon EOS 600D (4.3μ) 41% 0,41
Handeloh 21,1 ED80/510 (f/6.375) Colour ASI294MC Pro (4.63μ) 75% 0.48
Elmshorn 20,5 ED80/510 (f/6.375) Colour ASI294MC Pro (4.63μ) 75% 0,83
Kiripotib 21,9 APM APO 107/700 * 0,75 (f/4,9) Colour Canon EOS 600D (4.3μ) 41% 0,18
Kiripotib 21,9 APM APO 107/700 * 0.75 (f/4,9) Colour ASI294MC Pro (4.63μ) 75% 0,39

Diese “Light Pollution Rate” liefert also Elektronen pro Sekunde; also immer mehr (linear), je länger wir das Einzelfoto belichten.

Thermisches Rauschen

Das Thermische Rauschen können durch Kühlung des Sensors reduzieren.

Tabelle 5: Light Pollution Rate und erforderliche Kühlung für meine präferierten Beobachtungsorte

Standort SQM Teleskop (f Ratio) Imager (Sensor) Imager (Pixelsize) Imager (QE) Light Pollution Rate Thermal Noise Limit (10%) Erforderliche Sensor Temperatur
Eimsbüttel 18,0 ED80/510 (f/6.375) Canon EOS 600D (4.3μ) 41% 3,9 0,39
Eimsbüttel 18,0 ED80/510 (f/6.375) Sony IMX294 ASI294MC Pro (4.63μ) 75% 8.27 0.83 ca. +25°
Handeloh 21,1 ED80/510 (f/6.375) Canon EOS 600D (4.3μ) 41% 0,41 0,04
Handeloh 21,1 ED80/510 (f/6.375) Sony IMX294 ASI294MC Pro (4.63μ) 75% 0.48 0.05 ca. -15°
Elmshorn 20,5 ED80/510 (f/6.375) Sony IMX294 ASI294MC Pro (4.63μ) 75% 0,83 0,08 ca. -5°
Kiripotib 21,9 APM APO 107/700 * 0,75 (f/4,9) Canon EOS 600D (4.3μ) 41% 0,18 0,02
Kiripotib 21,9 APM APO 107/700 * 0.75 (f/4,9) Sony IMX294 ASI294MC Pro (4.63μ) 75% 0,39 0,04 ca. -15°

In der Spalte “Imager (QE)” haben wir die Quanten-Effizienz des Sensors angegeben (41% gilt für die unmodifizierte Cannon EOS 600D)

Die Spalte “Light Pollution Signal” wurde berechnet mit dem “Sky Background Calculator”: Link: https://tools.sharpcap.co.uk

Wie sich das Thermische Rauschen durch Kühlung reduziert, ist für jeden Sensor anders.

Die Spalte “Erforderliche Sensor Temperatur” ergibt sich aus Abbildung 2 (s.o.) für den Sensor Sony IMX294.

Mein Ausleserauschen

Das Ausleserauschen unseres Sensors pro Einzelbild ist ein unvermeidlicher Einflussfaktor; im Beispiel der ZWO ASI 294MC Pro:
R = 1,5 e-/pixel/sec

Zusammenfassung: Optimale Sub Exposures an meinen Standorten

Bei einer 60 Minuten Gesamtbelichtung habe ich ein den unterschiedlichen Standorten unterschiedliche “optimale” Belichtungszeiten für die Einzelaufname (Sub Exposure),wenn man einen persönlichen Qualitätsanspruch von 5% Zusatz-Rauschen ansetzt.

Tabelle 6: Optimale Einzel-Belichtungszeit

Standort Lichtverschmutzung SQM [mag/arcsec²] Teleskop Kamera Light Pollution Rate [e-/pixel/s] Kühlung Einzel-Belichtungszeit [s]
Eimsbüttel 18,0 f/6,375 ZWO ASI294MC Pro 8,31 +25° 3
Handeloh 21,1 f/6,375 ZWO ASI294MC Pro 0,48 -15° 45
Namibia 21,9 f/4,9 ZWO ASI294MC Pro 0,39 -15° 55

Einzelberechnungen: Optimale Sub Exposures an meinen Standorten

Im Einzelen gehen die hier aufgeführten “optiomalen” Einzel-Belichtungszeiten aus den Tabellen x-y hervor.

Optimale Belichtungszeit in Eimsbüttel (SQM 18,0, P=8,27)

Tabelle 7: Ergebnisse: Total Noise in the Stack in Eimsbüttel

Sub Exposure Length Total Stack Noise ASI294 MC Pro Total Stack Noise ASI294MC Pro
[s] e-/pixel/s [%]
1 194,6 112,8
2 183,9 106,6
2,64 181,2 105,0
5 177,2 102,7
10 174,9 101,3
20 173,7 100,7
30 173,3 100,4
100 172,9 100,1
300 172,6 100,0
1000 172,6 100,0
3600 172,55 100,0

Mit folgenden Annahmen:

  • T = 3600 Sekunden
  • P = 8.27 e-/pixel/s
  • R = 1,5 e-/pixel/s  (ASI294MC Pro, Gain=121)

Optimale Belichtungszeit in Handeloh (SQM 21,1 P=0,48)

Tabelle 8: Ergebnisse: Total Noise in the Stack in Handeloh

Sub Exposure Length Total Stack Noise ASI294MC Pro Total Stack Noise ASI294MC Pro
[s] e-/pixel/s [%]
1 99,1 238,3
2 76,0 182,7
5 57,9 139,1
10 50,4 121,1
30 44,7 107,5
45 43,7 105,0
60 43,2 103,8
120 42,4 101,9
300 41,9 100,7
1200 41,7 100,1
3600 41,60 100,0

Mit folgenden Annahmen:

  • T = 3600 Sekunden
  • P = 0.48 e-/pixel/s
  • R  = 1,5 e-/pixel/s (ASI294MC Pro, Gain=121)

Optimale Belichtungszeit in Kiripotib (SQM 21,9 P=0,39)

Tabelle 9: Ergebnisse: Total Noise in the Stack in Kiripotib

Sub Exposure Length Total Stack Noise ASI294MC Pro Total Stack Noise ASI294MC Pro
[s] e-/pixel/s [%]
1 97,5 260.0
2 73,9 196,9
5 55,0 146,6
10 47,1 125,5
30 40,9 109,1
55 39,4 105,0
60 39,2 104,6
120 38,4 102,3
300 37,8 100,9
1200 37,6 100,2
3600 37,50 100,0

Mit folgenden Annahmen:

  • T = 3600 Sekunden
  • P = 0.39 e-/pixel/s
  • R  = 1,5 e-/pixel/s (ASI294MC Pro, Gain=121)

Anhang: Lichtverschmutzung

Lichtverschmutzung im Internet