Neuer Stacker & Kombinierer

Status
Es sind keine weiteren Antworten möglich.
Ah, wie dumm von mir _jungeschlagen:
Nach einem git clone funktioniert das Bauen.
Die github-URL in dem "go get" Aufruf hatte irgendwie suggeriert, dass "go get" selbstständig clonen würde. Das hat man davon, wenn man ohne zu Denken Copy-and-Paste einsetzt.

Mit dem golang 1.11 von Debian Stable geht es nicht, aber mit 1.14 aus den Backports war der Build erfolgreich.
 
Zuletzt bearbeitet:
Klasse, Steffen. Der Umfang deiner Arp-Rohdaten als FITS war zunächst zu groß für GitHub. Zum Glück halbiert gzip die Größe verlustfrei. Wenn eine FITS Datei in .gz oder .gzip endet, wird sie jetzt beim Lesen und Schreiben automatisch entpackt und gepackt. git pull und Release 0.1.9 bringen diese Neuerung.

Damit steht auch das Arp 316 Repository mit Deinen Daten. Bitte schau mal, ob das für Dich so in Ordnung ist, und schaue auch im README.md, welche der noch offenen Angaben Du ggf. noch ergänzen möchtest.

make stackt zuerst innerhalb der Unterverzeichnisse je Session, und dann insgesamt. Ich habe die Flats letztlich rausgenommen. Sie schaden eher durch neue Geisterbilder, insbesondere in Session 4. Damit habe ich bei meinen Aufnahmen auch lange gekämpft. Die Anschaffung einer guten Flatbox hat sich für mich sehr gelohnt.
 
Ich habe jetzt auch noch ein bisschen herumgebastelt an meiner Software. Was mich schon lange geärgert hat, war der grüne Schleicher im Bild der ASI1600MC. Mal abgesehen, dass es sehr lästig und aufwendig ist, in PI das DBE zu benuzten, liefert es auch keine guten Ergebnisse. Vielleicht muß man da mehr üben oder irgendwelche Tricks anwenden.

Jedenfalls habe ich mir nun ein Tool geschrieben, was den Hintergrund vollautomatisch abläuft, d.h. ohne weitere Parameter eingeben zu müssen. Zudem braucht es nur ca. 8 sec. Schnelligkeit ist bei mir auch immer ein Thema.

NGC4274_Dark_Flat_RGB_Align_RunMean.gif


Das sieht schon vesser aus, der Schleier ist weg. Damit bin ich erst mal zufrieden. Und habe bei der Gelegenheit glich nochmal eine Weiterbearbeitung des Bildes vorgenommen:

NGC4274_Dark_Flat_RGB_Align_RunMean_BG_gray_LRGB_usm.png


So ganz bin ich mit dem Hintergrundrauschen noch nicht zufrieden. Jedenfalls ist es heute dunkel, dass ich das am Bildschirm beurteilen kann. Es sind insgesamt 78 Einzelbilder a 300s in dieses Bild gegangen. Na, ja für f/10 ist die Galaxie ein bisschen schwierig.
 
So ganz bin ich mit dem Hintergrundrauschen noch nicht zufrieden. Jedenfalls ist es heute dunkel, dass ich das am Bildschirm beurteilen kann. Es sind insgesamt 78 Einzelbilder a 300s in dieses Bild gegangen. Na, ja für f/10 ist die Galaxie ein bisschen schwierig.
Hi,
das untere Bild sieht aber komisch aus. Im Histogramm sind die drei Farbkanäle identisch. Der Hintergrund ist komplett ohne Farbe, soweit ich sehen konnte, sind alle Pixel im Hintergrund grau. Es gibt auch mindestens 3 senkrechte Streifen im Bild. Ist deine Blockgröße des Algorithmus vielleicht ein Vielfaches davon?
Der Grüne Hintergrund entsteht immer dann, wenn man die Farbbalance anwendet und der Hintergrund noch nicht abgezogen wurde. Ist m.E ein Verarbeitungsfehler beim Bildkalibrieren vor dem Stacken.
Man kann dann recht einfach in PS den Hintergrund markieren, kopieren, glätten und vom Bild abziehen.
Du quälst das Bild schon ein wenig.
 
Hi,
das untere Bild sieht aber komisch aus. Im Histogramm sind die drei Farbkanäle identisch. Der Hintergrund ist komplett ohne Farbe, soweit ich sehen konnte, sind alle Pixel im Hintergrund grau. Es gibt auch mindestens 3 senkrechte Streifen im Bild. Ist deine Blockgröße des Algorithmus vielleicht ein Vielfaches davon?

Das stimmt. Ich setzte das Hintergrundrauschen in Grauwerte um, sonst ist der Hintergrund zu bunt-meliert. Mir gefällt das so besser. Alllerdings ist das auch ein schwieriges Bild, weil das Objekt zu schwach ist.

Die Streifen sind vorher schon im Bild. Das war nach der Behandlung mit nightlight genau so. Vermutlich ist das Dark "gealtert". Ich muß mal wieder neue Darks machen, um das zu testen. Mein Hintergrund-Algorithmus kann keine Streifen erzeugen.

Ich habe die beiden Bilder der Animation in PI ohne Farbkoppelung mit der ScreenTransferFunction erzeugt, um so den Farbkontrast zwischen den beiden Bildern zu erhöhen. Die STF hat also die Bilder manipuliert. Das war Absicht. Weil es eben ein schwieriges Bild ist, eignet es sich gut zum Testen.

Da ich nur auf Linux unterwegs bin, nuzte ich PhotoShop nicht. Zwnagsläufig habe ich aber eine kleine ZBox Nano, die ich draußen mit meiner Montierung und Kameras usw verbinde und via TeamViewer aufs Notebook bringe.
 
Bayer-bewusste kosmetische Korrektur in Nightlight ist fertig und in Release v0.2 oder über git pull verfügbar.

Peter, nochmal vielen Dank für Deine Daten. Damit sieht NGC4274 so aus (alles Nightlight, letzte Kurve in Gimp). Wenn OK für Dich, stelle ich auf GitHub die Rohdaten und das Makefile ein.

NGC4274_RGB_Curves_1920.jpg
 
Da kann man auch den Hintergrund auswählen und die Farbsättigung leicht reduzieren. ;-)
Statt PS gehen ja auch viele andere Programme. Gimp unter Linux.

Es gibt eben mehrere Wege zum Ziel. Ich bevorzuge meinen. Es gibt auch eine Lightroom Version für Linux, die nennt sich Darktable und ist kostenlos. Da gibt es auch für die Schieberegler-Fetischisten viele Möglichkeiten, das Bild zu bearbeiten. Allerdings ist das Ergebnis dann immer ein Unikat. Das ist nicht mehr reproduzierbar. Es sein denn, man schreibt alle Einstellungen akribisch mit . Das ist der große Nachteil von fertigen Programmen. Die loggen nicht mit. Wenn man selbst programmiert, kann man auch das leisten.


Bayer-bewusste kosmetische Korrektur in Nightlight ist fertig und in Release v0.2 oder über git pull verfügbar.

Peter, nochmal vielen Dank für Deine Daten. Damit sieht NGC4274 so aus (alles Nightlight, letzte Kurve in Gimp). Wenn OK für Dich, stelle ich auf GitHub die Rohdaten und das Makefile ein.

Hallo Markus,

das sieht in der Tat gut aus. Ich werde mir Deine neue Version(en) weiter herunterladen und testen. Natürlich hast Du mein OK für die Freigabe der Daten.

Allerdings fehlt die Farbe noch. Ich hatte die Serie im April aufgenommen und auch schon mal hier präsentiert. Damals habe ich anderen Farben herausbekommen, als in der oben gezeigten Neubearbeitung. Die Farbgebung vom April gefällt mir besser. Leider scheint die Galaxie sehr selten abgelichtet zu werden, so dass der Vergleich fehlt. Die Farbe ist aber sowieso Ermessenssache.

Ich finde so eine Scripting-Lösungen, wie sie nightlight bietet, besser, weil ich mir die Parameter alle in ein Script schreiben kann und die ganze Sache damit reproduzierbar bleibt. Über die Schnelligkeit hatte ich mich ja füher schon einmal ausgelassen. Die ist nicht zu überbieten. Ich reduziere meine Bilder immer gleich am nächsten Morgen nach der Beobachtung bei zwei Tassen Kaffe. Nach der zweiten will ich das Bild fertig haben. Da bin ich mit nightlight auf einem guten Weg.

Gruß,
Peter
 
Noch eine kleine Bitte: Vielleich solltest Du ein --Version Keyword einführen, damit man den Überblick behält, welche Version gerade installiert ist.
 
Jetzt habe ich noch ein bisschen Farbe aus dem Bild gequetscht:

NGC4274_Dark_Flat_RGB_Align_RunMean_BG_pLRGB2_gray_usm.png


Das Rauschen ist nun auch moderater, indem ich die Helligkeitskurve konkav verbogen habe. Das hatte ich bisher anders herum konvex verbogen. Den Hintergrund habee ich trotzdem sichtbar grau gemacht, damit man die schwachen Ausläufer der Galaxie noch erkennen kann. Und ein bisschen Unsharp-Masking in PI.
 
Zuletzt bearbeitet:
Hallo Peter, vielen Dank für die anregende private Diskussion. Ich habe Deine Ideen für die Hintergrundextraktion mit drei wesentlichen Änderungen übernommen und in Go umgesetzt. Erstens verwende ich statt eines globalen Hintergrundmittels das lokale Mittel im jeweiligen Gitterkästchen, um besser mit fehlenden Flats umgehen zu können. Das erfordert zweitens einen Parameter, um bei großflächigen Objekten zu helle Gitterkästchen auszublenden. Und drittens habe ich Artefakte beseitigt, die auftreten wenn die Bildgröße kein ganzzahliges Vielfaches der Gittergröße ist. Dazu arbeite ich mit einer Fliesskomma-Gittergröße und lokaler Rundung.

Release 0.2.1 verfügt damit über eine leistungsfähige Hintergrundextraktion, die durch drei Parameter gesteuert wird. -backGrid setzt die Gittergröße, z.B. 128. -backSigma setzt den Schwellwert für das Ausblenden von Vordergrundobjekten, z.B. 1.5. Und -backClip legt fest, wieviele der hellsten Gitterzellen durch einen lokalen Medianfilter ersetzt werden.

Zusätzlich habe ich den Sättigungs- bzw. Chroma-Boost ausgebaut. Bisher hat -chroma die Sättigung mit einem Faktor multipliziert. Das erzielt für bereits halbwegs gesättigte Bilder gute Ergebnisse, ist jedoch für blasse Bilder nicht optimal. Daher gibt es jetzt -chromaMul und -chromaAdd für multiplikative und additive Korrektur. Ich habe auch einen Schwellwert -chromaSigma eingeführt, um Pixel auszublenden, die nicht mindestens N Standardabweichungen über dem Hintergrundmittel liegen.

Das von Dir angeregte Kommando version ist ebenfalls umgesetzt.

Für Dein Beispielbild kommt damit folgende Sicht heraus. Wesentliche Parameter siehe unten.

NGC4274_RGB_1920.jpg


Code:
RGB=-cfa GRBG -backGrid 256 -backClip 8
COMBINE=-autoScale 0.2 -ppGamma 2.7 -ppSigma 1.7 -chromaAdd 11 -chromaSigma 3.0 -scnr 0.5 -scaleBlack 3.5
 
Hallo Markus,

das sieht doch schon sehr gut aus. Ich habe mir die neuste Version heruntergeladen und ausprobiert.
Ich habe mich seit Anfang der Woche in GO eingearbeitet und schon ein paar Programm erstellt. Im Vergleich mit Python ist das natürlich mit sehr viel mehr Tipp-Arbeit verbunden, weil GO rudimentärer ist als Python. Außerdem gibt es da eine Menge Bibliotheken, die ich bei GO vermisse. Da muß ich sehr viel selbst entwicken und programmieren. Aber mit der Zeit wird das sich noch was. Selbst die fitsio Library mußte ich erst patchen, um 3D Bilder (Farbbilder) herausschreiben zu können.

Jetzt habe ich noch ein paar Wünsche an Dein Programm, damit ich meine Datenauswertung fast vollkommen mit nightlight ausführen kann. Einmal wäre das, die Hintergrund zu neutralisieren. Eine farbiges Hintergrundrauschen braucht kein Mensch.

NGC4274_gray_test.png

Mit einfachen Mitteln kann man den Hintergrund grau setzen, ohne die astronomischen Signal davon in Mitleidenschaft zu ziehen. Ich habe zu Domozwecken die Sättigung hochgezogen, damit man den Übergang besser sieht. Das ist das Ergebnis der Default-Einstellung. Das GO Programm dazu habe ich Dir zugeschickt.

Eine andere Sache ware ein "Unsharp Masking". Das habe ich schon mal vor langer Zeit als C-Programm geschieben, das brauche ich nur noch auf GO zu übersetzen. Das werde ich nächste Woche angehen. Das ist natürlich ein bisschen trickreich, weil man noch eine Schwelle angeben muß, ab der man die Schärfung anwendet. Das muß man dann immer erst ausprobieren, mit welcher Maske (Schwelle) man für das einzelen Bild die besten Ergebnisse erzielt. Rauschen zu schärfen ist eher kontraproduktiv. ;)

Gruß,
Peter
 
Klasse Peter, ich schaue mal, wie sich das integrieren lässt.

Mein Ansatz war bisher, die Schärfe bei der Bilderfassung über Motorfokus auszureizen. Aber vielleicht geht in Software noch mehr. Unsharp klingt daher interessant.

Oder vielleicht Deconvolution? Die Sternerkennung könnte man ja benutzen, um die point spread function (PSF) der Optik anzunähern.
 
Eine gute Fokusierung ist immer Voraussetzung für gute Bildverarbeitung. Aber das Seeing spielt noch eine Rolle dabei. Dadurch werden Strukturen verwaschen. Die kann man mit Software aber wieder herausholen, in vielen Fällen.

Ja, direkte Deconvolution ist auch möglich, aber zu komplex, wie ich finde. Da muß man im Vorfeld zuviel wissen über das Bild. Unsharp Masking benutzt zwar (in meiner Ausarbeitung) einen 3x3 Kernel zum Falten (convolution, deshalb der Name Unsharp Masking), verstärkt aber die Differenz zum Original, um es mal sehr einfach auszudrücken. Da gibt es weniger einzustellenden, kritische Parameter, und das Ergebnis ist auch nicht schlechter.

Anwendersoftware soll so einfach wie möglich sein. Einfach zu bedienen, schnell in der Ausführung und mit möglichst vielen Default-Einstellungen, die schon ein gutes Resultat bietet. Wenn man dann noch mehr herausholen will, kann man die Parameter verändern, und sehen, was geht. Dazu muß sich der Anwender aber sehr gut auskennen mit den dahinter steckenen Algorithmen. Daran hapert es aber meistens. Oft geht das dann mit Trial and Error.
 
Gut. Dann lass uns doch Unsharp Masking probieren. Ein 3x3 Kernel bietet sich auch gut für AVX2 an. Sag Bescheid, wenn Du eine erste lauffähige Version hast!
 
Hallo Peter, vielen Dank für Deine Untersuchungen. Ich habe die Neutralisierung von Hintergrundfarben in Release v0.2.2 eingebaut. Mit -neutSigmaLow und -neutSigmaHigh hat sie zwei Parameter: eine untere und eine obere Schranke in Standardabweichungen über dem Hintergrundmittel. Pixel mit Helligkeit unterhalb der unteren Schranke werden vollständig entsättigt, Pixel oberhalb der oberen Schranke behalten ihre volle Farbigkeit, dazwischen wird linear interpoliert. Ich verwende dafür wieder eine Wandlung des Bildes in den CIE LCH-Farbraum, der Luminanz, Farbsättigung(Chroma) und Farbton(Hue) schön herausarbeitet.

Ein kleiner Wermutstropfen bleibt, wenn man selektive Streckung über -ppGamma verwendet: die standardmäßige Hintergrunderkennung ist so sensitiv, dass sie selektiv gestreckte Pixel dann als Teil des Vordergrunds erkennt. Für -neutSigmaLow muss man dann teils absurd hohe Werte von 10, 15 oder gar 20 angeben. Eine visuelle Prüfung des Histogramms in Gimp zeigt jedoch, dass der Hintergrundpeak tatsächlich so schmal ist.
 
Das habe ich noch nicht ganz verstanden. Muß man denn die beiden Schwellen nahe Sigma angeben, oder wird das automatisch vorgenommen? Auf jeden Fall ist das eine gute Implementation. Das Grauwertesetzen mach ich sowie so nur ganz zum Schluß, aber vor dem Schärfen.

Wo wir gerade beim Sigma, also beim Rauschen, sind: Ich habe in meinem Programm seit neustem auch eine "photometrische" Kalibration eingebaut. Das kann man sogar nur über das Rauschen machen. Eine Kalibration sollte ja auch unabhängig vom astronomischen Signal sein, damit man es eichen kann.

Wenn man eine Serie von Bilder mit Dark und Flat kalibriert, sind die Farben im Endbild erst einmal undefiniert. Dann kann man am besten am Rauschdiagramm erkennen:

Screenshot_20200720_175805.png

Die drei Farben sind im Rauschhistogramm zumindest am linken Teil der Gaußkurven, deren Maximum und Halbwertsbreiten aber von einander verschieden sind. Im Bild macht sich das als einfarbiger Hintergrund bemerkbar.

Screenshot_20200720_184440.png

Jetzt kann man die Maxima durch verschieben der Offsets alle übereinanderlegen. Das Bild erscheint nun im Hintergrund eher neutral, aber das astronomische Objekt möglicherweise farbig. Eine Gaußkruve ist definiert durch Offset und Halbwertsbreite.

Screenshot_20200720_182932.png

Normiert man diese Kurven über die Halbwertsbreite, liegen die Kurven (fast) Deckungsgleich. Verarbeitet man diese Bild aber weiter und verstärkt seine Farbigkeit, kommt aber sowas heraus:

Screenshot_20200720_183157.png

Neongrün, würde man sagen. So sieht keine Galaxie aus. Die Farbe Grün ist eher selten am Himmel. Das iiegt nun daran, dass das Chip in der Kamera nicht konstante Empfindlichkeit über das Farbspektrum hat. Dem muß man Rechnung tragen. Am einfachsten kann man eine Farbkalibrierung über das Tool "PhotometricColorCalibration" in PixInsight PI realisieren. Schaut man sich das Histogramm in PI im Anschluß an diese Prozedur an, sind die Maxima der Kurven nicht mehr identisch hoch:

Screenshot_20200720_190425.png

Vergleich man die Maxima, erhält man die Empfindlichkeiten für das Chip in den drei Farben. ich habe für Rot 0.75, für Grün 1.00 und für Blau 0.55 herausgefunden und fest verdrahtet, weil die Verhältnisse alleine vom Chip abhängen. Mit diesen Werten erhalte ich bei gleicher Anwendung der Programme, mit Anwendung dieser Konstanten, dieses Bild:

Screenshot_20200720_183257.png

damit bin ich zufrieden. Die Farben scheinen "echt" zu sein. Damit kann man eine Kalibration alleine über das Hintergrundrauschen machen. Dazu muß auber ausreichend Hintergrund im Bild vorhanden sein. In der galaktischen Ebene wird's schwierig. Aber auch mit dem Abzug eines Hintergrunds, ebenso, wie die Neutralisierung des Hintergrunds.

Da mußman sich was anderes einfallen lassen. Den grüne Schleier-Hintergrund kann man ja auch aus einem Bild mit ausreichend Hintergrund extrahierend und benutzen.
 
Hallo Peter, tolle Betrachtungen. Die erreichte Farbigkeit finde ich stark.

NL verwendet zur Farbkalibrierung bisher die Position des Hintergrundpeaks, und die mittlere Farbe erkannter Sterne (genauer, den Median). Schwarz und Weisspunkt werden so verschoben, dass die Peaks übereinander liegen, und die Sterne neutralisiert werden. Evtl müsste man saturierte Pixel der Sterne ausnehmen.

Woher würde man die von Dir gewählten Konstanten denn kennen, wenn man kein PI hat? Sie ergeben sich ja aus dem Zusammenspiel von Kamera und Filtern.

Für die Neutralisierung ungestretchter Daten funktioniert ein niedriges Sigma von 0.8 und ein hohes von 1.2 ganz gut. Auf aggressiv nichtlinear gestreckten Daten nimmt die Peak-Erkennung irgendwann an, dass es sich um Vordergrundsignal handelt, und man muss deutlich höher gehen. Experimentieren.
 
Mit den Farben war ich bisher noch nicht zufrieden. Heute bin ich auf einen Artikel von Madratter aufmerksam geworden. Er bringt gute Argumente dafür, Farbkalibrierung und Sättigung auf linearen Daten vorzunehmen. Also vor der Anwendung von Gammakurven, nicht danach wie ich es bisher gemacht habe.

Ich habe das in NL Release 0.2.3 umgesetzt. Dabei ist mir auch aufgefallen, dass fast alle NL Farboperationen von RGB nach HCL und zurück konvertieren. Daher habe ich den Farbraum direkt auf HCL umgestellt. So kann man für Schwellwerte auch die echte Luminanz nutzen. Die Sättigungssteigerung konnte ich dadurch auch so umstellen, dass sie eine Gammakurve direkt auf die Sättigung anwendet. Der neue Parameter -chromaGamma ersetzt -chromaMul und -chromaAdd.

Ergebnis: sattere Farben, weniger Artefakte, 3x schnellere Laufzeit der Farbkombination. Hier Steffens Arp316 im neuen Glanz, das zugehörige Makefile liegt im Arp316 Dataset Repository:

Arp316_RGB_4k.jpg
 
Hallo markus,

Mit den Farben war ich bisher noch nicht zufrieden. Heute bin ich auf einen Artikel von Madratter aufmerksam geworden. Er bringt gute Argumente dafür, Farbkalibrierung und Sättigung auf linearen Daten vorzunehmen. Also vor der Anwendung von Gammakurven, nicht danach wie ich es bisher gemacht habe.
das ist doch selbstverständlich. Die Skala muß linear sein, sonst kann die Phototmetrie nicht funktionieren. Wenn Du das an den gestreckten Bildern vornimmst, muß das schief gehen.

Screenshot_20200721_074341.png

Die Photometrie wird über Farbdifferenzen in einem bestimmten Farbsystem gemacht. Und da wird dann linear gefittet. Das kann man natürlich nur an linearen Daten machen.

Weil ich aber für NGC4274 keine Photometrie machen konnte, weil es vermutlich keine Eichsterne in diesem Gebiet gibt (???), mußte ich mir was anderes einfallen lassen, um das Bild reproduzierbar zu machen. Deshalb bin ich auf das Verfahren, dass ich oben beschrieben habe, gekommen. Allerdings liegt der Rot-Wert eher bei 0.7, wenn man vorher den Hintergrund abzieht. Es schadet auch nichts, Grün danach noch einaml zu neutralisieren.

Ich weiß nicht, wie Du an Deine Farbskalierung kommst, die den Weißabgleich macht. Normalerweise sind die Sterne ja bunt und nicht weiß. Deshalb muß man den Farbindex mit berücksichtigen beim Wrißabgleich, so wie oben im Plot zu sehen ist.

Noch eine Anmerkung: Wenn man seine Daten astrophysikalisch auswerten will, muß man das unbedingt an den linaren, nicht gestreckten Daten machen. Das Strecken ist nur was für die Kosmetik, damit man ein schönes Bild erhält. Danach ist das Bild aber für eine Auswertung ungeeignet. Sogar unbrauchbar.
 
Zuletzt bearbeitet:
Hallo Peter, danke - wieder etwas gelernt. Dann bleibe ich in NL bei der Farbkalibrierung auf linearen Daten.

Ich nehme bisher vereinfacht an, dass sich bläuliche und rötliche Sterne ungefähr die Waage halten, und der Median aller Sternpixel daher ein neutrales Grau ist. Je nach Himmelsausschnitt und Anzahl der gefundenen Sterne streut der tatsächliche Median vermutlich mehr oder minder um diesen angenommenen Wert. Für meinen M42 kommen damit auch ganz passable Farben heraus (siehe unten).

Ggf. könnte man die Annahme noch parametrisieren. Z.B. indem man den mittleren B-V Farbindex angibt. Dann hätte man nur einen Stellhebel für die ganze Palette der Sternenfarben von violett, blau, weiss, gelb bis rot. Diesen Index könnte man leicht umrechnen. Was meinst Du?

M42_Orion_LRGB_FHD2.jpg
 
Zuletzt bearbeitet:
Eigentlich sind blaue Sterne viel kurzlebiger als rote. Damit ist die Verteilung vorgegeben. Das gilt natürlich nicht für alle Regionen. Weiße Zwerge eigenen sich eigentlich ganz gut zum Weißabgleich. :cool: Die muß man nur im Bild finden. Da sind wir auch schon beim Thema. Eigentlich mußt Du die Sterne klassifizieren, um eine Eichung vorzunehmen, wie in Deinem Link beschrieben. Die großen Sternkataloge, die man herunterladen kann, um die Position der Stern im Bild zu bestimmen, haben aber keine Farbinfo, glaube ich.

Außerdem verfälscht die Verfärbung der Sterne durch Staub und Gas das Ergebnis. Das ist halt keine leichte Aufgabe. Deshalb habe ich mich für die statistische Auswertung des Hintergrundrauschens entschieden. Selbst wenn sonst nichts im Bild ist, Rauschen ist immer da. Warum soll man es dann nicht nutzen? Trotzdem belibt es auch hier eine diffizile Angelegenheit. Aber ich habe meinen Algorithmus auch auf andere Galaxien angewendet, immer mit Erfolg. So kann ich im Vergleich mit der Photometrie vielleicht meine Konstanten noch etwas schärfen. Das ist eine einfache Methode, die immer da anwendbar ist, wo genügend Hintergrundrauschen vorhanden ist. Jedenfalls ist die Anzahl der Rauschpixel meist sehr hoch, um eine statistische Verteilung gut bestimmen zu können.
 
--->
Noch eine Anmerkung: Wenn man seine Daten astrophysikalisch auswerten will, muß man das unbedingt an den linaren, nicht gestreckten Daten machen. Das Strecken ist nur was für die Kosmetik, damit man ein schönes Bild erhält. Danach ist das Bild aber für eine Auswertung ungeeignet. Sogar unbrauchbar.

Das wäre nach diesem Post meine Anregung, der Maschine per Option mitzuteilen ob sie ein lineares, durchkalibriertes Bild liefern soll für die Auswertung oder ein automatisch gestrecktes als "Pretty Picture", alternativ das lineare Bild als Ausgangsprodukt mitzuspeichern.

CS
Jörg
 
Klasse, Peter. Das nehme ich zeitnah auf, wenn du mir aktuelle Quellen schicken kannst.

Jörg, das geht. autoLoc und autoScale auf 0 setzen, dann erfolgt kein Stretching.
 
Nightlight Release v0.2.4 hat Unsharp Masking (danke, Peter!). Parametrer -usmSigma für die Breite der Normalverteilung (versucht mal 0.5 bis 3.0) -usmGain für die Stärke der Maskierung (versucht mal 0.5 bis 4.0), und -usmThreshold für die Schwellwert in Standardabweichungen über Hintergund, unterhalb dessen keine Schärfung erfolgt (versucht mal 0.5 bis 2.0).

Darüberhinaus habe ich die Nutzung von Farbräumen für die RGB-Nachverarbeitung optimiert. Die Farbkalibrierung anhand des Hintergrundpeaks und der Sternfarbe erfolgt in linearem RGB. Die LRGB-Kombination erfolgt im linearen Farbraum CIE xzY. Für Farboperatoren wie Sättigung kommt jetzt ein modifizierter nichtlinearer CIE L*C*H* zum Einsatz, genauer gesagt ein L*SH* mit S=C/L, in dem Sättigung und Luminanz komplett unabhängig sind. Und Tonwertkurven erfolgen wieder im linearen CIE xyY.

Unten ein paar neu bearbeitete Testbilder: Leo Triplet, Pinwheel, Whirlpool und offener Haufen M3. Was meint ihr?

Noch offen:
  • Die Tonwertstreckung über Gamma wirkt noch zu flach. Peter hat eine Funktion MidtoneTransfer in petto, die bessere Ergebnisse verspricht
  • Peter hat auch noch eine alternative Farbkalibrierung, die nur über Mittelwert und Standardabweichung des Hintergrundes arbeitet - konnte ich bisher noch nicht integrieren
  • Ggf. Ränder beschneiden, wenn die Ausschnitte der Farb- und Luminanzkanäle gegeneinander verdreht sind wie beim Pinwheel.
  • Mich stören auch noch einige Artefakte an hellen Sternen auf dem Whirlpool-Bild, die vermutlich daran liegen, dass einzelne Farbkanäle der Kamera in die Sättigung gegangen sind.
Viele Grüsse,
Markus

M65_LeoTriplet_LRGB_FHD.jpg


M101_Pinwheel_LRGB_FHD.jpg


M51_Whirlpool_LRGB_FHD.jpg


M3_LRGB_FHD.jpg
 
Release v0.2.5 hat jetzt auch Midtone Mapping (danke an Peter). Für einige Objekte erzielt dieser Operator ohne weitere Gammaanpassungen tolle Ergebnisse. Für andere, wie M5, ist eine Kombination mit Gamma nötig.

Markus

M3_LRGB_FHD_mt.jpg
 
Status
Es sind keine weiteren Antworten möglich.
Oben