Stackingvergleich: APP, DSS, Siril und PI

Vielen Dank für die Arbeit. Die Ergebnisse sehen wirklich ähnlich aus, hätte ich so nicht gedacht.

Ich habe inzwischen schon relativ viele Bilder gestackt, bin von DSS zu Siril, dann zu Affinity Photo und zuletzt zu APP gekommen.

Ich kann nur meinen subjektiven Eindruck schildern:

DSS ist mir zu einfach und wird nicht weiterentwickelt. Siril ist kostenlos und ein Kompaktpacket mit der Bildbearbeitung. Der Stackingteil ist aber wenig variabel, etwas rätselhaft und ist bei mir auch langsam und stürzt gerne mal ab. Der Bildbearbeitungsteil ist teilweise elegant, reicht aber nicht aus. Affinity Photo ist mein Bildbearbeitungsprogramm, finde ich wirklich gut. Der Stackingteil ist aber nur Automatikbox ohne Info und Eingriffssmöglichkeit. Ganz anders wie der Bildbearbeitunsgteil mit den vielen Klasse-Astromakros von James Ritson.

APP ist relativ teuer, aber sehr variabel und klar zu steuern. APP kommt mit allen meine Frames, Filtern, Mosaics etc. gut zurecht. Man kann alles kombinieren und sieht sofort was man macht, bekommt Informationen über jedes Bild und ich finde allein das Datenmanagement klasse. Seitdem herrscht Ordnung auf meiner Festplatte. Ich finde auch den Nachbearbeitungsteil sehr gut. Das Rohbild wird in APP letztlich schon gut vorbereitet, was in Siril nicht so ist. Ich benutze auch oft den Stretchingteil von APP und übergebe ein Tiff-File dann an Affinity Photo.

Gruß Peter

Hallo Seraphin

da bist du aber noch nicht ganz fertig

nimmst du jetzt über lange Zeit Bilder auf von einem Horizont zum Anderem, dann verzerrt die atmosphärische Refraktion die Bilder erheblich

stell dir ein Quadrat im Süden 60grad Höhe vor, im Osten steht es tief und wird stark verzerrt wie bei einer Stablinse, die Ecken links oben und rechts unten werden auseinandergezerrt,

gibt ein schönes Trapez, im Westen passiert selbes mit den anderen beiden Ecken.

Das passiert auch nicht einfach linear.

welches Programm bekommt da nun die Sterne übereinander

Theli kann das und PI bietet auch Entzerrung über Astrometrie an, für jedes Einzelbild......das dauert, aber was zählt ist das Ergebnis

nur so nebenbei, man guidet ja auf einen Stern, der Effekt wird über lange Einzelbelichtung weiter weg vom Guidestern Strichspuren erzeugen, nicht das noch einer denkt schlecht geguidet oder Sensor schief oder Teleskop dejustiert

Gruß Frank

@ Seraphin

Das passt zu meinen Beobachtungen. Hatte extra den Arbeitsspeicher erweitert und war dann doch irritiert wie lange das Ganze braucht. Danke für deine investierte Zeit !

Also wohl am besten eine Astrocam kaufen damit es etwas flotter wird. Werde mich mal mit dem Thema beschäftigen.

Ich habe ja zurzeit Pixinsight als 45 Tage Trial im Test als Alternative zu Siril. Je mehr ich Frank Sackenheims YT-video sehe, mir das alles notiere und an alten Daten nachvollziehe, dest mehr finde ich gefallen daran.

OK, der Preis ist immer noch heftig, aber da gibts hier im Forum noch an anderer Stelle eine Diskussion dazu,... wobei, bevor die irgendwann mal auf die Abo-Idee kommen...  

Was mir aber nun aufgefallen ist, sind die megalangen Stacking-Zeiten. Ich habe vor ein paar Monaten umgesattelt von i5 Kaby Lake 5,4GHz / 32GB Ram auf nun i9 13th. gen / 32GB-Ram und meine zeitlichen Stacking-Durchläufe gingen dramatisch runter (Siril).

Was mir nun auffällt ist, dass Pixinsight extrem langsam ist im Vergleich zu Siril. Das hat mich zu diesem Thread hier geführt. Ich nutze das WBPP-Script und für 300 x 10sek Lights des Seestar mit ca. 4MB/frame brauchte PI über 40 Minuten.

Eben dann in Siril 1.2.1 gestackt in 54 Sekunden!

Habt ihr ähnliche Ergebnisse bzw. nutzt ihr zum stacken auch eine SW ausserhalb PI? Findet ihr die Ergebnisse unter PI besser?

Grüße

Hartmut

Hi Hartmut,

ich kann das auch für Affinity Photo bestätigen.

Die interne Stackingmöglichkeit hängt sich bei Bildern >100 entweder auf oder dauert gefühlt 10x als mit dem DeepSkyStacker (5.1.5).

Bis da ein Update das ganze stabiler macht, stacke ich erstmal ausserhalb und bearbeite dann das "32-bit/K Rational TIFF" in AP2 weiter.

Grüße

Andreas

Hallo Hartmut,

in der Tat braucht das WBPP Script sehr lange für die Integration der Daten. Versuche doch mal einen Durchgang unter Abwahl der Option „Local Normalization“ und vergleiche den Durchgang mit einem, der alle Optionen beinhaltet, ob du wesentliche Unterschiede siehst. Laut Frank Sackenheim ist dieses Prozeß sehr zeitaufwändig.

Ich verwende übrigens aus diesem Grund APP zum Stacken, geht um einiges schneller bei identischen Ergebnissen. Dann müßtest du jedoch noch eine Software kaufen. Dann verlege doch lieber das Stacking in die Kaffeepause .

Viele Grüße

Heinz

Hallo zusammen,

Danke für die Bestätigung! Ich werde das noch mal testen wie vorgeschlagen, würde in der Praxis aber nicht auf Optionen verzichten wollen.

Ich dachte nur, kann doch nicht möglich sein... Im Grunde hab ich es ja auch nicht eilig, ausser man will noch mal schnell was anderes ausprobieren.

Mit Siril wäre das ja mal fix möglich, mit WPTT würde ich wohl kaum Experimente machen und mir so den Tag um die Ohren schlagen wollen.

Grüße

Hartmut

Hui spannend,

ein fast ein Jahr alter Thread, der sich genau mit dem beschäftigt, was mich gerade umtreibt.

Streng genommen werden hier zwei verschiedene Themen betrachtet. Einmal die Software Performance und einmal die System Performance.

Zwar gehören beide irgendwie zusammen, aber wenn man vergleicht, nimmt man entweder verschiedene Software bei gleichem System, oder das gleiche System für verschiedene Software.

Daher sind Seraphins Ergebnisse für mich schon recht interessant und decken sich auch mit meinen Erfahrungen.

Ich habe mich immer wieder gefragt, warum der Stacking Prozess in PI so elendig lang dauert und ob es dann dadurch signifikante Vorteile gibt. Die Einordnung von PI als pre processing Software und nicht als stacking Software erscheint mir da eine plausible Erklärung.

Der Grund warum mich das gerade beschäftigt ist zum einen, der wirklich gut abgestimmte "gaming Rechner" den ich gerade für meine 12jährige Tochter zusammengestellt habe. Der beinhaltet zum Teil 8 Jahre alte Technik, aber alles ist aufeinander ideal abgestimmt. Das beinhaltet übrigens nicht nur den Prozessor, sondern Auch das Board, die Speicher und deren Takt bzw. Lese und Schreibgeschwindigkeiten. Es gibt Prozesse beim Stacken, die nutzen die volle Schreibgeschwindigkeit von über 500MB/s meiner Samsung EVO 870 SSD aus. Größere Datenmengen (ab ca. 150 Lights) lasse ich dann schon über meine M2 EVO970 PLUS mit PCIe3.0 laufen. Das geht nochmals schneller, aber die Platte ist klein.

Meine Bilder stammen übrigens aus einem IMX 571c Sensor. Ein Bild ist also knapp 50MB groß und im RGB somit knapp 150MB.

Der "billige" Rechner meiner Tochter hat mich derart überrascht ( macht 100 Lights + je 15 Darks, Flats, Darkflats mit Siril in knapp 6min statt in 20min als mein 10 Generation i7 im Laptop), dass ich mir gerade einen neuen Rechner für mein Hobby zusammenstelle.

Zum anderen schiele ich immer wieder auf PI, da meine Daten immer besser werden.

Es steht ausser Frage, das PI das Maß der Dinge im Bereich pre processing ist, jedoch schreckt mich der Preis immer wieder ab. Es ist sicherlich nicht zu teuer, aber ich überlege immer sehr genau und sehr lange, ob es das für mich wert ist und ob ich es überhaupt nutzen kann. Dieser Tag wird bestimmt kommen, aber aktuell bin ich beruhigt, dass zumindest der Stackingprozess in Siril dem in nichts nachsteht.

Ich bin übrigens bekennender Siril-Fanboy , und kümmere mich dann mal zuerst um die Workstation, dann um das Material und schließlich um das Werkzeug.

Danke an alle für die zahlreichen nützlichen Beiträge hier drin.

Grüße

Marco

Noch ein Nachtrag...

Auf der Suche nach dem Begriff "Performance" und Pixinsight bin ich darauf gestoßen, dass sich die Verarbeitungsgeschwindigkeit erhöhen läßt.

Dazu müssen anstatt des Default-Verzeichnis für die temporären Swap-Dateien mehrere (bis zu 8 Pfade (auch identische!) zu möglichst schnellen Festplatten eingetragen werden.

Dazu unter EDIT/Global Preferences dort "Directories and Network" wählen und die Pfade eintragen:

Ich habe den Default-Pfad auf meine SSD mit dem OS (WIN11) gelöscht und stattdessen 8 Pfade zum schnellen 256GB-NVRAM eingetragen.

Dann unten links auf den blauen Kreis klicken zum speichern.

Man kann sich vorab und danach eine Benchmark-Test anschauen.

Dazu vor Anlegen der neuen Pfade unter Script/Benchmarks "Pixinsight Benchmarks" aufrufen.

Den Test mit RUN laufen lassen und das Ergbebnis speichern.

Dann die neuen Pfade eintragen, speichern, ggf. PI neu starten und den Benchmark-Test noch mal starten und die Ergebnisse vergleichen.

In der Praxis habe ich beim ersten Test mit WBPP (Stacking,...) eine Performance-Steigerung von ca. 4,5min erreicht, was aber im Gesamtergebnis nicht besonders viel ist.

Beim Stacking mit allen Kalibrierungs-Bildern und Lights bin ich von ca. 59min auf ca. 54min gekommen.

Danach habe ich den Test mit 300 Seestar Lights durchgeführt. Hier bin ich von ca. 42min auf 16min gekommen. Ich bin mir aber aufgrund der immensen Leistungssteiegrung in diesem Fall aber nicht sicher, ob hier nicht irgendwie andere Einstellungen beim Stacking-Prozess dazu geführt haben. (In jedem Fall habe ich "beste Qualität" eingestellt.)

Während des gesamten Prozessduchlaufs habe ich bemerkt, dass dass "temp-Verzeichnis" kaum genutzt wird bei diesem Prozess oder aber ich habe nicht oft genug im Win-Explorer auf Refresh geklickt.

Ganz zum Schluss konnte ich sehen, dass beim eingestellten Auto-Crop ein paar Dateien dort auftauchten und sofort wieder gelöscht wurden.

Es kann daher sein, dass die TEMP-Verzeichnisse eher bei der Durchführung anderer Prozesse genutzt werden und dort ihr neues Potenzial entfalten.

Grüße

Hartmut

Es gibt im Web ein paar Beiträge dazu. Hier mal exemplarisch einer:

Pixinsight Performance and Swap Files - AstroBin

PS -> man muß zum Schluß auch noch zu EDIT -> Write Settings File gehen, sonst ist die Änderung wieder weg beim nächsten Start

Zitat von astrophin

Hi Sebastian

Bei mir liegen Die Daten auch auf einer HDD, daher kanns nicht kommen. Meine Cams haben aber nicht den grössten dynamikumfang, sprich die Daten sind nicht extrem gross. Vielleicht liegt es daran?

Hallo Seraphin, Danke für den Test.

Ich benutze prkatisch immer APP und hatte bei vielen Frames auch lange Rechenzeiten trotz relativ schnellem Rechner. Das hat sich geändert, seit ich die Daten auf eine SDD vorher überspiele. Es wird zwischendurch ja immer wieder auf die Daten zugregriffen und da bremst eine HDD enorm. Simpler Blick auf den Windows Task manager zeigt einem das sofort.

CS Peter

Danke für den ausführlichen Vergleich und der weiteren Diskussion hier.

Zitat von astrophin

Ich finde auch in der Bedienung Siril deutlich einfacher als DSS.

Das empfinde ich genau anders herum. In DSS lade ich einfach Lights, Flats und Darks in die jeweiligen Reiter und los geht's. Die manuelle Stacking Prozedur in Siril ist mir ein Graus. Die Skripte fand ich auch sehr sperrig, man musste die Dateien genau so benennen, wie das Skript es verlangt und an die richtige Stelle kopieren. Ich habe z.B. meist keine Bias, die Skripte, die ich fand, wollten aber welche - was tun? Erlösung fand ich in Sirilic, das mir wieder eine menuegesteuerte Bedienoberfläche bietet, die ich von DSS gewohnt bin.

Außerdem ist DSS bei mir um mindestens Faktor 3 schneller als Siril. Wenn ich das Arbeitsverzeichnis auf meine SSD setze, wird Siril viel schneller, ist aber immer noch etwas langsamer als DSS.

Ich habe auch in den Ergebnissen den FWHM Sterndurchmesser in den Rohstacks verglichen. Die Sterne waren im Sirilstack um ca. 5% kleiner als im DSS, visuell sehe ich keinen Unterschied, auch nicht in den Deep Sky Details. Vielleicht liegt mein anderes Ergebnis an meinen schlechten Bedingungen?

Bei Schmalbandaufnahmen hatte ich mit DSS ab und zu farbige konzentrische Ringe, mit Siril nicht. Das Problem mit DSS erschien mit und ohne Flats. Ich habe nicht verstanden warum. Da es nur selten vorkam, habe ich es nicht weiter verfolgt.

Zur Zeit stacke ich fast immer mit DSS, da ich es gewohnt bin, es schneller ist, ich keine Daten hin und her kopieren muss und Zwischenverzeichnisse wieder löschen muss. Komplexe Objekte mit Schmalband, die mir wichtig sind, stacke ich auch zuerst mit DSS, um zu checken, ob alles passt und erst in der Endversion mit Siril (über Sirilic).

Ich nutze irgendeine für mich logische Benamung in NINA, lade die Lights und Korrekturbilder in die SIRIL Unterverzeichnisse und die Standard-Skripe (OSC-Preprocessing) verarbeiten alles ohne Änderung oder Probleme.

Von DSS bin ich lange weg.

Grüße

Hartmut

Hallo zusammen,

mir geht es wie Stathis.

DSS geht wunderbar leicht von der Hand und ist so richtig schnell.

Grüße

Andreas

Zitat von astrophin

So unterschiedlich sind die Geschmäcker, abgesehen davon dass DSS bei mir deutlich langsamer arbeitet und mit Mono eher mässig gut geeignet ist, ist die Handhabung für meinen Geschmack sehr hölzern und fühlt sich für mich zu sehr nach 90ern an 😉

Klar ist das Geschmackssache und man kann mit den kostenlosen Programmen wie DSS, Siril oder GIMP sich auch reinfuchsen und (fast) alles damit machen. Klar ist auch, dass, wer Geld für ein Programm ausgibt, es hinterher am liebsten besser finden will.

Ich bleibe für alle Zeiten zum Stacken bei APP . Das ist teuer, hat bei mir aber mit bei Arbeiten mit DSS, fitbits und Gimp die Erinnerung an den Beginn meines Rechnerleben ab den 80iger Jahren sofort hinweggewischt.

Man kann alles stacken, alles kombinieren, bekommt für PI gleich die richtigen Datenformate raus, kann sehr gut vorab probeweise stretchen und die Grundverarbeitungsschritte nach dem stacken sind eine sehr gute Alternative und Backuplösung für PI , falls es da mal Probleme gibt.

Aber, wie gesagt, ein jeder liebt es anders!

CS Peter