Sternidentifikation

Status
Es sind keine weiteren Antworten möglich.

JoernLenhardt

Aktives Mitglied
Hallo zusammen,

ich der letzten Zeit hab ich ein wenig an einer Software geschrieben, mit der ich Sterne auf einer Astro-Aufnahme identifizieren kann. Damit kann ich dann die Grenzgröße der Aufnhame bestimmen.

Einen Zwischenstand zu diesem Projekt'chen gibt es hier .

Insgesamt steckt das Ganze zwar noch in den Kinderschuhen, aber es wächst langsam...

Gruß aus der Pfalz
 
Hallo,

finde ich sehr interessant. Kann das für die Farbkalibrierung benutzt werden?

Gruß aus Worms

Kai



 
Hallo Jörn,

eine tolle Sache! Ich fände es sehr spannend, wenn Du noch bei Gelegenheit verrätst, wie Du die Sterne erkennst und die Kennzahlen bestimmst. weiterhin viel Erfolg und natürlich auch Spaß dabei!

Viele Grüße,
Tom
 
Hallo
ein japaner hat sich am selben problem ebenfals mal versucht
(sternaufnahmen automatisch zu identifizieren)
ist etwas schwiriger zu installieren
hier der Link
http://www.aerith.net/misao/pixy/index.html

Gruss aus stuttgart
 
Hallo Joern,

:respekt: so etwas zu programmieren ist schon nicht mehr ganz so trivial ;) .
Bildfeldwölbung und sonstige unerwünschte Verzerrungen im Bild können hier graue Haare wachsen lassen.
Ich möchte an dieser Stelle noch eine Anregung in eigener Sache beisteuern.
Wenn es Dir im Laufe des Projektes möglich wäre einen Algorithmus abzuleiten der die äquatorialen Außenkoordinaten eines "registrierten Bildes" ermittelt wäre das eine feine Sache :super: . Dieses Koordinatenpaar sollte dann RaMin/DeMin sowie RaMax/DeMax enthalten.
Diese Informationen über ein Bild könnte das ArtemisBBS direkt verwenden um ein Bild in die Datenbank zu übernehmen und es mit einer Reihe spezieller Algorithmen recherchierbar zu machen!.

Diese Funktion könnte Dein Tool sehr viel wertvoller machen als es bis dahin sowieso schon wäre :)

Gruß Alex (VectorSCOPE)
 
Hallo zusammen,

vielen Dank für die Rückmeldungen und die vielen interessanten Anmerkungen.

Kai: Für die Farbkalibrierung denke ich, kann man das ganze nicht benutzen. Es geht bei der Sache (zumindest für mich) um die Sternidentifikation. Oder mit welcher Idee/Ansatz würdest du die Farbkalibrierung daraus machen? Farbdaten aus den Kataogen mit den Aufnahmedaten abgleichen?

Tom: Die Gelegenheit wird bestimmt kommen. Im Moment feile ich noch ein wenig an den Algorithmen und an Optimierungen. Ich halte dich/euch dann auf dem Laufenden.

anthoja: Super, Danke für den Link. Ich hab zwar noch nicht näher reinschauen können, wenn ich mir aber die 'Functions of the latest version' anschaue, dann Hut ab... An dem sollte ich mein kleines Tool aber erst mal nicht messen, hehe.

Alex: Die Außenkoordinaten daraus abzuleiten schaue ich mir mal an. Und, graue Haare wollte ich keine weiteren bekommen. Aber du hast recht, wenn man alleine die Koordinaten und die Aufnahe vergleicht, kommt man schon etwas ins grübeln.

Gruß aus der Pfalz
 
Hallo,

ich finde es schwierig in eigenen Bildern geeignete Sterne z.B. zur B-V Farbkalibrierung sicher zu identifizieren. Mit der Bildverarbeitung von Astrobildern habe ich allerdings auch gerade erst angefangen. Dann könnte ich doch die Farbdaten aus Katalogen mit der eigenen Aufnahme besser abgleichen?

Gruß

Kai

 
Hallo Kai,

die Sternidentifikation ist eine Sache, die ich mit dem kleinen Tool (wenn's dann rund läuft) machen könnte.

Für eine Farbkalibrierung könnte man dann die Katalogdaten dieser so bestimmten Sterne heranziehen, das geht sicherlich. Danach müsste man sich aber mit einer solchen Farbkalibrierung auseinandersetzen. Dazu fließen die Kameraeigenschaften mit hinein (Empfindlichkeitsmaximum der Farben) oder die der verwendeten Filter, die ja nicht unbedingt den B-V Werten entsprechen muss. Mit passenden Filtern könnte man das aber mal versuchen (müsstest du aber machen, ich bin kein Astro-Fotograf).

Solch eine Kalibrierung dann in das Tool zu integrieren könnten wir ja gemeinsam angehen.

Gruß aus Bad Dürkheim nach Worms
 
ja cool, find ich auch ne supper Sache, aber warscheinlich auch kompliziert umzusetzen ?!
Vielleicht sollte man das Bild in verschiede Kontrast und Rot-Grün Blau whatever Chanels aufteilen, um noch mehr Daten bzgl. Helligkeit und Farbe der Sterne zu bekommen? Evtl. klnnte man sich Netze aus Dreiecken oder Waabenmuster ect. als Pattern(Muster) zum Matching(Prüfen) nehmen?
Also von Hellen zu schwachen Sternen, erstmal die Hellen Sterne matchen, dann die Schwachen ...
Vielleicht findet man auch Anregung bei Gesichtserkennungs-Algorithmen ect??

gruß
Don


 
Hallo Don,

Danke für die Rückmeldung. So ähnlich mache ich es, hab aber keine direkte Farbauswertung drin. Die RGB Daten rechne ich einfach in Helligkeiten um.

Der erste Ansatz zur Steridentifikation war, Dreiecke für jeden Stern zu jedem zu berechnen, für's Bild und für die Kartendaten. Daraus hab ich dann entsprechende Matches gesucht. Das war aber nicht so erfolgreich, da viele ähnliche Dreiecke entstehen. So hab ich keinen richtigen Ansatz für die Skalierung, Translation und Rotation erhalten.

Anschließend hab ich die Helligkeiten der Sterne im Bild grob bestimmt (einfach Helligkeit der Pixel um den Stern addiert). So konnte ich die Sterne der Helligkeit nach sortieren.

Die jetzige Auswertung erfolgt über die hellsten 5 Sterne des Bildes und der Kartendaten, um die Skalierung zu erhalten. Einen Stern ziehe ich zur Translation heran und mit einem zweiten Stern berechne ich die Rotation (deswegen die gute übereinstimmung der beiden Sterne). Hierbei gibt es aber immer noch einigs an Abweichungen (siehe letztes Bild in meiner Beschreibung), so das die "Erkennungsgrenze" für meinen Geschmack noch etwas zu weit heruntergesetzt ist. Es ist also so ein Gemisch aus Dreieck und Wabe.

Gruß aus der Pfalz
 
Hallo Jörn,

ich arbeite mich zur Zeit erst etwas in die Fotografie und Bildverarbeitung ein. Mir reicht im Grunde genommen erst mal eine Identifikation der Sterne im eigenen Bild zur manuellen möglichst korrekten Einstellung der Farbe. Dein Vorschlag geht ja um einiges weiter und wäre sicher eine tolle Hilfe und Erweiterung.

Womit ist Dein Programm denn geschrieben?

Gruß

Kai



 
Hallo Kai,

geschrieben hab ich das Programm in C# mit dem Visual Studio 2005. Es basiert auf dem .net Framework 2.0.

Gruß aus Bad Dürkheim nach Worms
 
Hallo,

den ersten Teil der Software hab ich schon mal beschrieben. Die Extraktion der Sterne aus dem Bild erfolgt folgendermaßen.

Der Rest an Beschreibungen der Identifikation folgt dann auch noch...

Gruß aus der Pfalz
 
Hallo zusammen,

next step in der Beschreibung ist fertig. Die Muster zur späteren Erkennung und Zuordnung sind hier beschrieben.

Gruß aus der Pfalz
 
Hi Joern,

1.)
:gutefrage: :gutefrage:

folgendes bringt mich etwas in Stirnrunzeln
Aber auch das fotografierte Objekt wird ausgeblendet, sonst erkennt mein Stern-Extraktions-Algorithmus falsche Sterne

Wie löst Du das dann bedienungsmäßig im Programm? Daß "nebulöses Material" bei der Sternextraktion Probleme macht ist einsehbar. Der Anwender müßte dann jedoch pro Bild individuell diejenigen Bereiche die im Bild nicht betrachtet werden sollen markieren können?
Vielleicht kann man dieses Problem durch Einführen eines "Annulus" bzw. einer freidefinierbaren Feldblende (vgl. Photometrie von Veränderlichen in Kugelsternhaufen bzw. dichten Sternhaufen) lösen.
Da die Startkoordinaten für die Ermittlung der Transformation vermutlich vom User voreingestellt werden ist die Lage des Feldes weitgehend bekannt. Durch Hinzuziehen von Messier/NGC/IC Katalog könnte man (mit einigem Aufwand) die Außenkonturen bekannter "Störquellen" wie Galaxien planetarische Nebel oder sonstige Nebelstrukturen ermitteln und als "FeldBlende" einsetzen.
Dazu müßte man allerdings die Transformationsmatrix bereits schon kennen um die Größe und Lage der Feldblende in Abhängigkeit der Brennweite berechnen zu können. ?) Da beißt sich also die Katze selber in den Schwanz.
Trotzdem wäre die Feldblende im Nachhinein nützlich da man dann alle Objekte die innerhalb der Feldblende liegen per Definition als vermutlich falsch erkannte Objekte deklarieren könnte. :cool:

2.)
Ableitung der maximalen Außenkoordinaten RaMin/DeMin+RaMax/DeMax.
Du legst also fest, daß alle Punktquellen deren Intensitäten mindestens 5Sigma oberhalb des Hintergrundes liegen als gültige Sterne erkannt werden.
Wenn es nun im Programmablauf gelingt eine gültige Transformationsmatrix von der Sternkarte (Referenzkatalog) auf das Bild zu errechnen ist die Ableitung der Außenkoordinaten nicht mehr schwierig. In diesem Fall können ja dann jedem (Stern)-Punkt im Bitmap (X/Y) die entsprechenden äquatorialen Koordinaten durch Anwenden der Transformationsmatrix zugeordnet werden.
Es müßten dann nur noch alle erkannten Punktquellen (gemäß der 5Sigma Vorgabe) mit Ihren X/Y Koordinaten auf äquatoriale Koordinaten transformiert und in eine Liste abgespeichert werden und diese dann einmal bezüglich Ra und einmal bezüglich De auf oder absteigend sortiert werden.
Die jeweiligen minimalen bzw. maximalen Koordinatenwerte in Ra bzw. DE definieren dann die Objekte die den "Außenrahmen" des Bildes definieren. Und somit wäre auch die Bildmitte ermittelt ;)

3.)
Tolle Sache, daß Du Deine Gedankengänge bei der Entwicklung der Software veröffentlichst.
Bei der Gelegenheit fällt mir ein, daß ich irgendwo eine Dissertation gesehen habe die sich mit genau diesem Thema beschäftigt. Wenn es Dir gelingt daß Programm wirklich gut hinzukriegen gibt es dafür eine ganze Menge Anwendungsfälle, vor allem auch in der Raumfahrt während des Ausrichtens von Satelliten beim "Lost in Space" Problem. :respekt2: Mach weiter...!!

Gruß Alex (VectorSCOPE)

P.S Die Dissertation findest Du hier
Ich denke, sie wird ein paar neue Denkanstöße geben :super:
 
Hallo Alex,

Danke für die Hinweise.

Wie löst Du das dann bedienungsmäßig im Programm?
Im Moment noch nicht per Bedienung. Ich such mir wirklich von Hand die Koordinaten heraus und geb diese Daten ins Programm ein (wirklich im Quellcode).
Das ganze ist noch nicht für 'Fremde' bedienbar, aber es funktioniert für mich erst mal. Ich hatte da als erste Verbesserung eigentlich an eine tabellarische Eingabe oder eine Markierung mit Maus gedacht, indem ich einfach ein Quadrat oder einen Kreis aufziehe.

Der Ansatz mit dem Einbinden einschlägiger Katalog ginge auch, dann müsste aber wie du sagst im Nachhinein ausgeblendet werden. Das wird aber einiges an Fehlerkennungen haben, bis eine Transformation passend gefunden wäre.

Über einen Automatismus hab ich schon mal nachgedacht. Die Objekte unterscheiden sich ja in der Form durch die Sterne. Wenn ich also Formen/Flächen im Bild erkennen könnte, so könnten diese (als nicht Sterne erkannten) Bereiche ausgeschlossen werden. Ich hab mich aber noch nicht näher damit beschäftigt...

Ableitung der maximalen Außenkoordinaten RaMin/DeMin+RaMax/DeMax
Das sollte wirklich nicht so schwierig sein.
Ich hatte mir eigentlich gedacht, das ich nach der Transformation die 4 Ecken des Bildes rückwärts von Pixel nach RA/DEC transformiere.

Tolle Sache, daß Du Deine Gedankengänge bei der Entwicklung der Software veröffentlichst
Nun ja, wenn ich irgend ein Tool schreibe, es dann zeige und...dann ätsch, ich verrat nicht, wie es funktioniert...ist ja auch unschön. Es gibt keine Patente darauf und vermarkten will ich es auch nicht. Also kann jeder auch wissen, wie ich es mache. So bekomme ich dann auch Anregungen, wie ich es verbessern kann.

Anwendungsfälle... Ausrichtens von Satelliten beim "Lost in Space" Problem
...ob die mal an einem Tool einen Wald-Feld-Wiesen-Programmierers Interesse haben...

Danke für die Dissertationsschrift, da find ich bestimmt noch einiges an Anrgungen. Hab nur noch keine Zeit gefunden, die ganz zu lesen.

Gruß aus der Pfalz
 
Hallo Joern,

Ich hatte mir eigentlich gedacht, das ich nach der Transformation die 4 Ecken des Bildes rückwärts von Pixel nach RA/DEC transformiere.

Rein von der Geometrie her betrachtet hast Du mit dieser Aussage recht.
Es kann aber sein, daß zwischen den absoluten Außenkoordinaten der Ecken und den real erkannten Sternen ein Leerraum existiert, der keine astrometrisch nutzbaren Informationen enthält da in diesem Bereich gar keine Sterne (Objekte) erkannt wurden. Für den Astrometriefall wäre also die Reduzierung der absoluten Außenkoordinaten auf die "nützlichen Außenkoordinaten" aller erkannten Objekte sinnvoll.

Dein Vorschlag wäre jedoch der Richtige wenn es z.b um das registrieren von Bildern für das ArtemisBBS geht, denn dort wären tatsächlich die Koordinaten der absoluten Ecken nötig auch wenn sich im Außenbereich nur "nebulöse Objekte" oder gar nur Leerraum befindet.

...ob die mal an einem Tool einen Wald-Feld-Wiesen-Programmierers Interesse haben...
Nun ja soweit würde ich das "Licht nicht unter den Scheffel" stellen. Wenn die grundsätzlichen mathematischen Probleme bzw. die Basisalgorithmik stimmt und ausgetestet ist steht mit der "Sternidentifikation" ein Fundament zur Verfügung auf dem sich einiges aufbauen läßt.
Ich habe hier eine Idee im Hinterkopf die zu einem äußerst interessanten Tool für die Astronomie führen könnte (und an dem mit einiger Sicherheit auch die "Profis" erhöhtes Interesse hätten) :cool:
Abwarten und weiterentwickeln :)

Gruß Alex (VectorSCOPE)
 
Hi Don

Joern interessiert sich bei seinem Projekt nicht für die Farbe an sich sondern für die Strahlungsintensität. Er benötigt also die Intensität des Luminanzsignals --> Luminanz


Die Antwort auf die Frage:
ist HPixel = (0,299 * rPixel) + (0,587 * gPixel) + (0,144 * bPixel)eigentlich richtig?


wird beantwortet durch:

Zitat:"Das Luminanzsignal E'Y errechnet sich aus den vorentzerrten nichtlinearen Farbwertsignalen E'R, E'G, E'B wie folgt:[1]

E'Y = 0,299 E'R + 0,587 E'G + 0,114 E'B."

Die Transformationsformel ist also korrekt...

Bei digital kodiertem Video muß man aber etwas vorsichtiger sein ;) .Steht aber auch im Wikipedia Artikel

Der Link, den Du angegeben hast bezieht sich auf die Transformation des RGB Farbraums in den HSV Farbraum.

Gruß Alex (VectorSCOPE)
 
Heyho,

Korrektur :augenrubbel:

Der Blauanteil in Joerns Transformations-Formel ist falsch.
Es muß heißen 0,114*bPixel und NICHT 0.144*bPixel

Insofern hat Don doch (zumindest teilweise) recht :super:
Habe ich tatsächlich auch erst nach 6maligem hingucken bemerkt :)

Gruß Alex (VectorSCOPE)
 
Hallo Don, Hallo Alex,

vielen Dank für die kritische Betrachtung der Algorithmen. Das hilft enorm bei dem Projekt'chen (und bei der Dokumentation). Auch vielen Dank für die Verlinkung auf die entsprechenden Wikipedia-Seiten, die als Hintergrund-Info dazu echt bereichern.

In der Software hatte ich es richtig, die Dokumentation hab ich eben nachgezogen.

Wenn euch sonst was auffällt oder unklar bleibt, dann einfach melden.

Gruß aus der Pfalz
 
hey hey hey, ne ne, ist mir auch nicht aufgefallen :).

Wollte auch garnicht so besserwisserisch rüberkommen, hab mir blos auch mal eine klasse gebastelte(allerdings in Actionscrtp=flash) wo ich das brauchte : RGB -> HSV.

Was mich daran grad mal interessiert wäre, wie man eigentlich ein Tonwertkurve bastelt?


Aha, bzgl. des Links:
Bei Positionsangaben muss man ja auch auf das Equinoktium des Katalogs achten – oder?
 
Zuletzt von einem Moderator bearbeitet:
Hi Don,

Aha, bzgl. des Links:
Bei Positionsangaben muss man ja auch auf das Equinoktium des Katalogs achten – oder?

So ist es!. Beim Vergleichen von Katalogörtern ist natürlich das Äquinoktium von entscheidender Bedeutung. Positionsangaben von Objekten müssen sich also auf dasselbe Äquinoktium beziehen. Früher war das B1950.0 , heute ist das Standardäquinoktium J2000.0.

Wenn man also vor dem Problem steht archivierte Sternörter bzw. Positionsangeben mit neuen Örtern zu vergleichen muß man die Örter transformieren, da sich wegen der Präzession der Erdachse der Frühlingspunkt und somit das Koordinatensystem verschiebt.

Wie man die Transformationen durchführt steht hier beschrieben

Für Joerns Anwendung sind also Referenzkataloge zu verwenden deren Äquinoktien möglichst nahe an der Epoche der Beobachtung liegen. Am besten also J2000.0. Wer es ganz genau will müßte aber tatsächlich noch die Transformation vom Standardäquinoktium auf die Epoche der Beobachtung durchführen und die Eigenbewegung von Objekten berücksichtigen. Ob das dann im Einzelfall noch nötig ist, sei dahingestellt weil bei der programmierten Sternidentifikation sowieso ein Fangraster um den vom CCD-Bild abgeleiteten individuellen Centroid eines Sternscheibchens (vgl. PSF) definiert werden muß, welches sicherlich größer sein wird als die Differenz der Katalogörter zwischen meinetwegen J2000.0 und einem Beobachtungszeitpunkt im Jahre 2009.


Gruß Alex (VectorSCOPE)
 
Hallo zusammen,

der verwendete Katalog hat die J2000 Koordinaten.

Die Präzession, also die Verschiebung des Frühlingspunktes, hatte ich mir auch schon mal angeschaut, bin aber zu dem Entschluss gekommen, das dieser eigentlich nicht berücksichtigt werden muss.

Das betrachtete Bild hat einen so kleinen Ausschnitt und ist auch weit vom Pol entfernt, so das anzunehmen ist, das die Präzession für die extrahierten Sterne dieselbe Verschiebung bedeutenb würde. Bei der Ermittlung der Kennzahlen wird diese Verschiebung aber eleminiert. So kam ich halt zu dem Entschluss...

Die Eigenbewegung der Sterne hatte ich ja auch schon betrachtet, und kam da - wie in der Beschreibung schon angedeutet - zu keinem befriedigenden Ergebnis, bin also damit auf die Nase gefallen.

Die Kartendaten projeziere ich aber im Moment noch nicht (stereografisch), sollte aber bei der weiten Entfernung vom Pol und dem kleinen Himmelsausschnitt auch noch keinen so gravierenden Einfluss haben. Das Suchraster ist jedenfalls grob genug.

Gruß aus der Pfalz
 
Hi Joern,

Falls es bei der Identifikation der Objekte zu größeren Problemen kommen sollte die nicht in der verwendeten Mathematik liegen solltest Du noch über die Berücksichtigung einer weiteren Korrektur nachdenken. Die Refraktion des Gestirns am Beobachtungsort zum Beobachtungszeitpunkt.

Die kann bei großen Abständen zum Zenit recht ordentlich groß ausfallen. Falls das vorliegende Bild von der Größe her halbwegs moderat ist, angenommen um die 30 arcmin, kannst Du in grober Näherung von einem linearen Verlauf der Refraktion in Altitude ausgehen und eine Refrakations-Korrektur in den Koordinaten anbringen, die der Position der der Bildmitte entspricht. Da die Koordinaten der Bildmitte als Startwert der Identifiaktion ja bekannt ist (sein sollte) ist die Bestimmung der Refraktion eventuell möglich.
Das könnte helfen die Genauigkeit der Objektidentifikation zu verbessern (vor allem wenn die Bilder größer werder --> z.b bei DSLR und kleineren Brennweiten).

Gruß Alex (VectorSCOPE)

 
Hallo Alex,

die Refraktion hatte ich eigentlich auch ausgeschlossen. Das Beispielbild, welches ich benutzt hab, hat ein Feld von ca. 3' (keine 30'). In so einem Bereich/Feld sollte die Refraktion auch nicht solche Effekte hervorrufen.

Ich tippe da eigentlich auf das Kartenmaterial.

Gruß aus der Pfalz
 
Hi Joern,

In so einem Bereich/Feld sollte die Refraktion auch nicht solche Effekte hervorrufen.
Rogger, würde ich auch so sehen. Kann aber nicht schaden die Refraktion als Störglied bei der Analyse größerer Felder im "Hinterkopf" zu verankern :) .

P.S Schnell noch eine Test-Idee hinterher. Hast Du schonmal versucht einen "Sektor-Plot eines Referenzkatalogs" gegen sich selber zu testen?. Wäre doch interessant zu sehen, was die Identifikation dabei ausspuckt ;)

Gruß Alex (VectorSCOPE)
 
Hallo Jörn,

durch Zufall bin ich auf deinen Thread gestoßen und da ich mich vor etlicher Zeit auch mit diesem Thema beschäftigt habe (und ein Progrämmchen in Delphi schrieb) möchte ich ein paar Anmerkungen machen (und hoffe mich korrekt zu erinnern):

Zur Sternerkennung:

Man müsste sich überlegen, in welchen Parametern sich ein Stern von einem flächenhaften Objekt (Nebel, Galaxie etc.) unterscheidet.
Ich hatte damals als weiteren Parameter jedem Stern eine "Rundheit" zugewiesen, also einfach das Verhältniss von Umfang^2 / Fläche.
Für "runde" Objekte wie Sterne ergibt sich der Minimalwert von 4pi ~ 12,57. Andere Objekte (wie Galaxien) haben eine größere Zahl.

Die exakte Helligkeits- und Positionsbestimmung eines Sterns ist nicht trivial. Mir sind 2 Arten bekannt:
1. "Schwerpunktmethode". Gewichtete Mittelwertbildung aller zum Stern gehörenden Pixel (gewichte: z.B. Helligkeit). Funktioniert wohl für deine Zwecke ausreichend gut. Probleme gibt es bei sich überlagernden Sternenscheibchen.
2. Fit an Modellfunktion. Pixel eines Stern werden an eine Modellfunktion angefittet (meißt ein Gauss). Google-Stichwort: Point Spread Function

------------------------------------------

Nun zur Identifizierung.
Ich habe damals einen Algorithmus verwendet, den ich aus einem NASA Paper habe. Die Grundidee ist,wenn ich mich recht erinnere die Folgende:
* Sortiere in Bild und auf Kartenausschnitt die Sterne ihrer Helligkeit nach.
* Nimm die ersten ca. N=20 Sterne und erzeuge Dreiecke der Sterne untereinander
* für jedes "Tripel" von Sternen erhält man einen Punkt in einem "Merkmalsraum" mit den Koordinaten x=b/a y=c/a wobei a,b,c die Längen der Dreiecksseiten sind (absteigend sortiert)
* ähnliche Dreiecke zwischen Bild und Karte liegen in diesem Merkmalsraum sehr dicht aneinander. ähnlich heißt hier: ähnliche Abstandsverhältnisse, also auch ähnliche Winkel, bei beliebiger Lage und Vergrößerung.
An den nächsten Schritt kann ich mich leider nicht mehr richtig erinnern (leider auch der wichtigste :-)
Man hatte irgendwie ein N x N array (N=anzahl der Vergleichssterne) erstellt und erstmal mit 0 initialisiert. Dann wird hochgezählt:hat Objekt i (=Stern auf Bild) ein ähnliches Dreieck (=geringer Abstand im Merkmalsraum) mit Objekt j (=Stern auf Karte) wird im NxN array i,j um eins erhöht. Das ergibt ein Voting-array, an welchem man am Ende sehr gut erkennen kann welcher Stern i zu j gehört. Es gibt also recht eindeutige i-j Paare.

Hat man das geschafft (die Implementierung ist sehr einfach. Ich konnte damals kaum programmieren und habs trotzdem hinbekommen ;) ) hat man N "Matchingsterne".
Mit denen kann man dann die "Plattenkonstanten" ausrechnen.(gibt 6 Stück davon)
Das sind im Prinzip die Koeffizienten einer Abbildungsmatrix, die die spährischen Koordinaten gnomisch auf die Kameraebene projiziert. Man hat also ein lineares Gleichungssystem
x'=ax+by+c
y'=dx+ey+f
bei dem man a-f bestimmen soll.
Da man bei z.b. 20 Sternen bereits ein überbestimmtes Gleichungssystem hat, bietet sich hier an dies durch eine Least Square Methode zu fitten.
Da es da auch schon viele fertige Algorithmen gibt, ist das ganze auch recht easy zu machen.

Soweit ich weiß gibt es auch andere ansätze bei denen es mehr als 6 Plattenkonstanten gibt, (um nichtlineare Effekte, also mehr als "rotation, translation, zoom, scherung etc.) abzubilden. Da bin ich allerdings überfragt.

So ich hoffe ich konnte dir ein wenig weiterhelfen.
Da ich damals selbst viel Zeit investiert hatte freut es mich, dass sich jemand wieder dafür interessiert :)
Leider bin ich zur Zeit etwas im Prüfungsstress, würde sonst auch gerne mal einen Blick auf den Code werfen.

Falls ich dir noch irgendwie behilflich sein kann, lass es mich wissen. Ich bin sehr gespannt, wie es weitergeht :)


Viele Grüße
Julian Stürmer

p.s. kurz vorm Abschicken der Nachricht habe ich doch das Paper hier auf dem Rechner gefunden...
FOCAS matching algorithms
p.p.s ich hatte auch mal was zur Helligkeitsbestimmung, das finde ich auch noch... :)

kleiner Nachtrag: habe gerade noch etwas zu den Plattenkonstanten gefunden: http://www.bellatrixobservatory.org/cvaaI/9/
viell. hilfts. :)
 
Zuletzt von einem Moderator bearbeitet:
Hallo Alex,

ich hab auch einen Test gegen die Kartendaten gemacht. Ich hab einfach einen Plot der Kartendaten in einer Datei gespeichert und dieses Bild als Bild in die Software zur Auswertung geladen. Das Ergebnis hier zeigt, das die Übereinstimmung doch recht gut nach der Transformation ist.



Gruß aus der Pfalz
 
Status
Es sind keine weiteren Antworten möglich.
Zurück
Oben