PixInsight - wie geht das?

[nebuloes]

@ Mostschädel
@ klausbaerbel

Dank euch sehr für die freundlichen Worte !
Ich freu mich, wenn ich was zurückgeben konnte!




@ Mostschädel

Ja die Maske ist sicher noch nicht nicht optimal, aber ich habe mich erst darauf konzentriert einen Weg zu finden.
Fine tuning kommt dann sicher noch.
Auch das Abarbeiten aller tips was ich bisher zurückgestellt habe.

[nebuloes]

Weil ich dem PixelMath etwas näher kommen wollte, habe ich hier die Pixelschieberei noch mit der Generierung eines Musters - im vorgegebenen Rahmen eines geöffneten Bildes - geübt:




Über die initialisierbaren Variablen "xOff" und "yOff" wird das Gittermuster im Bild zentriert - da muss man nichts machen, das geht sozusagen automatisch.
Über die Konstanten "MeshW" und "invers" kann die Gitterwreite (in Pixel) respektive eine inverse Darstellung (invers = 0 oder 1) beliebig vorgegeben werden


Symbols:
MeshW = 100,
invers = 0,
xOff = init(0),
yOff = init(0),
x,
y

Math:
x = x();
y = y();
xOff = trunc(((frac(w()/MeshW))*MeshW)/2);
yOff = trunc(((frac(h()/MeshW))*MeshW)/2);

iif( (!frac((x-xOff)/MeshW) ) || (!frac((y-yOff)/MeshW)), (iif((!invers),0, 1)), (iif((!invers),1, 0)) )


Ist vielleicht direkt für Astro Bildbearbeitung nicht sooo spannend, aber möglicherweise in Teilen mal irgendwo für irgendwas anderes brauchbar.


Die Möglichkeit Variable und Konstanten zu deklarieren macht das PixelMath ziemlich suprig !
So, jetzt aber wieder husch husch zurück zum Lovejoy

[Mostschädel]

Hallo nebuloes!
Eine sehr interessante Variante. Habs schon in meinen Beispiel-Ordner gespeichert.

[TONI_B]

@nebuloes

Alle Achtung vor deiner Lernkurve! Als nur Mitleser habe ich in den letzten Tagen beobachtet wie steil deine Lernkurve ist.
Bist du Programmierer oder in der IT-Branche tätig, dass dir das so leicht von der Hand geht?

[nebuloes]

Hallo nebuloes!
Eine sehr interessante Variante. Habs schon in meinen Beispiel-Ordner gespeichert.

Danke!

Man könnte zB nur die waagrechten Linien generieren und die "Maschenhöhe" auf 10% der Bildhöhe referenzieren - dann hätt' man bereits ein Skalierungsgitter zB für dein Kontrast Analyse Diagramm

@nebuloes

Alle Achtung vor deiner Lernkurve! Als nur Mitleser habe ich in den letzten Tagen beobachtet wie steil deine Lernkurve ist.
Bist du Programmierer oder in der IT-Branche tätig, dass dir das so leicht von der Hand geht?

Das nicht, aber vor gefühlt ewigen Zeiten mal für ein kleines Projekt PASCAL gelernt/ lernen müssen - scheint doch noch irgendwei nützlich gewesen zu sein.

[nebuloes]

Ich steh schon wieder im Wald - sorry. Diesmal mit dem ProzessContainer




https://pixinsight.com/doc/legacy/LE/12 ... iners.html

Soweit glaube ich das Prinzip kapiert zu haben - aber - sobald ich bei einem (PixelMath-)Bearbeitungsschritt eine Maske verwende bricht die Ausführung mit einer Fehlermeldung ab:
"Es sei keine Maske verfügbar"
(Error: no image available for $mask metasymbol:
iif($T*($M) > 0.001, 0, $T) )

Dabei liegt die Maske "mask" ganz normal als geöffnetes Bild vor:




Wie kann das sein, bzw was mache ich falsch?

Es ist ja nicht möglich - wie bei der "normalen" PixelMath Ausführung erforderlich - jedesmal das zu bearbeitende Bild samt Maske offen zu haben?
Insbesondere nicht, wenn ich den ProcessContainer auf einen ImageContainer - mit allen registrierten Rohbildern - anwenden will (was ja schlussendlich Sinn der ganzen Übung sein wird).

[nebuloes]

Hat sich erledigt.

Im PixelMath kann offenbar nur dann per *($M) auch die Maske angewendet werden wenn diese wirklich auf dem Bild liegt.
Und das ist beim ausführen des ProcessContainer einfach nicht der Fall - auch wenn ich diesen aus der History generiere, und im Process sichtlich auf den Namen der Maske referenziert wird.

Der work around scheint zu sein, die Maske im entsprechenden PixelMath nicht mit *($M) sondern halt eben mit dem entsprechenden Namen *(MakenName) einzutragen.

Ok, das machts nun etwas umständlichler, da ich die entsprechenden Schritte im ProzessContainer nun passend editieren muss.

[klausbaerbel]

Die PixelMath ist simpel und Macros per copy&paste in einer Minute erstellt
(einfach 4 oder 8 davon in unterschiedlicher Abfolge in einem Prozess Container zusammenfassen und diese dann mehrfach aufs maskierte Bild werfen):

pixel($T, iif(!frac(y()/2), xpos()+10, xpos()),ypos())
pixel($T, iif(!frac((y()+1)/2), xpos()-10, xpos()),ypos())
pixel($T, xpos(),iif(!frac((x())/2), ypos()-10, ypos()))
pixel($T, xpos(),iif(!frac((x()+1)/2), ypos()+10, ypos()))

Hallo nebuloes,

Ich habe Heute Deinen Pixelmathansatz versucht zu verstehen. Ist schonmal gescheitert, weil ich einfach die Gedanken und Umsetzung nicht verstehe. Ist mit zu hoch.

Aber ich habe Deine Formeln auf das entsterne Bild, sernmaskierte Bild angewendet, um Flecken mit umliegenden Pixeln aufzufüllen.

Das Ergebnis ist keine Kopie des umliegenden Rauschmusters, sondern eine wiederholte Überschreibung der Pixel, was am Ende zu einem Ergebnis führt, was der Medianeinfüllung sehr ähnelt.
Also wieder glatte Flecken, die aus dem Bild heraustreten.

Was habe ich falsch gemacht?

Liebe Grüße
Heiko

[nebuloes]

Danke für die Rückmeldung.
Mal sehen ob ich noch weiss, was ich "gestern" für einen Mathe-Semmel zusammengenagelt nabe




###

Möglicher Weise bekommst du dein Ergebnis weil deine Maske nicht funktioniert?
Wie im allerletzten Bild des animierten GIF (das mit dem vielen Rot) zu erkennen, müssen die Sterne - welche du entfernen möchtest - in den Maskenlöchern sein.

Am vorletzten Bild des animierten GIF sieht man, dass ich die Maskenlöcher "durchgestanzt" habe - dh ich habe das Bild zur Vorbereitung dort mit 0 bzw Schwarz gefüllt. Würde man die Maske entfernen (oder auf transparent schalten), ist das Bild mit schwarzen Löchern übersäht.
Diese Vorbereitung ist nicht wirklich erforderlich, erleichtert es uns aber zu erkennen, wann genau alle Pixel mit solchen aus der näheren Umgebung ausgetauscht wurden - nämlich genau dann wenn kein einziges schwarzes Pixel in den Maskenlöchern mehr zu sehen ist.

Ok soweit ?


###

Die Mathe ist ählich simpel - die Hürden liegen "nur" im Detail


Wenn du etwas weiter zurückgehst findest du dieses Bild:



Genau so ein Bild soltest du erhalten wenn du nur die erste PixelMath Zeile ausführtst - ohne eine Maske auf das Bild zu legen:

pixel($T, iif(!frac(y()/2), xpos()+10, xpos()),ypos())




Es zeigt, dass bei jeder zweiten Zeile das Bild ganz einfach um 10 Pixel zur Seite geschoben wurden.
Dh, die vorher ausgestanzen / auf Schwarz gesetzten Sternbereiche werden von der Seite her befüllt - und wenn keine Maske dies verhindert - wird das Schwarz gleichzeitig auch dorthin verfrachtet wo wir es eigentlich nicht haben wollen.


Die 10 Pixel sind übrigens nicht mehr als ein "educated guess" - einerseits ergeben 1-2 Pixel noch kein repräsentatives Rauschmuster - andererseits sind 100-200 Pixel nicht mehr die "nähere" Umgebung.
Darüber hinaus ists genau wie beim Sockenstopfen, wenn der Socken hauptsächlich aus Loch besteht dauert das stopfen überproportional lange. Das merkt man sofort wo die Löcher nahe beeinander liegen bzw sich sogar zu einer Wurscht überschneiden.

Konkret wird mit dem "xpos()+10" der Seitenverschub bewerkstelligt.
Mit dem "iif(!frac(y()/2)" wird sichergestellt, dass nur jede zweite Zeile genommen wird

Das Hauptproblem beim PixelMath - wie bei allen andern prgrammierungen - ist, dass man sich sklavisch an die vorgegebene Syntax halten muss. Irgendwo ein Stricherl zuviel oder zuwenig und man geht unweigerlich baden.


Ich hoffe ich konnte etwas Licht in die Sache bringen

[klausbaerbel]

Danke für Deine Antwort.

Die Maske beeinhaltet die Stellen, an denen die Sterne waren. Sie sind nicht schwarz (0) sondern etwas verfärbt, dunkler, bzw heller als die Umgebung.

Vielleicht muß ich anstelle 10 mal etwas höher ansetzen. Auch sind bei den Verschiebungen keine Pixelreihen zu erkennen, sondern es sieht so aus als würde komplett vom Rand her eingeschoben.

Die Einzelbilder des Gif kann ich leider nicht nacheinander abrufen.

Ich werde mich nochmal mit der Formel befassen und sehen, was passiert. Im Moment hängt PI und das bei einem Projekt. Unglücklicherweise hatte ich noch nicht gespeichert.

Liebe Grüße
Heiko

[klausbaerbel]

Also bei mir ist das Ergebnis das Beste, wenn ich die "2" durch eine "1" ersetze und anstelle 10 40 verwende.
Quasi direkt den maskierten Bereich mit dem daneben liegenden Bereich auffülle.

Also pixel ($T, iif(!frac(y()/1), xpos()+40, xpos()),ypos())

Die Stopferei erzeugt bei mir nur eine fein geriffeltes Quadratmuster, daß einer einfarbigen Fläche, ähnlich dem Median entspricht.

Warum auch immer das so ist.

Liebe Grüße
Heiko

[nebuloes]

Also bei mir ist das Ergebnis das Beste, wenn ich die "2" durch eine "1" ersetze und anstelle 10 40 verwende.

Siehst du - war doch gar nicht so schwer !




###

Was du gemacht hast entspricht in etwas dem, was ich weiter von gezeigt habe:




Das klappt eh ganz gut.
Nur dort wo es gröbere Helligkeitsgradienten gibt, hat man damit verloren.

Im Bild oben sind die so entstandenen Artefakte im Halo des Kometen deutlich zu erkennen (2Stk rechts des Kometen-Zentrums - leicht zu identifizieren mit der daneben liegenden Maske).
Die kommen daher dass vom helleren, mittigeren Anteil des Halo - zur Füllung der gestanzten Löcher - nach rechts verschoben wurden wo es eigentlich schon etwas dunkler sein sollte - und vice versa.

Mit der "stopfen Methodik" trifft man so einen Bereich leider auch nicht haargenau - aber doch deutlich besser.

[nebuloes]

Hier gibts nun ein Macro des "StructuredCloneStamp" zum Download
- damit beimSockenstopfen die Nadel nicht zu glühen anfängt.


http://www.kinotechnik.at/pages/astro/S ... x.xpsm.zip

Es benötigt eine Maske mit dem Namen "SCS_mask" welche am besten hart auf scharz/ weiss geclippt wird.
Die Maske muss dort 100% weiss sein, wo die Sterne durch Hintergrund ersetzt werden sollen.

Als erster Schritt wird die Maske automatisch aufs Bild "durchgestanzt" - damit man zum Schluss einwandfrei erkennen kann, ob keine schwarzen Pixel übrigbleiben - dh damit ist dann sichergestellt, dass auch wiklich alle Pixel in den Maskenlöchern mit den umgebenden Pixeln aufgefüllt wurden.

Bevor man den ProzessContainer auf einen Stapel Bilder im ImageContainer loslässt tut man gut daran, das Löcher füllen an einem einzelnen Bild zu kontrollieren.
Der Vorgang erfordert aufgrund der meherfachen Iterationen doch seine Zeit.
Bei mir waren etwa 30 Bilder / Stunde erreichbar .

Die grössten Löcher waren bei mir etwa 50Pixel in einer Richtung, die waren dann alle gefüllt.
Schlimmstenfalls muss man halt merhfach anwenden.

[nebuloes]

endlich bin ich soweit, dass ich erste Vergleiche anstellen kann:





Beide Bilder sind ein Teil-Stack, welcher jeweils das 8. Bild meiner Reihe verwendet

Beim linken Bild habe ich die Files mit dem im letzen Posting vorgestellten StructuredCloneStamp Makro vorbehandelt.
Meine Maske dafür war nach wie vor so grob wie weiter vorne zu sehen (hatte noch keine Zeit diese zu optimieren )

Das rechte Bild ist unvorbehandelt - aber mit den selben gezeigten Parametern - gestackt.

So jetzt gehts ans Finetuning für die MAske und die stacking Parameter und natürlich werde ich mir auch das neuteste CometAlign runterladen:

Hallo Heiko!
Das Schöne an PixInsight ist u.a. auch dass laufend neue Werzeuge entwickelt bzw.
bestehende erweitert werden.
So gerade geschehen mit dem "CometAlignment" Modul.
D.h. das Rausrechnen des Kometen aus dem "nur" Sternenbild ist jetzt im Prozess unterstützt.

Siehe im PixInsight Forum diesen Link:
http://pixinsight.com/forum/index.php?t ... 8#msg53248

Auf Seite 1 dieses Threads im PI-Forum steht auch der Link zum Runterladen der neuen Version.
Achtung dieser *.dll File muss nach dem simplen Download in den /bin Directory von PI kopiert werden.

Vielen Dank für den Hinweis!

[nebuloes]

So jetzt gehts ans Finetuning für die MAske und die stacking Parameter und natürlich werde ich mir auch das neuteste CometAlign runterladen:

WOW
Lesen die hier mit?

Grad noch das aktuelle PixInsight Update eingespielt und schon ist auch das neue CometAlign mit der "subtract" Funktion dabei.
Voll super !

[nebuloes]

Hallo nebuloes!
Danke für Deine Daten.
Anbei ein Link zum Screenshot der ersten Schritte nach dem Comet Align dass Du ja schon drauf hast.

Wie schon früher erwähnt ist es notwendig, um die Sigma Clipping Wirkung zu verbessern
sicherzustellen dass die Sterne von einem Bild zum Anderen weit genug auseinander stehen
damit bei der Integration das Sigma Clipping sie auch als "Ablehnbar" erkennt.
Dass habe ich so gemacht dass ich Deine 29 Bilder in 7 Gruppen zu jeweils 5 Bilder
unterteilt habe. Also zuerst Bild 17,24,31,38,45 dann 18,25,32,39,45(!) etc....
Der Screenshot zeigt die Bearbeitung der ersten Gruppe, alle anderen Gruppen werden dann analog
genauso bearbeitet mit minimalen Abweichungen bei den Reglern.(Ausprobieren)

http://www.werbeagentur.org/oldwexi/fot ... tAlign.jpg

Also alles beginnt im Bild von Links und geht nach Rechts.
Zuerst der Prozess ImageIntegration mit seinen Einstellungen. Beachte dass die Sigma Einstellungen
stark reduziert wurden um mehr Clipping zu erreichen. Auch hier machte ich einige Versuche
die zeigten ab wann der Komet angegriffen wird - so bin ich auf die Werte gekommen die aber
auf alle Gruppen passen.
Das Ergebnis ist das Bild (integration6) links oben an dem noch einige Sternüberbleibsel der größeren Sterne
sichtbar sind. Die Image Integration liefert aber auch noch ein Bild der abgelehnten Pixel (rejection_high6) !!
...
Ich hoffe das hilft

Deine genauen Einstellungen zu ImageIntergration waren sehr, sehr hilfreich - habe sie gleich als als macro abgespeichert.
Das Ergebins - mit (links) und ohne SCS Vorbereitung (rechts) - schaut gleich viiiel besser aus (im Vergleich zu meinem vorigen Posting)

[klausbaerbel]

Also bei mir ist das Ergebnis das Beste, wenn ich die "2" durch eine "1" ersetze und anstelle 10 40 verwende.

Siehst du - war doch gar nicht so schwer !




###

Was du gemacht hast entspricht in etwas dem, was ich weiter von gezeigt habe:




Das klappt eh ganz gut.
Nur dort wo es gröbere Helligkeitsgradienten gibt, hat man damit verloren.

Im Bild oben sind die so entstandenen Artefakte im Halo des Kometen deutlich zu erkennen (2Stk rechts des Kometen-Zentrums - leicht zu identifizieren mit der daneben liegenden Maske).
Die kommen daher dass vom helleren, mittigeren Anteil des Halo - zur Füllung der gestanzten Löcher - nach rechts verschoben wurden wo es eigentlich schon etwas dunkler sein sollte - und vice versa.

Mit der "stopfen Methodik" trifft man so einen Bereich leider auch nicht haargenau - aber doch deutlich besser.

Hallo nebuloes,

Einfach wurde es erst für mich, nachdem Du mir gesagt hast, was welcher Befehl wo bewirkt.
Da ich in Mathe nicht so bewandert bin, fällt es mir sehr schwer Formeln nachzuvollziehen.

Die Formel:
pixel ($T, iif(!frac(y()/1), xpos()+40, xpos()),ypos())

die ich verwendet habe schiebt die Pixel von rechts nach links.

Welche Faktoren muß ich verändern wenn ich aus einer anderen Richtung einschieben möchte?
Z.B. um Probleme bei Helligkeitsunterschieden zu minimieren.

Vielen Dank für Dein Makro.
Das habe ich gespeichert und werde es mir nachher genau ansehen und ausprobieren.

Liebe Grüße
Heiko

[nebuloes]

Einfach wurde es erst für mich, nachdem Du mir gesagt hast, was welcher Befehl wo bewirkt.
Da ich in Mathe nicht so bewandert bin, fällt es mir sehr schwer Formeln nachzuvollziehen.

Die Formel:
pixel ($T, iif(!frac(y()/1), xpos()+40, xpos()),ypos())

die ich verwendet habe schiebt die Pixel von rechts nach links.

Welche Faktoren muß ich verändern wenn ich aus einer anderen Richtung einschieben möchte?
Z.B. um Probleme bei Helligkeitsunterschieden zu minimieren.

Du warst schon am richtigen Platz.
Um in die andere Richtung zu verschieben änderst du nur von :

"xpos()+40"

auf:
"xpos()-40"


###

"pixel($T, xpos(), ypos())" gibt den Wert an einer konkreten x/y-Position des aktuellen Bildes zurück.
Auf dieser Standard-Funktion des PixelMath beruht die ganze hin und herschieberei.

Wenn du nun zB das "xpos()" durch den Ausdruck "xpos()+40" ersetzt - dann macht das nichts anders, als dass ein um 40 pixel rechts davon stehendes Pixel hergenommen wird.


###

In deiner Anwendung kannst auch noch eine Vereinfachung machen von:

pixel ($T, iif(!frac(y()/1), xpos()+40, xpos()),ypos())

auf:

pixel ($T, xpos()+40, ypos())


"iif(!frac(y()/1), , )" ist eine WENN Bedingung, welche in dieser Art immer erfült ist - und daher überflüssig wird.

[klausbaerbel]

Hallo nebuloes,

Aha, da kommt als die Richtung her.

Und wenn ich von oben nach unten oder umgekehrt verschieben möchte?
Bestimmt irgendwas mit Z. Aber wie ist das Gegeteil von Z?

Deinen Processcontainer habe ich eben ausprobiert. Er macht mir dunkelblaue Stellen an die Bereiche, die durch die Maske nicht abgedeckt werden.

Liebe Grüße
Heiko

[nebuloes]

Aha, da kommt als die Richtung her.

Und wenn ich von oben nach unten oder umgekehrt verschieben möchte?
Bestimmt irgendwas mit Z. Aber wie ist das Gegeteil von Z?

Guckst du weiter vorne;

Nach links verschobenes Bild generieren
pixel($T, xpos()+10,ypos())

Nach rechts verschobenes Bild generieren
pixel($T, xpos()-10,ypos())

Nach oben verschobenes Bild generieren
pixel($T, xpos(),ypos()+10)

Nach unten verschobenes Bild generieren
pixel($T, xpos(),ypos()-10)

Eigentlich recht simpel.
Kannst auch im PixelMath selber dich etwas schlau machen:

Öffne dort den "Expression Editor" - dann hast rechts eine Spalte mit sämtlichen Standard-Funktionen, Operationen etc
Unter "Functions" steht dann zB die "pixel" Funktion samt einer Erklärung zur Syntax, wennst draufklickst.

Auch diese pages waren für mich sehr hilfreich:
https://pixinsight.com/doc/legacy/LE/22 ... _math.html
http://pixinsight.com/forum/index.php?topic=6332.0
http://www.deepskycolors.com/PixInsight/PixelMath.html

Und natürlich das / die Videos von Gerald:
http://www.werbeagentur.org/oldwexi/Pix ... sight.html

Deinen Processcontainer habe ich eben ausprobiert. Er macht mir dunkelblaue Stellen an die Bereiche, die durch die Maske nicht abgedeckt werden.

Eigenartig!
Bekommst eine Fehlermeldung?
Wie sieht deine Maske aus - hast hart auf schwarz / weiss geclippt? Dh ohne weichgezeichnete Ränder?
Kannst eventuell ein Bild vom Bild, der Maske und dem Ergebnis einstellen (stark vergrössert dass man was sieht) und den genauen Ablauf nochmal beschreiben?

Oder mach' einen Screenshot und schick in mir.
Vielleicht hat sich doch ein Fehler beim Makro eingeschlichen.

[nebuloes]

Hallo nebuloes!
Danke für Deine Daten.
Anbei ein Link zum Screenshot der ersten Schritte nach dem Comet Align dass Du ja schon drauf hast.

Wie schon früher erwähnt ist es notwendig, um die Sigma Clipping Wirkung zu verbessern
sicherzustellen dass die Sterne von einem Bild zum Anderen weit genug auseinander stehen
damit bei der Integration das Sigma Clipping sie auch als "Ablehnbar" erkennt.
Dass habe ich so gemacht dass ich Deine 29 Bilder in 7 Gruppen zu jeweils 5 Bilder
unterteilt habe. Also zuerst Bild 17,24,31,38,45 dann 18,25,32,39,45(!) etc....
Der Screenshot zeigt die Bearbeitung der ersten Gruppe, alle anderen Gruppen werden dann analog
genauso bearbeitet mit minimalen Abweichungen bei den Reglern.(Ausprobieren)

http://www.werbeagentur.org/oldwexi/fot ... tAlign.jpg

Also alles beginnt im Bild von Links und geht nach Rechts.
Zuerst der Prozess ImageIntegration mit seinen Einstellungen. Beachte dass die Sigma Einstellungen
stark reduziert wurden um mehr Clipping zu erreichen. Auch hier machte ich einige Versuche
die zeigten ab wann der Komet angegriffen wird - so bin ich auf die Werte gekommen die aber
auf alle Gruppen passen.
Das Ergebnis ist das Bild (integration6) links oben an dem noch einige Sternüberbleibsel der größeren Sterne
sichtbar sind. Die Image Integration liefert aber auch noch ein Bild der abgelehnten Pixel (rejection_high6) !!

Dieses machen wir uns zunutze um es als Maske auszubauen. Wir strecken dieses Bild zuerst mit RangeSelection
und erzeugen daraus das rechts befindliche range_mask Bild. Hier sehen wir besser was alles rejected wurde.
Mit einem weiteren RangeSelection reduzieren wir dieses Bild (range_mask) auf die wesentlichen Teile und zeichnen
sie auch etwas weicher, Ergebnis range_mask1 weiter rechts. Die dazugehörigen RangeSelection Parameter
stehen immer unterhalb zwischen den Bildern, das ProzessIcon in der Mitte darüber.

Nun legen wir range_mask1 als Maske über das Bild integration6
Mit CurvesTransformation, siehe rechts daneben, reduzieren wir die Reststerne auf einen
Wert der weit unterm Median liegt. Vorsicht beim Reduzieren dass nicht im Schweif dunkle Scheibchen
entstehen! Das darüber befindliche Bild (integration6_clone) zeigt das Ergebnis.

Mit dem PixelMath Ausdruck med($T) wird mehrfach im noch immer maskierten Bild
der Wert dieser dunklen Scheibchen SChritt für Schritt auf den Medianwert des aktuellen Bildes
angehoben.
Im Prozess Container links oben sieht man dass ich es 7x gemacht habe.
Warum so oft - die Maske ist ja relativ dunkel daher wird nicht alles sofort
erhellt und ich kann aufhören wenn ich der Meinung bin das Maximum erreicht zu haben.
Ganz rechts sieht man dann das Ergebnis integration6_clone1.

Das wiederhole ich jetzt für alle restlichen 6 Gruppen
die Prozesse mit Ihren Parametern hebe ich neben den Bildern immer auf
damit ich nicht jedes Mal alles neu erfinden muss.
Am Schluss werden die 7 Gruppenbilder nochmals mit ImageIntegration summiert.

Ich hoffe das hilft

Komme erst jetzt dazu das im Detail durchzuarbeiten.

Nochmals herzlichen Dank für die genaue Anleitung.

Soweit glaube ich alles zu kapieren - speziell der Trick mit der Makenerstellung aus dem Rejected-Bild sowie der Trick mit dem CurvesTransformation aufs maskierte Bild ist voll suprig!


Es klappt auch alles gut bis auf den allerletzen Schritt - einfüllen des Medianwertes in die MAskenlöcher.

Offenbar klappt meine Maske aus irgend einem Gund nicht so wie sie soll - es wird mit med($T) einfach das ganze Bild mit dem Medianwert übergossen - dh das Ergebnis ist dann ein graues Bild ohne jeden Inhalt.
Andererseits habe ich auch nicht ganz begriffen warum du - laut deinem Text - diese Prozedur mehrfach durchführst?
Weil deine Maske nur eine Teil des Medians duchlässt und du dich auf diese Weise an ein stimmiges Ergebnis herantasten kannst?

Werde es nochmal von Vorn aufbauen und schauen ob ich meinen Fehler finde

[Mostschädel]

Hallo nebuloes!

range_mask1 wird mit RangeSelection vom range_mask Bild erzeugt.
Das range_mask Bild wird aus dem Rejection Bild erzeugt.
Im finalen range_mask1 Bild ist im Hintergrund alles 0 (schwarz) und nur die paar gewünschten Sternenrestpositionen erhalten
hellere Werte. Diese schwache selektive range_mask1 wird dann fürs PixelMath benutzt.
Du hast recht, durch mehrmaliges med($) nähere ich mich dann langsam dem Wunsch Ergebnis.

range_mask1 wurde durch das RangeSelection auch weichgezeichnet um nicht zu hart und zu schnell den Med($T) durchzulassen.

Gerald

[klausbaerbel]

Hallo Nebuloes,

Ich hatte mir schon öfters mal die Function in Pixelmath angesehen.
Mir fehlt einfach das abstrakte Denken, um daraus etwas machen zu können.

Und bei den Ausführungen in den Links, gehe ich total verloren.
Ich kann nur Formeln kopieren und wenn ich weiß, was sie bewirken dann einsetzen. Selbst kann ich keine Formeln entwickeln.
Wie ich schon sagte. Ich bin in solchen Dingen absolut ohne Verständnis.

Ich habe jetzt Deinen processcontainer nochmal ausprobiert.
Diesmal mit harter Makse.

Resultat am sternbereinigten, mit Median aufgefüllten Bild:



Wie man sieht ein Sockenstopfmuster.

Ich dachte, gut, kann ja daher rühren, daß da noch etwas von den Sternfarben übrig ist und habe mit Clonestamp den Bereich überstempelt, so daß dort nur noch Hintergrundmuster war und den Processcontainer nochmal ausgeführt.

Resultat:



Auch hier entsteht dieses Sockenstopfmuster.

Ich habe keine Ahnung, warum das nicht klappt.
Oder schaut es bei Dir genauso aus?

Wenn ich eine Formel anwende, die nur einmalig Pixel großzügig einschiebt ist das Resultat besser.
Dann entspricht das eingefügte dem Hintergrund.

Liebe Grüße
Heiko

[nebuloes]

Hallo Nebuloes,

Ich hatte mir schon öfters mal die Function in Pixelmath angesehen.
Mir fehlt einfach das abstrakte Denken, um daraus etwas machen zu können.

Und bei den Ausführungen in den Links, gehe ich total verloren.
Ich kann nur Formeln kopieren und wenn ich weiß, was sie bewirken dann einsetzen. Selbst kann ich keine Formeln entwickeln.
Wie ich schon sagte. Ich bin in solchen Dingen absolut ohne Verständnis.

Ok, kann man nichts machen - leider benötigt PixelMath etwas diesbezüglichen Background

Ich habe jetzt Deinen processcontainer nochmal ausprobiert.
Diesmal mit harter Makse.




Wie man sieht ein Sockenstopfmuster.

Das ist perfekt in Ordnung so wie es ist.
Der Hintergrund wird in genau so einem "Sockenstopf-Muster" einkopiert.
Dies entspricht der dz. etwas groben Vorgangsweise in welcher nur die vier Hauptrichtungen angewendet werden.


Für das Makro ist es belanglos ob die Maske weich oder hart ist - es wird einfach ab einem bestimmten Grenzwert eingefüllt.
Die "harte" Maske ist aber eine gute Hilfe dafür, dass du ganz genau erkennen kannst, wo die Grenze verläuft ab welcher die "nähere Umgebung" zum Auffüllen des Loches herangezogen wird.

Die Blau/ Lila Färbung kommt bei dir daher, dass deinen Maske zu knapp bemessen ist. Dh die Löcher deiner Maske sind so klein, dass der abgedeckte Rand noch nicht wirklich dem eigentlichen Hintergrund entspricht, sondern noch starke Anteile jener hellen Struktur enthält, welche du eigentlich überdecken wolltest
Kein Grund zur Panik. Dies ist bei mir an einigen Stellen genau so passiert. Diese Stellen muss ich mit einer eigenen Maslke mit grösseren Löcern - nacharbeiten.
Es sind allerdings übers ganze Bild bei mir nur ein knappes halbes Dutzend solcher Extrem-Bereiche - siehe nächstes posting (Sternhaufen oder Galaxien wahrscheinlich).


Da der - abgedeckte - Randberich bei dir stark hell-blau-violette Pixel enthält, wird auch das gestopfte Loch weitgehend hell-blau-violett.

Die Abhilfe ist simpel: die Löcher deiner Maske grosszügiger dimensionieren.

Ich dachte, gut, kann ja daher rühren, daß da noch etwas von den Sternfarben übrig ist und habe mit Clonestamp den Bereich überstempelt, so daß dort nur noch Hintergrundmuster war und den Processcontainer nochmal ausgeführt.

Resultat:



Auch hier entsteht dieses Sockenstopfmuster.

Ich habe keine Ahnung, warum das nicht klappt.
Oder schaut es bei Dir genauso aus?

Es klappt - genau wie es soll.


Genau so schaut das dann auf Pixelebene aus - ist aber (bei mir zumindest) wesentlich weniger ein Problem in der weiteren Bearbeitung, als einen gleichmässig glatten Median-wert einzufüllen.

Ich wüsste schon noch deutlich bessere Ansätze als diesen hier - allerdings wäre die Umsetztung dann schon ein echt riesiger Aufwand, den ich unmöglich stemmen könnte. Offenbar hat sich da auch sonst noch keiner - wirklich ernsthaft - drüber getraut.

Bei der Anwendung als Vorbereitung zum CometAlign gleicht sich das Socken-Stopf-Muster auf Pixelebene übrigens eh so perfekt aus, dass nach dem Stacken faktisch überhaupt nichts mehr zu erkennen ist. Auch nicht bei stärkstem reinzoomen.


Das Socken-stopf Muster an sich ist ein kleines Problem, aber die Farbe musst schauen dass sie nicht abweicht - das fällt extrem ins Auge.
Wie gesagt: die Löcher deiner Maske grosszügiger dimensionieren dann solltest passabel hinkommen, bzw sollte dann das obere Bild genau so aussehen wie das untere.

[nebuloes]

Hallo nebuloes!

range_mask1 wird mit RangeSelection vom range_mask Bild erzeugt.
Das range_mask Bild wird aus dem Rejection Bild erzeugt.
Im finalen range_mask1 Bild ist im Hintergrund alles 0 (schwarz) und nur die paar gewünschten Sternenrestpositionen erhalten
hellere Werte. Diese schwache selektive range_mask1 wird dann fürs PixelMath benutzt.
Du hast recht, durch mehrmaliges med($) nähere ich mich dann langsam dem Wunsch Ergebnis.

range_mask1 wurde durch das RangeSelection auch weichgezeichnet um nicht zu hart und zu schnell den Med($T) durchzulassen.

Gerald

Ok. Danke fürs nochmalige, detaillierte aufdröseln.
Dann hatte ich dich eh genau richtig verstanden aber offenbar irgendwo im Ablauf einen Fehler gemacht/ eingebaut.

Werds schon noch herausfinden - hoffe ich



Der Trick dieses Rejection Bild zur Maske auszubauen ist genial.
Das stacking der mit SCS vorbereiten Bilder ergibt zwar überhaupt kein für eine Maske verwertbares Rejection Bild - ABER - das stacking der nicht vorbereiteten Bilder sehr wohl (wie du eh schon gezeigt hast).
Damit kann ich nun perfekt die wenigen (knappes halbes Dutzend) prominenten Stellen nacharbeiten welche nach SCS Vorbereitung und (Teil-) stacken über geblieben sind:




Einfach super!

[klausbaerbel]

Es klappt - genau wie es soll.


Genau so schaut das dann auf Pixelebene aus - ist aber (bei mir zumindest) wesentlich weniger ein Problem in der weiteren Bearbeitung, als einen gleichmässig glatten Median-wert einzufüllen.

Ich wüsste schon noch deutlich bessere Ansätze als diesen hier - allerdings wäre die Umsetztung dann schon ein echt riesiger Aufwand, den ich unmöglich stemmen könnte. Offenbar hat sich da auch sonst noch keiner - wirklich ernsthaft - drüber getraut.

Bei der Anwendung als Vorbereitung zum CometAlign gleicht sich das Socken-Stopf-Muster auf Pixelebene übrigens eh so perfekt aus, dass nach dem Stacken faktisch überhaupt nichts mehr zu erkennen ist. Auch nicht bei stärkstem reinzoomen.


Das Socken-stopf Muster an sich ist ein kleines Problem, aber die Farbe musst schauen dass sie nicht abweicht - das fällt extrem ins Auge.
Wie gesagt: die Löcher deiner Maske grosszügiger dimensionieren dann solltest passabel hinkommen, bzw sollte dann das obere Bild genau so aussehen wie das untere.

Na super.
Ich dachte schon, ich hätte etwas falsch gemacht. Wenn das Muster so gehört, hab ich es schon recht gemacht.

Das da noch farbige Stellen von den Sternen sind, war klar. Ich habe ja auch nur auf die Schnelle eine Maske erzeugt, um zu sehen, ob es einen Unterschied macht, wenn sie hart oder weich ist.

Wenn man den Processcontainer an jedem Bild vor dem Stacken vornimmt, wird sich das Muster schon egalisieren, denke ich.
Ich habe ja ein gestacktes Bild für den Test benutzt.

Liebe Grüße
Heiko

[nebuloes]

Habe einen Ausflug in das Thema "deconvolution" gemacht und mich an folgender Anleitung entlang gehangelt:

http://www.clarkvision.com/articles/image-restoration2/

War von meinem Rekonstruktions-Ergebnis - durchgeführt in PixInsight - angenehm überrascht (im *.tif siehts noch etwas besser aus):




Leider lassen sich die Parameter keinwegs 1:1 auf meine Sternenbilder übertragen - aber das hoffe ich noch hin zu bekommen

[nebuloes]

Was mich derzeit beschäftigt sind die doch recht kräftigen comas meines Kameralein (zB in der linken obern Ecke).





Dazu habe noch keine rechte Handhabe in Pixinsigth gefunden?



Wenn ich richtig gesehen habe könnte man "deconvolution" anhand der PSF entsprechend hintrimmen?
Nur bin ich in dieser Richtung leider stecken geblieben.

Dass man die PSF in ein CSV file exportieren kann habe ich gesehen - aber wenn ichs recht verstehe ist das ja nur für genau den einen Auslesepunkt korrekt - man bräuchte aber sozsagen eine "PSF Funktion" welche über den Radius nach aussen hin die zuehmenden Abweichungen modelliert.

Oder bin ich da am Holzweg?

[nebuloes]

Soweit komme ich inzwischen.


Links das Ausgangsbild rechts das mit PSF-Deconvolution korrigierte Bild.

Aus den Originalbild errechnet "DynamicPSF" zB an einer Stelle die point spread function.
Diese exportiere ich mit dem Kamerasymbol in eigenes Bild.
Dieses Bild (der PSF Funktion) nehme ich in "deconvolution" als Basis für die "external PSF"

Dem Prinzip nach scheints zu gehen - aber brauchbar ists auf diese Art noch nicht.

Zuerst müssen die Artefakte weg und dann müsste eine Möglichkeit zur Funktions-Einbindung über den radialen Abstand (bzw die Polarkoordinaten ab Bildmitte) gefunden werden.

[nebuloes]

Mit "deconvolution" komme ich nicht weiter was die Verbesserung der Objektivfehler anbelangt.
Wünschen würd ich mir sowas:
http://startools.org/drupal/node/25

Habe mir Blenden für die Frontlinse zurechtgeschnippelt - mal sehen ob ich wenigstens die Blendensterne weg bekomme.


###

Andere Baustelle:
Auf der Suche nach besserer Auflösung bin ich beim "drizzlen" hängen geblieben.

Links normal gestacked - rechts nach der drizzle Anleitung von PixInsight:

http://pixinsight.com/forum/index.php?topic=7184.0




Abseits des feineren Rasters - welches man ja auch mit einem "rescale" erreichen könnte - sehe ich leider keinen Auflösungsgewinn.
Hier ist es eine Integration über 30sub.

Bekommt ihr mit drizzeln deutlich bessere Ergebnisse als normal gestacked?