Neuer Stacker & Kombinierer

[mlnoga]

Hallo Erik, danke, das freut mich. Ich habe die Speicherverwaltung jetzt völlig umgestellt. Nach zahlreichen erfolglosen Versuchen mit Speicherpools bin ich letztlich auf eine aggressive Garbage Collection umgeschwenkt. Das ermöglicht eine Skalierung bis weit nach unten, und bringt auf größeren Rechnern nur minimale Geschwindigkeitseinbußen mit sich. Die Ergebnise der einzelnen Batches brauchen jetzt auch keinen wachsenden Speicher mehr, weil ich inkrementelles Stacking dieser Zwischenergebnisse eingeführt habe. Bei der Sternerkennung konnte ich mit frühem Filtern den Speicherbedarf ebenfalls noch stark reduzieren. Und encoding.binary habe ich durch eigene Konvertierer mit schnellem Buffering ersetzt.

Ergebnis: Auf meinem Pi3 mit 1 GB geht -stMemory 700, wenn ich Astroberry ohne X-Windows boote und der Grafikkarte nur 16 GB zuweise. M42 läuft darauf durch, die Bubble auch. Wenn auch wenig sinnvoll, da bei Einzelbatches a 3 Bilder das Sigma-Stacking natürlich nicht mehr richtig tut. Mit Release 0.1.3 sollte der RasPi Support damit vorerst abgeschlossen sein.

Wenn Du magst, probiere es doch bei Gelegenheit mal aus. Es sollte auf dem Pi4 jetzt mit -stMemory 2500, -stMemory 3000 oder sogar -stMemory 3500 laufen. Je nachdem, was Du sonst noch im Speicher hast.

Steffen, ich denke, jetzt kann ich zeitnah das Debayering angehen.

Matthias, zum Thema GUI. Das hängt davon ab, wieviele Nutzer sich eine solche Oberfläche wünschen; wieviel Zeit ich habe, und wer mitmachen möchte. Ein plattformspezifisches GUI z.B. nur für Windows schliesse ich aus. Für portable GUIs könnte man in drei Richtungen gehen: HTML-GUI im Browser, Desktop-GUI z.B. über QT Wrapper oder OpenGL GUI mit fyne, gio o.ä. Was wäre Dir denn wichtiger: Fernbedienbarkeit von anderem Rechner über den Browser, schnellste Performance beim Pannen/Zoomen, nativer Look der Bedienelemente?

Markus

 

[Erik]

Nachtrag: Release 0.1.3 funktioniert jetzt auch mit - stMemory 2000 ohne Overflow und kommt auf 5min 42s.

 

[mlnoga]

Klasse, Erik.

Steffen, Debayering scheint mit Release 0.1.4 zu funktionieren. Ich habe zunächst das von Dir empfohlene bilineare Verfahren umgesetzt (mit Dank an Carsten für die Inspiration in C). Hier das erste Ergebnis der in diesem Forum geteilten Arp 316 Testdaten ohne Master-Dark und ohne Master-Flat, herunterskaliert auf 4K um den Größenbeschränkungen zu genügen.

Parameter für die Verarbeitung waren für Rot: -debayer R -cfa GBRG, für Grün -debayer G -cfa GBRG, für Blau -debayer B -cfa GBRG und für die RGB Kombination -chroma 1.9 -ppGamma 3.0 -ppSigma 2.0. Also Farbsättigung um 0.9x angehoben, und eine Gammakurve von 3.0 auf alle Werte gelegt, die 2.0 Abweichungen oder mehr über dem mittleren Hintergrund liegen. Die 2.0 habe ich mal ausprobiert, um die unebene Ausleuchtung aufgrund des fehlenden Flats wegzudrücken. Mit Flat nehme ich üblicherweise die Standardeinstellung 1.0.

Hast Du ein Master-Dark und ein Master-Flat für die CFA-Bilder in FITS zur Hand? Und mehr Lights als FITS? Es wäre spannend zu sehen, was hier noch geht. Evtl. könnten wir einen weiteren offenen Testdatensatz daraus machen, wenn es Dir recht ist.

Offen: Aktualisiertes Makefile mit besseren Regeln für CFA, Anpassung der kostmetischen Korrektur für Bad Pixels an CFA Daten.

Markus

 

[steffens]

Hallo Markus,

Vielen Dank für Deine Arbeit - das geht ja in enormem Tempo vorwärts.

Das Problem mit meinem Datensatz: es handelt sich um insgesamt 130 Lights, aufgenommen in 4 Nächten. Dazu gibt es dementsprechend 4 Master-Flats. Die ursprüglichen Flat-Einzelaufnahmen habe ich nicht mehr, nur noch die fertigen Masters, von Siril im 32 Bit Float-Format erstellt. Um die verwenden zu können, müsste Dein Programm also auch mit dem 32 Bit Float-Format umgehen können, und Flats in dem Format zur Kalibrierung von Lights in 16 Bit Integer-Format verwenden können.
Darks habe ich keine, nur Master-Bias.
Auch nach der Kalibrierung mit Flats sind die Bilder nicht wirklich eben. Da ich mit ungekühlter DSLR arbeite schwankt die Güte der Flat-Korrektur mit der Temperatur. Außerdem habe ich extreme Gradienten von Lichtverschmutzung und seitlich einfallendem Streulicht. Das mit einem automatischen Prozess wegzubekommen halte ich für ausgeschlossen.
Wenn Du trotzdem weitere Testdaten haben möchtest, kann ich sie aber gerne liefern.
Hier ist übrigens meine Bearbeitung von dem Datensatz.

Grüße,
Steffen

 

[Ehemaliges Mitglied 8776]

Moin,

ohne mich da in den Thread hängen wollen, Steffen, wäre das nicht was für Background Extraction?

CS
Jörg

 

[steffens]

Hi Jörg,

Bin mir nicht sicher, ob ich die Frage richtig verstehe.
Ja, meine Aufnehmen sind definitiv ein Fall für Background Extraction. Immer
Soweit ich das verstanden habe, unterstützt aber der neue Stacker von Markus das noch nicht. Ich bin mir auch nicht sicher, wie weit Markus da mit der Automatisierung gehen möchte. Aber ein Hintergrund-Abzug müsste ja schon möglichst früh passieren.

Grüße,
Steffen

 

[Ehemaliges Mitglied 8776]

Moin,

so war der Denkanstoß gemeint. Ich denke das wäre eine mehr als sinnvolle Funktion...

CS
Jörg

 

[steffens]

... lässt sich aber ohne manuelles Setzen von Sample-Punkten nur schwer machen. In Grenzen geht sowas wie die automatische Generierung von Punkten mittels Schwellenwert, aber um wirklich neutralen Hintergrund zu finden ist wohl auf jeden Fall manuelle Kontrolle (oder AI ) nötig.

 

[mlnoga]

Steffen, 32 bit float Fits sind kein Problem, genau diesen Workflow nutze ich auch für die Beispiele M42 und Bubble. Immer her damit, und mit den Lights.

Jörg und Steffen, mein Ansatz für ABE wäre wie folgt: einmal stacken. Der Nutzer malt dann in der Bildverarbeitung seiner Wahl eine Maske darüber und speichert sie. Dann setzen wir Kontrollpunkte in einem regelmäßigen Gitter einstellbare Kantenlänge, mit Ausnahme der maskierten Bereiche. Vorteil: volle Flexibilität in der BV, und bedingungslose Wiederholbarkeit im Prozess. Erkannte Sterne könnte man leicht schon jetzt maskieren, NL kann ja bereits eine Sternenmaske herausschreiben.

Was haltet ihr für wichtiger? Funktionen wie ABE, Formate wie Nikon/Canon RAW, oder GUI?

M

 

[Ehemaliges Mitglied 8776]

Oh je - was für ne Frage...

Ich würde keinen eigenen Raw-Converter machen, die gibt's wie ich finde in sehr guter Qualität. Eher GUI und Bildfunktionen, my five pence.

CS
Jörg

 

[Erik]

Zur GUI: ich persönlich benötige keine GUI, weil ich mich in den Untiefen von Unix halbwegs auskenne und das Makefile gut zu modifizieren ist. Aber der normale Nutzer wird den Stacker mit GUI nutzen wollen. Eine etwas ausführlichere Dokumentation oder ein Tutorial der vielen Programmmöglichkeiten wäre für mich viel interessanter.

Ich will den Stacker eigentlich in der Scriptsprache von CCDCiel einbinden, damit nach der Aufnahmesession auf dem RPI4 automatisch das Stacken abläuft.

Grüße
Erik

 

[steffens]

Immer her damit, und mit den Lights.

Das sind alles zusammen so 6,8 GB.
Die Lights als NEF-Raw wären nur etwas mehr als halb so groß, Du könntest sie z.B. mit Siril schnell selbst in CFA-FITS umwandeln. Zusammen mit den Master-Flats und einem Master-Bias sind das aber immer noch 4 GB!

Was haltet ihr für wichtiger? Funktionen wie ABE, Formate wie Nikon/Canon RAW, oder GUI?

Also, direktes Einlesen von RAW-Formaten fände ich schon wahnsinnig praktisch
Und kann Deine Software auch schon mit mehreren Sessions umgehen? D.h. die Aufnahmen einer Nacht auch mit den Flats von dieser Nacht kalibrieren, aber am Ende mit allen anderen Frames zusammen registrieren und stacken?

Grüße,
Steffen

 

[Ehemaliges Mitglied 8776]

Hallo Steffen,

ich denke den Formatconverter kann man als externe Funktion einbinden, den wirst Du nicht zwingend sehen müssen.

CS
Jörg

 

[moos]

Ich würde keinen eigenen Raw-Converter machen, die gibt's wie ich finde in sehr guter Qualität. Eher GUI und Bildfunktionen,

Hallo,
das sehe ich völlig anders. Die üblichen RAW-Converter sind für die bildmäßige Fotografie gemacht. Sie legen alle eine Gradatiosnkurve, Weißpunkt oder Schwarzpunkt und Farbbalance oder evtl. noch Schärfung mit an. Das können wir nicht gebrauchen.
Ein RAW-Converter nach fits macht eben nur das "Debayern" und das für lights nach dem Kalibrieren.Die Bilder bleiben linear.

 

[moos]

. lässt sich aber ohne manuelles Setzen von Sample-Punkten nur schwer machen. In Grenzen geht sowas wie die automatische Generierung von Punkten mittels Schwellenwert, aber um wirklich neutralen Hintergrund zu finden ist wohl auf jeden Fall manuelle Kontrolle (oder AI ) nötig.

Dazu braucht man ein automatisches Hintergrundmodell. Alle Sterne und Objekte müssen erkannt und entfernt werden. Das geht schon automatisch, selbst das alte IRIS kann das.

 

[Ehemaliges Mitglied 8776]

Hallo,
das sehe ich völlig anders. Die üblichen RAW-Converter sind für die bildmäßige Fotografie gemacht. Sie legen alle eine Gradatiosnkurve, Weißpunkt oder Schwarzpunkt und Farbbalance oder evtl. noch Schärfung mit an. Das können wir nicht gebrauchen.
Ein RAW-Converter nach fits macht eben nur das "Debayern" und das für lights nach dem Kalibrieren.Die Bilder bleiben linear.

Guter Einwand

 

[steffens]

Dazu braucht man ein automatisches Hintergrundmodell. Alle Sterne und Objekte müssen erkannt und entfernt werden. Das geht schon automatisch, selbst das alte IRIS kann das.

Ich sagte ja, in Grenzen geht sowas automatisch.
Aber bei ausgedehnten Nebelgebieten versagt das. Woran soll denn die Automatik bei nicht farbkalibrierten Stacks voller Gradienten und Nebelschwaden neutralen Hintergund erkennen?

 

[Ehemaliges Mitglied 8776]

Ja,

dann besteht die Gefahr dass das Bild unten rasiert wird. Schwierig. Allenfalls mit einem sehr knappen Differenzwert zum unteren Ende der Belichtungskurve.

CS
Jörg

 

[mlnoga]

Erik, ich komme aus einer ähnlichen Schule. Alles muss in einen Container passen, über Textdateien und Umgebungsvariablen konfigurierbar sein, in eine CI/CD-Pipeline einbindbar sein, usw. Sonst läuft es auf keiner modernen Cloud. Ich verstehe jedoch ganz klar den Punkt über Endanwender.

Carsten und Jörg, mit -starsShow stars%04d.fits kann man sich die Masken der Sternerkennung schon herausschreiben. Um mit nicht-stellaren Objekten umzugehen, würde zunächst pragmatisch auf dem Reference Frame eine Maske von Hand zeichnen. Im zweiten Schritt könnte man auch Plate Solven und die DSOs automatisch einzeichnen, nur eben als gefüllte Ellipse statt als Umrisslinie. Wenn man Zeit investiert, um das Star Alignment zum auflösungsunabhängigen Solver aufzurüsten, ginge das ggf künftig einmal auch ohne externe Software.

Wenn man es ganz präzise mag, könnte man die auf dem Reference Frame gezeichnete Maske auch zurücktransformieren in die Koordinatensysteme jedes einzelnen Lights. Die entsprechende Transformation liefert das Alignment ja bereits, und die Projektion ist schon implementiert.

Steffen, wenn Du die NEF Raws schicken kannst, mache ich das mit CFA FITS gern selbst. Flat und Bias gerne als 32 bit FITS.

 

[astrozausel]

Hallo

wollte das Programm gerade testen. Irgendwie geht das nicht auf bei mir.
Man sieht nur kurz ein Fenster das sofort wieder verschwindet.

vielleicht könnt ihr mir helfen

Gruß Dieter

 

[mlnoga]

Hallo Dieter, bitte öffne eine Kommandozeile und starte das Programm von dort. Es gibt bisher noch keine grafische Benutzeroberfläche. Vielen Dank für Dein Verständnis.

Viele Gruesse,
Markus

 

[steffens]

Session 1 von 4 (Lights, Master Bias, Master Flat), WeTransfer, 1 Woche gültig:

Session1/Lights/NGC_3185_Light_001.nef and 32 more files

33 files sent via WeTransfer, the simplest way to send your files around the world

we.tl

Session 2 von 4 (Lights, Master Flat)

Session2/Lights/NGC_3185_Light_001.nef and 36 more files

37 files sent via WeTransfer, the simplest way to send your files around the world

we.tl

Session 3 von 4 (Lights, Master Flat)

Session3/Lights/NGC_3185_Light_001.nef and 27 more files

28 files sent via WeTransfer, the simplest way to send your files around the world

we.tl

 

[steffens]

Und Session 4:

Session4/Lights/NGC_3185_Light_001.nef and 36 more files

37 files sent via WeTransfer, the simplest way to send your files around the world

we.tl

Sehr Off-Topic, aber wenn ich die Rohdaten hier schon mal hochlade - ich wäre sehr gespannt und interessiert, was andere aus diesen Daten herausholen können!
Also, wenn Ihr etwas Zeit übrig habt, tobt Euch gerne aus

Grüße,
Steffen

 

[astrozausel]

Hallo Markus

es geht nicht. Bitte erkläre genau wie man was dort eingibt.
Das Fenster für das Kommando öffnet sich... was genau gibt man da ein ?

Gruß Dieter

 

[moos]

Und Session 4:

Session4/Lights/NGC_3185_Light_001.nef and 36 more files

37 files sent via WeTransfer, the simplest way to send your files around the world

we.tl

Sehr Off-Topic, aber wenn ich die Rohdaten hier schon mal hochlade - ich wäre sehr gespannt und interessiert, was andere aus diesen Daten herausholen können!
Also, wenn Ihr etwas Zeit übrig habt, tobt Euch gerne aus

Grüße,
Steffen

Ja aber dann reduzier das doch mal auf die 36 Lights und Kalibrierdaten. Du hast uns 4x diesselben Lights darein gepackt und das ist vergeudet.

 

[steffens]

Ja aber dann reduzier das doch mal auf die 36 Lights und Kalibrierdaten. Du hast uns 4x diesselben Lights darein gepackt und das ist vergeudet.

Hm, also wenn da nicht bei dem Upload irgendwas sehr schief gegangen ist, dann ist da nichts vergeudet.
Es sind auch keine 36 Lights, sondern 130. Die waren aber zu groß, um sie mit einem Rutsch per WeTransfer zu verschicken. Also habe ich sie auf die einzelnen 4 Nächte aufgeteilt. Jeder Link enthält die Lights und ein Master-Flat für die jeweilige Aufnahme-Session einer Nacht. Der erste Link enthält zusätzlich das Master-Bias.
Es sind auch nicht 4x 36 Bilder, die Sessions haben unterschiedlich viele Bilder.

 

[mlnoga]

Steffen: Daten erhalten, danke schön. Es sind vier verschiedene Sessions mit den Kalibrierungsdateien wie von Dir beschrieben.

Dieter: Die einfachste Nutzung ist nightlight stack *.fits. Das stackt alle Fits-Dateien im aktuellen Ordner, und schreibt das Summenbild in die Datei out.fits. Die Verarbeitung kann man mit zahlreichen Schaltern verfeinern, siehe dazu die kurze Dokumentation. Wenn Du magst, kannst Du auch Beispieldateien herunterladen, z.b. den Bubble-Nebel.

All: Mein erster Versuch der Background Extraction. Idee ist, jede Gitterzelle durch eine lineare Funktion ax+by+c anzunähern, und diese dann vom Originalbild abzuziehen. In einigen Zellen oben links tut das schon ganz gut. In den meisten Zellen erzeugt es jedoch eher abstrakte Kunst. Mal sehen, woran das liegt.

 

[moos]

Hm, also wenn da nicht bei dem Upload irgendwas sehr schief gegangen ist, dann ist da nichts vergeudet.
Es sind auch keine 36 Lights, sondern 130. Die waren aber zu groß, um sie mit einem Rutsch per WeTransfer zu verschicken. Also habe ich sie auf die einzelnen 4 Nächte aufgeteilt. Jeder Link enthält die Lights und ein Master-Flat für die jeweilige Aufnahme-Session einer Nacht. Der erste Link enthält zusätzlich das Master-Bias.
Es sind auch nicht 4x 36 Bilder, die Sessions haben unterschiedlich viele Bilder.

Hi steffens, ja nun habe ich verstanden. Ich war nur verwundert, weil die lights der sessions auch die gleichen Dateinamen haben. Aber so macht es Sinn. Alles klar.

 

[steffens]

@mlnoga : Bzgl. Background-Extraction kannst Du Dich ja evtl. auch von der Implementierung in Siril inspirieren lassen, siehe background_extraction.c

 

[moos]

Hi steffens,
ich schaffe es nicht in akzeptabler Zeit Deine Daten zu verarbeiten. Ich habe die raws mit IRIS nach CFA-fits konvertiert.
Dabei habe ich zwei Schwierigkeiten,
1.) ich kann die BAYER-Maske nur durch Probieren nicht zweifelsfrei feststellen. Dazu müsste ich wissen, welche Farbe der Hintergrund der Bilder in etwa hat. Aber das ist mir viel zu aufwändig, zumal meine Versuche durch den Masterflat völlig falsche Farben hatten.
und 2.) der Masterflat hat erstens eine Spieglung, denn die Donuts entstehen verstärkt auf den gegenüberliegenden Seiten und die Bayermaske der flats scheint anders zu sein.
Es liegt an der Mischung aus Siril ? und IRIS. IRIS spiegelt die Bilder oder liest sie zumindest in anderer Folge ein.
Ich hätte auch gerne ein "normales Bild " durchgejagt und dann die Farben zugeordnet, aber das kann nightlight nicht.
Ich gebe es auf und versuche erstmal eigne Daten.