Laufzeit bei Planetenvideo | Astronomie.de - Der Treffpunkt für Astronomie

Laufzeit bei Planetenvideo

reibra

Mitglied
Hallo Rolf,
ich finde euer Projekt super und verfolge mit Interesse die Weiterentwicklung. Z.B. das RGB-Align stand auch auf meiner Wunschliste – scheint jetzt ja schon perfekt erledigt zu sein. Klasse!

Ich habe mit PSS 0.8.15 alte Mondaufnahmen geschärft und mit Registax-Versionen verglichen. Da finde ich dass PSS ist deutlich besser abschneidet als Registax.

Bei Planetenaufnahmen sehe ich das noch nicht so deutlich. Da muss ich wohl noch weiter experimentieren.

Beim Versuch Marsvideos zu stacken habe ich allerdings extreme Laufzeiten festgestellt.
Mein Rechner hat einen AMD Athlon(tm) II X4 640 Processor 3.00 GHz und 32 GB RAM und läuft unter Windows 10 64 -bit.

Das Video ist ein AVI mit 6,24 GB und ca 40.000 Frames .
PSS sagt: recommended level: 2, es wird aber maximal 16 GB Speicher belegt.
Das Ranking dauert 20 min, Aligning 7 min, Reference Frame 3 min und Stacking 34 min.

Zum Vergleich habe ich das Video in AS3 gestackt, da braucht der gesamte Ablauf ca 5 min.

Beim Programmstart bekomme ich die bekannte Meldung mit der mkl_rt.dll – kann das doch Schuld sein an der langen Laufzeit?


MfG
Reinhard
 

Rolf_Hempel

Mitglied
Hallo Reinhard,

zunächst einmal freut es mich, dass das Postprocessing mindestens so gut wie in Registax funktioniert, bei den Mondaufnahmen sogar deutlich besser. Das Auto-RGB-Alignment habe ich inzwischen auch bei großen DSLR-Bildern erfolgreich erprobt. Es fehlt nur noch die Implementierung von manuellen Korrekturen (die aber vermutlich nur selten gebraucht werden).

Die extremen Laufzeiten kann ich mir aber wirklich nicht erklären. Der von PSS ermittelte Buffer-Level klingt plausibel, wenn dadurch schon 16 GB belegt werden. Dann wäre Level 3 weit jenseits der verfügbaren 32 GB. Aber eine 12mal längere Ausführungszeit als AS!3 erklärt das nicht. Ich habe gerade mal ein Venus-Beispiel nachgeschaut vom September. Da hatte ich 27500 Frames gestackt, allerdings mit Buffer level 4. Das hat 41 GBytes RAM belegt. Die Gesamtzeit betrug 241 Sekunden. Bei Level 2 ist natürlich viel mehr I/O zu erledigen, aber diesen Riesenfaktor kann das nicht erklären.

Hast Du vielleicht den Protokoll-File des Laufs (hoffentlich im "Detail Level" 2)? Vielleicht ergibt sich daraus ja ein Anhaltspunkt, was schiefgelaufen ist.

Schöne Grüße
Rolf
 

reibra

Mitglied
Hallo Rolf,
danke für deine schnelle Antwort.
Ich habe das Video nochmal bearbeiten lassen und hänge jetzt das Protokoll an. Für mich sieht das sehr unspektakulär aus, vielleicht kannst du ja was draus erkennen.

LG
Reinhard
 

Anhänge

  • 2020-11-29-1746_6-RB-L-Mars_stacking-log_f8362_p20_b48_ap8.txt
    6,5 KB · Aufrufe: 44

Rolf_Hempel

Mitglied
Hallo Reinhard,

das ist mir wirklich rätselhaft. Der Protokoll-File sieht tatsächlich unspektakulär aus. Die Frames sind ja eher klein (wahrscheinlich hattest Du ein ROI bei der Aufnahme gesetzt). Die waren bei meinem Venus-Video sogar größer, allerdings war das Monochrome. Trotzdem: Mein Venus-Beispiel lief hier in vier Minuten durch, also weit entfernt von den bei Dir gemessenen Zeiten.

Ein paar Beobachtungen, die zwar nicht die Laufzeit erklären, aber die ich doch loswerden wollte:
  • Du hattest die Option (Fast changing object) angewählt. Das ist eigentlich nur bei Jupiter und Sonne sinnvoll. Beim Mars wird dadurch das Referenzbild etwas schlechter als es sein müsste.
  • Im Postprocessing sollte man auf dem ersten Layer mit dem kleinsten Schärfungsradius beginnen, und dann bei den nächsten Layern die Radien schrittweise vergrößern. Du machst es umgekehrt. Registax gibt das automatisch vor, aber auch in PSS sollte man so vorgehen.
Ansonsten ist mir aufgefallen, dass Du Drizzle eingeschaltet hast. Das sollte die Laufzeit eigentlich nicht so wesentlich vergrößern, und dann auch nur im Schritt "Stacking".

Hast Du denn auch bei Deinen Mondvideos so enorm lange Laufzeiten? Eigentlich ist meine einzige Erklärung, dass der I/O extrem langsam ist. Die Videodatei ist nicht etwa auf einem Memory-Stick mit USB 1? :)

Ansonsten kann ich mir das wirklich nicht erklären.

Schöne Grüße
Rolf
 

reibra

Mitglied
Hallo Rolf,
deine Frage, ob meine Mond-Videos auch so langsam laufen, kann ich leider nicht beantworten, da ich die aus Speicherplatzgründen gelöscht habe. Das Mars-Video ist natürlich auf einer internen Festplatte - allerdings nicht auf SSD.
Drizzle hatte ich eingeschaltet da der Mars mit 15" schon ziemlich klein war.
Meine C-Platte ist eine SSD mit 92 GB belegt und nur 19 GB frei - das ist bestimmt auch verbesserungswürdig.
Ich werde in den Weihnachtstagen mit meinen Söhnen mal sehen, ob wir dem Problem auf die Spur kommen. Über Ergebnisse werde ich jedenfalls hier informieren.

Danke für deine Tipps bezüglich "Fast changing object" und Postprozessing.

Beste Grüße
Reinhard
 

reibra

Mitglied
Hallo Rolf,
ich habe inzwischen Laufzeiten von PSS auf meinem Laptop mit meinem Desktop verglichen.
Der Laptop hat einen I5-Prozessor 16 GB RAM und 1 TB SSD, der Desktop hat einen AMD Athlon X4, 32 GB RAM und normale Platte. Daher ist es naheliegend dass der Laptop schneller ist.
Bei verschiedenen Videos war der Laptop bis zu 4x schneller.
Allerdings war im Vergleich zum Laptop AutoStakkert3 noch ca. 20x schneller.
Aufgefallen ist mir, dass PSS eine Prozessorauslastung von 30-40% hat, AS3 dagegen 90-99%. Dagegen belegt AS3 weniger RAM als PSS.

Was mein Sohn rausgefunden hat, hat mich erstaunt: sowohl beim Align als auch beim Stacking werden alle Frames nochmal bearbeitet, nicht nur die zu stackende Anzahl. Ist der Grund dafür, dass in allen Frames die besten Alignmentpoints gesucht werden, die ja aus unterschiedlichen Frames kommen können?

LG
Reinhard
 

Rolf_Hempel

Mitglied
Hallo Reinhard,

die große Laufzeit verstehe ich immer noch nicht so ganz. Ein paar Anmerkungen aber habe ich schon:
  • Zu Deinem Erstaunen, dass die Frames "nochmal bearbeitet werden": Tatsächlich werden die Frames mehr als zweimal bearbeitet. So einfach ist der Stacking-Prozess nämlich nicht. Deswegen ist es für die Performance auch so wichtig, möglichst viel im Buffer halten zu können. Bei Buffer-Level 2 können die Original-Frames und die davon abgeleiteten Grayscale-Varianten nicht gehalten und müssen mehrfach eingelesen werden. Das kostet natürlich Zeit. Nur bei Level 4 muss jedes Frame nur genau einmal eingelesen und seine Varianten berechnet werden. Es würde hier zu weit führen, den Algorithmus im Detail zu erklären. Aber Du kannst das in diesem Dokument nachlesen.
  • Es stimmt, dass PSS mehr RAM verbraucht als AS!3. Ich kann natürlich nicht in AS!3 hineinschauen, bin mir aber ziemlich sicher, dass Emil Kraaikamp sehr weitgehende Optimierungen bezüglich RAM und Rechenzeit vorgenommen hat. Das ist von der Programmierung her schon eine beeindruckende Leistung. Ich glaube aber, dass sich dies andererseits in Artefakten zeigt, die viele User (so wie ich auch) bei AS!3 oft in glatten Flächen sehen (z.B. Schachbrettmuster in Mond-Mareflächen). Bei PSS habe ich im Zweifelsfall immer die Vermeidung von Artefakten höher bewertet.
  • Drizzling ist in PSS (noch) nicht wirklich befriedigend gelöst. Eine erste Implementierung, bei der ich rechenzeit- und speichersparend vorgegangen war, produzierte sehr hässliche Artefakte. Ich habe dann eine Variante gewählt, die sehr glatte Flächen produziert, aber sehr aufwendig arbeitet. Dabei ist 1,5x Drizzle die aufwendigste Variante von allen. Vielleicht finde ich oder einer meiner Ko-Autoren noch eine bessere Implementierungsvariante.
  • Die niedrige Prozessorauslastung ist tatsächlich ein Problem von Python. Grundsätzlich müsste es aber besser gehen, weil über 99% der Rechenlast bei PSS in hochoptimierten C++-Bibliotheken liegt. Wie man in diesen Bibliotheken die Mehrkernauslastung verbessert, ist ein Action Item meines Ko-Autors George Hilios.
Also zusammengefasst: So ganz kann ich die sehr lange Laufzeit nicht verstehen. Zumindest ein Teil lässt sich durch Drizzling und den niedrigen Buffer-Level erklären. Bei meinen eigenen Anwendungen beobachte ich typischerweise etwa 50% längere Laufzeiten als bei AS!3.

Schöne Grüße
Rolf
 

reibra

Mitglied
Hallo Rolf,
danke sehr für deine ausführliche Antwort. Ich werde versuchen dein Dokument "Summary of Algorithms used by PlanetarySystemStacker" zu verstehen - mal sehen wie weit ich komme.
Die Schachbrettmuster, die AS3 in Mareflächen erzeugt kenne ich auch. Bin gespannt wie PSS sich macht wenn ich wieder Mond-Videos habe.
Ich freue mich auf künftige Versionen von PSS. Würde auch gern mitarbeiten, bin aber ueber "C" nicht hinausgekommen.

LG
Reinhard
 

Rolf_Hempel

Mitglied
Hallo Reinhard,

wenn Du C programmieren kannst, sollte Python für Dich doch ein Klacks sein. Es gibt keine Pointer, und die Syntax ist sehr einfach. Ich habe früher auch Fortran und C programmiert und bin erst später zu Java und Python gekommen. Est ist nie zu spät! :)

Schöne Grüße
Rolf
 

wachtel

Mitglied
Hallo Rolf,

zunächt einmal ein grosses Dankeschön für die viele Arbeit und Mühe die ein solches Projekt mit sich bringt .:)

nach vielen Jahren Astronomiepause bin ich jetzt mit Sonne, Mond und Planeten wieder eingestiegen. Dazu gab es dann auch eine neue S/W Kamera von TIS.
Früher habe ich das Programm Giotto von Georg verwendet...und dann zu Beginn des Jahres Autostakkert3, bis ich auf PSS gestossen bin, welches dann auch gleich ausprobiert wurde.

Entstanden sind bisher nur Mondaufnahmen mit 500mm und 1250mm Brennweite. Jeweils .ser files mit 1000 Bildern und 12gByte Grösse.

Da ich weder mit Autostakkert3 noch mit PSS grosse Erfahrung habe wurden beide Programme parallel benutzt. Meiner Meinung nach ist PSS etwas besser im Endergebnis...aber da muss man schon genau hinschauen. Allerdings habe ich auch festgestellt dass PSS doppelt so lange für die Berechnung braucht wie Autostakkert3. Bei mir 4min gegen 2min.

Der Rechner ist ein Labtop mit I7 Proz. und 16Gbyte Ram. Gearbeitet wird immer von einer 1Tbyte SSD aus. Möglicherweise liegt es am grossen .ser file der ja im Bereich des RAM liegt. Trotzdem wäre es schön wenn zukünftig die Speicherverwaltung etwas optimiert werden könnte. Wenn ich in die log-files schaue wird da lange nicht alles genutzt was möglich wäre.

Ansonsten arbeitet das Programm bisher sehr zuverlässing und besonders der batch-Betrieb ist sehr wertvoll und macht die längere Bearbeitungszeit wieder wett da man dann in der Zeit ja was anderes machen kann.

Durch das Preprocessing steige ich momentan nicht wirklich durch...zumindest habe ich es bis jetzt noch nicht geschafft bei meinen Mondaufnahmen eine Verbesserung gegenüber einer nachträglichen GIMP Bearbeitung (der Originaldaten) zu erhalten. Da fehlt mir aber sicherlich auch noch die entsprechende Erfahrung welche in den nächsten Monaten zunehmen sollte.

Da man aus den vielen Tbytes Filmdaten später ja nur noch die daraus extrahierten Bilder behält ist es halt schon wichtig, dass man den Eindruck hat, das best mögliche Ergebnis mit der Bearbeitung erhalten zu haben.

Schönen Gruss

Konrad
 

Rolf_Hempel

Mitglied
Hallo Konrad,

vielen Dank für Deinen Erfahrungsbericht! Es freut mich, dass PSS bei Dir gute Ergebnisse produziert und Du insbesondere den Batch-Betrieb nützlich findest. Ich stimme Dir zu, dass beim Batch-Betrieb die Rechenzeit nicht mehr so wichtig ist, weil man die Berechnungen z.B. über Nacht laufen lassen kann. Ob der Rechner dann um 02:00 Uhr oder um 04:00 Uhr fertig ist , ist für mich dann eigentlich egal. Die doppelte Rechenzeit verglichen mit AS!3 kann durchaus plausibel sein, je nach Prozessor und Plattenzugriffsgeschwindigkeit. Herfür sind hauptsächlich die schlechte Mehrkernauslastung bei PSS und die etwas aufwendigeren Algorithmen verantwortlich.

Meinst Du wirklich, dass Du durch das "Preprocessing" nicht wirklich durchsteigst, oder ist es vielmehr das "Postprocessing"? Eigentlich bin ich besonders stolz auf das Postprocessing. Es ist mit Abstand der komplizierteste Teil der Software, weil bei Parameteränderungen sehr intelligent immer nur der Teil aktualisiert wird, der sich wirklich geändert hat. Damit folgt die Ansicht im Bildbetrachter sehr schnell den Parametereinstellungen. Und das bei interner 32-Bit-Genauigkeit. In der Anwendung muss man die Wirkung der "bilateralen Filter" verstehen, um optimale Ergebnisse zu produzieren. Das habe ich z.B. bei einem Tutorial auf der Würzburger Sternfreundetagung vorige Woche gezeigt. Damit lassen sich die hässlichen Zwiebelringe an scharfen Kanten vermeiden, ohne das Bild insgesamt unscharf zu machen. Ideal wäre es natürlich, wenn jemand ein Youtube-Video zur Nutzung des Postprocessings machte. Vielleicht findet sich ja ein Freiwilliger hierzu?

Schöne Grüße
Rolf
 

wachtel

Mitglied
Hallo Rolf,

ich meinte natürlich Postprocessing, sorry. Bisher hatte ich noch keine Zwiebelringe so dass ich das Postprocessing immer nur zur Schärfung eingesetzt habe. Ich bin mir aber nicht sicher ob das wirklich Sinn macht da ich die Bilder später immer noch mit GIMP endbearbeite. Da hat man unendlich viele Möglichkeiten der Filterung und Glättung. Wenn ich jetzt mit dem Postprocessing von PSS da schon eingegriffen habe wirds wirklich kompliziert. Sinn machen würde es nur wenn man ein PSS Postprocessing finden könnte welches immer zum optimalen Ergebnis kommt. Das wird aber ohne KI sicherlich nicht gehen und die müsste dann erstmal lernen was jeder user unter optimalem Ergebnis versteht. Der eine mags nämlich mit hart rausgearbeiteter Schärfe (oft mit Überschwingern) und der andere geht eher nicht an diese Grenze sondern bleibt leicht drunter. Und das Ganze hängt dann noch sehr stark vom S/N ab und vom seeing.
Letztendlich wird es dann doch auf eine Endbearbeitung jedes einzelnen Bildes hinauslaufen und da finde ich das automatische Postprocessing noch nicht sehr hilfreich.
So wie ich das momentan sehe sind die Bilder im Original-Stacking schon so gut dass man sie im Nachhinein mit GIMP immer so bearbeiten kann dass das Postprocessing Ergebnis erreicht oder übertroffen wird.
Trotzdem muss ich gestehen dass ich damit erst wenig Erfahrung habe. Möglicherweise gibt es ja doch einen genialen Parametersatz welcher die Endbearbeitung deutlich erleichtert.
Momentan ist es noch genug Arbeit die richtigen Parameter für das Stacking zu finden. Am Anfang habe ich geglaubt dass das Bild umso schärfer wird je weniger % man stackt. Also wurden nur 5% frames benutzt. Mittlerweile haben verschiedene Versuche gezeigt dass man durchaus bis 20% gehen kann ohne sichtbare Einbussen an Schärfe. Da hat man dann natürlich ein deutlich besseres S/N für die Endbearbeitung. Die Folge dieser Erkenntnis war dann etwa 1Tbyte Daten nochmal berechnen zu lassen.
Wie schon gesagt...irgendwann werde ich die Originaldaten dann mal löschen müssen denn die ext. Festplatte fasst nur 6TByte.
Ich bleibe dran und werde weiter berichten.

Schönen Gruss

Konrad
 

Rolf_Hempel

Mitglied
Hallo Konrad,

beim Postprocessing habe ich bisher immer mit Gewinn die speziellen Filter der Stackingprogramme genutzt, also AviStack2 (Wavelets) und Giotto (Mexican Hat). Mit Adobe Photoshop alleine habe ich dieselbe Qualität nicht erreicht, kann aber nicht ausschließen, dass auch hier eine genial kombinierte Filterkaskade zu ähnlichen Ergebnissen führen würde. In PSS habe ich zusätzlich noch die bilateralen Filter implementiert, die ich bisher in anderen Programmen nicht gefunden habe. Damit lassen sich die Überschwinger sehr wirkungsvoll vermeiden. Aber es ist schon so, dass jeder im Laufe der Zeit seine Postprocessing-Strategie entwickelt hat und dann bei den Tools bleibt, die er am besten kennt.

Zu den Stacking-Parametern: Die optimale Stackingrate ist tatsächlich sehr problemspezifisch. In Extremfällen kann sie deutlich unter 1% liegen (weshalb ich in PSS die Option eingeführt habe, statt der Stackingrate in % die Zahl der zu stackenden Bilder auszuwählen). In anderen Fällen (bei extrem gutem Seeing) kann sie auch schon mal 70% betragen. Deshalb muss man wirklich immer mit mehreren Raten experimentieren, um den Optimalpunkt für die Aufnahmesession zu finden. Dasselbe gilt für die AP-Patch-Größe. Der Standardwert von 48 Pixeln muss wirklich nicht optimal sein. Auch hier hilft nur Ausprobieren.

Und was das Aufheben der Rohdaten angeht: Ich habe noch nie Rohvideos gelöscht. Wenn ich ein Mondpanorama fertig bearbeitet habe, schreibe ich alle Videofiles auf ein LTO-6-Magnetband. Ein Band fasst 2,5 TBytes und ist 30 Jahre lang archivfest. Die Möglichkeit, auf die Originaldaten von vor mehreren Jahren zurückgreifen zu können, hat sich bei mir schon oft ausgezahlt. Insbesondere wenn ich eine deutlich verbesserte PSS-Version fertiggestellt hatte.

Schöne Grüße
Rolf
 
Oben