Stacking Vergleich: PixInsight, Siril und Deepsky Stacker

Status
Es sind keine weiteren Antworten möglich.

bento124

Aktives Mitglied
Hallo Zusammen,

aufgrund der anhaltenden dichten Bewölkung habe ich gestern Abend mal das Stacking Resultat der folgenden Tools verglichen:
  • DeepSky Stacker, V.4.2.6,
  • Siril, V.0.99.10.1
  • PixInsight / Weighted Batch Preprocessing Script, V.2.2.0
Verwendet wurden Aufnehmen von M57, die mit der Konfiguration ASI294, SC 150 / 1500, EQ6R-PRO gemacht wurden. Dabei hatte ich:
  • 10 x DARK (exp. 120 s)
  • 10 x FLAT (exp. 1,2 s)
  • 10 x DARKFLAT (exp. 1,2 s)
  • 10 x BIAS (exp. 40µs / 4E-5) *
  • 33 x LIGHT (exp. 120 s)
    * Gemäß der Empfehlung von Youtube Kanal astrophotocologne (Frank Sackenheim, hier)
    habe ich diese Frames bei der Erstellung der Korrektur nicht benutzt und durch DARKFLATS
    ersetzt.
Die generierten Calibration Frames sind meines Ermessens alle identisch.

Die Rechenzeit auf einem betagten 64 Bit Win 10 PC, mit i5 Prozessor (mit 8 GB RAM) unterscheidet sich stark.
  • PixInsight / WBPP, Dauer 22:06 (100%)
  • Siril, Dauer 13:45 (62%)
  • DeepSky Stacker, Dauer 6:48 (31%)
  • DSS war am schnellsten!
Das gestacke Resultat ist jedoch bei den einzelnen Tools stark unterschiedlich.
1634151744459.png

Reihenfolge: PixInsight -> Siril -> DSS
  • PI/WBPP: Hier habe ich im gestackte File sehr viele hässliche schwarze Pixel (verrauscht???).
  • Siril und DSS sehen für meine Augen erst mal sehr ähnlich aus.

Nun meine Zweifel:
  • Vermutlich habe ich bei PixInsight was falsch gemacht. Nur was?
  • Was gibt es dazu bei Euch für Erfahrungen?
 
Hi,

die schwarzen Flecken hat Adam Block neulich in einem Video erklärt, müsste jetzt aber selber nochmal anschauen was er da sagt, aber es ist glaube ich letztendlich eine kleine Einstellungssache gewesen.

Das Problem bei solchen Vergleichen liegt im Detail. Erstes Detail ist die Art und Weise wie die ScreenTransferFunction funktioniert mit der du nun die Bilder vergleichst. M.M.n müsstest du zunächst alle drei Bilder auf das gleiche Level bringen (Linear Fit) und dann der STF unterziehen.

Dann ist es so, dass WBPP ja ein weighting macht (darum heißt es so). Das kostet Rechenleistung und somit Zeit. Dazu muss man es auch erstmal anwählen und Parameter einstellen. Einfach der Automatik vertrauen geht m.E.n nicht. Es gibt in PI so viel einzustellen und da kann man eben auch Fehler machen. Sei es durch nichts tun oder durch falsches dazu tun. Nach welchen Kriterien zum Beispiel wurde die Gewichtung berechnet? Welchen Stacking Algorithmus hast du gewählt oder hat PI automatisch gewählt (ESD tippe ich).
In DSS findet meines Wissens nach nicht mal annähernd etwas ähnliches statt. Es gibt wohl eine Normalisierung, aber das wars dann auch schon. Auch bei Siril wird nicht viel mehr passieren. Der Stacking Algorithmus in DSS ist ein schnöder Sigma Combine, da hat PI ganz anderes zu bieten, aber eben mit Fallstricken, Einstellungen die gewählt werden wollen.

Ich sehe es so, dass hier letztendlich die Methode wie du vergleichst Fehler aufweist. Man müsste zum Beispiel mal in PI alles so einstellen wie in DSS und dann würde es mich wundern wenn groß was anderes raus käme. Ich habe das mal mit APP und PI gemacht und dann war letztendlich der einzige Unterschied der Debayer Algorithmus. Und da konnte man tatsächlich einen Unterschied sehen. Als nächstes wären dann die Stacking Methoden dran. Sieht man einen Unterschied zwischen ESD und Winzorized Sigma oder Linear Fit? (ESD ist mit "Test" gekennzeichnet. Wird aber in den meisten Fällen automatisch gewählt. Ich kann mich damit noch nicht so recht anfreunden). Dann was machen die weigthing Methoden? Noise estimated z B ist Fehleranfällig wenn z B Wolken durchfliegen.

Und so weiter und so weiter. Bin gespannt was andere dazu sagen, aber ich vermute mal wir haben es hier schlicht mit der guten alten Äpfel und Birnen Problematik zu tun.

CS Frank
 
Hallo,

ich vermute, dass Frank schon im Wesentlichen recht hat, dass hier vergleichbare Parameter eingestellt werden müssten. Auf der anderen Seite kann man es ja auch so sehen, dass bei allen drei Programmen das Ergebnis mit "Standardeinstellungen" verglichen wird. Und da schneidet PI durchaus nicht immer gut ab. Mir ist es z.B. in letzter Zeit wiederholt vorgekommen, dass PI Flats überkompensiert (aber interessanterweise - trotz identischer Behandlung - nur in Grün, während es in L , R und B einwandfrei funktioniert, die Routinen sind allesamt dieselben). Astroart z.B. als mein älteres Stackingprogramm rechnet das einwandfrei um in perfekt korrigierte Lights. Und wenn ich das Flat in Astroart zusammenbaue, kommt auch PI damit klar. Für mich nicht nachvollziehbar. Auch sprechen mich die Kontrastanpassungsmöglichkeiten von PI nicht sehr an (Histrogramm Transfer, Curves klar, aber alles andere hat für meine Augen gravierende Nachteile). Da produziert z.B. das alte CCDStack bei mir nach wie vor bessere Resultate. Einstellungssache? Vielleicht, aber selbst mit den Parametern von Tommy gefallen mir die Ergebnisse nicht besonders. Beispielsweise bekommen die Kerne hellerer Sterne bei PI gerne Fehlfarbenränder, während das in AA nicht passiert. Woran es liegt? Vermutlich "falsche Einstellungen", ich habe aber wenig Lust, stundenlang zu probieren, bis ich vielleicht brauchbare Ergebnisse erziele, während eine andere Software das sofort mit automatischen Einstellungen schafft. PI hat seine spezifischen Vorteile, aber ich denke derzeit darüber nach, meinen Workflow wieder auf andere Programme auszudehnen.

VG
Stefan
 
Es gibt in PI so viel einzustellen und da kann man eben auch Fehler machen. Sei es durch nichts tun oder durch falsches dazu tun. Nach welchen Kriterien zum Beispiel wurde die Gewichtung berechnet? Welchen Stacking Algorithmus hast du gewählt oder hat PI automatisch gewählt (ESD tippe ich).
In DSS findet meines Wissens nach nicht mal annähernd etwas ähnliches statt. Es gibt wohl eine Normalisierung, aber das wars dann auch schon. Auch bei Siril wird nicht viel mehr passieren.
Etwas mehr geht da bei Siril schon ;)
Es gibt verschiedene Normalisierungs-Methoden (Additiv/Multiplikativ, mit/ohne Scaling), verschiedene Rejection-Algorithmen (darunter Winsorized, Linear Fit, Generalized Extreme Studentized Deviate Test, ...), die Frames können nach Background-Noise-Level gewichtet werden, und nach verschiedenen Kriterien (FWHM, weighted FWHM, roundness, ...) gefiltert werden.
Das sieht man bei einfacher Anwendung der Skripte natürlich nicht, aber wer will kann sich da schon austoben.

Grüße,
Steffen
 
Hallo Zusammen,

vielen Dank für die Hinweise, insbesondere den Hinweis auf das Video von Adam Block. Dieses Video ist „Große Schule“. Ich habe folgendes verstanden:
  • Der Erste Punkt der im Video angeführt wird, war, dass man bei so einem Vergleich die entsprechenden Einstellungen vergleichen sollte.
    • Da hat er sicherlich recht. Hierzu also im Anhang en PDF mit den entsprechenden Screen shots.
  • Die anderen Programme auch unterschiedliche Stacking Algorithmen nutzen. Dies kann naturgemäß zu einer anderen Rechenleistung führen. Im gegebenen Fall hat PI tatsächlich mit der rechenintensiven ESD Methode gearbeitet, während DSS mit der Sigma Clipping Methode gearbeitet hat.
    • Verstanden.
  • Adam Block argumentiert, dass es bei diesen schwarzen Pixeln zu einer Überkorrektur kam, zum Beispiel durch zu alte Darks. Nun ja, meine Darks waren in der Tat 3 Tage alt, also nicht am gleichen Tag aufgenommen.
    Ferner habe ich die BIAS Frames durch DARKFLATS (mit exp. 1,2 sek.) ersetzt. Diese Wurden im WBPP allerdings nicht zu den BIAS gruppiert, sondern zu den DARKS.
    • Könnte das auch der Grund einer Überkorrektur sein?
1634227468838.png

Alles weitere muss ich jetzt mal im Detaill das Video von Adam Block nachvollziehen und ausprobieren, dafür brauche ich aber ein wenig Zeit.

Vielen Dank für die reichlichen Informationen und Denkanstöße ?

LG und CS

Bernd
 

Anhänge

  • Stacking Vergleich.pdf
    391,7 KB · Aufrufe: 97
Auch sprechen mich die Kontrastanpassungsmöglichkeiten von PI nicht sehr an (Histrogramm Transfer, Curves klar, aber alles andere hat für meine Augen gravierende Nachteile). Da produziert z.B. das alte CCDStack bei mir nach wie vor bessere Resultate. Einstellungssache? Vielleicht, aber selbst mit den Parametern von Tommy gefallen mir die Ergebnisse nicht besonders. Beispielsweise bekommen die Kerne hellerer Sterne bei PI gerne Fehlfarbenränder, während das in AA nicht passiert. Woran es liegt? Vermutlich "falsche Einstellungen", ich habe aber wenig Lust, stundenlang zu probieren, bis ich vielleicht brauchbare Ergebnisse erziele, während eine andere Software das sofort mit automatischen Einstellungen schafft.
Das ist alles ganz prima Stefan, aber das hat eigentlich nichts mit dem Ursprungsthema zu tun, sondern eher ob einem ein Benutzerinterface gefaellt/anspricht und ob man eine "offene" Programmarchitektur mag, bei der man auch bis zum Ellenbogen in der Sosse ruehren kann, oder lieber eine Oberflaeche mag, die viele Dinge vom Benutzer eher abschirmt und intern erledigt.
Ich mag z.B. beides: die schweren Erdarbeiten in PI, danach der Feinschliff (was das Abstimmen des Mittenkontrasts und der Farbtoene mit einschliesst) dann lieber mit Lightroom oder PS. Ich wuerde beides nicht missen wollen.

@Bernd Noch mal kurz zur eigentlichen Sache, dem Stacking-Vergleich:
Ich will nur mal anmerken, dass mir die "reject maps" nach dem Stacken/Integrieren von PI immer wieder eindruecklich vorfuehren, wieviele Guiding-Aussreisser da galant verschwinden und kleine Wolkenbesuche zu den Akten gelegt werden. Ich mache meine Astroknipserei unter erschwerten Umstaenden (sehr launiges Wetter und viel Lichtverschmutzung) und da ist ein gutes Preprocessing das A und O, sonst kann man frustriert einpacken.
Ob das alles mit dem DeepSky Stacker nicht auch irgendwie geht (Siril kenne Ich nicht gut genug), vermag Ich nicht zu sagen, Ich bin damit jedenfalls auf keinen gruenen Zweig gekommen und musste stundenlang alle moeglichen Artefakte von Hand hinterher herausprozessieren.
Mit PI habe Ich mich dann auch an Sachen herangetraut, die mir mit dem DSS nicht im Traum eingefallen waeren: PI erlaubt auch mal ein 2x3 Mosaik in LRGBHOS (immerhin satte 42 Stacks) komplett automatisch durch das Preprozessing (mit den jeweiligen Bias, Flats und Darks) zu mangeln und seine Zeit dann der eigentlichen Bildbearbeitung zu widmen. Da hat sich in den letzten zwei Jahren irre viel getan und Ich staune jedesmal wie viele Gedanken und Ideen da eingeflossen sind.
Beim Preprocessing per Hand haette man alleine dafuer mehr als einen vollen Tag zu tun und die DSS gesparte Rechenzeit wuerde Ich 3x so lange in Files sortieren und umkopieren versenken.
Damit will Ich den DSS nicht abwerten, nur das ist irgendwo schon ein Vergleich Florett gegen schwere Saebel. Und letzterer liegt nun mal auch deutlich schwerer in der Hand.

Was PI bedauerlicherweise nicht hat, ist GPU-Beschleunigung. Das ist ein Thema, dass in den PI Foren immer wieder kontrovers diskutiert wird und bisher mit "eines Tages vielleicht, hat aber derzeit keine Prioritaet" abmoderiert worden ist.

CS
 

Hallo Steffen,
Stimmt, ich hatte da nicht nochmal explizit nachgeschaut.
Aha, Generalized Extreme Studentized Deviate, das Test ist Bestandteil des Namens? Ich habe nichtmal im Ansatz verstanden wie der funktioniert, produziert aber gerne mal Artefakte wenn ich die Standard Einstellungen verwende.
Auf der anderen Seite kann man es ja auch so sehen, dass bei allen drei Programmen das Ergebnis mit "Standardeinstellungen" verglichen wird.

Hallo Stefan,
ja, ich verstehe schon die Vorgehensweise. Aber es sträubt sich mir innerlich das so zu machen. Es ist aus meiner Sicht methodisch einfach falsch. Aus Sicht des Anwenders natürlich aber nachvollziehbar. Ich denke nur das solche Vergleiche eben nicht der Wahrheitsfindung dienen und Futter für Pauschalaussagen werden. So habe ich mal gelesen wie jemand geschrieben hat: AstroPIxelProzessort stackt besser als PixInsight. Ohne weiteren Kommentar. Sowas wird dann aufgegriffen und fröhlich weiter verbreitet. Und solche Pauschalaussagen werden weder der einen noch der anderen Software gerecht.
Wie man nun am Ende für sich entscheidet und ob ein gewisser Pragmatismus letztendlich doch ausschlaggebend ist, muss jeder für sich entscheiden. Tatsächlich wollte ich immer mal einen Vergleich machen und scheitere daran die geeignete Methodik zu finden. Man kann durchaus dann mal darüber nachdenken das Ganze aus rein pragmatischer Sicht zu betrachten. Ist aber irgendwie nicht so mein Ding.

Das mit den Flats hatte ich umgekehrt aber auch schon. Also APP hat über korrigiert PI nicht. Ist zu 99% irgendwas mit den Bias oder Flatdarks und oder der Software Logik.

Ferner habe ich die BIAS Frames durch DARKFLATS (mit exp. 1,2 sek.) ersetzt. Diese Wurden im WBPP allerdings nicht zu den BIAS gruppiert, sondern zu den DARKS.
  • Könnte das auch der Grund einer Überkorrektur sein?

Hallo Bernd,

ich denke nicht. In deinen Screenshots sieht man dass du alles auf Automatic stehen hast. Wenn du das abwählst und auch mal den "normalen" Sigma Combine auswählst und zudem das weighting abwählst, wird vermutlich alles gleich aussehen. Wenn nicht werde ich den Besen eben fressen müssen :)

CS Frank
 
*Klugschiss an*:
Was an Generalized ESD Tests so rechenintensiv ist, ist Folgendes: Der Test erlaubt grundsaetzlich zu bestimmen, wie viele Aussreisser sich in eine normalverteilte Stichprobe geschummelt haben. Und zwar bis zu einer vorgegebenen maximalen Anzahl n.
Um das zu tun, tested das Ding aber jedesmal fuer jeden Pixel in gesammten Stack fuer n Ausreisser, n-1 Aussreisser, n-2 Ausreisser, n-3 etc.
Das sind z.B. bei einem Stack von 100 Bildern unter der Annahme von max 50% Muell dann aber auch 50x so viel Rechenzeit, verglichen mit z.B. bei Sigma-Clipping, wo einmal die Standartabweichung und der Median einer Pixelposition im Stack berechnet wird und dann alles was Median +- Standardabweichung weg liegt, einfach 'rausgeworfen wird.

GESD macht Sinn, wenn die "Ausreisser" weit weg von den normalverteilten Daten sind und z.B. nur in eine Richtung ausreissen. Mehr als gelegentlicher Wolkenbesuch und mehr als gelegentliche Guidingwackler sind genau so eine Situation, wo man mit dem GESD theoretisch besser faehrt, als z.B. mit einem einfachen Sigma-Clipping.

Klar kann man dann die reine Rechenzeit vergleichen, dann muss man aber beim Sigma-Clipping auch die Zeit einrechen, die man braeuchte mit Blink durch alle Daten per Hand zu gehen und alle Wolkenbesuche/Wackler per Hand herauszunehmen, denn ansonsten dominieren diese ganz fix die Standardabweichung des Stacks an dieser Pixelposition und wenn diese erst mal sehr gross geworden ist, dann beleibt kleinerer Muell wie eine Satelitenspur in den Daten, denn Sigma-Clipping packt ein.

Andererseits ist GESD ohne Wolken und ohne Guidingwackler in einer guten Nacht kompletter Overkill, wenn es nur darum geht mal eine ganz gelegentliche Satelitenspur herauszuwerfen.
Der Grund warum PI GESD als Standardeinstellung hat, ist vermutlich weil man lieber laengere Rechenzeiten fuer Overkill in Kauf nimmt, als das bei z.B. Teilbewoelkung die Integration dann schnell sehr viele Artefakte hat.

Bei mir steht das Telekop z.B. auf der Terasse und schwingt daher mit dem Gebaeude ab und zu etwas, z.B. wenn einer die Treppe wie ein Elefant herunterennt. GESD ist meine "Geheimwaffe", damit helle Sterne in Frames die leicht verwackelt sind nicht die Umgebung zu sehr kontaminieren. Wer sein Rohr auf der Betonsaeule im Garten stehen hat, dem kann das z.B. weitgehend egal sein und der hat mit einem Sigma Clipping genauso schoene Ergebnisse.
Horses for Courses.

CS
 
Hallo zusammen,
wollte mal kurz einen Zwischenstand geben. Die dunklen Pixel sind verschwunden, nachdem ich wie von Adam Block empfohlen mal auf die Schnelle überall die „ESD low response“ von Default 1,5 auf das Minimum 1,0 reduziert habe.
  • Damit ist das gestackte Bild absolut sauber geworden :) .
Bei den nächsten bewölkten Tagen werde ich versuchen das aufgetretene Problem noch genauer zu untersuchen. Jetzt geht’s erst mal wieder zum Fotografieren ?.

Einstweilen ein dickes Dankeschön an alle beteiligten - ich habe durch die reichlichen Kommentare auf jedenjalls viel gelernt.
 
Status
Es sind keine weiteren Antworten möglich.
Oben