Hallo Beisammen,
Ich hab den Rohstack vom M81 zum Download auf meine Webseite gepackt. (230MB)
https://www.skywatcher.space/download/m81_rawstack.zip
Bitte berichten, wenn neue / innovative Workflows interessante Ergebnisse bringen.
Clear Skies,
Gert
Hi Jürgen,
Das ST4 Protokoll basiert auf der 4 Leitungen für die Richtungen und einer Masse. Das Signal wird gesetzt wenn eine Relais ( früher mechanisch,, heute elektronisch) die Richrungs-Leitung mit der Masse verbindet. Normalerweise sind die Relais offen, heisst kein Steuersignal. Wenn so eine Nachführsteuer6ng aktiv ist zieht sie je nach Richtung eins der Relais an. Ganz einfach kannst Du sowas simulieren indem Du den Massekontakt an der Buchse mit einem der Richtungssignale verbindest. Kleines Kabel oder Büroklammer. Die ST4 Steuerung braucht keine besondere Elektronik. Wenn jetzt in der Steuerbox ein Relais kaputt ist und immer anzieht (oder der Transistor der das Relais ansteuert) dann ist das Geschwindigkeitssignal immer gesetzt. (Wenn das gerade ein Signal für RA ist). In der Richtung solltest Du mal nachforschen.
Clear Skies
Gert
Hallo Beisammen,
Ich will zum Abschluss (die Finger sind schon ganz abgerubbelt vom Tippen) die Mosaik Schritte beim Rohstack zeigen. Eigentlich gefällt mir die Idee, denn dann hat man ein Bild und alle Verarbeitungsschritte greifen alles gelchermaßen an. Das entspricht sehr meinen Idealvorstellungen.
Den Workflow bei PI mit der Koordinatentransformation nach RA/DEC hatte ich ja beschrieben.
1. Script PlateSolve -> Aufpassen. Polynomgrad mehr als nur 2, wenn man z.B. einen Newtonkorrektor hat.
2. Script MosaicByCoordinates. Alles mit Defaults. Mich würde mal eine bessere Beschreibung der Projektionsmethoden mal interessieren. Bei Klick auf die Doku gibt es diese nicht so tolle Anzeige (die es leider bei PI viel zu oft gibt!)
3. Process GradientMergeMosaic. Das ist der Standardprocess von PI, den ich zuerst beim fertigen Bild probiert habe und wo ich dachte, das mache ich hier genauso. Der macht aber bArtefakte an den Übergängen und ist nicht akzeptabel.
Hier mal ein Beispiel.
Eine Anfrage beim PI Forum hat dann das Script PhotometricMosaic von John Murthy (der ist bestimmt NICHT der von Murphy's Law, denn das Ding funktioniert klasse!) als Empfehlung gebracht.
Das braucht noch einen extra Schritt:
2a. Script -> TrimMosaicTile. Das beschreibt der John auch gut in der Anleitung. Was mich total verwirrt hat, war das es beim Klick auf 'Run' keine Rückmeldung gibt das überhaupt was passiert ist. Da habe ich erstmal gedacht, ich habe nicht richtig den Button getroffen und nochmal draufgeklickt. Wieder nichts passiert. Ich klopfe also 20x auf den Knopf und wundere mich nur noch. Was das Geheimnis war, die 5 Pixel, die das Script per Erosion vom Bild wegschneidet, sieht man in dem Preview überhaupt nicht! Das hatte das Script auch schon beim ersten Mal Klick auf den Button korrekt gemacht. Das war nur nicht zu erkennen. Und bei meinen fehlgeleiteten 20x weiteren Klicks wurde das Bild dann immer jeweils um 5 PIxel kleiner, bis ich das dann gesehen hab, das am Rand ein Stern plötzlich weg war. Da muss John dringend ein Pop-up machen, das sagt, "OK, jetzt sind 5 Pixel vom Rand des Bildes abgeschnitten, Sie können das Script jetzt zu machen."
Dieser Trim vom Bild ist für den Code von Johns Mosaicmethode wohl wichtig, und er schreibt, dass es z.B. bei der Koordinaten Ausrichtung der Bilder weiche Kanten geben kann, die dann zu Artefakten führen.
3. Script PhotometricMosaic. Da eigentlich alles bei Deufault. Der John hat da auch eine vorbildliche Dokumentation geschrieben. Total ausführlich und zum Glück gibt es eine 'Quick Start' Abteilung, wo man nicht alles lesen muss und mit mehr Bildern.
Hier das Ergebnis, wo man in einem Bild auch noch die Überlappregion angezeigt bekommt.
Da kann man jetzt mit dem Zoom reinkriechen und nach Artefakten suchen. Aber ich habe da wirklich keine gefunden.
Ich gehe jetzt nicht nochmal die Bearbeitungsschritte durch und zeige hier dann das fertige Mosaik in der zweiten Version. Ich muss da zugeben, dass ich da bei der Verarbeitung nur schnell durchgegangen bin, weil ich die zweite Version fertig haben wollte. Eigentlich müsste man da auch mit noch mehr Aufwand mal rangehen. Sicher will ich da nochmal zum Startpunkt mit dem Mosaik zurück gehen.
Link zum Bild in voller Auflösung : https://www.skywatcher.space/C…_m82_asi2600mc_v2_txt.jpg
Danke an die, die mitgemacht haben und ich bin gespannt auf Kommentare und Ideen.
Clear Skies,
Gert
Hallo Heinz, hallo Jens,
Danke für die sehr schön illustrioerten Beiträge.
Heinz fragt nach LHE und dazu dann auch die HDRMultiscaleTransform. Dann gibt es noch das Script DarkStructureEnhance. Meine eigenen Beobachtungen dazu sind, dass ich LHE ganz gut finde. In der M81 Verarbeitung hätte ich wie Jens schreibt die LHE schon am Anfang mit Masken einsetzen müssen. Ist mir hinterher auch eingefallen. Zu Masken sage ich gleich noch was. Bei M81 hatte ich da einfach nicht dran gedacht. Daher hat LHE das Rauschen im Hintergrund angehoben. Da hätte man sich eine Menge Ärger mit Farbrausch-Entfernung und BackgroundNeutralization sparen können.
Ja, Masken sind eine tolle Sache, aber die fügen auch eine neue Dimension möglicher Parameter ein, die dann zu optimieren ist. Wenn ich eine Maske einstelle, ob nach Range oder Schärfe / Unschärfe und dann in Kombination mit einer Verarbeitungsprozedur die auch nochmal (oft mehrere) Einstellparameter hat dann ist es oft ein Ratespiel was man hätte einstellen sollen, was man erst sieht, wenn das Ergebis fertig ist. Wenn ich einen Parameter X bei der Maske und (nur) einen Y bei der Verarbeitungsprozedur habe, dann ist der Spielraum X * Y. Und das Ergbis sieht man erst am Ende. Eine eher unangenehme Extrarunde, die man da laufen muss. Es wäre super cool wenn PI Masken-Parameter dynamisch machen würde, so dass man die Einstellung im Bild z.B. bei einem Prozess-Preview machen kann. Das wäre total interessant.
Jens spricht noch Drizzel an. Ja, die 5min Rohaufnahmen sind all mit Dither gemacht. In NINA Dither bei jeder Belichtung. Ich sehe auch, dass speziell nach BlurXT und NoiseXT im gestreckten Bild die kleinen Sterne schon 'klotzig' aussehen. Ein Zeichen, dass man da dem Sampling mit Drizze auf die Sprünge helfen sollte. Im Preprocessing Script WBPP habe ich die 2x drizzle Daten auch schon erzeugt, muss die nur noch bei der speziellen DrizzleIntegration verbrauchen. OK, dann wir das Bild hinterher 2x2 so groß. Das ist auf der To-Do Listre bei mir noch drauf.
Hier mal ein Beispiel für die Sterne (mit mega Zoom), wo man deutlich sieht, dass da 2x Drizzle helfen könnte.
Bei den Kontrast steuernden Transformationen bin ich bei dieser Verarbeitung bei LHR geblieben. Die HDRMsTrans hat die komische Eigenschaft, dass ich die garnicht genug reduzieren kann, so dass das Bild noch ansehbar bleibt. Selbst mit 1x Interation und 0x Overdrive ist das Ergebnis immer noch massiv zu stark. Was dem HDRMsTrans fehlt ist ein Schieber wo man jetzt das Gewicht der Anwendung einstellen kann. Und natürlich fehlt ein live-Preview. Evtl. ist HDRMsTrans ein Code aus alten Zeiten bei PI und halt lange nicht mehr richtig auf den neuen Standard gebracht.
Immerhin mit der Stärke der Anwendung kann man was machen und einen Multiplikator per Maske einstellen. Dazu mache ich mit PixelMath eine Maske, die überall den Wert 30% hat und lege die über das Bild. Da könnte man auch noch (der Idee von Jens folgend) einen Faktor aus der Luminanzmaske reinbringen. Dann HDRMsTrans anweden und die Stärke ist im Bild auf 30% reduziert. Da kommt auch mein Punkt hoch, dass eine Einstellung der Masken Prozente z.B. in einem Preview eine tolle Sache wäre. Aber PI liest hier bestimmt nicht mit. 
Hier im Beispiel:
Link oben -> Original
Daneben -> Bild mit HDRMsTrans. Sieht gruselig aus. Viel zu stark
Unten links -> Eine Maske mit 30%
Mitte -> Maske auf dem Bild
Rechts -> Ergebnis. Angenehmere Kontraste.
Unten -> PixelMath Formal für die Maske
Vielen Dank für die prima Idee & Clear Skies,
Gert
Hallo Beisammen,
Bei den APS-C Sensoren und feinen Pixeln geht es nicht mehr so einfach die Einzelbilder vom Mosaik in Photoshop aufeinander zu schieben. Man kann machen was man will, an irgendeiner Stelle gibt es verzogene Sterne oder Artefakte. In PI gibt es ein paar mehr Schritte, die aber ein akkurates Mosaik garantieren.
Im letzten Beitrag sind da zwei Varianten angedacht und hier will ich erstmal die erste vorstellen. Also zwei 'fertige' Bilder zusammenbauen. Klar sind die Bilder nie 100% gleich und mit dem Thema werden wir uns dann befassen.
Erstmal brauchen wir das Bild von M82 mit den selben Process Schritten wie M81.
Das haben wir hier. Fall sich jemand das Bild in voller Größe angucken will gibt es hier den Link:
https://www.skywatcher.space/CCD_Galery/m82_asi2600_v2_txt.jpg
Naja, man sieht vielleicht schon den Farbton Unterschied im Hintergrund. Dazu kommen wir noch.
In PI wird ein Mosaik nicht in X-Y Pixel-Koordinaten beschrieben, sondern mit Plate Solving in RA und DEC Koordinaten. Als erstes lassen wir die Mosaik-Bilder im Solver laufen.
Eingerahmt ist der Polynom-Grad der Transformationsgleichungen. Beim Standard Solve ist das nur 2. Da wir aber durch den Koma Korrektor speziell in den Ecken Verzeichnungen haben (die Sterne sind zwar von BlurXT klein geklopft, stehen aber nicht da, wo sie nach rechtwinkligen Koordinaten stehen müssten!) Für die M81 M82 Bilder hat sich Grad 4 als OK erwiesen.
Als nächstes werden die Bilder so erweitert, dass jedes einzelne den Beraich des ganzen Mosaiks abdeckt. Dazu gibt es bei PI das Script MosaicByCoordinates.
Hier sind die Defaults alle OK.
Jetzt sehen die Bilder so aus:
Man sieht es in der Bildschirmkopy nicht genau, aber die Kanten sind jetzt z.B. nicht mehr 'gerade' sonder ganz leicht gekrümmt, das kommt von der Kompensation der Bildverzeichnung der Originale. Eigentlich kann man die Bilder jetzt übereinader legen und blinken und im Überlappbereich bewegt sich nichts mehr. Allerdings wird man die Helligkeit und Hintergrund Variationen sehen.
Jetzt gibt es bei PI zwei Möglichkeiten.
1. Das normale PI Tool 'GradientMosaicMerge' (Für diese Beispiel werde ich das nehmen)
2. Das Script Projekt 'PhotometricMosaic' von John Murphy (das werde ich beim nächsten Post beim Mosaic aus den Rohstacks zeigen)
Für den Feather Bereich habe ich tutorials gesehen, die 10-100 vorschalgen. Bei meinen Bildern mit recht gleichmäßigem Hintergrund hat 10 gereicht.
Beim Mosaik-Prozess wird auch versucht den Übergang auszugleichen.
Das Ergebnis sieht dann so aus.
Man sieht noch ganz wenig die schwarzen Ränder und die machen wir mit einem Crop weg.
An dieser Stelle denkt man, man ist eigentlich fertig, aber ich habe mir nochmal das gesamte Bild mit GraXpert angeguckt. Und der hat noch kleine Unterschiede im hintergrund gefunden und abgezogen.
Also hier das fertige Bild. Wer will kann sich die gesamten 7400x6000 Pixel (15.5MB) ansehen:
https://www.skywatcher.space/CCD_Galery/m81_m82_asi2600mc_v1_txt.jpg
Beim nächsten Mal will ich noch die Mosaikerstellung im Rohstack mit dem Script von John Murphy zeigen.
Kommentare und Verbesserungen sind wie immer willkommen.
Clear Skies,
Gert
Hallo Beisammen,
Nach dem nun gestreckten Bild kommt bei mir die Kontraststeuerung. In PI ist das LocalHistogramEqualization LHE). Das verschiebt das Histogram so, dass lokal der Eindruck von mehr Kontrast entsteht. Ich setze das nur sehr abgeschwächt ein, hier 30%. Bei mehr wird mir das zu viel. Was wählen da die anderen PI User hier im Forum?
Wir sehen, wie die Staubwolke vor dem Kern und auch die inneren Spiralarme deutlicher geworden sind. Man sieht aber auch, dass das Rauschen mehr geworden ist. Hier kann man mit einer Maske nur die Galaxie bearbeiten (habe ich hier bei diesem Schritt nicht gemacht. Warum? Habe ich vergessen. Mache ich beim nächsten Verarbeitungsdurchlauf) Ich verwende LHE später noch mal, und da nehme ich eine RangeMask auf den hellen Bereichend der Galaxie.
Langsam geht es in die Feinjustage am Ende.
Erstmal ist der Hintergrund noch zu hell und die Farben sehen noch komisch aus. Das ist der Punkt, wo mir das Problem mit SPCC aufgefallen ist. Eigentlich sollte ich jetzt nicht mehr an den Farben was ändern müssen. Seufz. Also stelle ich im Histogramm-Tool nicht nur den gemeinsamen RGB Regler ein, sondern mache dann auch noch in den Farben kleine Verschiebungen. Damit sind die Farbewerte aus den Gaia Daten dann im Eimer. Sieht aber besser aus.
Nun will ich noch mehr Sättigung bei den Spiralarmen. Da brauche ich Blau und etwas Rot für den kern. Grün soll eigentlich nicht verstärkt werden. Dazu stelle ich im ColorSaturation Fenster eine Kurve ein, die erstmal allgemein angehoben ist und bei Blau noch etwas verstärkt ist. Bei Grün ziehe ich die etwas runter.
Von der Verstärkung ist eine Menge auch im Hintergrund gelandet, was mir nicht so gefällt. Ich hatte das mit dem BackGroundNeutrasiation Tool versucht, aber das hat nicht viel geholfen. Weil es so aussieht, als ob das meiste Farbrauschen ist, habe ich es mit SCNR (Einstellung Rot) nochmal probiert. Das sah dann OK aus. Wahrscheinlich hätte das auch alleine gereicht.
Jetzt wirds nochmal spannend. Der NoiseXT Hammer kommt. Hier ist die Schwelle bei 60% eingestellt. Das geht per Augenmaß in einem Preview, ohne dass man die ganze Rechenzeit jedesmal investieren muss. Vielleicht geht 5% mehr auch noch, aber ich mag diese ganz glatten Bilder nicht so sehr. Ein wenig Krümel im Hintergrund ist schon OK.
Das sieht schon mal sehr gut aus. Zumindest gefällt es mir. Jetzt kommt ein zweiter LHE mit Maske auf dem Galaxienkern. Es geht mir dabei hauptsächlich um die Wolken vor dem Kern. Ich zeige mal den Vergleich vorher/nachher und die Maske.
Ich denke das LHE hebt immer den Hintergrund etwas an. Also kommt ein letztes Mal ein Histo zur Feinjustage.
OK. Das ist jetzt erstmal das fertige M81.
Wer das Ding in voller Größe 6k x 4k sehen will kann sich das hier bei de Link angucken (10MB):
https://www.skywatcher.space/CCD_Galery/m81_asi2600_v3_txt.jpg
Als nächstes habe ich zwei Wege zum Mosaik mit M82 verfolgt.
1. M82 mit den selben Process Icons verarbeitet (mit minimalen Justagen), so dass ein Bild rauskommt, das in etwa wie der M81 oben aussieht, und dann die beiden als Mosaik verknoten.
2. Zurück zu den linearen Rohstacks von beiden Bildern, dort das Mosaik machen und dann auf das gesamte Bild die Process Schritte anwenden.
Beides Funktioniert und ich werde die Schritte dazu dann im nächsten Post zeigen.
Rückmeldungen sind wie immer willkommen.
Clear Skies,
Gert
Hallo Beisammen,
Noch eine Antwort zu Peters Kommentar zum Stern-Halo bei BlurXT. Warum ich den auf 10% vergrößere. Ich empfinde das so, dass BXT Sterne und Halos vom Original erst schärft (dabei werden die Halos der hellen Sterne kleiner) und dann die vom User angegebene Vergrößderung anwendet. Schauen wir mal die Bildschirmkopie an.
Links das Original (erkennt man an den fetten Sternen!).
Mitte BXT 40% sharpen stars, 0% Halo und 70% sharpen nonstellar (super schicke punktförmige Sterne!). Der Halo ist deutlich kleiner geworden.
Rechts (da muss man jetzt mt den Augen kneifen) 10% Halo. Das bringt den Halo etwas in Richtung Original zurück. Finde ich eigentlich OK. Die hellen Sterne sollen im Bild auch hell bleiben. Gefühlt ist das für mich so 1/4 oder 1/3 auf dem Weg zurück zum Original, aber immer noch deutlich reduziert. Mir kommt es bei BXT auf die kleinen Details an. Diese Halo-Einstellung ist nicht zentral für mich, und die hellen Sterne sollen mit ihrem Strahlen eigentlich erhalten bleiben. Was meint das Forum?
OK. Weiter mit Stretching:
Was meint die Community: Ist das neue GHS oder das alte Histogramm besser zum Strecken?
Beim GHS sieht man Tutorials, wo das mehrfach hintereinander angewendet wird mit immer neuen 'Symmetry Point' und 'stretch factor' Werten. Die Idee dabei (so wie ich das sehe) ist, das die Daten das Histogramm soweit wie möglich ausfüllen. Der verbrauchte Bereich im Histogramm soll ein rechteckiger Klotz von links bis rechts sein. Das heisst (für mich) dass der Kontrast im Bild überall gleichmäßig verteilt ist also man überall Strukturen optimal sehen kann. Aber was bedeutet das für ein Bild und will man das überhaupt?
Der Gegenspieler ist das alte Histogramm. Klar, wenn man das voll ausreizt, sind zwei fast gleich helle Bereiche (z.B. Strukturen im Kern vom Orionnebel) nur noch knall weiß und nicht mehr unterscheidbar. Aber ich finde den 'Verlauf' dahin von dunklen zu hellen Gebieten irgendwie natürlicher. Ich habe bei M81 3x GHS (mehr schrittig) probiert, und fand das erstmal ganz schick. Aber später im Flow. Z.B. nach LHR und HDRMultiscaleTransform gab es dann schlimme Artefakte. Der Galaxienkern sah zuerst deutlicher 'abgesetzt' aus als beim Histo, aber nach LHR war da ein farbloser, blasser Halo um den Kern und erst dann wurde es wieder heller. Sieht furchtbar aus.
So sieht es nur nach dem Stretch aus (link GHS, rechts Histo:
Man denkt im linken Bild vielleicht, oh schick, da sieht man den innersten Kern. Aber so sieht das dann am Ende aus nach LHE und HDRMultiscaleTrans.
Oben GHS (würg),unten Histo. Ich bin mit dieser mehrfachen Anwendung bei GHS auch nicht so glücklich. Am Ende empfinde ich die Übertragungskurve als total durchgeknetet und auch 'unvorhersagbar'. Wenn man mich fragen würde, das selbe Bild nochmal zu verarbeiten würde was anderes rauskommen. Wie sieht die Community das?
Nochwas zu dem Tipp von Jürgen. Bitte macht ein Posting, wenn jemand irgendwelche schicken Mausklick-Effekte bei PI kennt.
Z.B. habe ich erst in einem Video von Adam Block gesehen, wie man zwei Versionen von einem Bild blinkt. Man stellt Bild#1 nach Größe und Rechteck so ein, wie man es will. Dann zerrt man die Ecken von Bild#2 über die von Bild#1 (die rasten dabei ein) . Nun zeigen beide Bilder ja noch unterschiedlichen Zoom und Bildausschnitt. Die Bilder nochmal etwas gegeneinander verschieben und den Names-Reiter links von Bild#2 auf den von Bild#1 zerren. (nicht darunter, dann wird das zur Maske). Dann sind bei Bilder genau im gleichen Zoom und Ausschnitt. Wieder übereinander einrasten und durch Ctrl-PageDown kann man die beiden dann blinken. Cool!!!
Wer kennt noch weitere solche Tricks??
Clear Skies,
Gert
Hallo Jürgen,
Danke für den Tipp. Das hilft ein gutes Stück, wenn sich bei Scripts die Konsole irgendwie automatisch über das Bild schiebt und dann da einrastet. Die auszuschalten gibt dann wenigstens die Möglichkeit Bild und Script_Fenster gut zu sehen.
Danke & Clear Skies,
Gert
Hallo Beisammen,
Ach ja, ich wollte noch was zum SPCC meckern. Der hat ja nun das Bild anhand der Farben der Gaia Sterne balanciert. Da sollte es doch im ganzen restlichen Flow nicht mehr nötig sein irgendeine Farbbalance anzufassen. Ist aber nicht so. (Oder mache ich da was falsch?) Ich mache mal zur Anschauung gleich nach dem SPCC eine mega Farbsättigung.
Das kommt dabei raus. (Oben Rohstack, unten SPCC mit mega Sättigung)
Also an die Sterne kann man sich gewöhnen, aber was sollen denn Bananen Gelbe Galaxien? Ich hab also später im Flow Die Balance so hingeschoben, dass mir die Galaxien und Sterne besser gefallen. Aber damit ist die Ausrichtung an den Gaia Daten im Eimer. Da kann man doch nie sagen, dass die Farben zumindest irgendwie auf natürlichen Werten basieren. Da kann ich die Sterne doch gleich in lila Falschfarben colorieren. Was ist da los?
OK, weiter im linearen Bild, wir haben da noch zwei Schritte abzuarbeiten. Hintergrund und Farbsättigung.
Den Hintergrund glätten übernimmt GraXpert. In der letzten Zeit ist die Verbindung zu PixInsight besser geworden. Das Plugin-Script hat Durchgriff auf die Einstellungen in GX und man kann es als Process-Icon (mit den Einstellungen) auf dem PI Desktop ablegen. Nach der Anwendung gibt es die Hintergrund-Landkarte anzugucken.
Wie zum Geier kriegt man es in PI hin, dass dieses dusselige Konsolenterminal nicht vor dem Desktop steht? Bei scripten ist das einfach eingerastet!
Der wichtigste Blick ist auf die Hintergrund-Karte. Da will ich kein durch gedrücktes Bild der Galaxie oder von sonst irgendwas vom Bild (was ich behalten will!) sehen. Ist hier gut der Fall.
Im mit Screen-Stretch gestreckten neuen Bild sind die Fasern aus dem galaktischen Cirrus noch gut zu sehen. Aber die sind so gestreckt, das wird man nicht hinkriegen, dass man die am Ende im Bild mit dunklem Hintergrund noch sieht. Vielleicht ganz schwach.
Auf zur Farbsättigung. Wie gesagt, damit habe ich noch große Unsicherheiten. Bei PI gibt es da 'ColorSaturation' (wo man eigentlich als erstes dran denkt) und in den Curves eine Saturation Kurve. Ich hab das mal im PI Forum gefragt. Da hieß es, ColSat würde die Verhältnisse der Farben zueinander nciht erhalten. Wie? Ich sehe da doch eine gerade horizontale Linie, da sind doch gerade alle Farben gleich betroffen! Eher im Curves Tool mit dieser Beule denke ich, werden die Verhältnisse der Farben zueinander verschoben.
Hier mal die beiden Werkzeuge und Ergebnisse. Ich finde bei der Sättigungskurve ist die Galaxie schon zu gelb. Außerdem kann man an der Kurve in jedem Winkel zerren und das ändert doch die Farben. Da bleibe ich beim ColSat. Oder kann mich jemand vom gegenteil überzeugen?
In der Diskussion im PI Forum kam auch die Empfehlung Farbsättigung im Gestreckten Bild zu machen. Ich halte nichts davon. Da kommen die Maximalwerte der Sterne und ggf. Galaxienkern zu dicht an 100%. Da kann sich dann keine mehr Farbe halten und so ein Bereich wird Weiss. Wenn ich Farbsättigung im linearen Bild mache, habe ich am Schluss Sterne, die fast bis zur Mitte Farbe haben. Was empfehlen die Mitleser?
OK. Als nächstes kommt Strecken. Ich kämpfe mit GHS und Histogram. Mehr im nächsten Post.
Verbesserungen und Kommentare willkommen.
Clear Skies,
Gert
Hi Stathis
Im Ernst, sehr schöne und tiefe Aufnahme, die muss deutlich jenseits der 21,5 mag gehen, wow! Vielleicht kannst du diese ermitteln? Peter hat hier erläutert, wie es auch jenseits des GAIA Katalogs gehen könnte. In Siril kann man das auch direkt ohne Rechnerei machen (s. Siril Photometry), so etwas müsste es auch für PI geben?
Am linken Rand von Homberg IX ist sogar die HII Region [MH94a] Ho IX 9 und auch weitere des MH94a Katalogs zu sehen.Das kleine lange dünne Galaxiechen ist übrigens die "allseits bekannte" und "wohl klingende" SDSS J095903.74+690657.0
Unten in der Übersicht ist die noch flächenschwächere M81 Satellitengalaxie PGC 28731 zu sehen.
Auf meinem Bildschirm empfinde ich die Farbsättigung als zu hoch, Holmberg IX und die äußeren Spiralarme wirken zu sehr blau, helle Sterne haben starke Farbsäume. Dafür kommen natürlich die HII Regionen in den Spiralarmen schön heraus. Geschmackssache.
ASTAP sagt 21.8mag im Stack nach RGB Align.
Es gibt auch bei PI sowas wie eine Farbkalibrierung mit der Annahme, dass die Sterne 'im Mitel' Weiß sind. Habe ich auch früher viel gemacht und funktioniert gut. Aber z.B. bei den Dual-Narrowbandfiltern hatte ich Probleme damit. Mit der SPCC und Gaia Daten klappt es besser. Da werden echte Daten der Sterne im Bild genommen und 'nicht nur' Mittelwerte. Ist bei OSC Camera sicher kein riesen Sprung. Macht halt ein wohliges Gefühl.
Farbsättigung ist ein großes Thema. Ich hab ja geschrieben, dass der Snapshot noch Version 0.9 der Verarbeitung ist. Farbe ist da ein dicker Punkt. neulich im PI Forum hat es geheißen mal soll garnich den 'ColorSaturation' Process nehmen, sondern die 'Curves' Funktion und da die Saturation Kurve.
Ich will noch meine Gedanken zu Farbbalance und Sättgung schreiben. kommt noch.
Clear Skies,
Gert
Hallo Beisammen,
Wir sehen uns mal die Schritte im linearen Bild an.
Erstmal ein Blick auf den Stack wie der jetzt aussieht.
OK sieht nicht schlimm aus. Gradienten sind da, kein Problem damit wird GraXpert fertig. Es ist auch dieser galaktishe Cirrus zu sehen, aber ich glaube nicht, dass der im normal bearbeiteten Bild am Ende rauszuholen ist. Zu dicht am Rauschen. Evtl. in einer inversen S/W Darstellung als separates Bild.
Nun zu den Schritten
Wer sind da die Bewerber (in unstrukturierter Reihenfolge)?
Es gibt da eine gesunde Konkurrenz um die Reihenfolge. Wie man jetzt die Reihenfolge hier macht ist eine offene Diskussion, was meinen die Mitleser hier?
Hier sieht man an der Leiste der Process-Icons, wie ich das mache.
Also zuerst SPCC. Abgleich der Farben mit Spektraldaten der echten Sterne aus Gaia Katalog. Damit der Vergleich zu Gaia klappt muss die SPCC Funktion in PI im Bild die RA/DEC Koordinaten haben. Also muss vorher der Platesolver laufen. Der ist in PI ein Script und wenn man da die Bildmitte, Brennweite und Pixelgröße richtig einträgt gibt es da kein Problem.
Im Protokoll-Fenster sieht man, dass der Solver gut gelaufen ist und die Brennweite wirklich ganz genau 856.20mm ist. (nett) Die Transformationsmatrix selber zu Fuß nachrechnen überlasse ich dem Mitleser als Hausaufgabe. 
Ich traue der mal.
Im SPCC hat dann die Zuordnung zu Gaia geklappt und es wurden die Verhältnisse R/G und B/G korreliert. Es kommen schöne Geraden raus, was für ungefilterte One-Shot-Color Aufnahmen auch so zu erwarten ist. Bei multi Narrowband Filtern ist das schon anders.
Das SPCC Fenster hat diese Abteilung, wo man ein Hintergrundstückchen von einem Preview angeben kann. Was ich erst in einem Tutorialvideo gesehen habe ist, dass man den Preview Reiter von der Seite vom Bild mit der Maus einfach auf diesen Button zerren kann und der damit übernommen wird. Warum werden solche tollen Tricks nirgendwo gesammelt und dem naiven Benutzer mitgeteilt? Da fummelt man Ewigkeiten in so einem Fenster rum und dann geht das so einfach.
Nach SPCC kommt Deconvolution. Der BlurXT von Russ Croman hat das für mich unendlich viel einfacher gemacht. Die Decovolution Prozesse in PI habe ich Ewigkeiten ausprobiert und nie gute Ergebnisse erhalten und dann eigentlich Deconvolution aufgegeben. Mit BlurXT ist das wie eine neue Welt.
Hier die Einstellungen. (Eigentlich ist der Default ganz OK) Ich mache mir einen kleinen (weil dann geht das Rechnen schneller) Preview mit viel Zoom und schubse dann an den Reglern rum)
Die Korrektur ist klasse. Nicht nur in der Mitte wie hier gezeigt, sondern auch Bildfehler Artefakte in den Ecken.
Wenn man mal FWHM vergleicht:
Entwicklung FWHM:
RGB_ReAlign : 3.313px = 2.69" (0.813"/px)
BlurXT : 1.729px = 1.41"
Da ist der Stern FWHM glatt halbiert. Wenn später das Strecken kommt wird FWHM wieder fetter, aber ein deutlicher Gewinn bleibt am Ende erhalten. Siehe z.B. das Grüppchen link unter dem hellen Stern in dern Mitte. Nach BlurXT kommt da der kleine Doppelstern raus!
OK. Soweit erstmal hier. Kommentare und Verbesserungen sind wie immer willkommen.
Clear Skies,
Gert
Hallo Beisammen,
Also eigentlich wollte ich das als animiertes GIF zeigen, aber das hat nicht geklappt. Ein erster Schritt nach Stack kommt ein Crop der Ränder mit den Unregelmäßigkeiten vom Dithern. Bei sind das so die letzten 50Pixel. Außerdem ma ich es wenn das Bild eine glatte Anzahl Prixel pro Kante hat. jetzt kommt ein RGB Re-Align. Warum? R,G und B unterliegen unterschiedlicher Refraktion in der Atmosphäre. Das wirkt wie ein Prisma. Jeder Stern ist ein kleines Spektrum und die Position ist für R, G, und B für den Stern ein ganz bischen anders. Wenn wir das Farbild nach einzelnen R, G und B Kanälen zerlegen können wir die miteinander (G als Referenz) ausrichten und dann neu zu einem Farbbild zusammensetzen.
So sieht das aus. Oben voher, unten nachher.
Man muss ein wenig mit den Augen kneifen und es ist kein riesiger Effekt. Bei 1:1 Betrachtung sieht man das im Bild nicht. Aber der geneigte Astrofoto-Freund kriecht ja mit den Augen in die Pixel rein.
In PixInsight sind hier die Schritte:
ChannelExtraction -> Macht R,G, B Bilder
StarAlignment -> G als Referenz und R und B werden ausgerichtet
ChannelCombination -> Wir nehmen R_aligned, G, B_aligned und machen ein neues RGB. Das sieht dann so aus wie Unten.
Ich bin die nächsten Schritte dann schon mal durchgeeilt und habe mir eine Version 0.9 des Ergebnisses gemacht. Was dran noch besser / anders geht, kann ich noch nicht sagen. Ich werde über die Beobachtungen berichten.
Und den M81, weil der im Zoom so schick ist.
Für die Sammler der 'Langen Dünnen'. Das Ding ist links neben M81 und ASTAP kennt keine Bezeichnung dafür. Nein, ist kein Asteroid. Da sieht man auch schon, dass evtl. eine 2x Drizzle Verarbeitung mal eine Option ist. Ja, die Farben in dem Ding sind grauslich.
Soweit zur Vorausschau. Ich schreib dann mit den nächsten Schritten weiter.
Fragen zum Bisherigen kann ich evtl. beantworten.
Clear Skies,
Gert
Hallo Beisammen,
Im Computerthread hatte ich schon ein erstes Ergebnis gezeigt, aber das weiter führende Thema gehört besser hier her.
In dem Thread hier will ich die Schritte der Verarbeitung dieses Projekts beschreiben. Ich bin gefühlt bei Version 0.9 und weiß nicht wohin die Reise geht. Kann dauern bis es fertig ist.
Am letzten Wochenende beim Bortle4-5 Platz unseres Astrovereins habe ich mit dem Skywatcher 10zoll F4 und der ASI2600MC (Color) Belichtungen gemacht. Ziel war M81 und M82. Genau genommen hätten die beide in ein Feld gepasst, aber dann wären die 'Target' Objekte in den Bildecken wo die doch leicht vorhandenen Artefakte vom Koma-Korrektor, Vignettierung etc. zuschlagen. Über den Kampf mit dem Korrektor und Tubusstreulicht hatte ich schon geschrieben.
Zuerst zur Planung. M81 & M82 sollten also jeweils in der Bildmitte stehen. Wenn man das clever macht, kriegt man das in einem 2x Mosaik unter und hat ncoh ein paar kleine Galaxien drumrum. Beide Galaxien kulminieren so ca. 0:40 und das erlaubt eine praktische Zweiteilung der Nacht. von Abend-Astro-Dämmerung bis 0:40uhr M81, Dann Montierung-Flip, und M82 bis Morgengrauen. Das reicht schön symmetrisch verteilt für ca. 5Std pro Objekt, abzüglich sowas wie Autofokus Pausen, Dithern und PHD wieder einpendeln lassen. Genau all diese Schritte im NINA Sequencer geplant und dann gestartet. Bis zum Schwenk hab ich der Sache zugeschaut und als der geklappt hat bin ich in den Schlafsack gekrabbelt. Am Morgen habe ich dann das Scope wie gewünscht in Parkposition vorgefunden, Montierungsmotoren aus, Camera-Kühlung deaktiviert. Alles sehr zufriedenstellend. Ich hab noch gedacht in dem jetzt so schön horizontal stehenden Tubus könnte ein kleine Vogelpaar angefangen haben zu nisten, aber da war niemand. Also konnte ich zufrieden abbauen.
Hier das HFR Protokoll von NINA von der Nacht.
Bei M81 habe ich noch Notizen nebenher gemacht. (Die mag sind mit dem SQM Gerät)
20:00 2.6C 57% 20.60mag Foc 16030
21:10 1.9C 59% 20.65mag Foc 16016 PHDavg 0.62"
22:20 1.9C 57% 20.77mag Foc 15995 PHDavg 0.56"
23:20 1.4C 59% 20.83mag Foc 16004 PHDavg 0.51"
00:20 -0.2C 63% 20.80mag Foc 16030 PHDavg 0.50"
Flip
00:55 1.4C 53% 20.80mag Foc 15982 PHDavg 0.59"
Ich fand interessant, dass bei Abkühlung der Fokus erst kürzer und dann wieder länger geworden ist. Ich hätte gedacht bei Abkühlung wird der Metalltubus kürzer und der Fokus muss monoton nach Außen korrigiert werden. It aber nicht so. Wer hat da Ideen?
M81 Version 0.9
In PI mit dem WBPP Script erstmal einen Kalibirierungs- und Stackdurchlauf. Dann gucke ich immer noch mal mit SubFrameAnalyzer in die ausgerichteten Bilder. Dabei sind von 59x5min Bildern 6 weggefallen. Einmal war ein Anschubser vom Tubus, der Doppelsterne gemacht hat und dann am Anfang des Abends ein paar Belichtungen mit Wind. Der 10zoll Newton mit Taukappe bietet halt doch ganz schön Angriffsfläche.
Die ausgewählten Frames kommen dann nochmal in einen neuen Stack und mit dem geht es dann weiter.
Für die nächsten Schritte brauche ich noch ein paar Screencopies. Wenn ich die habe schreibe ich weiter.
Clear Skies,
Gert
Hi Marvin,
Ich mach noch eine Diskussion auf, wenn ich bei V0.99 bin. V1.0 ist noch in der Ferne.
Ultimativ soll das ein 2x Mosaik werden. M81 und M82 stehen ja so nett beieinander und kulminieren beide ca. 0:40uhr. Dazu hab ich mit NINA und dem Sequencer einen Plan gemacht. Vom Dunkel werden bis 0:40 M81, dann Montierung flip und M82 bis Dämmerung. Sind jetzt 53x5min (ausgewählt von 59) M81 und 52x5min M82 (noch auf der Platte)
Leider war das Wetter in der ganzen Region klar, und die ganzen LIchter von 5Mio Leuten tragen zur Lichtglocke bei. Manchmal liegt über den Städten eine tiefe Wolkenschicht und es ist dann dunkler. Am Wochenende war beim Beobachtungsort nur ca. Bortle 4-5. SQM (Mitternacht) 20.8
Clear Skies,
Gert
Hallo Beisammen,
Herzlichen Dank an Jochen und alle für die Guten Ratschläge.
Zum Ende hier erstmal ein kurzes Vorab-Ergebnise der Imaging Session vom Wochenende. Ist erst die Version 0.9. Wenn das noch etwas besser aussieht werde ich das im Imaging-Forum zeigen.
Clear Skies,
Gert
Hallo Beisammen,
Erstmal Danke für die positive Diskussion.
Gestern war ich draußen im Felde zum Imaging. Beim Win10 Pro Laptop hab ich am Tag vorher Updates aufegrufen. Der wollte aber keine. Dann auf 3 Tage 'Pause Updates' geschaltet. Tatsächlich hat NINA die ganze Nacht durch Aufnahmen gemacht und am Morgen war das Scope friedlich in der Parkposition und der Laptop stand bei NINA, hatte den Desktop auf dem Screen und war OK. Auswertung der Bilder kommt dann demnächst.
Also im Moment 1:0 für die Update + dann Pause Methode.
Clear Skies,
Gert
Hi,
Müsste man mal bei Gelegenheit recherchieren.
Ich fahre heutue mal zum Beobachtungsort und habe vorher die Updates gemacht und dann 3 Tage Pause eingestellt. Ist vielleicht nicht so streng wie die 7 Tage Pause und kommt unter der Beobachtung von Klaus noch durch.
Wenn jemand einen MSFT IT Admin kennt wäre sowas doch mal eine Frage für einen Experten. Als Amateur hat man da ja eh keine Chance durchzublicken. 95% der Kernelmessages bei meinem Raspberry verstehe ich auch nicht! Liegt also nicht nur an MSFT.
Clear Skies,
Gert
Hallo Klaus,
da ich bei den Aufnahmen keinen Internetanschluss am Notebook brauche, schalte ich vor Beginn meiner Session in den Einstellungen ganz einfach das WLAN aus. Dann ist Ruhe! Das ist einfacher als
den Router zu deaktivieren und dgl.
Ich hatte so einen Reboot schon mal im Felde, weit ab von jedem Netz. Forensik hinterher ergab, dass ein Update lange vorher geholt worden war und zu der schönen friedlichen Nachtzeit 'wo niemand seinen PC braucht' installiert wurde. Gefolgt von einem Reboot.
Ich folge jetzt erstmal Matss Vorschlag und gebe eine 7 Tage Pause vor. Nach dem Beobachtungstrip ins Feld kann man die ja wieder abschalten.
Clear Skies,
Gert
Hi,
du könntest im Router den Internetzugang nur für den Aufnahme-PC sperren, viele Router haben solche Funktionen.
Gibt es dazu eine Amateur-Admin geeignete Anleitung? Mein Router ist Asus RT-AC68U.
Allerdings hat ein unangemeldetes Reboot den Laptop auch schon im Feldeinsatz mitten in der Nacht ohne jeden Funkzugang neu gestartet und NINA gestoppt. Die beste Lösung ist ein besseres Einstellen der Erlaubnis für den Update/Reboot Prozess. Gibt es da eine Detailierte und getestete Anleitung?
Vielen Dank and die Experten & Clear Skies,
Gert
Hi,
...kann auch sein weil ihr zu viele Services bei der Installation zugelassen habt? Ich deaktiviere grundsätzlich alle Features die Windows mir beim installieren anbietet wie Diagnose ect....
Das ist sicher mein Problem. Kannst Du da mal ein Tutorial angeben, wo das alles für den nicht Informatiker vorgemacht wird??
Vielen Dank und Clear Skies,
Gert
Hi,
das beste ist kein Windows zu benutzen.
Ja, ist klar. Kann ich auch wenig dagegen argumentieren. PC Benutzung ist halt mit Windows genetisch verbandelt.
Ich hätte jetzt schreiben wollen, dass halt der meiste Astro Kram und jeder kleine Treiber für einen Motorfokus oder Flatpanel mit 99% Wahrscheinlichkeit in Windows daher kommt. Aber dann gibt es die gut gemeinten Fingerzeige auf 'guck mal, da gibt es ein PHD Guide Projekt für Linux'. Wahrscheinlich sogar völlig korrekt und berechtigter Weise. Aber die Energie, die ich aufzubringen bereit bin das ganze Imaging-Rig auf Linux umzutopfen ist bei mir nicht vorhanden. Ich mag mich auch nicht in Astroberry einarbeiten, und bin da beratungsresistent.
Clear Skies,
Gert
Hallo Beisammen,
Danke für die Rückmeldungen.
Offline ist unbequem, weil man ja den Laptop auf dem Balkon hat und via Remote-Desktop am Schreibtisch in der warmen Stube die Session verfolgt. Dabei ist der Laptop ja via Wifi am Hausnetz. OK, man könnte jetzt das gesamte Hausnetz isolieren, aber dann kann man beim Belichten nicht mehr mit dem Schreibtisch-PC im Forum schmökern.
Enttäuschend, dass gerade das Feature 'active hours' was ja wohl dafür gedacht ist updates/reboots während der 'Arbeitszeit' zu verhindern nicht funktioniert. Oder hab ich da noch was übersehen? Gibts da irgendwo eine saubere Doku?
Wie machen das die Leute, die solche Mini-PCs an die Fernrohre schrauben? Starten die auch den Setup am Nachmittag und laasen präventiv Updates durchlaufen? Das ist doch ein Murks. Wie kann man da bei einer Wolkenlücke spontan was beobachten?
Clear Skies,
Gert
Hallo Beisammen,
Mitten in einer Imagingsession hat der Windows Laptop ein Update installiert und dann ein Reboot ausgelöst. Das hat natürlich die Imagingsession beendet. In der Windows Steuerung hatte ich die aktive Arbeitszeit am PC auf 18-10uhr eingestellt. Trotzdem zeigt die System Event Anzeige ein Update Download 22:28:32 und dann Reboot 22:39:46. Siehe Markierungen in Bildschirmkopie.
Vielleicht können die PC Experten hier sagen, was ich noch übersehen habe und wie ich das entsprechend umkonfigurieren kann.
Siehe in der Bildschirmkopie die markierten Bereiche beim Event Log und den Systemeinstellungen zum Zeitdfenster, wo der PC nicht neu starten sollte.
Vielen dank & Clear Skies,
Gert
Hallo Robert,
Toller Bericht. Ich wundere mich, wieso Alt die Höhenlagerung mit diesem einen Bolzen gemacht hat. Das lädt doch praktisch Schwingungen ein! Ich sehe den selben Fehler z.B bei G11. Richtig gemacht bei AVA. AP und (alten) Paramount. Da wird die StdAchse oben und unten in einer weiten 'Gabel' gehalten.
Sicher ist das bei Alt stabil, aber durch viel übertriebenen Materialeinsatz. Die ganze Paramount in unserem Verein auf der wir ein C14 mit Leitrohr haben kann ich gut angeben. Bei der Alt würde ich mir das nicht zutrauen.
Ich denke, da sind moderne Konstruktionen einfach eine bessere Optimierung aus Material, Fertigung und Stabilität.
Bin auf Deine weiteren Berichte gespannt.
Clear Skies,
Gert
Hallo,
Komisch. Jetzt geht's wieder.
Wie immer bei PCs hilft mehrfaches Ein- und Ausschalten und neu Starten über mehrere Tage hinweg. Cool.
Clear Skies,
Gert
