ZFX + Developia

Nach dem ich über eine Stereokamera mehere Tiefenbilder gewonnen habe stehe ich jetzt vor dem Problem diese in ein 3D Mesh um zu wandeln und diese dann zu einem zusammen zusetzen. Auf den ersten Anhieb sind mir zwei Varianten in den Sinn gekommen.

Allgemein: Der Ursprung ergibt sich bei mir Realativ, da ich das Stereokamerasystem irgendwo mal hinstelle und von dort aus relativ messen beginne.
Ebenso kann ich die Blickrichtung schätzen.

Hier würde ich eine Parallelprojektion des Meshs ansetzen.
Das bedeutet, dass der Blickvektor von der Kamera zum Blick(Target)Punkt ein LookAt Vektor ist, oder? Darauf müsse sich die Ebene in der die Polygone (ohne Tiefe) liegen dann bestimmen lassen, aber wie lege ich in dieser Ebene dann die Punkte fest ohne, dass sie verzerrt oder verdreht werden? Würde dies über ein rechtwinkliges Koodinatensystem an diesen Punkt dann dann berechenbar sein?
- Der Normalenvektor und zwei auch rechtwinklig auf einander stehende Vektoren bestimmen um das Koodinatensystem zu erhalten.
- wenn man dann diese normalisiert sollte man in Schritten der Vektoren die Punkte bestimmen
Die "Tiefe" der Punkte kann ich dann über einen Normalisierten LookAt Vektor bestimmen. ( Ziel zu Kamera Vektor)

Kann man diese Berechnungen in eine Transformationsmatrix-Matrix packen (wenn ja wie) oder muss man hier jeden der Schritte einzeln für jeden Punkt berechnen? Vom Laufzeit verhalten dürfte es massiv an Echtzeit vorbei gehen...

Ich vermute, dass hier es zu Fehlern kommen wird. Welche sich dann im Matching bemerkbar machen werden, da eine Kameraaufnahme keine Paralellprojektion ist. Deshalb kommt jetzt die zweite Variante in der ich die Brennweite der Kameras miteinrechne.

Der Ursprung, Kameraposition usw ist wie oben, aber nun müsste ich um die Tiefe der Punkte zu bestimmen den Strahlensatz bemühen...
Also für jeden Punkt des Meshs einen Vektor bestimmen, diesen Normalisieren und dann darauf addieren.
Ob dies schnller geht?

Hat jemand schon mal sowas gemacht? Oder Erfahrungen wie man diese Berechnungen ansetzt ohne alles mit Vektoren zu rechnen?

Dieser Post kannst du ruhig als Sinnlos deklarieren:

Finde ich ja mal genial was du vorhast.
Es gibt schon solche Programme, die dir aus >2 Fotos ein Mesh generieren.
Das Programm das ich meine, kommt ohne die Parameter der Kamera aus:
http://www.photo-to-3d.com/

Wie ist das zu verstehen, das du schon mehere Tiefenbilder gewonnen hast?
Was meinst Du damit?

Gruß

joggel hat geschrieben:Dieser Post kannst du ruhig als Sinnlos deklarieren:
Finde ich ja mal genial was du vorhast.
Es gibt schon solche Programme, die dir aus >2 Fotos ein Mesh generieren.
Das Programm das ich meine, kommt ohne die Parameter der Kamera aus:
http://www.photo-to-3d.com/
Wie ist das zu verstehen, das du schon mehere Tiefenbilder gewonnen hast?
Was meinst Du damit?
Gruß

Ist er nicht ^^
genial ist es, es ist ja auch meine Bachelorarbeit ist an welcher ich sitze. Programme welche aus 2 Bildern ein Mesh machen gibt es zwar schon, aber diese haben wie auf der Webseite zu sehen ja einige Lücken im Mesh. Diese Lücken sollte ich wegoptimieren um ein besseres Bild zu erhalten gleiches gilt fürs zusammen Setzen der Meshes. Von der auf der Seite angegebenen Berechnungszeiten sollte ich ebenso fern bleiben (Echtzeitfähig wie möglich). Je mehr parameter man in einer Berechnung hat desto genauer sollte das Mesh werden.

Zu den Tiefenbildern: Hier habe ich schon einiges mit OpenCV und EmguCV entwickelt ebenso habe ich eine eigene "Stereokamera" (2 Webcams) zusammen gebaut damit ich möglichst gute Tiefenbilder erhalte. (Wenige Störungen im Tiefenbild wie es der Algo zulässt ^^ und Echtzeitfähig) Damit habe ich bereits einige Aufnahmen geschossen und diese als Bilder Datenbank für Referenzwerte gespeichert. (Plus einige künstliche Aufnahmen von 3D Umgebungen).

Hi,

das Stichwort unter dem du tonnenweise Material finden wirst heisst Structure From Motion, oder auch SfM für Insider :)

Trivial ist das nicht, und ein Stereosetup mit wenig Aufnahmen macht das auch nicht wirklich einfach. Normalerweise macht man es sich ja dadurch einfach, dass man seine Kamera zunächst kalibiert, und zwar idealerweise durch Aufnahme eines Kalibrierobjektes. Daraus kann man dann die Kamera Intrinsics und Extrinsics ableiten. Gestern gab es einen interessanten Bericht dazu auf Kabel 1: http://www.kabeleins.de/auto/abenteuer_ ... ll_151696/

Als Kalibrierobjekt dienen dabei Klebepunkte und definierte Maßstäbe auf dem Objekt. Dann werden eine Reihe von Fotos geschossen, aus denen dann eine Punktewolke im 3D berechnet wird, namentlich die Klebepunkte. Dann kommt der Stereosensor ins Spiel und macht Aufnahmen von dem Modell. Die 3D Punktewolke dient dabei als "Kalibrierung" für den Stereosensor. Die vom Stereosensor gewonnenen Oberflächendaten (Meshteile) werden dann über ein Alignment mit Hilfe der erkannten 3D Punkte in der Punktewolke zueinander ausgerichtet.

Wenn man ohne jegliche Kalibrierung an die Sache rangeht ist es deutlich schwieriger, überhaupt passende 3D Daten zu gewinnen. Aber die oben genannte Stichwort SfM sollte dir genug Treffer zu entsprechenden Papers liefern.

Darf ich fragen, was du mit OpenCV bisher schon gemacht hast? Ich habe gerade erst angefangen, damit herumzuspielen. Es ist schon beeindruckend, was man mit einem einzelnen Funktionsaufruf so alles bekommt. Allerdings würde ich gerne die Intrinsics einer Kamera ohne Kalibrierung berechnen. Wie machst du das um zum Beispiel die Brennweite zu bestimmen und die Verzerrung herauszurechnen? Wenn ich OpenCV richtig überblicke, dann bietet das einem nur die Chance die Intrinsics halbwegs stabil zu berechnen, wenn man ein Schachbrettmuster vor die Kamera hält?

Ciao,
Stefan

Zum Kalibieren:

Da bin ich schon am Emgu Forum an schauen was dort nicht stimmt. (Emgu wird anscheinend ohne groß Testen online gestellt, da auch andere Probleme haben.)

Zum Video:
Das hat gerade meinen Laptop gekillt... 2 Mal kein Bild mehr dann Bluescreen (Unter Win7 echt nicht schön wenn sowas vorkommt)
Soweit ich aber die Vorschau des Kabel 1 Beitrags verstanden habe ist dies ein Aktives Verfahren gewesen oder?

Zum Stereosensor: Dies könnte ein TOF (Time of Flight) Sensor sein oder ein Laser Scanner, aber in meiner Arbeit geht es um einfache Webcams als Sensoren.

Mit OpenCV bin ich schon erfahren einige Studienarbeiten und private Spielereien habe ich da hinter mir meist war es aber Bildverarbeitung im Sinne von Bildverbesserung (Glätten, Farbänderungen usw) meine Spielereien waren auch mal Gesichtserfassung um ein Objekt aus verschiedenen Blickrichtungen anzuzeigen. Bei diesen Sachen kam es nie dazu, dass etwas nicht geklappt hat, bis ich zum Kalibieren gekommen bin... Mit den letzten 3 Emgu Versionen hat immer etwas anderes nicht geklappt.

"Allerdings würde ich gerne die Intrinsics einer Kamera ohne Kalibrierung berechnen. Wie machst du das um zum Beispiel die Brennweite zu bestimmen und die Verzerrung herauszurechnen?"
Da suche ich auch, aber dies sollte sich auch Kalibieren lassen, aber im Moment (siehe Bild oben) stimmt etwas an Emgu nicht und daher mache ich erst mal den 3D Teil weiter (hier verwende ich XNA).

Das "Structure From Motion" ist ein guter Tipp danke. Im Moment geht es erstmal darum das Mesh richtig zu erstellen bevor ich es dann Matche.

Ich werde leider weder aus deinen Bildern, noch aus deinem Text so richtig schlau, allerdings erscheint mir prinzipiell eine Zentralprojektion (Modell Lochkamera) wesentlich naheliegender als eine Parallelprojektion. So wahnsinnig schwierig dürfte das auch nicht sein, letztlich würdest du wohl für jeden Pixel die 2D-Pixelkoordinaten relativ zum Zentrum des Bildes nehmen, die so gewonnenen X- und Y-Koordinaten des Pixels mit zwei Kalibrierungsfaktoren (a, b) skalieren, daraus dann p_d = (a * x, b * y, 1) bilden, normalisieren (p_d = p_d / ||p_d||), und den 3D-Bildpunkt mit p = p_d * Pixeltiefe konstruieren. Der Bildpunkt ist dann relativ zur Kamera positioniert, der Pixel in der Mitte liegt direkt vor der Kamera in Blickrichtung (auf der Z-Achse des Kamerakoordinatensystems), d.h. in einen "absoluten Raum" müsstest du dann nur noch alle Punkte mit der entsprechenden Kameramatrix multiplizieren. Wenn du so alle paar Pixel mal Vertices erzeugst, solltest du mit passenden Konstanten schonmal ein akzeptables Mesh bekommen, wenn ich das soweit richtig verstanden habe?

Wozu du die ganzen Normalenvektoren brauchst verstehe ich leider gerade nicht, vielleicht kannst du das nochmal versuchen zu erläutern?

CodingCat hat geschrieben:Ich werde leider weder aus deinen Bildern, noch aus deinem Text so richtig schlau, allerdings erscheint mir prinzipiell eine Zentralprojektion (Modell Lochkamera) wesentlich naheliegender als eine Parallelprojektion. So wahnsinnig schwierig dürfte das auch nicht sein, letztlich würdest du wohl für jeden Pixel die 2D-Pixelkoordinaten relativ zum Zentrum des Bildes nehmen, die so gewonnenen X- und Y-Koordinaten des Pixels mit zwei Kalibrierungsfaktoren (a, b) skalieren, daraus dann p_d = (a * x, b * y, 1) bilden, normalisieren (p_d = p_d / ||p_d||), und den 3D-Bildpunkt mit p = p_d * Pixeltiefe konstruieren. Der Bildpunkt ist dann relativ zur Kamera positioniert, der Pixel in der Mitte liegt direkt vor der Kamera in Blickrichtung (auf der Z-Achse des Kamerakoordinatensystems), d.h. in einen "absoluten Raum" müsstest du dann nur noch alle Punkte mit der entsprechenden Kameramatrix multiplizieren. Wenn du so alle paar Pixel mal Vertices erzeugst, solltest du mit passenden Konstanten schonmal ein akzeptables Mesh bekommen, wenn ich das soweit richtig verstanden habe?

Wozu du die ganzen Normalenvektoren brauchst verstehe ich leider gerade nicht, vielleicht kannst du das nochmal versuchen zu erläutern?

"in einen "absoluten Raum" müsstest du dann nur noch alle Punkte mit der entsprechenden Kameramatrix multiplizieren"
public static Matrix CreateLookAt ( Vector3 cameraPosition, Vector3 cameraTarget, Vector3 cameraUpVector )
Diese Matrix müsste sich dann über einen CreateLookAt bestimmen oder?

Welche Achse ist die Blickrichtung?
Die ganzen Normalenvektoren würden dazu dienen um das Relative Koodinaten system zu beschreiben, aber die Multiplikation mit der Kameramatrix sollte dies übernehmen. (Manchmal kommt man nicht aufs einfachste...)

Mit CreateLookAt ausgedrückt müsste die richtige Kamera-Matrix CreateLookAt(cameraPosition, cameraPosition + cameraDirection, cameraUp) sein, transformieren müsstest du aber mit deren Inversen, d.h. vor der Transformation ist die Blickrichtung einfach die Z-Achse, danach ist die Blickrichtung cameraDirection.

Welche Tiefeninformationen hast du denn? Zum einen interessiert mich, wie man das in OpenCV aus Stereokameras bekommt.

Zum anderen geht das natürlich in Richtung Ambient Occlusion im Screen Space bzw. sogar in das Deferred Rendering. Da hat man nämlich denselben Wunsch, und zwar aus einem linearen Depth Buffer und den Pixelkoordinaten die 3D Weltposition zu rekonstruieren. Dazu findest du hier einen entsprechenden Artikel mit Code wie man das in einem Shader macht. Aber die Logik dahinter sollte einfach auf die Welt ohne Shader zu übertragen sein ;)

http://mynameismjp.wordpress.com/2009/0 ... rom-depth/

Ciao,
Stefan

@CodingCat: Das mit der Matrix probiere ich noch aus. (Ich bin erst drauf gekommen, das meine Kamera die Darstellung verfälscht.)

@Stefan Zerbst: für eine "Echtzeit" Verarbeitung nutze ich den Block-Matching Algo (Klasse: StereoBM) für schönere Flächen nehme ich den Graph Cut (StereoGC). Problem ist, dass man für gute Ergebnisse Pixel- und Subpixelgenau die Kameras einstellen muss, dann noch für das richtige Licht sorgen muss usw...

Die Konstruktion, die ich oben beschrieben hatte, kommt ja gerade von der Weltpunktrekonstrution aus dem Bereich tiefenbasierte Grafikeffekte. Wobei man dort noch effizienter davonkommt, wenn man nicht den Abstand zur Kamera nutzt, sondern den Abstand zur Sichtebene, in der die Kamera liegt, einfach mittels Projektion der Positionen auf den Richtungsvektor der Kamera. In diesem Fall kann man sich nämlich die Normalisierung bei der Rekonstruktion der 3D-Weltposition einfach schenken.

Ich merke das deshalb an, weil es in der Tat eine Rolle spielt, was für Tiefenwerte du da eigentlich hast. Ich bin jetzt einfach mal stillschweigend davon ausgegangen, dass die Tiefen gerade den Abstand des Bildpunktes vom Punkt des Betrachters darstellen. Solltest du dagegen den Abstand zur Bildebene vorliegen haben, müsstes du die Normalisierung entsprechend weglassen.

Interessant, über Disparity Maps hatte ich bisher noch nichts gelesen. Hier gibt es einen Artikel wie man aus den Maps die 3D Positionen berechnen kann. Aber Lücken scheinen da auch aufzutreten. Ich müsste erst etwas mehr über Disparity lesen, wie man es errechnet und wie der Zusammenhang zu echten Tiefenwerten dabei ist.

http://www.cs.washington.edu/homes/indr ... paper.html

Kurzes schnelles Danke, dass mit dem Invertieren war ein guter Hinweis. Am Rest sitze ich noch ^^

PS: Das Rote ist ein Ring welcher um eine Figur in Blau gelegt ist daneben befindet sich eine grüne Pyramide. (Wenn man das Original kennt sieht man es besser ^^)

Sieht zwar nicht so aus, aber mit der Projektion liegen die Punkte viel besser als vorher. Leider hat mir die Projektion meine Entscheidungen welche Polygone ich lösche über den haufen geworfen...

Wie kann ich an Hand eines sinnvollen Merkmals festmachen, dass meine Polygone "zu sehr" verzerrt sind. Mein Ansatz über die Flächeninhalte zu gehen ist leider nicht mehr erfolgreich, da die Flächen auf eine Kugel projeziert werden und die entfernte Polygone mehr gestreckt werden als die anderen. Mein neuer ansatz ist es auf die Werte des Tiefenbilds zu gehen.

Ich berechne mir aus 4 Punkten den Farb Mittelwert danach bestimme ich die Standardabweichung und entscheide an hand eines Schwellenwerts ob die Abweichung zu groß ist oder nicht. Wenn "zu groß", dann verwerfe ich das Polygon (4Eck) wenn nicht dann suche ich nach einem Ausreißer (Grubbs Test) und entferne diesen einen Punkt damit wird der Rest zu einem Dreieck. Aber liegt eine Gauß-Verteilung bei Bild-Pixeln vor oder eher eine Gleichverteilung von Zufällen?

Edit: neues Bild ^^ jetzt sieht es schon besser aus leider liegen die Flächen noch nicht Optimal.

Hi

ich kann darauf nicht viel erkennen ;)

Vielleicht zeigst du mal ein Fotos dazu, was aufgenommen wurde. Dann wäre auch ein Bild von der Punktewolke an sich noch hilfreich.

Ciao,
Stefan

Ich habe zwar leider nicht die ganze Diskussion mitverfolgt, von daher weiß ich nicht, ob soetwas schon geschrieben wurde.
Du hast ja ein Tiefenbild aus den Fotos generieren können.
Also, jeder Bildpunkt hat eine 3D-Koordinate, oder?
Daraus entsteht ja eine Punktwolke.
Aus dieser Punktwolke könnte man dann doch einen Mesh generieren.
Stichpunkt wäre zum Beispiel: "Crust-Algorithmus".

Hab letztens auch ein YouTube-Video gesehen, die ein guten Algorithmus vorgestellt haben... aber finden tue ich das nicht mehr.

Um aus Punktwolken Meshes zu generieren gibt es eine ganze Reihe von Ansätzen. Genannt wurde bereits von joggel die Crust&Cocone-Familie, welche ich auch am überzeugensten finde. Papers zu diesem Thema gibt es wie Sand am Meer, besonder schwer (mit den richtigen Bibliotheken) zu implementieren ist das auch nicht. Wie gut die Verfahren auf Stereo-Daten arbeiten kann ich leider nicht beurteilen, da ich auf LiDAR-Daten arbeite. Ohne jetzt selbst gesucht zu haben, würde ich behaupten, dass es in diese Richtung sicher auch Forschung gab. Anzumerken ist natürlich noch, dass diese Verfahren sehr langsam sind, aber dafür auch wirklich schöne Ergebnisse liefern.

Gibts was neues an der Foto-to-Mesh-Front?


Gruß Joggel

joggel hat geschrieben:Gibts was neues an der Foto-to-Mesh-Front?
Gruß Joggel

Ja und nein ich muss erst mal einige Seiten an meiner BA schreiben und mir geht die Zeit aus...
Problem sind die "Tiefenbilder", da man nicht direkt von einer Farbe auf eine Tiefe schließen kann. Die "disparity maps" sind auch sehr ungenau als, dass man einen zusammenhang ziehen kann. Nett ist auch, dass die Texturierung eine Verschiebung ausmachen kann. Dazu habe ich einige Bilder gerendert und die Textur immer wieder geändert... mal ist das Objekt näher mal weiter weg... Ergebnis ist halt, dass man mit Emgu und reinen Kamerabildern nicht so genau wird wie ich es gerne hätte.

Aha, okay.

Ergebnis ist halt, dass man mit Emgu und reinen Kamerabildern nicht so genau wird wie ich es gerne hätte.

Schade eigentlich.

Good luck..

joggel hat geschrieben:Aha, okay.

Ergebnis ist halt, dass man mit Emgu und reinen Kamerabildern nicht so genau wird wie ich es gerne hätte.

Schade eigentlich.

Good luck..

"Endstand":
Meine Messungen sind nun alle eingetragen ich komme in virtuellen Aufnahmen (ohne Störungen) auf eine Standardabweichung von ca. 30 cm.
Einzelne Aufnahmen können einen Fehler von einem Meter aufweisen.
Wenn man sich die Tiefenbilder ansieht kommt es einen ganricht so massiv vor...

Nochmal danke an alle ^^

Apropos 3D Scannen :) http://www.trimensional.com/ Das ist mal eine lustige Idee :)

Da fällt mir eine Idee dazu ein... weiß aber nicht in wie weit man die Umsetzen kann, oder in wie weit sie "gut" ist.
Durch diese "3D Scanner" für iPhone könnte man ja Apps/Spiele machen, die auch mit "gescanten" Objekten funktionieren.
Interessant wäre auch noch zu wissen, ob man Objekte damit komplett (rundum) abscannen kann, oder nur von einer bestimmten Seite.

Nur mal so ein Gedankenspiel... :D