Archiv verlassen und diese Seite im Standarddesign anzeigen : [Signalverarbeitung] 1 oder 0, das ist hier die Frage
Hallo Leute,
ich habe ein Problem bei der Auswertung von Daten...
hier mal ein Beispiel wie ein "guter" Datensatz aussieht:
http://mad-clan.de/gray1.png
Das soll einfach nur in binäre Form umgewandelt werden.
zuerst dachte ich mir ich verwende mal (max - min)/2 als Schwelle,
was in diesem Fall auch völlig problemlos funktioniert und das korrekte Ergebnis 00001000111 liefert.
Dummerweise sehen aber nicht alle Datensätze so schön aus.
Dieser z.B. ist schon etwas schlechter, wird aber immernoch korrekt ausgewertet:
(man beachte die Skalierung der Y-Achse)
http://mad-clan.de/gray2.png
Leider geht es aber noch wesentlich schlechter, das sieht dann so aus:
http://mad-clan.de/gray3.png
Ob ihr es glaubt oder nicht: was man hier sieht sollte eigentlich 00000000000 sein.
Und genau hier versagt die einfache Variante, denn sie liefert 01111111111 (was natürlich völlig falsch ist).
Hier noch ein paar Details die vielleicht relevant sein könnten:
- Die mittleren 9 Bit sind Gray-codiert, und enthalten die eigentlichen Nutzdaten
- Das erste Bit gehört nicht zum Datensatz sondern ist der Mittelwert der Minima aller Datensätze.
(eingefügt habe ich es nur, um auch den Gray-Code 111111111 korrekt erkennen zu können)
- Das letzte Bit ist bei allen gültigen Datensätzen 1 (auf dem 3. Bild ist also ein ungültiger Datensatz zu sehen)
- Die Datensätze liegen in Form mehrerer Bilder vor (10 um genau zu sein, also ein Bild pro Bit bzw. ein Datensatz pro Pixel)
Vielleicht hat ja Jemand eine kreative Idee wie sich das sinnvoll auswerten lässt.
Mein erster Versuch wäre, den Mittelwert zu nehmen, dann drüber = 1 und drunter = 0
[quote="Felix G"](max - min)/2 als Schwelle[quote]
Macht er ja Praktisch schon, nur dass das ein Plus ein muss....
PickNick
Das habe ich schon ausprobiert, und leider sind die Ergebnisse damit sogar noch ein bischen schlechter :-(
@lpw
ups #-o
ich probiers gleich mal mit einem +
edit:
was so ein kleiner Fehler alles bewirken kann...
also mit (min+max)/2 ist das Ergebnis schonmal deutlich besser
wirklich optimal ist es allerdings noch nicht
Nach welchen kriterien gibt es denn die Ausgangswerte, denn ich finde, das beim lezten Beispiel es nicht eindeutig ist was das sein soll.
Das letzte Beispiel ist ein Schatten, also ein Pixel der auf allen 10 Bildern mehr oder weniger dunkel ist.
Wenn man die Skalierung der Y-Achse betrachtet sieht man sehr gut daß alle 11 Werte in einem Bereich liegen,
der bei den anderen beiden Beispielen ganz eindeutig als 0 eingestuft würde.
Die Schwierigkeit liegt also in der Entscheidung ob es sich um einen Schatten handelt,
oder doch um gültige Daten die einfach nur einen sehr niedrigen Kontrast haben.
Ich will mal verraten worum es hier geht: 3D-Bilderfassung durch Streifenprojektion
Dabei werden verschiedene Streifenmuster auf das Objekt projiziert und zwar derart,
daß in der Hell-Dunkel-Abfolge jedes Pixels die Nummer des Streifens codiert ist zu dem dieser Pixel gehört.
Da Kamera und Projektor prinzipbedingt gegeneinander verschoben sein müssen,
sind natürlich auch Schatten auf den Bildern die keine Informationen enthalten können.
Andererseits kann der Kontrast bestimmter Pixel aber auch deshalb niedrig sein,
weil das Objekt selbst an dieser Stelle vielleicht eine dunkle Farbe hat.
(und dann sind ja evtl. doch noch verwertbare Informationen enthalten)
Ich bin inzwischen davon überzeugt daß man die Pixel nicht separat betrachten darf,
sondern auch die nähere Umgebung in die Auswertung mit einbeziehen muss.
die Frage ist nur: wie?
Wie werden dann die Eingangsdaten verarbeitet? Beseitigst Du im Bild vorher die lokalen Helligkeitsschwankungen, die durch Abschattung entstehen (z.B. durch einen großen (!) Tiefpass?
Dann interessiert Dich ja der Übergang dunkel/hell bzw hell/dunkel zwischen zwei Pixeln. Bei einem derart gestörten Signal ist da ein globals Schwellenkriterium nicht besonders hilfreich. Du solltest in dem Fall lokale Kriterien anwenden (z.B. Sprung um mindestens n-Grauwerte). Auch hier gibt es noch potenzielle Probleme (z.B. Rauschen) aber auch das ist in den Griff zu bekommen.
Naja, die Streifen auf dem 9. Bild (also dem letzten Bild das noch zum Gray-Code gehört)
sind nur etwa 2-4 Pixel breit, deshalb bin ich da natürlich auch nicht mit irgendwelchen Filtern ran.
Momentan läuft die Auswertung so:
- (optional) vergrößern der 10 Bilder um einen frei wählbaren Faktor
- erstellen eines (einfarbigen) Dunkelbildes (das optimalerweise etwa so hell sein sollte wie ein Schatten)
- "Schwellenbild" erzeugen (Formel wie oben, also (max+min)/2)
- die ersten 9 Bilder (das 10. gehört nicht zum eigentl. code) nach binär umwandeln (mit dem zuvor errechneten Schwellenbild)
- für jeden Pixel: Hell-Dunkel-Abfolge decodieren, und als Dezimalzahl in die Ergebnismatrix schreiben
- (Ergebnismatrix wieder auf Originalgröße der Bilder verkleinern)
Das Ergebnis ist so schon ganz gut, aber es wäre halt schön wenn auch recht dunkle Streifen noch gut erkannt würden.
(also solche die ich auf den Bildern sehen kann, die aber mit dieser einfachen Methode nicht mehr erfasst werden)
Sehr praktisch wäre es auch, wenn ich zusätzlich zu den Ergebnissen jeweils noch ausrechnen könnte wie "zuverlässig" der Wert ist
(also quasi "Pixel x gehört mit y%iger Wahrscheinlichkeit zu Streifen Nr. z")
- Die Vergrößerung bringt m.E. nichts. Aber vielleicht hast Du ja gute Gründe das zu tun.
- Statt des Dunkelbildes (wie wird das erstellt) kannst Du ein Originalbild nehmen und mit einem großen Tiefpass filtern. Das gefilterte Bild ziehst Du dann vom Original ab. Damit verschwinden globale (!) Kontrastunterschiede
- jetzt kannst Du auf das Bild einen LoG-Filter (laplacian of gaussian) anwenden. Damit bekommst Du ein tiefpassgefiltertes Kantenbild (2. Ableitung) in dem Du nach lokalen Grauwertübergängen suchen kannst.
Mit dem Verfahren solltest Du die Kanten schwellenwertunabhängig finden. Ich habe die Filterung meistens auf Floats durchgeführt, die Ergebnisse werden da besser, da der Filterkern genauer berechnet werden kann. Du solltest aber mindestens mit einem 5er, besser: 7er Kern arbeiten.
Hallo,
wie wäre es mit einem Mindestwert und einem maximalwert für den Schwellenwert. Also du bildest den Schwellenwert weiterhin so wie jetzt, aber er muss mindestens 25 sein, ist er kleiner, wird er auf 25 gesetzt. genauso mit einem Maximalwert.
Das Problem mit dem Mittelwert tritt genau dann auf, wenn nur 1 oder 0 im Ergebnis vorkommt, weil dann mit der alten Berechnung der kleinste wert auf jeden Fall unter dem Schwellenwert liegt und der größte auf jeden Fall darüber. Für die Zuverlässigkeit der Aussage kannst du deshlab die Differenz zwischen kleinstem und größtem wert heranziehen. Ist die groß, weißt du, dass mindestens eine 1 und eine 0 in deinem Ergebnis vorkommt, dein Mittelwert also dazwischen liegt. Ist sie klein, ist die Wahrscheinlichkeit groß, dass lauter 1 oder 0 im ergebnis sind. Es also leicht zu Fehler kommt, weil der Mittelwe´rt an der falschen Stelle liegt.
MfG jeffrey
- Die Vergrößerung bringt m.E. nichts. Aber vielleicht hast Du ja gute Gründe das zu tun.
ich habe festgestellt, daß das Ergebnis mit Vergrößerung etwas besser ausschaut (bewirkt eine Kantenglättung)
- Statt des Dunkelbildes (wie wird das erstellt) kannst Du ein originalbild nehmen und mit einem großen Tiefpass filtern. Das gefilterte Bild ziehst Du dann vom original ab. Damit verschwingen globale (!) Kontrastunterschiede
tja, wie wird das Dunkelbild erstellt...
- ich erzeuge ein Bild welches aus den Mittelwerten der Eingangsbilder in Z-Richtung besteht (Matlab-Befehl: mean(images, 3) )
- dann berechne ich den jeweils kleinsten Wert pro Spalte, und aus denen wiederum den Mittelwert
das ist nur durch rumprobieren zustande gekommen und für meine Bilder liefert es einen Wert,
der etwa in der gleichen Größenordnung liegt wie die Schatten auf dem Bild.
Die Variante mit Tiefpass + log teste ich gleich mal.
edit:
@jeffrey
Also wenn ich dich richtig verstanden habe müsste die Berechnung etwa so aussehen:
(max(Pixel) - min(Pixel)) / max(Bilder), was mir dann einen Wert zwischen 0 und 1 liefert.
Hallo,
nein ich hatte an soetwas gedacht:
schwelle=min(150,max(25,(max(pixel)+min(pixel))/2));
hoff ich hab jetzt keine klammern vergessen.
mfg jeffrey
nochwas dazu zur bewertung, da könnte man soetwas machen, um eine aussage über die güte zu erhalten:
bewertung=min(abs(pixel(1:end)-schwelle))/max(pixel);
ka, ob des funzt, mal ausprobieren, ob was sinnvolles raus kommt.
mfg jeffrey
Das mag vergrößert besser aussehen, die Nutzinformation ist dann aber schon verändert.
Hast Du vielleicht ein Bild, dass DU hier mal posten kannst?
Also ich hätte hier mal zwei ganz frisch decodierte Bilder...
hier ohne Vergrößerung:
http://www.mad-clan.de/decoded_1.png
und hier mit Vergrößerung(2x):
http://www.mad-clan.de/decoded_2.png
(nein, das bin nicht ich)
Die wurden beide nach der von mir oben beschriebenen Variante ausgewertet,
was beim zweiten verständlicherweise viel länger gedauert hat als beim ersten.
Wie man sieht sind die Ergebnisse garnicht mal so schlecht, aber ich denke mir halt daß es auch besser gehen müsste.
@jeffrey
also bei der Schwelle willst du alles über 150 und alles unter 25 abschneiden, richtig?
Da ist es halt ein bischen schade, daß man diese Werte selbst festlegen muss
(schöner wäre es wenn derartige Grenzen automatisch errechnet werden könnten)
Was die Bewertung betrifft habe ich inzwischen einen relativ vielversprechenden Ansatz gefunden...
log(max(Bilder,[],3) ./ min(Bilder,[],3)));
Laut Wikipedia errechnet sich nämlich der Kontrast zu max/min, und das mache ich eben für jedes Pixel einzeln.
Den Logarithmus verwende ich, weil ein paar kleine Spiegelungen im Bild sind, bei denen der Kontrast natürlich extrem erhöht ist.
Resultat ist ein Bild bei dem die Schatten interessanterweise wesentlich dunkler sind als der Rest.
(also auch dunkler als Stellen die auf den Originalbildern aufgrund der Farbe des Objekts relativ dunkel sind)
Also bei den beiden Bildern ist der Ansatz mit dem großen Tiefpass und der Subtraktion mit Sicherheit erfolgreich. Du wirst dann ein Bild bekommen, dass nur noch die Kontraste des Vordergrundobjektes (und dessen Schatten) enthält, aber nicht mehr den "Graukeil" des Hintergrundes.
Hast Du mal ein Originalbild, so wie es von der Kamera kommt?
Der Graukeil ist Absicht ;-)
Die beiden Bilder da oben sind ja schon fertig ausgewertet, d.h. der Wert eines Pixels
entspricht der Nummer des auf dem Originalbild an dieser Stelle sichtbaren Streifens.
Da die Streifen von links nach rechts aufsteigend durchnummeriert sind, entsteht dieser Graukeil.
das ist das 9. Originalbild, also das mit dem feinsten Streifenmuster
http://www.mad-clan.de/bild9.png
wie man sieht gibt es Stellen an denen noch Streifen zu sehen sind,
die aber kaum heller sind als der große Schatten auf der linken Seite
Da sollte Dir der LoG eigentlich gute Kanten liefern. Da Dich in dem Fall speziell vertikale Kanten interessieren, kannst Du den Kern entsprechend wählen.
Hmm...
also ich habe mal den LoG auf alle Bilder angewendet und der macht die Kanten wirklich sehr gut sichtbar,
aber um diesen Filter verwenden zu können müsste der Rest der Auswertung deutlich komplexer werden.
Die Auswertung basiert ja darauf, daß in der zeitlichen Hell-Dunkel-Abfolge eines Streifens seine Nummer codiert ist.
Das kann aber nicht mehr funktionieren wenn man alle Bilder durch einen LoG Filter jagt, da dann alle Streifen grau sind.
(die Kanten sind zwar sehr schön hervorgehoben, aber ich kann den Gray-Code nicht mehr auswerten)
Als nächstes werde ich mal schauen wie die Bilder aussehen wenn man jeweils die Differenz zum vorherigen nimmt.
Bei Fester Kamera, Beleuchtung und Hintergrund hast Du bei der zeitlichen Abfolge im LoG, eine Abfolge von Kanten.
Aber da ich Deinen restlichen Algorithmus nicht ausreichend genug kenne, kann ich Dir da nicht viel mehr raten.
Also inzwischen hab ich noch einiges versucht, aber das Ergebnis wurde - wenn überhaupt - nur minimal besser.
Die Verbesserung steht jedenfalls in keinem Verhältnis zum erhöhten Aufwand, daher lasse ich das jetzt so wie es ist.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.