Neuer Stacker & Kombinierer

  • Ersteller des Themas Ersteller des Themas mlnoga
  • Erstellungsdatum Erstellungsdatum
Status
Es sind keine weiteren Antworten möglich.
mlnoga

mlnoga

Aktives Mitglied
Hallo,

ich arbeite aktuell an einem neuen Stacker. Er soll schnell und automatisch ein 3/4 fertiges Bild erstellen. Der Stacker erreicht für die Vollverarbeitung eines Kanals auf meinem kleinen Testrechner Durchsätze um eine Aufnahme pro Sekunde. Vollverarbeitung eines Kanals heisst Darks, Flats, kosmetische Korrektur, Sternerkennung, Alignment, Normalisierung und Stacking. Die verwendeten Rohaufnahmen haben 20 Megapixel bzw. 40 MB. Sie werden auf einem Mini-PC mit AMD Ryzen 5 3400G, 16 GB Hauptspeicher und SSD verarbeitet. Zum Beispiel laufen 222 Luminanz-Frames von M101, also 8.7 GB Rohdaten, in 3 min 52 s durch.

Hat jemand von Euch Interesse, das mal auszuprobieren?

Der Stacker hat folgende Eigenschaften:
  • Hohe Qualität durch 32 Bit Fließkomma-Verarbeitung
  • Hohe Geschwindigkeit durch In-Memory Architektur mit randomisiertem Batching ohne temporäre Dateien, Ausnutzung von Multicore und selektive AVX2 Optimierungen
  • Darks, Flats und kosmetische Korrektur von heißen/kalten Pixeln
  • Sternerkennung und Multi-Star Alignment mit Subpixel-Genauigkeit
  • Normalisierung der Bilder mit schneller und robuste Statistik (Mean/StdDev, Median/MAD, clipped median/iterative Qn)
  • Zahlreiche Stacking-Algorithmen (median, mean, sigma, winsorized sigma, linear fit; optional mit Gewichtung)
  • Goal Seeking, um einen gewünschten Prozentsatz an High/Low-Rejections beim Stacking zu erreichen (dauert dann etwas länger)
  • RGB Kombination sowie LRGB Kombination im CIE LCH Farbraum
  • Automatisches Stretching gemäß Histogramm
  • Automatische Wahl von Schwarzpunkt gemäß Histogrammpeak und Weißpunkt gemäß mittlerer Sternenfarbe
  • Operatoren zur Bildoptimierung: Gamma, selektives Gamma rechts des Histogramm-Peaks, prozentualer Schwarz-/Weißpunkt, CIE LCH Chroma-Anpassung (perzeptive Sättigung), selektive Chroma-Anpassung nach Farbton (z.B. um Violett zu entsättigen), selektive Verschiebung von Farbtönen (z.B. grün nach gelb für die Hubble-Palette), SCNR (zum Entfernen von Grünstich)
  • Läuft auf x86-64bit unter Windows, Mac und Linux
Er hat natürlich auch ein paar Einschränkungen:
  • Liest nur Mono-FITS (noch kein Debayering, kein Camera RAW Input für DSLRs)
  • Keine Background Extraction (die Flats müssen reichen)
  • Bisher nur für DSOs (kein Planetary Alignment, keine Derotation)
  • Kommandozeile, kein GUI (am besten aus einem Makefile aufrufen)
Viele Grüsse,
Markus
 
Hallo Markus,

Das Projekt sieht wirklich sehr vielversprechend aus!
Ich bin kein Go-Experte, aber bei einem kurzen Blick in den Sourcecode scheint alles sehr sauber und gut strukturiert zu sein.
Schade, dass die Einschränkungen für mich zur Zeit leider ein K.O.-Kriterium darstellen, da ich mit DSLR-Bildern arbeite, und Flats allein nie reichen :(

Planst Du auch ein UI, wenn der Core mal steht?

Grüße,
Steffen
 
Hallo Markus,

Dein neuer DSO-Stacker ist guter Ansatz. Für Planeten-Stacking gibt es ja hier schon ein eigenes Projekt samt eigenem Forum, deswegen halt ich es nicht für nötig, dass zu implementieren.

Meine Wunschliste wäre:
- eine ARM-Untertützung für den RPI4, auch wenn die AVX2-Unterstützung dann wegfällt.
- mehr Schemata für das Kombinieren LLRGB, HaRGB, ... bzw. eine Angabe über eine freie Formel, wie die Stacks kombiniert werden sollen.

Nightlight könnte dann auf einem RPi4 in aller Ruhe nach der Aufnahmesession das Preprocessing durchführen (mit SIRIL geht das schon) und ich müsste nicht meine wertvolle Freizeit vor dem DeepSkyStacker versitzen.

Ich werde die Software gerne mal an eigenem Material testen. Der Code sieht super strukturiert aus, auch wenn ich mich mit GO noch nicht näher beafasst habe.

Grüße,
Erik
 
Vielen Dank, Steffen. Was für eine DSLR nutzt du denn? Canon CR2 ist ja leidlich gut dokumentiert.

Erik, Arm für den PI4 sollte nicht schwer sein, es geht um weniger als eine Handvoll Funktionen.

Mehr Schemata gehen schon jetzt. LRGB nutzt die vier übergebenen Bilder als L, R, G und B Kanäle. Wenn Du Ha, L, R, G, B übergibt, wird also HaRGB erzeugt. Im Beispiel-Makefile sollte dafür auch schon eine Zeile existieren.

LLRGB habe ich noch nicht gemacht. Was ist das für ein Prozess?

Markus
 
Hallo Markus,

PI4-Unterstützung wäre super. Danke.

Bei LLRGB wird aus den RGB-Daten die Luminanz extrahiert und dann zu den L-Daten dazu addiert. Falls die RGB-Daten genug Qualität haben, kann damit die SNR der L-Daten verbessert werden.
Aber Dein Quellcode ist leicht lesbar und gut dokumentiert. So etwas ist leicht einfügbar.

Grüße

Erik
 
Alles klar. Ich nehme LLRGB dann als "good First issue" für Contributors auf.

Braucht der Pi4 64-bit oder 32-bit ARM?
 
Der Pi4 hat noch 32-bit, zumindest beim Kernbetriebsystem Raspian. Es gibt aber auch schon 64-bit LINUX dafür und bei Raspbian eines erste 64bit-Testversion. Mit einer 32-bit-Version wäre man universeller. Wäre die 64bit essentiell schneller ?

Grüße

Erik
 
Wenn man nicht speziell dafür optimiert, nein. Die Bilddaten sind ja float32. Auf einem 32 Bit System verändert sich jedoch die Wortbreite des Typs int, was unerwünschte Effekte haben kann. Sollten aber nicht viele Stellen sein, hauptsächlich Schleifenzähler. Überwiegend habe ich ohnehin explizit int32 oder int64 geschrieben.

Was ist mit Big endian/little endian? Ggf muss man sich FITS I/O nochmal daraufhin ansehen.

M
 
Fuer den RasPi bin ich zuversichtlich. Ich setze als Issue #4 um. Endianness ist glücklicherweise wie auf x86. Habe ein Build-Ziel nightlight_linux_arm7 eingeführt.

Für Basic Stats, Variance und Noise Estimation waren auskommentierte klassische Implementierungen schon vorhanden. Die sind bereits in eine saubere Dateistruktur mit Build Tags überführt: xxx.go für gemeinsame Funktionen, xxx_amd64.go für x86 Stubs, xxx_amd64.s für x86 Assembler und xxx_noarch.go für andere Plattformen. Habe eine CPUID-Bibliothek gefunden, die sowohl für amd64 als auch für ARM funktioniert. Schöner Nebeneffekt: Fallback auf eine klassische Umsetzung für x86 CPUs ohne AVX2.

Noch offen: Median3x3, sowie eventuelle int-Problematik bei Umstellung auf 32 bit.
 
Steffen, Debayern würde ich vor Raw angehen (Issue #5). Ist ja eine Umrechnung im Umkreis von ein paar Pixeln. Das braucht man auch für OSC Astrokameras, die FITS Daten liefern.

Leider habe ich nur Mono-Kameras. Kannst Du vielleicht CFA Testdaten als FITS hochladen? Z.B auf Github wie dieses Beispiel? Das wäre grosse Klasse.

Markus
 
Hi Markus,

Das kann ich gerne machen, allerdings ist ein CFA-Fit von meiner Kamera 48,3MB groß!
Wie viele bräuchtest Du? Nur Lights, oder auch Calibration-Frames? Wobei ich da immer nur die Masters aufhebe, aber Bias kann ich schnell machen und die Flats müssten ja für Testzwecke nicht perfekt passen.

Steffen
 
Steffen, es wäre auch gut zu wissen, was für eine Bayermatrix die Kamera hat (RGGB, oder ...).
Danke, Markus
 
Hallo Markus,

Hier (WeTransfer) habe ich mal 10 Lights hochgeladen.
Die Bayermatrix ist RGGB, steht auch so im FITS Header.
Die RAWs wurden mit Siril konvertiert. Das schreibt die FITS wenn ich das richtig verstehe in bottom-up-order, also von unten nach oben. Das ist beim Debayern wichtig.

Grüße,
Steffen
 
Erik, ich habe ein erstes Release v0.1.1 auf dem Raspberry Pi zum Laufen bekommen. Auf meinem Pi3 mit 1 GB macht es jedoch kaum Spass, weil bei mehr Bildern schnell die Fehlermeldung "out of memory" auftritt. Magst Du nighlight_linux_arm7 mal auf Deinem Pi4 mit mehr Speicher versuchen?

Steffen, vielen Dank. Ich habe die Bilder heruntergeladen und kann sie öffnen. In Zwischenzeit hat mir ein weiteres Forumsmitglied Quellcode für Debayering in C in Aussicht gestellt. Mal sehen, vielleicht kann man den ja nach Go portieren.

Viele Grüsse,
Markus
 
Zitat von mlnoga:
Steffen, es wäre auch gut zu wissen, was für eine Bayermatrix die Kamera hat (RGGB, oder ...).
Klicke in dieses Feld, um es in vollständiger Größe anzuzeigen.
Ansich schon, aber immer in jedem Fall zu verifizieren. Es kommt auf die Speicherereihenfolge beim Exportprogramm und die Einlesereihenfolge an. Am einfachsten ist es, den Algorithmus der Farbinterpolation innerhalb der Software auf z.B. RGGB festzulegen. Man kann jede Bayermaske auf dieses Muster bringen.
Beispiel: Eine GRBG Folge. Man schneidet die erste Spalte (= links) ab und hat einen RGGB. Oder: Eine GBRG. Man schneidet die oberste Zeile ab. Deshalb spielt es keine Rolle, welche Bayermaske der Sensor hat.
Wichtiger sind die Fragen, wann debayert wird, wann die Farben RGB und g gewichtet werden und dass beim Flatfielding keine Farbstiche hineinkommen. Ein skyflat als Divisor macht ordentlich rot ;-). Außerdem der Algorithmus ansich: Ein einfacher bilinearer kann nachträglich gut geschärft werden und reduziert das Farbrauschen, ein kontrastreicher starker bringt Rauschen hinein.
 
Hallo,

danke für den Raspi Build. Ich werde das am Wochenende mal auf meinem RPi mit 4GB testen. Seit neuestem gibt es den auch mit 8GB RAM. Das sollte also kein Problem darstellen.
Ich werde deine M42 Testdaten verwenden.

Grüße
Erik
 
Hallo,

ich habe den Build gerade auf dem RPi4 laufen lassen, es steigt aber mit einem Out of Memory aus.

Hier der relevante Teil des Logs:

>>>>>>>>
Estimating memory needs for 51 images from L/2020-01-21_21-29-08_Great Orion Nebula_L_G50.00_O8.00_-20.00_60.00s_1.fits:
Image has 5496x3672 pixels (19.2 MPixels) and takes 76 MB in-memory as floating point.
Physical memory is 3854 MB, -stMemory limit for stacking is 3083 MB.
Maximum batch size is 40 images which take -1016 MB for stacking.
Using 2 batch(es) of 26 images each, which needs 2001 MB
Randomizing input files across batches...

Starting batch 0 of 26 images: [2 3 4 6 9 11 15 18 19 20 21 24 26 27 28 32 35 36 37 41 43 45 47 48 49 50]...

Preprocessing 26 frames with dark=1 flat=1 binning=0 normRange=0 bpSigLow=3.00 bpSigHigh=5.00 starSig=10.00 starBpSig=5.00 starRadius=16:
.......
32: Stars 125 HFR 2.95 Min 982.042 Max 67064.3 Mean 1552.96 StdDev 1056.6 Location 1461.83 Scale 129.165 Noise 109.8
35: Removed 22906 bad pixels (0.11%) with sigma low=3.00 high=5.00
runtime: out of memory: cannot allocate 83886080-byte block (2860023808 in use)
fatal error: out of memory
>>>>>>>>>>>>>>

Kannst Du damit etwas anfangen ?

Grüße
Erik
 
Ich glaube, die Berechnung des Speicherplatzes ist noch nicht genau genug. Neben dem Platz für die Lights wird ja auch noch Platz für Dark, Flat, Stack usw benötigt. Ich passe die Formel an. Magst du in Zwischenzeit mal versuchen, den genutzten Speicher mit -stMemory 2000 auf 2 GB zu begrenzen?
Markus
 
Ich werde es heute Abend einmal versuchen.
Aber wenn der Stacker generell Alles im Speicher vorhält, kommt man mit größeren Datensätzen auch mit 16GB schnell in Probleme. Mit Kurzzeitbelichtung an einer CMOS-Kamera hat man schnell mal einige hundert Bilder zusammen.

Grüße
Erik
 
Erik, der Stacker stellt aus den Bildern randomisierte Batches zusammen, die jeweils in den Hauptspeicher passen sollten. So kann er insgesamt auch erheblich groessere Datensatze verarbeiten.

Das Problem ist die berechnete Groesse dieser Batches. Die Formel orientiert sich bisher am physisch vorhandenen Speicher, nicht am freien Speicher. Und sie beruecksichtigt nur die Lights des aktuellen Batches. Es braucht jedoch auch Platz fuer das Dark, fuer das Flat, fuer ein temporaeres Bild je CPU-Thread waehrend der Vorverarbeitung, sowie fuer die Summenbilder der Batches und fuer den Gesamtstack. Die sind in der Formel nicht beruecksichtigt. Auf dem PC mit Swapfile war das bisher kein Problem; notfalls lagert das Betriebssystem ja einige selten verwendete Seiten aus und schiebt den parallel geoeffneten Webbrowser aus dem Hauptspeicher. Bei Geraeten ohne Swapfile wie dem RasPi ist der Hauptspeicher jedoch eine harte Grenze, so dass Probleme wie das gesehene auftreten koennen.

Dein RasPi ist ausgestiegen, als der Stacker schon 2860 MB alloziert hatte, und 80 MB fuer das naechste Bild anfordern wollte. D.h., er braucht satte 1.2 GB fuer die laufende Basisumgebung. Versuch bitte einmal, den Speicherbedarf mit -stMemory 2000 auf 2000 MB zu beschraenken; oder ggf 1800, 1600 ... Ich wruerde gerne verstehen, ob der Stacker auf dem Pi4 grundsaetzlich durchlaeuft und akzeptable Performance liefert, bevor ich ins Speichertuning einsteige.

Ich habe fuer diesen Crash Issue 7 angelegt.

Vielen Dank,
Markus
 
Hallo Markus,

ich probiere -stMemory 2000 heute Abend aus. Eigentlich sah der Durchlauf bis zum Abbruch recht flott aus. Ich bin da optimistisch, dass es komplett durchläuft. Der Raspi hat duchaus ein Swapfile, aber das ist zum Schutz der SD-Karte bei den älteren 1GB-Raspis meist recht klein eingestellt (100MB). Das könnte ich versuchsweise größer machen.

Grüße
Erik
 
Hallo Markus,

ich habe alle -stMemory-Größen von 2000 bis 500 runter getestet, aber es kommt immer zu einem Speicherüberlauf bei > 3GB die ein Prozess auf dem Raspi zur Verfügung hat. Ein größeres Swapfile hat auch nichts gebracht. Bei 500 nutzt er nur Batches zu 5-6 Bildern, aber das ändert an der Speichernutzung anscheinend nichts.

Grüße

Erik
 
Danke für Deine Ergebnisse und für Deine Geduld, Erik. Ich gehe der Sache jetzt mit dem Speicherprofiler auf den Grund. Eine Teilursache habe ich schon gefunden: die Standardbibliothek binary zum Einlesen der Pixelwerte führt offenbar ein Eigenleben und alloziert nochmal 20% zusätzlichen Speicher.
 
Zuletzt bearbeitet:
Kein Problem, dafür ist das Testen ja da. Ich stehe für weitere Tests gerne zur Verfügung.

Grüße
Erik
 
Hallo Marcus,

Kommandozeile ist ja nun nicht wirklich Benutzerfreundlich. Planst du eine gui und falls ja, bis wann?

viele Grüsse
matthias
 
Hallo Markus,

nachdem sich meine SD-Karte am RPI4 vermutlich mehrfach in den Kopf geschossen hatte (Hitzeproblem), konnte nach dem Rückspielen des Backups endlich deine aktuelles Release 0.1.2 testen.

Bei -stMemory 1200 lief der M42-Datensatz in exakt 6 min erfolgreich durch. Mein 3 GHz i5 (2C/4T) braucht dafür 1,5 min. Bei weniger Speicher brach das Programm sehr früh ab, bei mehr war der Speicheroverflow wieder da.

Aber es läuft erst einmal. Danke für Deine Anpassungen.

Grüße

Erik
 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben