Bewegungsmelder

[raffo]

Habe seinerzeit von der Heft CD PC-Magazin das wunderbare Programm LiveCam Pro 2.0 bekommen, das auch diesen Bewegungsmelder drin hat, funktioniert vorzüglich und man kann einen Schwellwert einstellen - ob das alles so einfach ist, bezweifle ich.

[glkgereon]

ich würde auf 256 farben reduzierte bitmaps nehmen...

sonst löst ein auto das in 500m entfernung vorbei fährt und überall minimal erhellt den sensor aus

reduziert man die farben, muss es schon näher kommen

Edit:
Ansonsten wäre es noch interessant das ganze lernfähig zu machen (So man gibt 2 Bilder rein und sagt ihm "Melden" oder "Nicht melden" und er vergleicht jeweils die Änderungsquote à là DGL-Luke)...

so kriegt man eine realistische zahl

[himitsu]

Mit weniger Farben hast du dann aber relatv gesehen größere Sprünge in den Farbwerten.

ein vorbeifahrendes auto kann also bei weniger möglichen arbwerten einen viel größeren Sprung verursachen.

Bei mehr möglichen Farben verändert sich das ergebnis zwar stärker, aber über das gesamte mögliche Farbspektrum ist die Veränderung dann relativ gesehen geringer


Bei 16 Farben entspricht eine Veränderung von einem Schritt gleich 6.3%,
wobei es bei 256 Farben nur noch 0.4% sind.

[w3seek]

Ist zwar in C# aber vielleicht hilft es dir ja: http://www.codeproject.com/cs/media/..._Detection.asp

[glkgereon]

das problem ist:

nimm 16 bit, und du hast in jedem pixel ne farbänderung, immer.
jedes auto, das in 500m vorbeifährt, jedes eichhörnchen das einen fahren lässt, jede nervensäge die durch nen ball nen minimalen schatten verursacht wird alles ändern. viel zu empfindlich. klar kann es sein das sich durch eine erhöhte fehlergrenze das alles regulieren lässt...aber ich würde trotzdem die 256 farben nehmen. um eine "wirkliche" änderung zu erkennen reicht es imho.

oder ausprobieren.


wie hoch jeweils diese grenze sein soll, musst du ausprobieren.

[himitsu]

Ja, es wird dann natürlich immer größere änderungen geben.

Aber da er ja eh mit einem Schwellwert rechnen muß, ist das doch wieder ausgeglichen.

Bei 16 Farben ist für eine Anderung von mindestens 50% ein Schwellwert von 8 nötig,
wobei es bei den 256 Farben dann ein Schwellwert von 128 sein wird.

Also zuerst ist bei mehr möglich Farbewerten die Fehlerrate geringer und dann kann man dort auch noch feiner abstimmen, da ja auch der Schwellwert kleinere/mehr Schritte besitzt.



Ach ja, ich würde noch empfehlen das Bild in mehrere Abschnitte zu unterteilen und dann den Abschitt mit der größten Veränderung mit dem Schwellwert zu vergleichen.

[turboPASCAL]

So einen "Bewegungsmelder" zu machen ist gar nicht so leicht. Wenn man bedenkt das jedes Bild zu dem vorherigen unterschiedlich ist welches von einer Kamera aufgenommen wird. Damit meine ich das Bildrauschen was in der Kamera entsteht. Jeder Pixel ist von den Farbwerten leicht unterschiedlich.
Um das zu umgehen müsste man die Farbwerte verringern, ein Graustufenbild mit 256 Farben wäre da eine Alternative.
Jetzt könnte man ein aufgenommenes Bild (Bitmap) mit einem davor aufgenommenen Bild vergleichen.

Dabei ist die nun die Frage wie diese beiden Bilder verglichen werden sollen.

- gesamte Bilder vergleichen Pixel für Pixel / hohe Fehlerrate bei viel Bewegungen

- Bilder in Bereiche aufteilen und anschließend diese vergleichen / hohe Genauigkeit geringe Fehlerrate

Zum vergleichen von zwei Bitmaps Pixel zu Pixel zwei einfache Varianten:

abfragen der Pixel uber die GDI mit:

Delphi-Quellcode:

for y := 0 to Bitmap1.Height -1 do
      for x := 0 to Bitmap1.Width -1 do
      begin
        Bitmap1_PixelColor := Bitmap1.Canvas.Pixels[x,y];
        Bitmap2_PixelColor := Bitmap2.Canvas.Pixels[x,y];
        if Bitmap1_PixelColor <> Bitmap2_PixelColor then ...
      end;

da diese Funktion sehr langsam ist sollte man sich für Scanline entscheiden. Das würde dann so aussehen:

Delphi-Quellcode:

function BitmapCompare(Bitmap1, Bitmap2: TBitmap; DifferentPixel: Integer): TRect;
var
  y, x, CountDifferentPixel: Integer;
  Bitmap1Pixel, Bitmap2Pixel: PRGBQuad; // PRGBQuad def. in Unit Windows;
  aRect: TRect;
begin
  // ein Rechteck auf Min-und Maxwerte vordef.
  aRect := Rect(65000, 65000, 0, 0);
  CountDifferentPixel := 0;

  for y := 0 to Bitmap1.Height - 1 do
  begin
    // Bitmaps Y Linie einlesen
    Bitmap1Pixel := Bitmap1.ScanLine[y];
    Bitmap2Pixel := Bitmap2.ScanLine[y];

    for x := 0 to Bitmap2.Width - 1 do
    begin
      // Pixel farbwerte vergleichen zw. Bitmap1Pixel u. Bitmap2Pixel
      if RGB(Bitmap1Pixel^.rgbRed, Bitmap1Pixel^.rgbGreen, Bitmap1Pixel^.rgbBlue) <>
        RGB(Bitmap2Pixel^.rgbRed, Bitmap2Pixel^.rgbGreen, Bitmap2Pixel^.rgbBlue) then
      begin
        // das Rechteck (aRect) auf die Werte der unterschiedlichen
        // Pixel erweitern die ausserhab des Bereiches des Rechtecks liegen
        if x < aRect.Left   then aRect.Left   := x;
        if y < aRect.Top    then aRect.Top    := y;
        if x > aRect.Right  then aRect.Right  := x;
        if y > aRect.Bottom then aRect.Bottom := y;
        Inc(CountDifferentPixel);
      end;
      // Zeiger auf nächsten Pixel setzen
      Inc(Bitmap1Pixel);
      Inc(Bitmap2Pixel);
    end;
  end;
  // keinen Unterschied gefunden dann kein Rechteck ansonsten
  // das Rechteck zurückgeben in dem sich die Pixel unterscheiden.
  if CountDifferentPixel > DifferentPixel // Grosse des Schwellwerts der Unterschiede
    then Result := TRect(0, 0, 0, 0)
    else Result := aRect;
end;


// Umwandeln eines Bitmaps in Grauwerte auf einfache Art und Weise (eine Möglichkeit von vielen)
procedure MakeGreyBitmap(aBitmap: TBitmap);
var
  PixelLine: PByteArray;
  x, y: integer;
begin
 aBitmap.PixelFormat := pf24Bit;
 for y := 0 to aBitmap.height - 1 do
  begin
    PixelLine := aBitmap.ScanLine[y];
    for x := 0 to aBitmap.width - 1 do
    begin
       PixelLine^[x*3]   := (PixelLine^[x*3] + PixelLine^[x*3+1] + PixelLine^[x*3+2]) div 3;;
       PixelLine^[x*3+1] := PixelLine^[x*3];
       PixelLine^[x*3+2] := PixelLine^[x*3];
    end;
  end;
end;

// Aufruf zB. so, hier wir in ein Preview Bitmap ein
// Rechteck gezeichnet in dem ein Unterschied vorliegt.

// ...
MakeGreyBitmap(BitmapAlt);
MakeGreyBitmap(BitmapNeu);
PreviewBitmap.Canvas.Rectangle(BitmapCompare(BitmapAlt, BitmapNeu, 1000));

Der Code ist jetzt nur mal so zusammengetippt und nicht getest.

Wenn man die Farbwerte zu gering setzt also zB. 16 Farben ist durch das Umrechnen der Farbwerte die Fehlerquelle zu gross, da man beim umrechnen icht immer die selben Farbwerte erreicht wie bei der vorherigen Umrechnung, das kann man mal mit einem Paint Programm ausprobieren.

[ManuMF]

Ein weiteres Problem: Wenn es dunkler wird, entsteht bei vielen Kameras sofort Bildrauschen, wie turboPASCAL geschrieben hat. Das dürfte bei der Überprüfung der Bilder sofort "Alarm auslösen", da es mitunter sehr stark sein kann.

[turboPASCAL]

[OT]

Da könnte es helfen wenn man eine Lampe aufstellt. So ca. 1000W machen da schon einiges gut !

[/OT]

[gmarts]

Zitat von ManuMF:

Ein weiteres Problem: Wenn es dunkler wird, entsteht bei vielen Kameras sofort Bildrauschen, wie turboPASCAL geschrieben hat. Das dürfte bei der Überprüfung der Bilder sofort "Alarm auslösen", da es mitunter sehr stark sein kann.

Generell würde ich vorschlagen, die Bilder nicht komplett zu vergleichen, sondern sie in Segmente zu zerlegen und dann mit ihrem Äquivalent zu vergleichen.
So lassen sich Änderungen durch Helligkeitsschwankungen oder den Signalverstärker von "echten" Bewegungen um einiges besser unterscheiden.

Und wenn man es noch weiter mit der Genauigkeit treiben will: Histogramm der im Bild vorkommenden Farben machen.