Lucky Imaging automatisieren, Software?

Status
Es sind keine weiteren Antworten möglich.

Counterfeiter

Aktives Mitglied
Hallo,

Mir ist aufgefallen das beim Lucky Imaging im Grunde nur die Helligkeit des Objekts im Raw-Frame und die Schärfe die Parameter für ein gutes Bild sind. Nehmen wir zur Vereinfachung an wir haben am Auszug den perfekten Fokus eingestellt. Dann reduziert sich doch die Parametersuche auf Belichtungszeit und den davon abhängigem Gain, außerdem der richtige Moment: definiert durch die Bildschärfe. Dies klingt irgendwie nach einer Aufgabe für eine automatisierte Software, gibts da bereits etwas?
Derzeit scheint es eher darauf hinauszulaufen das tonnenweise Daten anfallen und die dann später untersucht und verrechnet werden und weil die Rohdatenmenge so riesig ist, sind es bei den meisten nur ein bis fünf Minuten Video aus einer ganzen Nacht.
Klingt mir irgendwie unlogisch. Weil es nicht sicher ist, das in diesen zwei Minuten das Seeing der Nacht ausgereizt wurde und die Kamera dem Seeing angepasst war. Meine Idee wäre hier eher die Framerate soweit zu reduzieren, dass die Bild live auf ihre Qualität überprüft werden können und ein Algorithmus durch "empirisches Ausprobieren" oder etwas clevereres die optimalen Parameter für die aktuellen Bedingungen findet. Gespeichert werden dann nur Bilder die eine bestimmte Qualität erreichen. In einer weiteren Stufe könnte der Algorithmus natürlich auch an einem automatisierten Fokus drehen.

Gibt es Software die das bereits kann und habe ich etwas bei meinen Gedanken übersehen?

Viele Grüße

Basti
 
Moin,

- Fokus könnte man laufend mitführen (technischen Fokus des Setups);
- Belichtung messen (zeitnah) - wie? Dafür müßte man ein mitlaufendes Video haben, wäre aber denkbar;
- Schärfe beurteilen - wie vor

Letztlich liefe das auf einen Videostream hinaus der in Echtzeit ausgewertet wird zwecks Entscheidung, welches Bild man behält und welches man verwirft

Richtig?

CS
Jörg
 
Exakt. Bei dem aktuellen Kameratreiber erhalte ich sogar Meta-Daten wie der aktuelle Fokus bewertet wird, was Kameras meist eh für ihre Autofokus-Funktion benötigen. Im Grunde sollte das genau das passende sein und die Framerate bleibt sehr hoch.
 
Moin,

dann haben wir hier eine Programmieraufgabe definiert, denn können tut das derzeit kein mir bekanntes Programm, aber das sollte für einen Coder lösbar sein.

CS
Jörg
 
Hi Basti @Counterfeiter ,

also in SharpCap gibt es beim Live-Stacking einen FWHM Filter, der bewirkt dass nur Bilder mit einer bestimmten, guten FWHM in den Stack aufgenommen werden.
Das ist ein bisschen das was du vorschlägst.

Aber es findet bei BLZs im Sekundenbereich und nicht in ms statt.
Robin Glover ist aber sehr offen für Verbesserungen. Vielleicht kann man ihn motivieren so etwas ähnliches in einem Video-Stream für Lucky Imaging einzubauen.

Gruß
Peter
 
Huhu,

SharpCap läuft leider nur unter Windows.
Ich bin gerade dabei ein eigenes Script zusammen zu bauen. Ich hab ein bisschen hin und her gebaut, wie man den meisten Datendurchsatz hin bekommt (bei schnellen Belichtungszeiten). Wahrscheinlich wird es so werden, dass man ca. 2 bis 10 Sekunden Videosequenzen unter den aktuellen Settings im RAW Format von der Kamera lädt und dann auf Qualität überprüft. Je nach Belichtungszeit werden dann mehr oder weniger Frames enthalten sein und je nach Belichtungszeit kann natürlich der Content "on the fly" oder mit bremse der Framerate untersucht werden.

Ich melde mich zurück, wenn ich was vorzeigbares fertig habe.

Viele Grüße

Sebastian
 
Hallo,
ich habe ein Script gebaut, was eine bestimme RAW-Video Länge in einer bestimmten Setting (Gain, Exposure) aufzeichnet und anschließend auswertet.
Eins vorweg: Das mit der Schärfeerkennung ist scheinbar gar nicht so leicht. Rauschen ist z.B. Schärfe. Ich habe den Laplace Kernel zur Kantenerkennung verwendet und eine blur-Funktion aus skikit-images. Irgendwie hat beides seine Berechtigung und ich habe thresholds für beide Varianten eingefügt.

Ich werde mal kurz berichten, wie es jetzt umgesetzt ist und wenn jemand eine bessere Idee hat, dann gern her damit. Was Bildverarbeitung angeht, habe ich noch nicht so viel gemacht.
Nach der Aufzeichnung in den Arbeitsspeicher werden die Raw Bilder aus dem Video extrahiert und geschaut ob genug Dynamik im Bild vorhanden ist, wenn die Farbpixel einen zu kleinen Bereich in den 12 Bit ausfüllen, dann ist die Dynamik schlecht und die Bilder werden verworfen. Ich nehme aber an hier könnte es durchaus pro Objekt abweichende Settings geben.
Wenn 0,1 % der Pixel Maximum sind, ist es überbelichtet und das Bild wird verworfen.
Schaffen es das Bild bis hierher wird mit einem convolution filter auf gray scale debayert und die Auflösung dabei um 1/4 reduziert. Von dem Bild wird dann zur Visualisierung ein Histogram erzeugt. Weiterhin werden zwei verschiedene Blur-Tests durchgeführt. Anschließend wird das Graustufenbild auf die vollen 12 bit zur Visualisierung gestrecket.

Wurden alle Gain und Exposure Settings durchlaufen werden die noch übrigen Bilder, falls sie durch die erforderlichen Schärfe-Thresholds kommen als *.dng 12 bit raw Bild abgespeichert (Format kann Siril auch einlesen). Das unschärfste Bild und das schärfste Bild zeige ich aktuell mit dem Histogramm (vor dem Strecken) zusammen an:

Figure_1.png


Ich denke, dass das Raspberry Pi 4 in der Lage ist die aktuelle Funktion mit mindesten 10 fps auszuführen. Wenn man bedenkt, dass ein RAW-Bild vom IMX290 Sensor schon 2,4 Megabyte groß ist. Sind am Ende der Nacht noch sehr viele bereits vorsortierte und hoffentlich aufs Seeing abgestimmte Daten übrig.

Was aktuell noch fehlt, ist ein halbwegs cleverer Suchlauf durch Gain und Exposure mit den implementierten Bewertungskriterien.

Wer möchte kann gern mit an der Software schreiben oder Tipps geben. Ich habe das Projekt mal etwas unkreativ "NotSoLuckyImaging" genannt:
https://github.com/Counterfeiter/NoSoLuckyImaging

Viele Grüße

Sebastian

P.S. Nicht wundern, das Histogramm ist noch logarithmisch skaliert, dass macht eine Kamera sicher anders. Ich wollte aber gern sehen ob und wie viele Pixel settigen und das sieht man eigentlich nur so.
 
Hi Sebastian,

finde ich sehr interessant. Neue Ideen sind immer gut.
So ganz verstanden habe ich es aber nicht. ;)
Gibt es eigentlich nicht auch Funktionen die einen allgemeinen Schärfe Qualitäts-Wert aus einer beliebigen Aufnahmen bestimmen können?
Das machen doch die automatischer Fokus Funktionen der Kameras.

Du hast völlig recht, dass man die Aufnahmen gleich "online" möglichst gut automatisch selektieren sollte. Auch sollten mM in der Astrofotografie aufgrund der Leistung heutiger Rechner möglichst viele stupide Preprocessing Dinge in die Zeit der Aufnahmen vorverlegt werden.

Mein Überblick zu diesem Thema:
Es gibt mM grob 3 Bereiche in der AF: Lucky Imaging, Kurz- (<<10s) und Lang-Belichtungen >>1min.

Lucky Imaging wird heute einfach durch Aufnahme von Videos mit den dann entsprechenden kurzen Belichtungen im ms Bereich und eigentlich nur für Planeten gemacht. Diese Technik finde ich ziemlich gut entwickelt und es gibt einige gute Programme, die dann aus dem Video nach bestimmten Kriterien die "guten" Aufnahmen heraussuchen.

Bei Langzeit-AF werden mehrere bis zu 100 (wirklich so viel?) Bilder gemacht und nach der Aufnahme durch viele gute Programme entsprechend selektiert und verarbeitet. Es ist etwas ineffektiv, da viel Verarbeitungszeit benötigt wird. Hier wäre eventuell ein automatisches Kalibrieren gleich während der Aufnahme interessant oder auch eine Vor-Selektion. Aber man hat den Nachteil, dass man dann auf diese Kalibrierung und Vor-Selektion angewiesen ist und sie nicht im Nachhinein ändern kann.

Am interessantesten finde ich die Kurzeit-AF oder auch EAA. Hier ist der Vorteil, dass der Aufnahme Vorgang viel weniger komplex ist, zB ist kein Guiding
notwendig und man das Ergebnis schon während der Aufnahme kontrollieren und eingreifen kann. Hier finde ich ist das grösste Potential für "online Processing".
SharpCap macht da zB schon einiges. ZB Background Subtraction (das ist echt super, braucht man kein Flat mehr), Filtern nach der FWHM, Schärfen, Entrauschen usw.

Es gibt auch noch ein grundsätzliches Problem. Um überhaupt "stacken" zu können, muss die Aufnahme genug Sterne enthalten um sie ausrichten zu können.
Das heisst, dass leider wohl Aufnahmen deutlich unter 1s, bei denen man zB das Seeing besonders gut austricksen könnte, nicht geeignet sind (ausser beim Sonderfall Planeten Lucky Imaging).

Sorry für diesen meinen Überblick. Ich habe das gebraucht. ;)

Gruß
Peter
 
Zuletzt bearbeitet:
Hallo Peter,

der Automatische Fokus bei Kameras ist noch etwas komplizierter mit ihren Phasenfokus-Messpunkten im Sensor. Ich denke der allgemeine weg ist den Fokus mit dem Laplace Kernel oder ähnlichen abgeleiteten Methoden zu untersuchen. Jedoch habe ich mich gestern mit dem neuen Script am Jupiter versucht und habe erste Erfahrungen am "lebend Objekt" sammeln können.
Also Abseits der grauen Theorie gibt es ein riesen Problem:
Je nach Histogramm wird die Schärfe durch ein Schärfebestimmungsfunktion unterschiedlich beurteilt und das ist ein echtes Problem. Ich konnte gestern quasi nur Schwellwerte pro Blichtungszeit/Gain-kombi festlegen. Natürlich könnte man das automatisieren, indem man nur die besten 10 aus 100 nimmt, bei gleichen Settings.
Das Problem trifft leider auch nicht nur mein Script allein. Bei AutoStakkert war es das selbe Trauerspiel. Ich hatte Bilder mit unterschiedlichen Belichtungszeiten reingegeben. Alle Bilder aus einer Reihe wurden automatisch Unscharf behandelt und die aus den anderen wurde selektiert. Es gab wirklich keinen Grund das andere Material zu verwerfen. Also die Software hat quasi das selbe ungelöste Problem: AutoStackart sollte nur mit Material aus den selben Settings gefüttert werden, sonst wird es "quatsch".
Ich hatte ein wissenschaftliches Paper gelesen, indem bei den Sternen der Strehlverhältnis als Schärfefunktion ausgewertet wird - zum Idealen Strehl der Optik. Das geht natürlich beim Planten, Sonne und Mond nicht.

Insgesamt bin ich mit der 30 $ IMX290 sehr zufrieden und werde weiter am automatisierten Skript arbeiten, weil es doch recht viel Material vorselektiert hat. Gerade bei 12 Bit Raw mit Full HD ist es nicht ganz unrelevant nicht GB-Weise die Daten aus einer Nacht durchsuchen zu müssen.


Nochmal zum Stacking:
Wenn man ein Foto von einem Deep-Sky Objekt schießt und hat keine Sternen dabei, wird man wohl auch kein Objekt drin haben.... jedenfalls sagt mir das mein Gefühl. Aber wahrscheinlich kann man bei der Registrierung nicht die selben Schwellwerte wie bei der Langzeitbelichtung wählen (für die Sternerkennung).
 
Ich habe die letzten Abende mit dem Handling vom Multiprocessing verbracht. Nun läuft das Script auf allen 4 CPU-Kernen des Raspberry Pi 4 und schafft doch "nur" 3,9 FPS ungekühlt. Ich weiß jedoch, dass ein gekühltes Raspberry ca. das 1,5 fache schafft. Also muss die Nacht kalt sein oder diese Raspberry Pi Cases mit diesen nervigen Minilüftern heulen auf (Ohje, dann lieber weniger FPS).
Hier mal noch die Featureliste des Scripts:
  • multi CPU-Kernen fähig
  • IMX290 mit libcamera über den CSI Port des Raspberry PI 4 mit 8 GB (30 $ IMX290 + min 100 € Raspberry Pi 4)
  • Speichert FITS (4,2 MB) und/oder DNG (3,4 MB) 12 Bit RAW-Bilder ab
  • Speichert nur Raw-Bilder die einstellbare Kriterien erfüllen (Dynamik, nicht Überbelichtet, nicht verschwommen (scharf))
  • Es werden im Hintergrund kurze Videos mit bis zu 60 FPS aufgenommen, jedoch ist die effektive Bearbeitungsrate nur 3,9 FPS

Also vielleicht nochmal kurz meine Gedanken mit Beispielrechnung, die mich auf die Idee mit dem Script gebracht haben:

Ein RAW-Bild des IMX290 Sensors ist: 1920 x 1080 x 2 Byte ~ 4 MB groß. Würde man ein Target (z.B. Planeten) mit den möglichen 60 FPS auf einen 64 GB USB3.0 Stick aufnehmen, wäre der Stick innerhalb von ca. 4,5 Minuten gefüllt.
Ob das Seeing, in den 4,5 Minuten von den vielleicht 3 h in denen der Planet ausreichend hoch steht, gut war, wird man erst zuhause nach ein paar Minuten oder Stunden der Auswertung von 64 GB feststellen können. Naja, Lucky Imaging halt. :D

Natürlich gäbe es noch die Option mit komprimierten Videocodes zu filmen und dabei die Kamera von 12 Bit auf 8 Bit zu verstümmeln... naja...

Mit dem NotSoLuckyImaging Script definiert man einen Schwellwert des Bildmaterials das man behalten möchte: zB. 5 % und stellt es für drei Stunden zu ca. 4 FPS an. Man erhält also: 3 x 3600 x 4 x 0,05 = 2160 selektierte RAW-Bilder zu 8,6 GB (FITS). Auch nicht gerade wenig, aber mit 1 % des besten Materials der 3 h wäre es nur noch 1,7 GB.

Ich hoffe es wird mal wieder besseres Wetter, dann werde ich mich noch einmal am Jupiter versuchen.

Das Script werde ich immer auf meinem github-Repo auf dem neusten Stand halten. Wer die selbe Hardware hat, kann gern mal testen.

Viele Grüße

Sebastian
 
Vorschlag:
Neben den einstellbaren Kriterien wird noch ein "Qualitätswert" berechnet. Z.B. ganz simpel als gewichtete Multiplikation der Dynamik, Überbelichtung, Schärfe). Idelerweise mit einstellbaren Gewichtungsfaktoren.
Außerdem kann man dann festlegen wie viele Bilder man haben möchte. Beispielsweise 1000 Bilder. Dann nimmt das Script die ersten 1000 Bilder welche die Kriterien erfüllen und speichert sie, merkt sich aber zu jedem Bild den Qualitätswert in einer sortierten Liste. Neue Bilder werden dann nur gespeichert, wenn sie besser als das bisher schlechteste Bild sind. Das "schlechte" Bild wird dabei einfach überschrieben/gelöscht.
Das sollte sich mit relativ wenig Aufwand realisieren lassen. Und man könnte den Speicherbedarf für einen "Durchlauf" damit zuverlässig begrenzen und kalkulierbar machen. Damit wären dann auch mehrere Durchläufe kein Problem - es bleiben halt aus jedem Durchlauf nur die xxx besten Bilder übrig für die spätere Verarbeitung.

Ciao, Udo
 
Hi Sebastian,
Zitat von Counterfeiter:
...
Ob das Seeing, in den 4,5 Minuten von den vielleicht 3 h in denen der Planet ausreichend hoch steht, gut war, wird man erst zuhause nach ein paar Minuten oder Stunden der Auswertung von 64 GB feststellen können. Naja, Lucky Imaging halt. :D
...
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
wie willst du eigentlich bei so langen Aufnahmezeiten mit der Rotation der Planeten umgehen?

Gruß
Peter
 
@ubit diesen Qualitätsindex hätte ich tatsächlich auch gern berechnet. Leider stellt sich das als gar nicht so einfach heraus. Z.B. die Schärfe nach dem Laplace Kantenfilter hat z.B. keine direkte Range und ist nach oben offen und ist auch pro Motiv sehr stark unterschiedlich. Man kann es also schlecht zusammenbringen.

Die Idee mit den z.B. 1000 Bilder max finde ich gut. Müsste ich nochmal überlegen, wie man das effektiv anstellen könnte, da das Abspeichern eines FITS-Bildes doch recht lange benötigt (0,2 Sekunden). Klingt aber sehr interessant, warum nicht auch altes Bildmaterial löschen, wenn man besseres gesammelt hat.

@AstroPZ Ich hatte das so verstanden: Das Seeing ist die Luftunruhe und kommt durch Luftströmungen zustande. Hierfür gibt es mal besser und mal schlechtere Zeiten. Wegen der Rotation kann man Planetenabhängig nur 2 bis 4 Minuten am Stück stacken. Bis zu 30 Minuten könnten möglich sein, wenn man es mit weiterer Software derotiert. Falls meine Annahme falsch ist, gern korrigeren...
Nun wäre meine Vorstellung, dass in den z.B. drei Stunden Beobachtung einige Momente existieren, die innerhalb kurzer Zeit viel scharfes Bildmaterial liefen. Demnach müsste man die gesammelten 3 h nach diesen "Schüben" durchsuchen und stackt dann Bildmaterial aus einem relativ kleinem Zeitraum. Bei 4 Minuten mit 4 FPS wären es 960 Bilder, von denen man evtl. 20 % verwenden kann obwohl man nur nach den Besten 1 % suchen lässt. Da alle Bilder schon vorselektiert sind, würde man im Stacking natürlich nicht mehr nur 5 oder 20 % der Bilder nehmen, sondern 80 % oder mehr.

Wenn sich natürlich in der Praxis zeigt, dass man über eine Beobachtungszeit X eine zeitlich sehr gleichmäßig verteilte Anzahl an Bilder abspeichert (also immer zwei gute pro Minute), wird einem dieses Skript nicht weiterhelfen. So hatte ich aber die Bewegung der Luftmassen nicht verstanden.

Viele Grüße

Sebastian
 
Wie sind denn die Wertebereiche? Wenn x-unendlich, dann nimmt man halt 1-1/Wert. Bei Werten von 0-100 nimmt man Wert/100. Usw. Jeweils multipliziert mit einem einstellbaren Gewichtungsfaktor. Sinnvolle Faktoren sollten sich empirisch ermitteln lassen wenn man das Verfahren "offline" auf z.B. die extrahierten Einzelbilder eines längeren Videos anwendet.

Vorteil wäre halt, dass man die Qualitätsschwellen recht niedrig ansetzen könnte und beispielsweise beim Jupiter trotzdem in 2 Minuten die besten 150 Frames sammeln kann.

Und speichern sollte mit einer SSD (M.2) deutlich schneller gehen. Die ist für einen Astro-Raspi eh gut angelegtes Geld.

Ciao, Udo
 
Hi Sebastian,
Zitat von Counterfeiter:
@ubit diesen Qualitätsindex hätte ich tatsächlich auch gern berechnet. Leider stellt sich das als gar nicht so einfach heraus. Z.B. die Schärfe nach dem Laplace Kantenfilter hat z.B. keine direkte Range und ist nach oben offen und ist auch pro Motiv sehr stark unterschiedlich. Man kann es also schlecht zusammenbringen.

Die Idee mit den z.B. 1000 Bilder max finde ich gut. Müsste ich nochmal überlegen, wie man das effektiv anstellen könnte, da das Abspeichern eines FITS-Bildes doch recht lange benötigt (0,2 Sekunden). Klingt aber sehr interessant, warum nicht auch altes Bildmaterial löschen, wenn man besseres gesammelt hat.

@AstroPZ Ich hatte das so verstanden: Das Seeing ist die Luftunruhe und kommt durch Luftströmungen zustande. Hierfür gibt es mal besser und mal schlechtere Zeiten. Wegen der Rotation kann man Planetenabhängig nur 2 bis 4 Minuten am Stück stacken. Bis zu 30 Minuten könnten möglich sein, wenn man es mit weiterer Software derotiert. Falls meine Annahme falsch ist, gern korrigeren...
Nun wäre meine Vorstellung, dass in den z.B. drei Stunden Beobachtung einige Momente existieren, die innerhalb kurzer Zeit viel scharfes Bildmaterial liefen. Demnach müsste man die gesammelten 3 h nach diesen "Schüben" durchsuchen und stackt dann Bildmaterial aus einem relativ kleinem Zeitraum. Bei 4 Minuten mit 4 FPS wären es 960 Bilder, von denen man evtl. 20 % verwenden kann obwohl man nur nach den Besten 1 % suchen lässt. Da alle Bilder schon vorselektiert sind, würde man im Stacking natürlich nicht mehr nur 5 oder 20 % der Bilder nehmen, sondern 80 % oder mehr.

Wenn sich natürlich in der Praxis zeigt, dass man über eine Beobachtungszeit X eine zeitlich sehr gleichmäßig verteilte Anzahl an Bilder abspeichert (also immer zwei gute pro Minute), wird einem dieses Skript nicht weiterhelfen. So hatte ich aber die Bewegung der Luftmassen nicht verstanden.

Viele Grüße

Sebastian
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
hört sich alles nach einem guten Plan an.
Ich glaube, dass die Derotation allerdings irgendwann bei zu grossen zeitlichen Abständen nicht mehr funktioniert. Ist natürlich auch von Planet zu Planet unterschiedlich.

Ok, ich hab's jetzt endgültig verstanden. ;)
Du minimierst/optimierst damit die abgespeicherte Datenmenge, auf das was am besten ist.
Und man kann sich dann die besten Momente aus einem längeren Zeitraum heraus picken.
Und muss nicht die ganze Zeit am Teleskop auf den "Moment" warten.
Das wäre auch etwas für Holger @komposer.

Gruß
Peter
 
Yupp - bei Mars kann man dann halt längere Einzelsessions fahren, bei Jupiter sollte man im Bereich 2-3 Minuten bleiben. Aus diesem Zeitraum werden dann nur die besten xxx Bilder "behalten" - statt später aus einer riesigen Zahl von Einzelbildern die besten yy% herauszufischen. Grundsätzlich eine sehr nette Lösung um Speicherplatz zu sparen. Doof ist halt die starke Reduktion der Framerate bei der Aufnahme - wäre natürlich super, wenn das quasi "in Echtzeit" wirklich schnell ginge. Das ist auf einem Raspi aber eher illusorisch. Schnelle Mini-PCs sollte da aber durchaus mehr leisten können (natürlich auch abhängig von der Pixelzahl/Kameraauflösung/ROI). Wobei die Auswahl der ROI eine deutliche Steigerung der Framerate möglich machen sollte - auch auf einem Raspi. Das reduziert die Menge der Daten ja doch erheblich und macht sowohl Auswertung als auch Speicherung deutlich schneller.

Ciao, Udo
 
Zusätzlich einen Beschleunigungssensor am RP, so dass Aufnahmen aus Zeiträumen mit Erschütterungen an der Optik verworfen werden :)
 
@Wintergatan die Idee ist gut... eigentlich wird das Bild beim Wackeln natürlich auch aussortiert, aber ein Wackeln am Teleskop würde dann die ganzen Filterparameter nicht verändern/beeinflussen...

@ubit der Wert selbst ist nicht das Problem, aber je nach Historgram wird ein Bild als Scharf oder nicht Scharf klassifiziert. Kannst du gern mal mit AutoStakkert testen, der kann auch nur Bilder mit halbwegs gleichem Histogram vergleichen.


Gerade ist perfektes Wetter um das Script zu testen... immer mal zieht ne Wolke vorbei ... und dann werden die Bilder gleich aussortiert.

Ich habe das komplette Multithreading zwei mal überarbeitet. Jetzt läuft es mit 5,6 Bildern die Sekunde bei 10 % Speicherung auf einen USB3.0 Stick (0.1 bis 0.05 Sekunden Speicherzeit pro Bild)....

Code: 
5.8 images per second blur processed (2825 / 490.47300386428833 s)


Viele Grüße

Sebastian
 
Gibt es wirklich so große Unterschiede im Histogramm? Bzw. sind das dann nicht ohnehin Dunst/Wolken?
Kann man ggf. eine gewisse Abhängigkeit finden zwischen Histogramm und Unschärfe? Vielleicht die Breite des "Wellenberges" bei 50% Max-Wert?

Ciao, Udo
 
Hallo Udo,

also in den Papers die ich gelesen habe stand, dass die Lösung dazu weiterhin erforscht wird. Gerade fürs Machine Learning und Gesichtserkennung ist man natürlich daran interessiert unscharfe Bilder nicht in die Anlernphase zu bringen. Was sich wohl automatisiert äußerst schwierig gestaltet. Ich denke, jenes Thema ist mir zu groß. Ich mach es einfach wie jede Kamera auch, wenn man Gain und Exposure gefunden hat, schaut man welches Bild (direkter Bildvergleich) die beste Kantenschärfe liefert. Mehr tut Autostakkert und co. auch nicht.

Tests heute: scheint erstmal zu funktionieren... Bequemer könnte es sein und eine GUI bekommen, aber das steht hinten an.

Viele Grüße

Sebastian
 
Da die Bilder vom Script bereits nach dem "Blurparameter" sortiert sind ist bei AutoStakkert 3.0 zu sehen, wie die Bildqualität ähnlich der grünen (sortierten) Kurve erfolgt. Ist nochmal ein netter Test ob alles funktioniert... demnach ist alles vorsortiert und ich könnte auch nur die beste Bildauswahl reingeben. Kleiner Unterschiede werden wohl dadurch kommen, dass die Bilder getrimmt bei AutoStakkert auf Schärfe untersucht werden.

1669840933911.png
 
Hallo,

da der letzte Test am Mond recht gut gelungen war, habe ich direkt das Script auf DeepSky erweitert...
Es ist aus dem Python Package "photutils" ein DAOStarFinder implementiert, der die Schärfe der 10 hellsten Sterne auswertet. Wobei es durchaus cleverer sein könnte einen Stern manuell zur Beobachtung zu selektieren (wie bei PHD2). Aber die schweren GUI Sachen später, erstmal am Himmel testen.
Mit diesem Algorithmus sind nur noch 2 Bilder die Sekunde in der Abarbeitung möglich, wobei das bei DeepSky ausreichend sein sollte. Ich denke eher an Kugelsternhaufen mit Belichtungszeiten um 1 Sekunde herum. Da man DeepSky Objekte die ganze Nacht aufzeichnen kann (keine schnelle Rotation wie bei Planeten) macht das "NotSoLuckyImaging" Script meiner meiner Meinung nach wieder Sinn.
Beispielrechnung:
8 h * 3600 Sekunden * 4 MB Fits Datei (für IMX290) = 115 GB an Dateien
Hier würde es Sinn machen nur die besten 2 h in eine spätere Auswertung mit aufzunehmen.

Leider zeigt sich der Himmel bedeckt und so bedeckt, dass nicht mal das Skript helfen kann... Weitere Tests lassen noch auf sich warten.

Viele Grüße

Sebastian
 
Moin Sebastian,

coole Sache die Du da machst - ich bin auf erste Ergebnisse mehr als gespannt.

CS Jörg
 
Hallo,

ich habe mir gedacht, warum aufhören, wenn ich jetzt schon die Sternpositionen habe. Nun können die Bilder auf Wunsch auch "plate solved" werden. Damit es nicht ewig dauert, kann man optional die ungefähre Position angeben und ein Such-Timeout. Andere Parameter (arcsec per pixel) müssten einmalig eingetragen werden.
So gehts:
  • astrometry.net offline solver auf Pi installieren und den passenden Sternenkatalog für die Brennweite laden (Beispiel IMX290 an 1200 mm):
  • Code: 
    #!/bin/bash
for ((i=1;i<=100;i++));
do
   wget http://data.astrometry.net/4200/index-4204-`printf %02d $i`.fits
done
  • die config von Astrometry.net in /etc/ auf den Index-Ordner zeigen lassen
  • das Kommando solve-field sollte nun lauffähig sein und mit einem Testbild passend zum Index-File funktionieren

Implementiert habe ich es wie folgt:
  • Die Sterne werden nach einer Background Substruction durch DAOStarFinder gesucht
  • anschließend wird die Schärfe, gemittelt für 10 Sterne, den Qualitätsparameter bilden
  • wenn die plate solve Option aktiviert ist, werden die Sternpositionen und die ermittelten Magnituden-Werte in einer Fits-Datei mit nur einer BinaryTable abgelegt (kein Bild Inhalt)
  • atrometry.net kann nun dieses Fits-Datei (nennt sich dann *.xyls) öffnen und die Sterne nach den mag Werten sortieren
  • der Vorteil ist, dass der Astrometry-Aufruf nicht erneut damit beginnen muss, das Bild nach Sternen zu durchsuchen - das spart Rechenzeit
  • Ich parse die Ausgabe von solve-field auf Ra und Dec, außerdem auf WCS Rotation für die Kamera
Derzeit gibt es keinen direkten Mehrwert durch das Plate Solving, das soll sich aber ändern. Mit einem kleinen Testscript und PyIndi ist es mir gelungen die ermittelten Koordinaten in das Teleskop zu Sync'en. Ich müsste die Funktion jetzt demnächst ins Hauptskript überführen, dass ich dann einfacher das Newton auf EQ-Plattform Richtung Target bekomme - also über Ansicht von KStar oder Stellarium. Weiterhin wäre die WCS Information per pyIndi auch an einen Indi Kameratreiber übertragbar, damit könnte KStar direkt den Bildausschnitt am Himmel anzeigen.

Nun wäre mir noch ein Sache wichtig. Wenn das Plate Solven im Hintergrund vor sich hin passiert, wäre es schön direkt den Ausrichtungsfehler zu berechnen während es die ersten Aufnahmen macht. Da hänge ich aber gerade an den Formeln.
Dieses hier hatte ich gefunden:
aber leider steht nur wie der Fehler für das Drift Alignement per Süd und West/Ost pro Achse berechnet wird, nicht wie man aus beliebigen Himmelskoordindaten den Ausrichtungsfehler bestimmen kann. Vielleicht habe ich es auch nur nicht verstanden? Hat das schon mal jemand Versucht? Ich habe im Grunde alle Variablen zusammen, ich benötige nur noch eine passende Formel für die beiden Ausrichtungsfehler Az und Alt meiner EQ-Plattform.

Viele Grüße

Sebastian
 
Hi Sebastian,

toll, was du da entwickelst.
Ist auch für meine eigene SW interessant, zB Berechnung des Alignment Error. Kann dir da aber nicht helfen.

Vorschlag: Kannst du das Script in einen Teil aufteilen, der unabhängig von Kamera HW und Library ist, dann könnte man diesen Teil da es ja Python ist auch auf anderen Systemen (Windows) benutzen.

Im Idealfall, könnte man das als Python Script in SharpCap laufen lassen. Das wäre wahrscheinlich genial.

Gruß
Peter
 
Hallo Peter,

es ist auch geplant den Kamera-Teil zu abstrahieren. Damit das Script nicht nur auf libcamera beschränkt bleibt. Es scheint erstaunlich simple zu sein mit Indi eine "blob" zu empfangen, der z.B. ein FITs Bild ist. Ich denke nur, für die Kamerafunktion und Framerate bei Videos würde Indi die Sache sehr ausbremsen. Aber ich habe hier keine Erfahrungen. Hat jemand schon über Indi-Treiber Videos bezogen? Per PHD2 lese ich eine Webcam aus, aber auch nur aller 0,5 Sekunden... das klappt noch ganz gut bei sehr wenigen Pixeln.

Okay, vielleicht werde ich mal zur Himmelsmathematik ein Beitrag eröffnen.

Viele Grüße

Sebastian
 
Nabend,

also das Projekt ist nicht tot... es wird immer bedienfreundlicher. Es ist jedoch bisher noch recht stark auf meine Bedürfnisse zugeschnitten.
Jedoch gibt es jetzt eine GUI, in der schon die ersten Dinge konfiguriert werden können. Die GUI läuft im Webbrowser und das Videomaterial wird in den Browser gestreamt. Ich kann also mit dem Smartphone am Teleskop stehen und den manuellen Fokus einstellen und parallel im Haus mit dem PC das Videobild sehen.
Ich habe auch ein PyIndi Client geschrieben, der mein Teleskop verbindet und mit dem über das Webfrontend manuell geguidet werden kann. Also per "Pulse Guide Command". Daher die neuen Guide Buttons. Wenn die Ausrichtung nicht ganz perfekt war, kann man hier den Planeten oder "what ever" wieder zurückbringen.
Ich spiele auch mit dem Gedanken nach dem "Center of Mass" im Bild automatisch zu Guiden. Natürlich nicht so gut wie PHD2, nur ausreichend gut um einen Planeten halbwegs in der Mitte des Bildes zu halten. Naja, mal schauen! Angeblich solls hier 0 Uhr freie Sicht geben... drückt mir die Daumen... aber mit der Wolkendecke ist auch der Funktionsumfang gewachsen ;)

1675547314093.png


P.S. Ich habe keine Ahnung von Webdesign... man sieht es sicherlich. Falls mir da jemand einen Pull-Request auf Github schicken will... gern :)
 
Hallo,

eigentlich hatte ich heute was anderes vor und wollte meine neue ToupCam Guiding Cam am Raspberry Pi zum Laufen bringen. Irgendwie hat nichts funktioniert, alles sehr instabil. Sowohl PHD2 als auch KStars auf dem Host System und auf dem Raspberry Pi immer wieder abgestürzt. Also nichts mit Guiding... wie aus dem aktuellen Aufbau noch irgendwas rausholen? Achja, ich hab ja noch meine App auf dem PI.

Alles lief auf Anhieb und ich habe 30 Minuten Daten vom Mond sammeln können. Einfach den Regler auf 5 % Speicherrate gestellt, Methode Laplace und nebenher beim durchs Forum stöbern Mond geschaut und immer mal nen Guiding Pulse über das Webfrontend an die EQ-Platform gegeben, damit die aktuellen Krater im Bild bleibt.

Regler auf 5 % waren nach 30 Minuten dennoch ca. 6,5 GB an Fits-Daten.

1677622203215.png


Nebenher konnte ich beobachten, dass es immer mal "Bursts" von gutem Seeing gab. Da das Seeing, in meiner App, über die letzten 1000 Bilder gemittelt ausgewertet wird (also ca. 100 Sekunden), werden solche "guten Brusts" auch bei 5% vollständig abgespeichert. Damit ist eigentlich das Hauptziel erreicht. Es verfestigt sich der Gedanken, dass ein 3 Minuten und 30 GB großes Video nicht das Optimum aus der Nacht herausholen kann.

Ein fertiges Bild werde ich mal nachreichen. Derzeit wehrt sich aber Autostakkert beim Debayern der FITs oder was dieses Pattern da soll...

Viele Grüße

Sebastian
 
Nabend,

Ich wollte gern noch meine Aufnahme von gestern zeigen.
Das vielleicht interessante: Mein Workflow bei Autostakkert ist nun ein bisschen anders. Gerade weil Autostakkert auch recht schnell durcheinander kommt, wenn die Oberfläche sich zwischen den Aufnahmen zu sehr hin und her bewegt. Jedenfalls ich bekomme da schnell Artefakte hinein.

Autostakkert:
  1. 15 sehr gute Aufnahme auswählen, die sehr ähnliches Alignement haben - also einfach nach Dateinamen sortieren, da der Bewertungsfaktor das Erste im Dateinamen ist.
  2. Stacken mit 1.5 Drizzle und "Sharpened", da bei Lucky Imaging, meiner Meinung nach, schon mit 2,7 um Pixel und 1200 mm Brennweite ein Undersampling vorhanden ist
  3. Processing Time ca. 45 Sekunden
Siril:
  1. Da ich im Autostakkert bereits recht angetan vom "Sharpened" Häkchen bin, habe ich nur noch eine vorsichtige Runde Deconvolution durchgeführt
  2. Remove Green Noise
  3. Stretch
Das Bild habe ich hier:
forum.astronomie.de

Mond - Not So Lucky Imaging

"Not So Lucky Imaging" Aufnahme mit eigener Aufnahme-APP, die bereits die verwaschenden Aufnahmen verwirft und nur einen vorgewählten Prozentfaktor an guten Aufnahmen abspeichert. Somit konnte ich den Mond (und die Atomsphäre) über 30 Minuten...
forum.astronomie.de forum.astronomie.de

Viele Grüße

Sebastian
 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben