spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Moin,

ich habe ein Verständnisproblem bei folgendem paper: http://ieeexplore.ieee.org/xpl/login.jsp…number%3D238279

Viele können das vmtl nicht kostenfrei einsehen, daher hoffe ich meine folgende Erklärung reicht aus. Es geht prinzipiell darum aus einem Graustufen-Bild das Zentrum eines Blobs zu finden.

Dazu wird (separat für X und Y Achse) folgender Algorithmus angwendet:

Original-Text:
The gray-value ramp in Fig. 3 is an image that encodes the horizontal coordinate value (0-255) for each point in the image as a gray value. Thus, it is in immage that is black (0) at horizontal pixel 0 and white (255) at horiztontal pixel 255. If we logically and each pixel of the above threshold velocity image (Anmerkung: Graustufen-Eingabe Bild in dem die Position eines Blobs gefunden werden soll!) with the ramp image, we have an image which encodes high velocity pixels with their positional coordinates in the image, and leaves pixels with no motion at zero.

Also generell geht es darum ein Objekt zu detektieren, das sich bewegt. Die Bild ist bereits so codiert, dass helle Pixel eine "hohe Bewegung" kodieren und dunkle Pixel "wenig Bewegung". Insgesamt haben wir hier mit einem 8-Bit Bild und einer Auflösung von 256x256 zu tun.

Ich verstehe schonmal gar nicht, wie auf ein Pixel mit diesem Ramp-Image ein logisches und angewendet werden soll.
Am Ende sollen Pixel die sich nicht/wenig bewegen, dann möglichst schwarz sein, generell soll aber in den Pixel die Position kodiert werden (Für eine Achse logischerweise). Anschließen wird im nächsten Schritt mit einer Kombination aus Histogram und Mittelwert das Zentrum des Blobs ermittelt.

Ich steh irgendwie total auf dem Schlauch und steig da schon ziemlich aus was den jetzt genau passieren soll und dann schlussendlich effektiv im Bild kodiert ist nach diesem logischen UND mit dem Ramp-Image.

Herzlichen Dank, an denjenigen der mir hier weiterhelfen kann!

Klingt für mich so als sei das "threshold velocity image" nur noch ein Binärbild, bei dem Pixel oberhalb des Threshold weiß, sonst schwarz sind. Ein logisches UND beider Bilder schreibt dann die Position weißer Pixel in den Pixel. Vermutlich wird das so gemacht, um später keine Fallunterscheidung treffen zu müssen und alle Pixel zur Bildung des Mittelwert der hellen Pixel aufaddieren zu können, ähnlich der berühmten Funktion BitBlt.

Zitat von »fraggr«

Klingt für mich so als sei das "threshold velocity image" nur noch ein Binärbild, bei dem Pixel oberhalb des Threshold weiß, sonst schwarz sind. Ein logisches UND beider Bilder schreibt dann die Position weißer Pixel in den Pixel. Vermutlich wird das so gemacht, um später keine Fallunterscheidung treffen zu müssen und alle Pixel zur Bildung des Mittelwert der hellen Pixel aufaddieren zu können, ähnlich der berühmten Funktion BitBlt.

Ja du hast Recht, es ist ein Binärbild indem die betreffenden pixel als 255 kodiert sind. Und auch damit warum man das macht hast du Recht. Das mit dem Threshold um ein Binärbild zu erzeugen habe ich irgendwie übersehen, aber damit ist es leicht verständlich.

Vielen Dank!