PSS Parameter zum Stacking von Marsaufnahmen und Vergleich mit AS!3

Status
Es sind keine weiteren Antworten möglich.

Chris77

Mitglied
Danke an Rolf Hempel und das gesamten Entwickler-Team für die Initiative eine Open-Source Software für das Stacking und die Nachbearbeitung von Lucky Image Aufnahmen ins Leben zu rufen. Die in seinem Online Vortrag genannten Gründe und die Problemen mit den aktuellen "closed source" Tools kann ich absolut nachvollziehen. Seine Aussage die Ergebnisse von PSS sind vergleichbar oder besser als AS!3 haben mich motiviert es selber einmal auszuprobieren.

Zunächst habe ich Marsaufnahmen vom 11.12.2020 mit den Standardparametern von DSS (0.8.22) bearbeitet: mit einem ernüchternd schlechten Ergebnis.
Dann hat mich der Ehrgeiz gepackt und ich habe das Stacking mit AS!3 und PSS mit diversen Parametern durchlaufen lassen, mit Registax nachbearbeitet und verglichen.

Mit dem Ergebnis:
Durch Anpassung von Parametern konnte ich ein mit AS!3 vergleichbares Ergebnis erzielen. Hier: Noise=11, align box width=40, align search width=24, align min bright = 50.
PSS scheint aktuell eher für das Stacking von hochauflösenden Oberflächenaufnahmen (Mond/Sonne) optimiert zu sein und ich sehe etwas Verbesserungsbedarf für das Stacking von Planetenaufnahmen

Im angehängten Dokument sind Bearbeitungsworkflow, Parameter-Tests und die Ergebnisse dokumentiert. Ich habe es in Englisch geschrieben, damit es ggf. auch nicht deutschsprachige User oder Entwickler lesen können.

Bei welchen Planetenaufnahmen und Parametern konntet ihr die besten Ergebnisse erzielen?
 

Anhänge

  • PSS_test_2021-01-05.pdf
    1,6 MB · Aufrufe: 695
  • 2020-11-12-2154_3-CR-RGB-Mars_pss_f1000.png
    2020-11-12-2154_3-CR-RGB-Mars_pss_f1000.png
    308,4 KB · Aufrufe: 216
  • 2020-11-12-2151_8-CR-RGB-Mars_f1000_AS!3.png
    2020-11-12-2151_8-CR-RGB-Mars_f1000_AS!3.png
    310,3 KB · Aufrufe: 237
Hallo Christian,
zunächst einmal vielen Dank für den ausführlichen Erfahrungsbericht. Diese Art von Erfahrungsaustausch zwischen Anwendern der Software gibt es viel zu wenig. Wie Dein Beispiel zeigt, ist Stacking ein viel zu komplizierter Prozess, als dass es eine „Rundum-Sorglos-Parametrisierung“ geben könnte. Die vom Programmautor eingestellten Default-Werte sind nur für einen bestimmten Fall optimal. Andere Einsatzsituationen können davon stark abweichen und völlig andere Einstellungen erfordern. Das macht den Vergleich der Leistungsfähigkeit verschiedener Programme schwierig, und man muss sich schon Mühe geben, damit das Ergebnis fair ausfällt. Diese Mühe hast Du Dir gemacht, und das finde ich toll.

Ich könnte den Bericht jetzt einfach so stehenlassen und die erhoffte Diskussion mit anderen Usern abwarten. Aber ein paar Anmerkungen von meiner Seite sind vielleicht als Hintergrundinformationen ganz nützlich. Das werde ich im Folgenden versuchen:
  1. Tatsächlich liegt der Anwendungsfall ziemlich weit vom „Designziel“ meiner Standardparametrisierung entfernt. Das Video wurde mit recht starkem Oversampling (über vier Pixel pro Auflösung) aufgenommen. Das erklärt z.B., warum die voreingestellte „alignment search width“ zu klein ist. Wenn ich den Standardwert aber von 14 auf 24 erhöht hätte, könnte es bei Videos mit „normalem“ Sampling (2:1) zu Fällen kommen, wo sehr hohe Warp-Shifts fälschlicherweise für richtig gehalten werden und das Ergebnis verschlechtern. Daher ist es in der Tat nötig, mit diesem Parameter zu experimentieren, um beste Ergebnisse zu bekommen.
  2. Drizzle ist ein schwieriges Thema. Tatsächlich habe ich es erst kürzlich hinzugefügt und halte die Implementierung noch nicht für endgültig. Der Rechenaufwand steigt enorm, besonders bei 1.5x (der aufwendigsten Einstellung). 2x würde vielleicht etwas schneller laufen. Noch wichtiger aber: Bei meiner Implementierung wird das Summenbild oft weicher, aber auch rauschärmer als bei AS!3. Bei der späteren Schärfung erfordert das Bild dann eine etwas stärkere Filtereinstellung, verträgt diese aber auch wegen des geringeren Rauschens. Die Anwendung derselben Postprocessing-Einstellung für die verschiedenen Stacking-Programme ist daher nur scheinbar objektiv. Richtiger wäre es, die Schärfung jeweils so einzustellen, dass die Schärfungsartefakte („Körnigkeit“) ein gleiches Niveau haben. Wenn man das macht, ergeben sich oft fast identische Bilder für AS!3 und PSS.
  3. Du hast an verschiedenen Stellen die Problematik angesprochen, dass die Viewer in PSS das Bild auf die Fenstergröße vergrößern, auch wenn die geringen Pixelzahlen das eigentlich gar nicht hergeben. Tatsächlich war das bei meinen Mondbildern nie ein Problem, aber einige Planetenfotografen haben das schon bemerkt. Daher habe ich jetzt in allen Viewern die Möglichkeit eingebaut, durch Drücken der Taste „1“ (wie bei Gimp) den View auf 100% Zoom einzustellen. Im Postprocessing-Dialog wird zudem die aktuelle Zoom-Rate unter dem Bild angezeigt.
  4. Du fragtest, ob die merkwürdig in die Länge gezogenen AP-Patches für randnahe APs ein Bug oder „Feature“ wären. Tatsächlich sind sie kein Bug, sondern sollen helfen zu vermeiden, dass bei randnahen APs der Fall eintritt, dass ein ansonsten unnötiges Hintergrundbild berechnet wird. Das ist zugegeben eher bei Mond / Sonne relevant. Aber ich habe noch nicht gesehen, dass dadurch Artefakte außerhalb des Aufnahmeobjekts entstanden sind.
  5. Die Auswahl der Stack-Size ist tatsächlich bisher ausschließlich auf die Prozentzahl ausgelegt. Im interaktiven Dialog kann man zwar auch die Zahl manipulieren, aber was zählt ist der daraus berechnete Prozentwert. Im Kommandozeilenmodus habe ich erst nach Deinem Bericht bemerkt, dass man zwar die Frame-Zahl angeben kann, dass dieser Parameter aber noch ignoriert wird. Hier ist also noch eine Baustelle, die mir irgendwie durch die Lappen gegangen ist. (Habe ich in die Development-Roadmap aufgenommen). Der Plan ist, beide Zahlen alternativ wählen zu können, sowohl in der GUI als auch über die Kommandozeile.
  6. Die Diskussion, ob PSS den Zeitpunkt ausrechnen könnte, dem das Summenbild am Ende entspricht (für sowas wie WINJUPOS-Anwendungen), hatten wir auf Cloudy Nights schon vor einer Weile. Tatsächlich ist hierfür ja der zeitliche „Schwerpunkt“ der Frames maßgeblich, die für das Referenz-Bild verwendet wurden. Hierzu bräuchte ich die Zeiten all dieser Frames. Das könnte man für AVIs und SERs vielleicht noch herausbekommen. Aber es gibt ja auch die Option, Verzeichnisse mit Einzelbildern zu stacken. Die haben dann alle möglichen Fileformate. Das Ganze würde daher zumindest eine große Fleißarbeit, und es könnte viele Fehler geben. Wenn irgendjemand sich dieser Aufgabe annehmen möchte, könnte vielleicht etwas daraus werden. Ich habe es jedenfalls nicht auf meiner Agenda. Immerhin habe ich (bei Protokoll-Level 2) die Ausgabe aufgenommen, wo über die Gesamtlänge das Referenzframe verortet ist: "Position of reference frame in video time line: 6.7%", d.h. wenn alle Zeitabstände zwischen den Frames gleich sind (wie bei Videos), liegt der Zeitpunkt bei 6.7% der Videolaufzeit. Damit kann man sich zumindest von Hand den Zeitpunkt ausrechnen.
  7. In Deinen detaillierten Kommentaren zum Workflow äußerst Du Wünsche zur Benennung von Ergebnis- und Protokolldateien. Hier kann man sich eine Menge vorstellen, aber gerade für so etwas habe ich die Kommandozeilenoption hinzugefügt (die übrigens keines der anderen Stackingprogramme anbietet). Man kann damit PSS in Shell-Skripten oder aus anderen Programmen heraus aufrufen und Namensänderungen durch diese Skripte erledigen lassen. Alternativ gibt es bei einem Open-Source-Projekt ja auch immer die Möglichkeit, die Software selbst weiterzuentwickeln (was hätte ich darum gegeben, wenn AS!3 das ermöglicht hätte!). Gelungene Erweiterungen kann man mir dann auch gerne als „Pull Request“ ans Github-Repository schicken. Dann könnten sie Teil der offiziellen Version werden.
Nochmal vielen Dank für Deinen interessanten Bericht. Ich bin gespannt auf Fortsetzungen durch andere Nutzer.

Schöne Grüße
Rolf
 
Hallo Rolf,
ich habe mit Interesse Christians umfangreiche Ausarbeitung und deine detaillierte Antwort gelesen.
Zu deinem Punkt 3: Taste „1“ für 100% Zoom finde ich sehr gut - hatte mir bisher auch gefehlt.
Christian hat Alignment Points von ausserhalb des Planeten nach innen geschoben. Ist das sinnvoll bzw. nötig? Warum werden überhaupt die Punkte ausserhalb gelegt?

LG
Reinhard
 
Hallo Reinhard,

bei Planeten ist die Setzung der APs schon so eine Sache. Experten wie Emil Kraaikamp raten eigentlich dazu, sie von Hand zu setzen. Anders als bei großflächigen Objekten ist das ja keine Heidenarbeit, führt aber oft zu etwas besseren Ergebnissen.

Entscheidend sind eigentlich nicht die Alignment-"Punkte", sondern die ganzen "Patches" darum herum. Die werden nämlich zum De-Warping herangezogen. Wenn der Mittelpunkt dann selbst außerhalb liegt, ist das nicht unbedingt gefährlich. PSS verschiebt schon von sich aus einen Patch zum Planeten hin, wenn ein zu großer Teil des Patches außerhalb liegt. Wie groß der Qualitätsunterschied ist, den Christian mit der Verschiebung der Punkte bewirkt hat, kann ich nicht sagen.

Generell habe ich noch vor, mir das Thema "Alignment-Punkte automatisch setzen" nochmal vorzunehmen. Die bisherige Lösung hat sich bei meinen Mondvideos bestens bewährt. Ich selbst habe wenig Erfahrung mit der Planetenfotografie und auch nur relativ wenige Beispielvideos. Ich könnte mir vorstellen, dass es da noch eine bessere Strategie gibt. Möglicherweise verwende ich dann auch unterschiedliche Algorithmen, je nachdem, ob der User bei der Bildstabilisierung "Planet" oder "Surface" gewählt hat. Aber das ist ein Thema jenseits des nächsten Releases 0.9.0.

Schöne Grüße
Rolf
 
Seit Version 0.8.27 gibt es in PSS eine Quick-Start Guide.
Aufgrund der oben beschriebenen Mars-Stacking Erfahrung könnte man hier noch Ergänzen:
For noisier planetary images, try "Noise levels" up to the maximum.
Consider increasing the "Max alignment search width" for oversampled (planetary) images.
Higher "Alignment box width" values help to avoid stacking artifacts but my lead to loss of detail in return.

Leider habe ich keine "guten" Jupiter / Saturnaufnahmen mehr um PSS zu testen, da ich diese früher aus Platzgründen immer nach dem Stacking gelöscht habe.

Hat noch jemand Erfahrung mit dem Planeten Stacking (Mars, Jupiter, Saturn) gemacht und passenden Parameter gefunden?
Falls ihr es noch nicht probiert habt: man kann den Test einfach mit einer Batchdateien automatisieren und muss nachher nur noch die Ergebnisse vergleichen.
Anbei ein Beispiel (muss noch von .txt in .bat umbenannt werden)

Viele Grüße,
Christian
 

Anhänge

  • n11.txt
    1,5 KB · Aufrufe: 135
Hallo Christian,

vielen Dank für Deine Anregungen zum "Quickstart Guide". Ich habe den Guide folgendermaßen geändert:

screenshot.PNG


Viel ausführlicher darf das nicht werden, sonst liest auch diesen Text niemand mehr.

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