Neues Stacking-Software-Projekt "PlanetarySystemStacker"

Status
Es sind keine weiteren Antworten möglich.

Rolf_Hempel

Aktives Mitglied
Vor ein paar Monaten habe ich mit der Entwicklung einer neuen Stacking-Software für Objekte des Sonnensystems (Mond, Sonne, Planeten) begonnen, unter Verwendung aktueller Softwaretechnologie. Gerade ist ein erster Prototyp fertig geworden. Er enthält alle Komponenten, die zum Stacken eines Videos oder einer Sammlung von Einzelaufnahmen erforderlich sind. Lediglich eine graphische Benutzerschnittstelle fehlt noch, so dass die Ausführung einstweilen nur im Batchbetrieb möglich ist. Der gesamte Source-Code ist auf Github frei zugänglich (Open Source). Zusätzlich plane ich, alle algorithmischen Details zu veröffentlichen.

Bisher gibt es drei Softwarelösungen zum Stacken: Registax, AviStack2 und AutoStakkert!3. Die ersten beiden sind seit über acht Jahren nicht mehr gepflegt worden, so dass meines Wissens AutoStakkert!3 das einzige noch aktive Projekt ist. (Ich habe zum Beispiel sehr gerne AviStack2 für meine Mondaufnahmen benutzt, aber seit ich auf Windows 10 umgestiegen bin, kann das Programm meine Input-Files nicht mehr öffnen.)

Wir sollten den Autoren der existierenden Programme dankbar sein für die vielen Stunden, die sie in die Entwicklung ihrer Programme und die Bereitstellung der Executables investiert haben. Ich sehe aber ein großes Problem in der Abhängigkeit von einer einzigen Closed-Source-Software und ihrem Entwickler. Um diese Abhängigkeit zu überwinden, habe ich mich entschlossen, ein eigenes Open-Source-Projekt zu beginnen. Da keiner der früheren Autoren den Source-Code veröffentlicht hat, ganz zu schweigen von den zugrundeliegenden Algorithmen, war der Start etwas mühsam. Glücklicherweise ist die Entwicklung eines Stacking-Programms aber keine "Rocket-Science", und so habe ich nach ein paar Monaten den obengenannten Prototypen fertiggestellt. In meinen bisherigen Tests produziert er Bilder gleicher Qualität wie AutoStakkert!3, aber ich bin sicher, dass bei Tests mit weiteren "pathologischen" Anwendungsbeispielen noch einige Justierungen erforderlich sein werden.

Den Prototypen habe ich in Python geschrieben. Er ist also noch nicht optimiert hinsichtlich Ressourcennutzung (CPU, RAM). Tatsächlich braucht er für dasselbe Ergebnis auf meinem Laptop im Moment noch etwa zwei mal so lange wie AutoStakkert!3. Ich habe noch nicht entschieden, welche Programmiersprache und welches GUI-Toolkit für die endgültige "Produktionssoftware" zum Einsatz kommen wird. Optimale Performance, gute Wartbarkeit und eine moderne Benutzerschnittstelle werden die wichtigsten Kriterien sein.

Mit dem folgenden Beispiel möchte ich die Leistungsfähigkeit des Prototypen illustrieren. Das Video habe ich mit meiner ASI120MM-S am C11 aufgenommen. Die Luft war ziemlich unruhig, so dass viele kleinräumige Verzerrungen im Video die Qualität des Multi-Punkt-Alignments herausforderten. Ich habe 10% der 1785 Frames gestackt. Das Ergebnis habe ich dann noch mit Wavelets in AviStack2 geschärft. Hier ist das ganze Beispielbild:

complete_PSS.jpg

Zum Vergleich mit AutoStakkert!3 habe ich dasselbe Video auch mit diesem Programm bearbeitet, unter Verwendung einer ähnlichen Zahl von Alignment-Punkten (ca. 450). Schärfung wieder in AviStack2 mit denselben Einstellungen wie oben. Hier das Ergebnis:

complete_AS.jpg


Um eventuelle Unterschiede besser sichtbar zu machen, habe ich dann beide Bilder auf 200% vergrößert und kritische Zonen herausgeschnitten. Hier ist erst einmal Sinus Iridum und Umgebung. Die Details auf dem strukturarmen Mareboden sind eine Herausforderung für das Programm, weil es dort kaum Anhaltspunkte für die Verschiebungsberechnung findet. (Das scharfe "gestackte" Bild steht ja noch nicht zur Verfügung!) Zunächst die Version mit meinem Programm:

sinus_iridum_PSS.jpg

Und hier die von AutoStakkert!3:
sinus_iridum_AS.jpg


Das nächste Beispiel zeigt die Zone nahe dem Mondrand. Das Problem hier ist das Fehlen von Schatten und der abrupte Übergang zum Hintergrund. Wieder zunächst mein Programm:

rim_PSS.jpg

Und jetzt AutoStakkert!3:
rim_AS.jpg

Meiner Meinung nach sind die Unterschiede marginal. Das PSS-Bild ist vielleicht etwas weniger "körnig", so dass es ein wenig mehr Schärfung vertragen könnte. Aus Gründen der Fairniss habe ich das aber nicht gemacht.

Wir wird es jetzt weitergehen? Nun, bisher habe ich den gesamten Code für den Prototypen selbst geschrieben. Mein Ziel ist es aber, das Projekt zu einer Community-Aktion zu machen, zu der andere professionelle Softwareentwickler beitragen können. Ein Freund aus Dänemark hat schon ein Modul zum Import von SER-Videos geschrieben, das bald in den Code integriert werden soll. Als Leiter eines Software-Forschungsinstituts im Deutschen Zentrum für Luft- und Raumfarht (DLR) hoffe ich natürlich auf Hilfe durch den einen oder anderen meiner Mitarbeiter. :) Andere Freiwillige sind aber natürlich auch willkommen!

Wie sagt man so schön: "Stay tuned" für weitere Details zum Projekt.

Beste Grüße
Rolf
 
Hallo Rolf,

ich finde Transparenz von Programmen und Beschreibung von Algorithmen immer sehr gut. Auch, wenn die Anwender der Software ihre Bearbeitungsschritte dokumentieren. Dann kann man das alles nachvollziehen. Und selber viel daraus lernen.

Aus eigenem Interesse ;) hoffe ich, dass Du bei Python bleibst. Mit sehr viel neuem Aufwand lässt sich das vielleicht auch parallelisieren für eine bessere Performance?

Dein Programm braucht den Vergleich mit Astrostakkert nicht zu scheuen. Das sieht sehr gut aus. Vielleicht solltest Du die Bilder blinken (animated gif), um die Unterschiede zu verdeutlichen. Wenns die überhaupt gibt.

Viel Erfolg weiterhin für Deine Entwicklung,
Peter
 
Hallo Rolf,

ein tolles Projekt und ein bereits sehr gutes Ergebnis ! In der Amateurastronomie freut man sich ja über jede Weiterentwicklung und Dein Ansatz liefert schon im jetzigen Stadium sehr gute Ergebnisse. Ich bin sehr gespannt wie es weitergeht. Wenn meine Programmierkenntnisse nicht so furchtbar gering wären, würde ich das Projekt gern unterstützen. Aber Deine Software steht auf jeden Fall auf der Liste wenn die Planetensaison wieder losgeht. Tester werden ja immer gebraucht ;)

Wenn ich die 100% Ansichten blinke sehe ich kaum einen Unterschied. Einige Strukturen im Mareboden scheinen mir mit Deiner Software sogar etwas besser hervorzutreten. Ist aber wirklich nur ein sehr kleiner Unterschied wenn man blinkt. Sehr vielversprechend !

Schon jetzt vielen Dank für Dein Engagement und Deinen Einsatz. OpenSource ist ein guter Ansatz um einem solchen Projekt ein langes Leben zu ermöglichen und viele mit einzubeziehen.

Viele Grüße
Michael
 
Lieber Rolf,

auch von mir ein herzliches Dankeschön für den neuen Schimmer am Horizont und die Weitsicht mit dem Open Source Projekt! Momentan benutze ich AVIstack (SS) und AstroArt (DS) zum Stacken. Leider wird AVIstack nicht mehr weiterentwickelt, es war mir von der Handhabung und den Ergebnissen am Monde am sympathischsten.

Grüße, Gerd
 
Hallo Freunde,

vielen Dank für Eure positiven Kommentare zum neuen Projekt! Ich möchte hier nur kurz auf ein paar Aspekte eingehen.

Peter, ich würde auch gerne bei Python bleiben. Ich liebe Python für die Unmenge von nützlichen Bibliotheken und die Einfachheit der Programmierung. Aber bei einem Stackingprogramm hat Performance nun mal (bei gleicher Bildqualität) höchste Priorität. Und bei den Millionen von Verschiebungsberechnungen und Qualitätsbeurteilungen ist das nicht einfach in Python. Natürlich verwende ich schon Multicore-Parallelisierung (via Numpy), aber vielleicht ist das am Ende nicht genug. Im Moment experimentiere ich mit Numba. Darauf brachte mich heute ein Mitarbeiter aus unserer Abteilung für High-Performance-Computing. Mal sehen, wie weit das trägt.

Michael und Gerd: Mein Entschluss, selbst ein Stacking-Programm zu schreiben, entstand aus Frust über die Closed-Source-Natur der existierenden Programme. Und ja: Wenn das Projekt ein wenig weiter gediehen ist, brauchen wir natürlich Feedback von Anwendern. Auch ich habe am Mond am liebsten AviStack2 verwendet, solange es (unter Windows 7) noch ging. Es war zwar sehr langsam, zeigte aber die besten Ergebnisse und war ganz klar für die Mondfotografie optimiert. Bei Planeten würde ich immer AS!3 favorisieren. Ich meine natürlich: solange PSS nicht fertig ist! :)

Schöne Grüße
Rolf
 
Hallo Rolf,

bei mir läuft AVIstack V2 unter Windows-10pro auf dem Laptop. Zum Thema langsam: Als ich große RGB Mondbilder stackte, war es auch irre langsam. Das lag daran, das ich beim Schritt 'Frame Stacking' das Häkle 'Update Display' gesetzt hatte (wegen der Show). Macht man das nicht, wird das Stacken großer (Farb-)Bilder erheblich schneller!

Grüße, Gerd
 
Hallo Rolf,
auch von mir höchste Anerkennung für dein Propjekt/deine Projekte (habe auf der BoHeTa schon begeistert zugehört).
Vom Programmieren habe ich keine Ahnung. Bei den vorbestehenden Softwares zu diesem Thema fehlt Georg Ditties "Giotto", das wohl das erste dieser Art war. Ich kenne Georg als sehr kommunikativen und aufgeschlossenen Programmierer - der hat bestimmt auch gute Tips beizutragen. Schau mal dort: Giotto-Software
 
Siril ist auch OpenSource und hat einen Modus für Planetary Stacking, der im Moment überarbeitet wird (mpp branch). Vielleicht lohnt es sich auch, da mal vorbeizuschauen.

Grüße und CS,
Steffen
 
Hallo Rolf,

ich bin von Python und vor allem von der Vielzahl der zur Verfügung stehenden offenen Bibliotheken begeistert. Daher freut es mich ganz besonders, dass mit Deinem Programm nun auch für den Bereich Stacking eine Open Source Lösung in Python zur Verfügung steht.

Zum Gui Toolkit: da bin ich nach einigen Tests mit IP Widgets, PySide und PyQT sowie WxPython doch wieder beim guten alten tkinter und ttk gelandet. Nicht die modernste Bibliothek, dafür aber in der Python Grundinstallation jeder Version enthalten und damit für die Wartung auf verschiedenen Systemen die einfachste Lösung.

Eine Software muß wegen der Abhängigkeit von verschiedenen Bibliotheken oft auch auf älteren Python Versionen sowohl unter Linux als auch Windows stabil laufen, und da ist mir im beruflichen Umfeld eine stabile Umgebung wichtiger als ein paar Features, die die Oberfäche hübscher und moderner aussehen lassen.

Vielen Dank für Deine Initiative und viel Erfolg!

CS
Arnold
 
Hallo Freunde,

vielen Dank für Eure interessanten und positiven Antworten. Ich möchte sie alle kurz beantworten.

@Gerd: Die Falle mit dem "Update Display" in AviStack2 war mir wohlbekannt. Ohne dies auszuschalten, hätte ich meine Bilder gar nicht bearbeiten können. Aber auch so bleibt AviStack2 sehr langsam. Das liegt an der relativ ineffizienten Implementierung auf Grundlage von IDL. Aber die Bildqualität war wirklich erstklassig!

@Martin: Natürlich kenne ich Georg Dittié und sein Programm Giotto. Georg und ich sind gute Freunde (wir wohnen nur ca. 15km auseinander) und haben uns auch schon zum PSS ausgetauscht. Zu seiner Zeit war Giotto tatsächlich eine tolle Sache. Mit der technischen Weiterentwicklung zum Multi-Point-Alignment war Giotto als Stackingprogramm für ausgedehnte Objekte wie den Mond allerdings obsolet. Da spielen AviStack2, AutoStakkert!3 und (mit gewissen Einschränkungen) Registax in einer völlig anderen Liga. Ich habe trotzdem Giotto noch lange Zeit zum Schärfen benutzt. Der "Mexican-Hat-Filter" ist einfach genial. Als ich dann immer sehr viele Aufnahmen auf einmal zu schärfen hatte (für meine großen Mondpanoramen), musste ich dann auch hier von Giotto auf AviStack2 umsteigen, weil Giotto für die Nachbearbeitung keinen Batch-Mode unterstützt. Wenn es soweit ist und ich in meinem Programm die Schärfungsalgorithmen angehe, habe ich schon angekündigt, Georg um Rat zu fragen. Beim Stacking selbst kann er mir allerdings kaum helfen.

@Arnold: Ich stimme Dir zu, dass Portabilität und Stabilität wichtige Kriterien sind. Allerdings dafür auf so altertümliche GUI-Toolkits wie tkinter und ttk zu setzen, geht mir denn doch zu weit. Ich habe meine bisherigen GUIs immer mit QT erstellt und in Verbindung mit Python auch immer einigermaßen hinbekommen (inzwischen Python 3.5 + QT5). Das einzige Problem, mit dem ich hier immer noch kämpfe, ist die mangelhafte Unterstützung bei der Anpassung an verschiedene Bildschirmauflösungen.

@Steffen: Dein Tipp, mir mal SIRIL anzuschauen, war tatsächlich der Haupttreffer! Ich habe mir den Code angeschaut und sofort gesehen, dass die Entwickler beim Multi-Point-Alignment an derselben Stelle hängengeblieben waren wie ich nach ein paar Wochen. Ich habe Cyril Richard und Vincent Hourdin dann gleich kontaktiert und bin inzwischen mit ihnen in einem regen Austausch. Vincent hat mir bestätigt, dass sie nach anfänglichen Versuchen nicht weitergekommen sind und die Sache erstmal aufgegeben haben. Als sie hörten, dass ich die algorithmischen Probleme gelöst habe, war ihre Freude groß. Wir waren uns schnell einig, dass wir zusammen den besten Stacking-Code entwickeln und die Geheimniskrämerei der Closed-Source-Software überwinden möchten. Vincent und Cyril sind beide Wissenschaftler wie ich und teilen daher meine Abscheu gegen das Bunkern von Herrschaftswissen. SIRIL ist in C programmiert und unterstützt schon Multi-Threading mit OpenMP. Es sollte damit möglich sein, gute Performance zu bekommen und zusammen mit meinen Algorithmen AutoStakkert!3 in jeder Beziehung zu übertreffen.

Möglicherweise werde ich daher mein eigenes Implementierungsvorhabent aufgeben und bei SIRIL mitarbeiten. Mal sehen, wie das ausgeht.

Schöne Grüße
Rolf
 
Hallo Freunde,

[...] Wir waren uns schnell einig, dass wir zusammen den besten Stacking-Code entwickeln und die Geheimniskrämerei der Closed-Source-Software überwinden möchten. Vincent und Cyril sind beide Wissenschaftler wie ich und teilen daher meine Abscheu gegen das Bunkern von Herrschaftswissen. SIRIL ist in C programmiert und unterstützt schon Multi-Threading mit OpenMP. Es sollte damit möglich sein, gute Performance zu bekommen und zusammen mit meinen Algorithmen AutoStakkert!3 in jeder Beziehung zu übertreffen.

Möglicherweise werde ich daher mein eigenes Implementierungsvorhabent aufgeben und bei SIRIL mitarbeiten. Mal sehen, wie das ausgeht.

Schöne Grüße
Rolf

Hallo Rolf,

Eure Einstellung teile ich uneingeschränkt! (y) Open Source ist auch ein Prinzip von Linux. Ich kenne SIRIL nicht, hoffe aber, dass es auch unter Linux lauffähig ist. Dann freue ich mich darauf, demnächst Eure anwenden zu können.

Ich wünsche Euch eine gute und erfolgreiche Zusammenarbeit.

Gruß,
Peter
 
Hallo Freunde,

vielen Dank für die aufmunternden Worte! Ich sehe überhaupt kein Problem darin, auch den "Planetary-Mode" auf allen Betriebssystemen ans Laufen zu bekommen. Schon mein PSS läuft problemlos auf Windows und Linux.

Etwas Sorgen macht mir noch eine möglichst elegante Einbindung in die GUI. Die jetzige SIRIL-GUI finde ich alles andere als übersichtlich, und sie ist deutlich auf Deep-Sky-Anwendungen ausgerichtet. Wenn wir die Mond-/Planetenfreunde ansprechen wollen, könnte das ein Hindernis werden. Aber das steht im Moment noch nicht im Vordergrund.

Schöne Grüße
Rolf
 
Erst einmal vielen Dank an Rolf für seine Arbeit und für die Beiträge der anderen.

Helft mir bitte mal auf die Sprünge bzgl. des Begriffs Stacking. Bei den genannten Programmen handelt es sich um Software, die aus einem Film ein Einzelfoto bastelt.

Das ist ja nicht das, was Deep Sky Stacker macht. Hier werden viele Einzelfotos eingelesen mit Darks etc. Unterscheidet es sich nur dadurch von den Film-Stackern, dass jedes berücksichtigte Foto als Einzeldatei vorliegt?
 
Hallo Rolf,

vielleicht könnt Ihr Euch ja dazu entschließen, auf Basis von SIRIL und Deinem Beitrag, eine gesonderte Software für Mond-/Planeten zu schreiben. Unabhängig von dem, was schon existiert. Ich persönlich halte nicht viel von "eierlegenden Wollmilchsäuen". Ich glaube auch, das Ganze ist separat einfacher zu händeln.

Gruß,
Peter
 
Helft mir bitte mal auf die Sprünge bzgl. des Begriffs Stacking. Bei den genannten Programmen handelt es sich um Software, die aus einem Film ein Einzelfoto bastelt.

Das ist ja nicht das, was Deep Sky Stacker macht. Hier werden viele Einzelfotos eingelesen mit Darks etc. Unterscheidet es sich nur dadurch von den Film-Stackern, dass jedes berücksichtigte Foto als Einzeldatei vorliegt?
Eben, ein Stacker macht aus vielen Ausgangsbildern ein Ergebnisbild.
Ob die ursprünglichen Bilder als Film oder als einzelne Dateien vorliegen ist dabei erstmal egal. Siril kann z.B. mit beidem umgehen.
 
Moin,

ich denke, man sollte erstmal die algorithmischen Aufgaben angehen, wie die Kollegen es wie ich den Posts entnehme, vorhaben, das User-Interface ist sicher eine Sache für sich, aber z.B. zwei Modes zu implementieren wäre ja auch eine Möglichkeit für die verschiedenen Aufgaben, vielleicht sogar einfacher als es in einer Variante allen Recht machen zu müssen. Wir werden sehen, ich finde den Ansatz aber hervorragend, sich zusammenzutun statt konkurrenzierend nebeneinander her zu werkeln. Das ist im kleinen so sinnfrei wie im (ganz) großen!

CS
Jörg
 
Hallo Freunde,

zunächst zum Begriff "stacken": Tatsächlich gibt es das sowohl bei Deep Sky als auch bei Mond/Pleneten. Der Unterschied ist aber, dass man bei Deep Sky normalerweise länger als ca. 1/100 sec. belichtet. Daher nimmt man immer eine Mittelung über das durch Luftturbulenz verschmierte Bild auf. Das Stacken erledigt dann nur noch die gegenseitige Ausrichtung der Bilder und ihre Aufsummierung. Zudem ist die Ausrichtung extrem einfach, weil die Sterne perfekte Ankerpunkte liefern. All das ist um Größenordnungen schwieriger bei turbulenten Mond-/Planetenvideos. Hier hat man es mit Ausgangsbildern zu tun, die nur in Teilbereichen scharf sind und im Hundertstelsekundentakt hin- und herwabern. Ankerpunkte sind auch praktisch nicht vorhanden.

Der erste Ansatz (z.B. Giotto) war, einfach nur die Verschiebung des ganzen Bildes gegeneinander (z.B. wegen Wind oder Nachführfehlern) auszugleichen, dann die schärfsten Bilder auszusuchen und diese aufzusummieren. Das ist algorithmisch sehr einfach. Anspruchsvoller wurde die Technik dann aber mit dem Multi-Point-Alignment. Hier summiert man nicht mehr ganze Bilder, sondern sucht sich aus jedem Frame nur die scharfen Stellen zum Stacking heraus. Zudem entzerrt man die Frames kleinräumig mit teilweise über 1000 Ankerpunkten, an denen man die lokalen Verzerrungen misst. Das ist heute "State of the Art" und in AviStack2 und AutoStakkert!3 realisiert. Die hierzu nötigen algorithmischen Kniffe haben die Autoren nie preisgegeben. Daher sind unsere französischen Freunde zunächst gescheitert, und auch ich habe mehrere Monate rätseln müssen.

Mit meinen Algorithmen wird diese Technik jetzt erstmals veröffentlicht, so dass das jeder nachprogrammieren kann.

@Jörg: Du hast völlig recht. Das User-Interface steht erst einmal nicht im Vordergrund. Auch die Idee, hinterher zwei GUIs zu machen, eine für Deep Sky und eine für die Sonnensystemleute, ist mir auch schon gekommen. Wenn ich mich mit Vincent und Cyril geeinigt habe, ihre Software zur Produktivversion weiterzuentwickeln, geht es erst einmal darum, die Algorithmen darin umzusetzen. Und dann kommt die Perfomance-Optimierung. Erst wenn das erledigt ist, denke ich an die Benutzerschnittstelle. Es wird also alles noch eine Weile dauern.

Schöne Grüße
Rolf
 
Hallo Rolf!

Hm, ist das wirklich so geheimnisvoll? Vielleicht helfen ja auch andere Ansätze:

http://www.iosrjournals.org/iosr-jce/papers/Vol16-issue4/Version-1/C016411117.pdf
Removing Atmospheric Turbulence

Sind nicht bei terrestrischen "Zielen" die Probleme ähnlich gelagert oder womöglich sogar noch kniffliger, weil das Beobachtungsobjekt ggf. auch in Bewegung ist?
Das ist gerade einmal nur ein Mittagspausenansatz von mir - aber vielleicht ja auch ganz spannend in der Umsetzung.

Besten Gruß,
Stefan Korth
 
Hallo Stefan,

ich denke, wenn ich Rolf richtig verstehe, ist die Algorithmik allein weniger das Problem als die Effizienz. Da die Entwicklung ja für "normale Rechner" gemacht werden muss kann man - es gibt im übrigen eine Reihe weiterer Arbeiten zu vergleichbaren Themen - nicht alles so ohne weiteres Umsetzen, man schaue sich die Thematik dynamischer 3D-Simulationen an, das ist eine vergleichbare Sache diese zu rendern. Nicht umsonst sind die Rechneranforderungen für dynamische Grafikdarstellung so anspruchsvoll. Wenn man von vorn herein die Verwendung einer leistungsfähigen Grafikkarte ansetzen könnte wäre das sicher auch einfacher.

CS
Jörg
 
Hallo Rolf,

auch von meiner Seite erstmal großes Lob und Hochachtung für deine Initiative!
Das ist eine tolle Sache!

Wenn hier schon über HMI etc. diskutiert wird, dann erlaube mir noch eine kleine Bitte noch bzgl. Benutzerfreundlichkeit:
Siril hätte m.E. einen deutlich größeren Anwenderkreis, wenn es fertig kompilierte Pakete gäbe.
Aber leider muss man die Software nach dem Runterladen erstmal selbst kompilieren und dann vergleichsweise aufwändig installieren. Dazu gibt es zwar eine Anleitung im Netz, aber das Abtippen von Kommandozeilenbefehlen ist halt nicht jedermanns Sache...
Daher die Bitte, auch an "normale" Anwender zu denken, für die eine .exe oder ein .app-File halt das Maß der Dinge sind...

Danke!

Viele Grüße
Stefan
 
Hallo Freunde,

heute habe ich zum ersten Mal überhaupt ein Planetenvideo mit PSS gestackt. Dafür ist die Software überhaupt noch nicht eingerichtet. Insbesondere habe ich das Feature "Planetary Alignment" noch gar nicht implementiert, musste also wie beim Mond ein Surface-Alignment machen. Auch ist die automatische Erzeugung von Ankerpunkten bei Planeten (und gerade beim Saturn) sehr fragwürdig. Da ich keine GUI habe, kann ich aber im Moment die Ankerpunkte noch nciht manuell setzen.

Also langer Vorrede kurzer Sinn: Es geht bestimmt noch besser! Das Video habe ich von Cyril Richard bekommen, einem der Autoren von SIRIL. Es wurde mit einem Celestron 11 aufgenommen und hat ca. 1800 Frames. Mehr weiß ich auch nicht darüber. Beim Thema Schärfung und Nachbearbeitung bei Planeten kenne ich mich auch nicht besonders aus. Aber ich habe es mal probiert. Hier ist das sehr vorläufige Ergebnis:
sat_c11_ser_F0001-1731.avi.stacked_pp.jpg

Immerhin ist das Programm nicht ausgestiegen. Es besteht also Hoffnung, dass PSS auch bei Planeten funktioniert.

Schöne Grüße
Rolf
 
Hallo Stefan,

Hallo Rolf!

Hm, ist das wirklich so geheimnisvoll? Vielleicht helfen ja auch andere Ansätze:

http://www.iosrjournals.org/iosr-jce/papers/Vol16-issue4/Version-1/C016411117.pdf
Removing Atmospheric Turbulence

Sind nicht bei terrestrischen "Zielen" die Probleme ähnlich gelagert oder womöglich sogar noch kniffliger, weil das Beobachtungsobjekt ggf. auch in Bewegung ist?
Das ist gerade einmal nur ein Mittagspausenansatz von mir - aber vielleicht ja auch ganz spannend in der Umsetzung.

Besten Gruß,
Stefan Korth

vielen Dank für den Hinweis auf diese Publikation. Die kannte ich tatsächlich noch nicht und werde sie mir in Ruhe anschauen. Ich habe allerdings eine ganze Reihe von Ansätzen verfolgt und haufenweise Publikationen gelesen. Teilweise habe ich die Algorithmen sogar nachprogrammiert. Dabei habe ich keinen Algorithmus gefunden, der gleichzeitig schnell und sehr gut arbeitet. Als Beispiel hier mal ein Ausschnitt (im Vergleich zu den Sinus Iridum-Aufnahmen oben, aus demselben Video berechnet), wo ich zum De-Warping die Technik des "Optical Flow" programmiert habe. Die scheint ähnlich zu der von Dir zitierten Arbeit zu arbeiten und kommt z.B. ganz ohne Ankerpunkte aus:

Moon_Tile-024_043939_stacked_optical_flow.jpg


Das ist nicht ganz schlecht, aber eben auch nicht gut. Eine Riesenenttäuschung!

Tatsächlich sind wir Amateurastronomen sehr anspruchsvoll: Die resultierenden Bilder sollen optimal scharf sein, aber das Ganze soll in Nullkommanix auf einem alten Laptop laufen. Da liegt die Messlatte schon ziemlich hoch.

Ohne es im Detail nachvollzogen zu haben fürchte ich, dass die Sache mit den B-Splines zur "Non rigid registration" zu viel Rechenzeit kosten würde. Aus demselben Grund hatte ich mich schließlich von der pixelweisen Interpolation ganz verabschiedet. Ich bin ziemlich fest überzeugt, dass sich so die Laufzeit von AutoStakkert!3 nicht erreichen lässt.

Schöne Grüße
Rolf
 
Hallo Stefan,
Hallo Rolf,

auch von meiner Seite erstmal großes Lob und Hochachtung für deine Initiative!
Das ist eine tolle Sache!

Wenn hier schon über HMI etc. diskutiert wird, dann erlaube mir noch eine kleine Bitte noch bzgl. Benutzerfreundlichkeit:
Siril hätte m.E. einen deutlich größeren Anwenderkreis, wenn es fertig kompilierte Pakete gäbe.
Aber leider muss man die Software nach dem Runterladen erstmal selbst kompilieren und dann vergleichsweise aufwändig installieren. Dazu gibt es zwar eine Anleitung im Netz, aber das Abtippen von Kommandozeilenbefehlen ist halt nicht jedermanns Sache...
Daher die Bitte, auch an "normale" Anwender zu denken, für die eine .exe oder ein .app-File halt das Maß der Dinge sind...

Danke!

Viele Grüße
Stefan
Vielen Dank für die netten Worte! Ich muss gestehen, dass ich SIRIL selbst noch nie benutzt habe. Aber ich stimme mit Dir überein, dass für Endanwender die Software auf jedem Fall mit einem automatischen Installer ausgeliefert werden muss. Die Installation darf nicht komplizierter sein, als wenn man auf seinem Windows-Rechner den Firefox installiert. Bei meinen bisherigen Open-Source-Projekten habe ich das immer so gehalten. Bei SIRIL bin ich natürlich auf die Kooperation der bisherigen Autoren angewiesen. Aber das wird schon klappen!

Schöne Grüße
Rolf
 
Hallo Freunde,

für den Fall, dass Ihr mal im Detail nachvollziehen möchtet, wie mein Stackingprogramm arbeitet: Im Open-Source-Repository habe ich eine Dokumentation des algorithmischen Ablaufs geschrieben. Das hat mich einen ganzen Tag gekostet. Aber ich glaube, dass dies nötig ist, wenn ich mit anderen am Code zusammenarbeite. Im Programmcode ist es oft schwer, den roten Faden zu finden. Die Beschreibung ist unabhängig von einer Programmiersprache. Grundsätzlich sollte man den Ablauf danach nachprogrammieren können.

Viel Spaß beim Lesen!

Schöne Grüße
Rolf
 
Hallo Rolf,

Interessante Dokumentation, da steckt einiges an Arbeit dahinter...
Beim Durchlesen ist bei mir eine Frage aufgekommen: Wie hältst Du den Speicherverbrauch im Zaum?
Wenn ich das richtig verstehe, dann werden ja nicht nur die Ausgangsbilder geladen, sondern auch noch verschieden bearbeitete Varianten davon (mono, mono_blurred, mono_blurred_laplacian)...

Gibt es denn schon Fortschritte in der Zusammenarbeit mit den Siril-Machern?

Grüße,
Steffen
 
Hallo Steffen,

den Speicherverbrauch habe ich tatsächlich noch nicht optimiert. Grundsätzlich kann man "out-of-core" arbeiten. Dann muss man allerdings die Frames mehrfach einlesen, was einige Sekunden mehr kosten würde. Bei den Varianten ist zu beachten, dass sie alle S/W sind, also nur ein Drittel des Speicherplatzes brauchen. Und diese bräuchte man auch nicht alle im Speicher zu halten. Z.B. halte ich mono_blurred_laplacian nur im Speicher, um dieselbe Berechnung nicht zweimal zu machen. Und "mono" könnte man sofort wegwerfen, wenn mono_blurred berechnet ist.

Allerdings ist RAM heute so billig geworden, dass die Optimierung mir auch nicht allzu wichtig ist. Mein PC hat z.B. 64GB RAM, und mehr als 11GB hat mein Programm noch nie belegt.

Mit den SIRIL-Entwicklern habe ich bisher vorwiegend algorithmische Details diskutiert. Sie sollten damit in der Lage sein, mein Verfahren in ihrem Programm zu implementieren. Ich selbst habe seit letztem Wochenende nichts mehr programmiert. Dieses Wochenende habe ich komplett damit verbracht, meine Vollmondaufnahmen von vorigem Sonntag zu einem 60 Megapixel großen LRGB-Komposit zu verarbeiten (mit meinem Programm PlanetarySystemLRGBAligner). Hat gut geklappt!

Schöne Grüße
Rolf
 
Status
Es sind keine weiteren Antworten möglich.
Oben