MastersForum

So, damit Worf und ich (und alle andern die es interessiert) in Ruhe schreiben können und den C++ Compiler Thread nicht weiter vollspammen, habe ich hier mal einen neuen Thread aufgemacht. Es geht um technische Details der Optic Flow Berechnung.

Also: Du hast natürlich recht das ich die Library ganz zu Anfang hätte gründlicher wählen sollen. Im moment bin ich allerdings mittendrin: Ich habe jede Menge ungetesteten Code. Wenn ich jetzt auch noch anfange on-the-fly die Matrix Library zu wechseln verliere ich gänzlich den Überblick. Stattdessen möchte erst wieder einen Zustand erreichen in dem das System läuft. Dann kann ich die Matrix Library austauschen und prüfen obs dann immernoch läuft.

Kurze Begriffserläuterung:

Lagged-Nonlinearity-Method: Das ist eine Methode um anstelle eines nicht linearen Gleichungssystems eine Serie linearer Gleichungssysteme zu lösen. Die Idee ist einfach den nicht linearen Ausdruck immer mit dem Ergebnis der vorhergehenden Iteration auszuwerten.

Warping: Ist ein Verfahren das man bei Optic Flow Computation dann benutzt, wenn es zwischen zwei aufeinanderfolgenden Frames weite Bewegungen gibt. Dann lässt sich der Datenterm nämlich nicht hinreichend gut mit Taylorexpansion linearisieren. Das Ergebnis ist ein nicht konvexes Energiefunktional, die dazugehörigen Euler-Lagrange Gleichungen haben also mehrere Lösungen und die unbekannten Funktion stehen im Argument. In diesem Fall verwendet man Warping, eine inkrementelle grob-nach-fein- Fixpunkt Iteration. Um das jetzt hinreichend zu erklären müsste ich noch einiges drum herum erklären. Das also nur so grob an dieser Stelle.

Beide (LNM und Warping) führen zu genaueren Verfahren zur Berechnung von Optic Flow (LNM erlaubt die verwendung subquadratischer Straffunktionen, Warping verbessert Ergebnisse bei großen Bewegungen), erhöhen aber den Rechenaufwand merklich. In Hinsicht auf meine Bachelorarbeit bedeutet das, das ich sie nur verwenden werden wenn die Ergebnisse ohne nicht genau genug für meine Zwecke sind (es geht um Gestenerkennung).

Und ja: Ich implementiere direkt in C++, ohne Matlab und Mathematica. Das ist für mich einfacher weil ich ja aus der Informatik komme und keine Erfahrung mit Matlab habe.

Jo, also....

Ja es geht um Optical Flow. Optic Flow. Das ist das selbe. Möglicherweise heißt es offiziell nur Optical Flow... anyways.

Also es geht nicht nur darum das nachzuimplementieren - das ist gewissermaßen selbst auferlegt weil ich hoffe so ein tieferes Verständnis zu erlangen. Wenn ich etwas fertiges nehmen wollte würde ich allerdings die C Libraries meines Lehrstuhls nehmen. Die sind absolute Experten auf dem Gebiet (die derzeit weltweit genauste Methode und etliche andere andere unter den Top 10 stammen von diesem Lehrstuhl, das ist Prof. Weickert, Andrés Bruhn und einige weitere für alle die sich auf dem Gebiet möglicherweise ein bisschen auskennen). Der zweite Grund (neben dem Lerneffekt) warum ich die C Libraries nicht nehmen möchte ist, das die eher nicht modular programmiert sind und nicht so ohne weiteres eingebunden werden können. Über OpenCV hatte ich zu Anfang auch nachgedacht es dann auf dringendes Anraten meiner Betreuer davon abgelassen. Das mag zwar arrogant klingen (und vielleicht auch sein), aber die sind der Meinung das das ziemlich verbugt ist und meinten andere am Lehrstuhl hätte versucht es zu verwenden und sich nur geärgert. Naja, selbst wenn das quatsch sein sollte will ich nicht am Ende mit Code da stehen den ich nicht verstehe und von dem mein Betreuer sagt: "Habe ich dir ja gleich gesagt". Sollte ich im Anschluss an meine Bachelorarbeit noch mal was zu diesem Thema machen werde ich mir definitiv ein genaueres Bild von OpenCV machen - aber für die Arbeit ist mir das zu riskant.

Und zum "Gehampel" :-P Doch, genau das wird bei den besseren Techniken gemacht. Ein paar Zahlen (grob): Mit einer korrekten Implementierung des sogenannten Horn/Schunck Algorithmus erreicht man für die sogenannte "Yosemite Sequence with Clouds" Average-Angel-Errors (das ist ein Fehlermaß) von etwa 10 Grad. Die originale Implementierung schaffte fast 32 Grad - die war nämlich nicht korrekt. Mit wirklich guten Methode kommt man auf nur 1,22 Grad AEE. Und dazu braucht man das "Gehampel".

An dieser Stelle noch mal der Hinweis: Ich fange mit der "schlechten" Horn und Schunk Methode an, weil es genug andere Probleme gibt die wahrscheinlich größeren Einfluss auf die Brauchbarkeit der Lösung haben und steigere mich dann wenn nötig.

Da meine Methode ja noch nicht vollständig entwickelt ist kann ich hier nicht alle Details erläutern. Aber zum groben Verständnis so viel (entschuldige bitte den Haufen Englische Fachbegriffe - aber ich mache das alles auf Englisch und kenne die deutschen Worte nicht, sollte es welche geben): Optical Flow nennt man das Displacement Field, das beschribt von wo nach wo sich ein Pixel im zwischen einem Frame und dem darauffolgenden Frame bewegt hat. Da geht es nicht um cluster, sondern um jeden einzelnen Pixel. Dabei gib tes eine Reihe von Problemen, die wichtigsten sind: Das Aperture Problem. Beispiel: Ich habe zwei Frames mit unterscheidlichen Ausschnitten einer ideal weißen Wand. Dann habe ich zwei weiße Frames in denen Null Information übr die Bewegung steckt. Oder aber ich habe eine weiße Linie, die sich bewegt. Wen nich nun jeden Pixel einzeln betrachte kann ich nicht sagen welcher Pixel im ersten Frame welchem Pixel im zweiten Frame entspricht. Ein anderes Problem wäre Subpixel Replacement: Ein schwarzer Pixel bewegt sich um einen halben Pixel. Dann würde vo nder Camera im zweiten Frame zwei graue Pixel nebeneinander angezeigt werden (die Intensität verteilt sich auf den alten und den halben neuen Pixel).
Üblicherweise hat man deshalb einen Data und einen Smoothness Term im Energiefunktional: Der Dataterm bestraft Abweichungen von den gewählten Annahmen (Greyvalue Constancy, Gradient Constancy...). Der Smoothness Term bestraft unregelmäßigkeiten im Flow Field, weil man davon ausgeht das benachbarte Pixel sich oft in eine ähnliche Richtung bewegen. Da gibt es dann Clevere Methoden die noch Edge Detection mit reinnehmen und tausend andere Späße.

Nun aber zurück zu dem was ich mache: Ich versuche Gesten anhand dieser Flussfelder zu kategorisieren. Die Grundhypothese ist, das Flusselder über mehrere Frames in irgendeiner Form charakteristisch sind für eine bestimmte Geste. Das klappt natürlich nur mit Gesten in denen Bewegung die wichtigste Rolle spielt. Dazu verwende ich also Verfahren zu Optischen Fluß Berechnung und verwende dann einfache Statistische Verfahren um die Ergbenisse zu quantifizieren und kategorisieren. Wie genau verkünde ich dann wen ndie Arbeit fertig ist :-)

Die Betonung bei all dem liegt auf EINFACH, aus zweierlei Gründen:

1. Eine Bachelorarbeit dauert alles in allem 3 Monate - das ist nicht sooo viel Zeit für komplexe Verfahren.
2. Warum kompliziert wenn es auch einfach geht? Und wenn sich herausstellt, das es einfach (jedenfalls so) nicht geht, dann hat man ja auch was dazugelernt.

jo, jetzt habe ich alles auf xcode umgestellt, bugs gefixt und es läuft irgendwie. Das wäre jetzt der Moment wo ich evtl auf Boost oder so umsteigen könnte. Vielleicht schaue ich mir jetzt mal an ob Boost meine "symmetrischen tridiagonalmatrizen mit seitenband" kann.

ich habe mir opencv jetzt mal näher angeschaut. Was cool ist ist das Webcam interface (das heißt, obs cool ist weiß ich nicht, aber kewl ist das es eins hat). An optic flow kann es nur Horn und Schunck, das ist schon sehr dürftig. Ich habe schon überlegt ob ich mich nac hder Arbeit mal hinsetze und da ein bisschen ergänze. Ist ja eigentlich schon cool so ne library. Mal sehen wieviel Zeit ich dann habe. Jetzt für die Arbeit werde ich die Zeit nicht haben mich da einzuarbeiten.