PI: repaired hsv separation script

Status
Es sind keine weiteren Antworten möglich.

Berlinsky

Aktives Mitglied
Hallo Zusammen,

das Skript ist schon recht alt und ermöglicht das Erhalten der Sternfarben in Sternen, die im Zentrum in Sättigung geraten sind. Ich finde den Einsatz und die Optimierung im Workflow etwas mühsam und würde gerne herausfinden, ob es eine attraktive Alternative gibt. Wie erreicht ihr eine homogene Farbverteilung über den Sternquerschnitt trotz enormer Variation der Luminanz?

VG - Oliver
 
workflow
Ich versuche immer so knapp zu belichten, dass keine Sterne ausbrennen (außer halt die wenigen sehr hellen Sterne).
Den zusätzliche Anteil an read noise wegen der größeren Anzahl an Frames muss man halt notfalls mit mehr Belichtungszeit kompensieren.
 
meine Antwort war dir offensichtlich zu knapp, also ein paar mehr Infos um die Diskussion anzuregen:

Mit dem repaired hsv separation script habe ich schon oft gearbeitet, aber es bleibt halt ein übler Hack.
Deshalb ist es wichtig das Problem an der Ursache zu bekämpfen:

Ich stehe seit Jahren an der gleichen Stelle und es ist eine Frage, wo man in der Entwicklung der Sternenkerne hin will:
Selbst wenn man das Bild konsequent so entwickelt, dass die Sterne am Ende als bunte Smarties leuchten, kommt man an einem Punkt, dass es dem Bild nicht schadet, wenn die wenigen extrem hellen Sterne im Kern weiß sind und am Sternernrand sauber die entsprechende Sternfarbe haben.

Das ist der Punkt, auf dem ich meine Belichtungszeit abstimme (zB 30s F6, unity gain, Ausbrennen einzelner Kerne)
Natürlich ist es extrem von Vorteil, eine Kamera mit großer Bit-Tiefe zu haben (ich habe eine Kamera mit 12Bit und eine mit 16 Bit - in 16 Bit sind Sternfarben wesentlich leichter zu handhaben)

Jetzt ist die Frage, wie man ein extrem kontrastreiches lineares Bild in PI so streckt, dass die Sternenkerne nicht einfach bei R/G/B=1/1/1 landen.

Dazu ein Schritt zurück:
Abhängig von dem ADC der Kamera kann es sein, dass die Sättigung eines Kanals nach dem Debayern nicht bei 1,00 liegt (Bereich von 0..1) sondern zB bei 14Bit von 16Bit das sind 0,25 von 1,0.
in R/G/B=0,25/0,25/0,25

Jetzt werden beim Weißabgleich nach dem Debayern (zB PhotometricColorCalibration) nur Faktoren der Kanäle R und B bestimmt und im Verhältnis zu G reinmultipliziert.
(Du siehst diese beiden einfache Faktoren bei PI im Terminal nach Anwendung von PhotometricColorCalibration)
Vereinfacht seinen die Faktoren für R und B gleich 2 und damit wäre jetzt ein gesättigter Pixel bei
R/G/B=0,50/0,25/0,50.
Und das ist leider nicht weiß (bzw hier neutralgrau).

Wer jetzt sein Bild einfach mit PI HistogramTransformation streckt, bemerkt diesen Fehler nicht, weil aus 0,50/0,25/0,50 dann 1,000/0,999/1,000 wird und das ist ein schönes Weiß.
Wer jedoch versucht, die Farbe in den Sternenkernen zu erhalten wird das lineare Bild zB mit PI MaskedStretch oder PI GHS strecken.
(Dieses Generalised Hyperbolic Stretch (GHS) mehrmals gefühlvoll angewendet ist übrigens mein Favorit.)
Jedenfalls führen diese Tools dazu, dass aus o.g. R/G/B=0,50/0,25/0,50 zB ein 0,9/0,8/0,9 wird.
-> Der Kern ist jetzt Pink!

Um das zu verhindern muss unbedingt nach dem Weißabgleich mit PI Statistics die Helligkeit der Kanäle geprüft und ggf. im Bild geclipt werden.
Das wäre in diesem Fall mit R/G/B=0,50/0,25/0,50 in HistogramTransformation die Highlights auf 0,25 beschneiden!
Ein repaired hsv separation script wird den Grünkanal bei mehreren Pixel großen Fehlflächen nicht sauber angleichen ohne Artefakte an den Übergängen. Deshalb besser sauber abschneiden!
Danach kann das lineare Bild gestreckt werden und die weißen Sternenkerne laufen sauber in ihre Sättigungsfarbe hinein.

Man sollte sich beim Strecken bewusst sein, dass klassisches Photoshop-Strecken immer entsättigt (linker Pfeil Lightness im HSL).

Hsl-hsv_models.svg.png



----

Wenn ich mit 3nm Schmalbandfiltern Minutenlang Nebel belichte, dann mache ich noch zusätzlich ein RGB (100nm Breite) ein paar kurze Belichtungen der Sterne (zB 1/20 der Zeit von Ha) für die schönen Farben.
Dann baue ich mir dann aus Ha+Oiii+R+G+b ein schönes Falschfarben-Bild.

Synthetic Green aus Ha und Oiii für Sternfarben um dann mit PI und PhotometricColorCalibration die Faktoren der Kanäle R und B zu finden ist eine üble Krücke und führt selten zu einer sauberen Lösung, dh diese Farben:
https://clarkvision.com/articles/blue-lions-on-the-serengeti-and-natural-colors-of-the-night-sky/
natural-colors-of-stars-vs_b-v_rnclark+labels_3s.jpg

----

Ich gehe hier davon aus, du hast nur Probleme hast mit gesättigten Pixeln.
Es gibt auch Kameras wo in der RGGB Bayer-Matrix ein gesättigter Pixel dazu führt, dass ein deutlich dunklerer Nachbarpixel leider in Richtung Schwarz "schwingt", dh es wird zu wenig Signal ausgelesen.
(Eigentlich laufen die Elektronen im Topf über und die Elektronik überkompensiert den Effekt)
Das führt dann zu intensiven Chroma-Farbkränzen um die ganz hellen ausgebrannten Sterne.
Ich bekämpfe dieses Problem in Photoshop indem ich in PI das lineare Bild defensiv so strecke in 16 Bit Tiff, dass wirklich nur die betroffenen hellen Sterne im Bereich von 90-95% Bildhelligkeit liegen.
Dann kann man in PS eine Maske auf die Helligkeit setzen und den Filter "helle Bereiche vergößern" in der Dimension von 1 Pixel anwenden. Dadurch werden diese Fehlpixel einfach aufgefressen.

---
Als tötlich für saubere Sternenfarben ist die Anwendung von KI wie NoiseXTerminator auf ein lineares Bild.
Solange man einfach mit Midtones in HistogramTransformation streckt und die Kerne nach 1/1/1 zieht, fällt das natürlich nie auf.
 
Zuletzt bearbeitet:
Hallo jfried,

vielen Dank für Deine ausführliche Erklärung zu Deinem Vorgehen. Der beste Ausgangspunkt ist natürlich ein Datensatz ohne Sättigungsartefakte, leider ist dieser aber nicht immer vorhanden. Da sich bisher niemand zu einem Nachfolger des repaired hsv seperation scripts geäußert hat, scheint es dieses nicht zugeben und es bleibt wohl der eher händische Ansatz mit umsichtigem Einsatz von GHS.
Ich habe aber dennoch zwei Rückfragen zu Details:

Um das zu verhindern muss unbedingt nach dem Weißabgleich mit PI Statistics die Helligkeit der Kanäle geprüft und ggf. im Bild geclipt werden.
Meinst Du hier die "Protect Highlights" Einstellung im GHS Script?

Als tötlich für saubere Sternenfarben ist die Anwendung von KI wie NoiseXTerminator auf ein lineares Bild.
Ich sehe hervorragende Bilder auf diversen Portalen, bei denen die Autoren NoiseXT im Workflow eingesetzt haben. Worauf basiert denn diese Aussage?

VG - Oliver

 
Du bist gedanklich immer noch bei „ich brauche ein besseres Repair-Script“ ;-)

Ich war früher auch öfters an diese Stelle in PI angekommen und habe erst später verstanden, das Problem der ausgebrannten Falschfarben-Sternkerne zu umgehen indem u.a. die PI Werkzeuge maßvoll an der richtigen Stelle im Workflow angewendet werden (linear, nichtlinear).
Dadurch meine o.g. Stichpunkte.

Du müsstest mir mal sagen, was dein Ziel ist in der PI Entwicklung:
da sehe ich drei Grund-Varianten
(a) RGB: bonbonfarbene Sterne, dh die Sterne sind auch im Kern farbig und dadurch praktisch alle gleich hell (siehe HSV Grafik oben)
(b) RGB: du hast oversampled helle Sterne (mehrere Pixel Durchmesser) welche im Kern Weiß sind und am Rand in ihre Farbe (B-V) auslaufen. Je heller der Stern umso größer der Durchmesser.
(c) HaOiii: du bastelst aus Schmalbandfilter Daten die RGB Sterne (Stichwort synthetic green) und versuchst die Farben nach Farbindex (s.o.) zu kalibrieren


Der Klassiker ist (b) und lässt sich am saubersten umsetzen.

Als nächstes müsstest du mir noch sagen, ob du eine Mono Kamera oder Kamera mit Bayer Matrix verwendest. Das hat großen Einfluss auf die Sterne (Form und Artefakte)
 
Zuletzt bearbeitet:
Hallo Oliver und jfried,

ich meine - die maßvolle Belichtung der Einzelframes vorausgesetzt - das Problem mit aufgeblähten und ausgebrannten Sternen durch Strecken der Daten hat sich doch mit Starnet und StarXt deutlich entschärft. Man hat es doch in der Hand, eine Sterne führende Version in der Bearbeitung allein auf die Optimierung der Sterne auszurichten und diese dann in die sternlose Variante zu überführen.

@jfried Deine Aussage zu NoiseXt kann ich so pauschal nicht nachvollziehen. Könntest du sie vielleicht ein wenig untersetzen?

CS Peter
 
@Berlinsky
ich beantworte mich mal selbst:
Dein Rosettenbild zeigt mir, dass Du mit einer Monokamera ASI294MM (14 Bit ADC) und 3nm Schmalbandfiltern unterwegs bist (dh Variante C)
4min Belichtung in Bortle Berlin bei 3nm und F4 klingt auch ok (swamp factor 5 bis 10)
Zusammengefasst: super Ausgangsmaterial, oversampled mit großen Sterne

jetzt ist die Frage, ob Du Dir
(a) in Deinem PI Entwicklungsprozess im Sternenkern falsche Wertwerte (zB pinke Pixel) eintrittst oder
(b) Du definitv die Farbe vom Sternenrand auch im Kern sehen willst (dh der Kern darf nicht weiß sein - siehe Bild oben zu HSL-HSV)
 
Deine Aussage zu NoiseXt kann ich so pauschal nicht nachvollziehen. Könntest du sie vielleicht ein wenig untersetzen?
das kann einige Tage dauern - ich muss da mal was raussuchen
Ich nutze NoiseX und BlurX mit Pixinsight und habe bei beiden Tools das Problem, dass diese KI-Tools angewendet auf ein lineares Bild gerne mal die Glockenkurve der Helligkeitsverteilung eines oversampled Sternes beeinflussen und das bei einigen Sternen zu einer üblen Farbverschiebung der letzten 1 bis 3 zentralen Pixels im Kern führt.
Dieser Effekt tritt am gestreckten Bild nicht auf!
Wenn man zum Schluss das Bild so streckt, dass die Kerne Weiß sind, dann merkt man es nicht.

Ich benutze einen Mac mit M1 Prozessor und da sich die Community über dieses Detail nicht beschwert, vermute ich, dass auf dem Mac M1 die ganze Berechnung in 16 Bit durchgeführt wird und da eine Ungenauigeit reinwandert.
Jedenfalls sind diese Tools auf dem Mac irritierend rasend schnell ;-)
Ich behelfe mich damit, notfalls in PI die Sternenkerne zu maskieren (zu schützen) wenn ich am linearen Bild mit NoiseX und BlurX arbeite.
 
Ich wende auf Bilder, die Sterne enthalten sehr selten eine Entrauschungsroutine an. Das ist meiner Erfahrung nach bei Sternen, die isoliert werden sollen, nicht nötig. Wenn doch, dann entrausche ich meistens ganz zurückhaltend und im leicht vorgestreckten, schon zu einem RGB kombinierten Bild. Mir sind dabei noch nie Artefakte aufgefallen. Allerdings habe ich auch beim Entrauschen im linearen Bild noch keine Artefakte gesehen.
 
ich bin gleich fündig geworden

anbei ein Screenshot von einem linearen Bild - die Helligkeit hier mit ScreenTransferFunction angepasst:
- der Stern links oben vom NGC4459 verläuft in seiner Helligkeit zu Weiß (siehe Detail oben links mit Lupe/Pipette 2^16 = "1,1,1")
- wenn ich NoiseX darüber laufen lasse (Detail unten links), werden die weißen Pixel in der Mitte farbig und auch noch in falscher (!) Farbe -> das darf nicht sein
Bildschirmfoto 2023-07-05 um 11.45.04.jpg


der Stern ist
mit B-V 1.83 (siehe Bild der Sternenfarben im 3. Post)
 
Zuletzt bearbeitet:
Hallo Peter,

ja, das hilft sehr. Streckst Du Deine Sterne separat mit GHS und schützt die Zentren mit "Protect Highlights" oder wendet Du eine andere Methode an, z.B. Arcsinh, an? Danke Dir.

VG - Oliver
Hallo Oliver,

also zunächst einmal vorab - ich bin nicht der Mann mit den schönsten Sternen, also bestimmt keine Referenz ;). Bei mir dürfen die hellen Sterne gern auch mal im Zentrum ausgebrannt sein. Das bringt für meinen Geschmack Prägnanz und einen Tiefeneindruck in das Bild. Ich halte sie gegen den aktuellen Trend auch meistens recht blass.

Meine Daten integriere ich fast immer in APP, auch die Gradiententfernung passiert in APP. Für die Sterne kombiniere ich in APP ein lineares (L)RGB und gehe damit zu PI. Als erstes muss ich die Datei dort astrometrieren um SPCC ausführen zu können. Nach SPCC kommt fallweise ggf. ein schwaches BXT. Bis dahin bin ich linear unterwegs, all diese Schritte würde ich in PI genauso machen.

Das kalibrierte (L)RGB strecke ich anschließend in APP mit einem konservativen Standardpreset (10% oder 15% BG), wobei die Sterne nicht ausbrennen. Dort regele ich auch die Sättigung etwas hoch. Die Sterne sind damit fast fertig. Nur wenn ich schlechte, verrauschte RGB Daten habe, lasse ich später in PI oder PS NoiseXt über das gestreckte 16 bit Tiff laufen. NoiseXt kommt bei mir eher im sternlosen Hintergrund zur Anwendung. Aber da ist das letzte Wort noch nicht gesprochen. Das (L) RGB File speichere ich aus APP als 16 bit Tiff ab. Auch diese ganzen Schritte könnte ich in PI machen, aber APP ist mir da einfach handlicher und bequemer.

Der Sternlayer wird aus dem APP erzeugten, gestreckten 16 bit Tiff in PI erzeugt. Die Rekombination dieser Daten mit den sternlosen Varianten erfolgt in PS. Dort regele ich bei der Kombination auch noch Details im Sternlayer. Dabei geht es i. W. um Sättigung, aber dort strecke ich ggf. auch noch ein wenig um den schwachen Sterne mehr Pep zu geben.

Das "L" habe ich die ganze Zeit in Klammern gesetzt, weil ich bei bestimmten Objekten manchmal ein sehr tiefes L schieße, das nicht zu einem normalen LRGB kombiniert werden kann und eine Sonderbehandlung benötigt.

CS Peter
 
Hallo Peter,

vielen Dank für den ausführlichen Einblick in Deinen Workflow, das ist sehr interessant und hilfreich. Ich bin fast ein wenig überrascht, dass Du auf das Preset in APP zurück greifst, aber offensichtlich leistet es ja gute Dienste und es besteht nicht die Notwendigkeit hier mit komplexeren Werkzeugen zu arbeiten :y:.

CS - Oliver
 
Hallo Peter,

vielen Dank für den ausführlichen Einblick in Deinen Workflow, das ist sehr interessant und hilfreich. Ich bin fast ein wenig überrascht, dass Du auf das Preset in APP zurück greifst, aber offensichtlich leistet es ja gute Dienste und es besteht nicht die Notwendigkeit hier mit komplexeren Werkzeugen zu arbeiten :y:.

CS - Oliver
Hallo Oliver,
Aber es ist schon klar, dass ich nur von dem Umgang mit Sternen gesprochen habe. Die Bearbeitung von Deep Sky Objekten und tiefem Hintergrund war ausdrücklich nicht gemeint und da wird es auch komplexer… :sneaky:

CS Peter
 
Hi Peter,

ja, vollkommen klar. Mir ist schon bewusst, welcher Aufmerksamkeit sich der "entsternte" Teil erfreuen darf ;).

VG - Oliver
 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben