Bewegungsmelder

[Clane]

Also ich habe eine digicam und möchte mir einen bewegungsmelder basteln ... also cam und n prog nur ich hänge hier an dem prog und weiß nich so recht wie ichs anstellen soll könnte mir da jemdemadn helfen und oder tipps geben ??

[Matze]

Moin!
Möchtest du, dass die Kamera als bewegungsmelder fungiert oder hast du einen Bewegungsmelder, den du per API ansteurst und der Kamera dann Befehle erteilst.

Soll die Kamera als Bewegungsmelder dienen müsstest du über den mitgelieferten (Webcam-)Treiber die Bilder vregleichen und bei größeren Änderungen entsprechend agieren. Aber so kann man noch keine Aussage treffen.

[Clane]

ich hab ne gaz normale digicam und möchte das die als bewegunsmelder fungiert nur mit dem jede secunde n bild machen und das mit dem vorigen verglecihen hab ich keine ahnugn wie ichs machen soll

[DGL-luke]

dann überleg dir mal was ;)

du könntest z.B. pixel für pixel vergleichen, und die änderungen addieren. Sobald der wert dann ein bestimmtes level übersteigt, gibst du alarm.

[Matze]

Hier gibt es ein Beispielprogramm zum Vergleichen von Bildern. Aber achte darauf, dass du eine gewisse Tolleranz mit einbaust, den 100% gleich werden die Bilder wahrscheinlich nicht sein.

[Clane]

und wie stell ich das mit der cam an das die bilder geschossen und als z.b pic1.jpg und pic2.jpg abgelegt werden um die zu vergleichen ? treiber sind installiert und die cam wird bei winxp im arbeitsplatz angezeigt

[himitsu]

Also JPeg's würde ich an deiner stellen lieber nicht nehmen.

Derartig komprimierte Biler bringen ja schließlich noch zusätzliche Fehler rein.
> Bedingt durch die Komprimierung werden halt die Farbwerte der Einzelnen Pixel etwas verändert.

Nimm lieber BitMap's ... bei 24-bit sollten derartige Fehler nicht all zu sehr in die Farbwerte der einzelnen Bildpunkte einschleichen.

Bei dem Zugriff kann ich allerdings nichts sagen ... aber eventuell kannst du ja mal in Richtung Scanner schauen ... der entsprechende Schnittstelle sollte hierfür auch gute Dienste leisten.

[rebugger]

Wie wärs mit der Forensuche?
Sprich "Webcam" - da findeste ca. >30 Ergebnisse

[zecke]

Nachteil der Bitmaps ist eben die Größe, also rate ich davon ab viele Bitmaps zu erstellen und zu speichern, sondern wenn Du Bitmaps verwendest - sie nach Gebrauch wieder zu löschen :)

[kiar]

hallo,

Ausserdem solltest du den Interval < 1 sek machen in einer sekunde kann sich schon was durch das Bild gelaufen sein, was du garnicht mehr aufzeichnest.

Raik

[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 :roll:

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. :roll:


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.

:gruebel:

[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 ! :mrgreen:

[/OT]

:gruebel:

[gmarts]

Zitat:

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.

[Clane]

da ich sehe das dieses thema hier "für helle aufredungs" :D sorgt würde ich vorschlagen das alle die an sowas interesse hätten sich mal eben hier eintragen und das wir dann n kleines gruppenprojekt daraus machen.

[Tubos]

Erstelle doch bitte einen Thread mit konkreter Beschreibung im "Projekte" - Bereich, wenn du Mitprogrammierer suchst.

[Clane]

das war ja erstmal die frag ob da jemand mitmachen würde wenn sich jetzt 2-3 leute oder mehr melden mach ich den thread schon keine bange ;)

[Tubos]

Im Projekte-Forum kriegst du aber mehr Aufmerksamkeit und die Chance dass du jemanden findest ist höher.
Wenns nichts wird ist es im Projekte-Board auch nicht falsch.

[Flips]

Hi.
Der Thread is zwar schon etwas älter, aber die Methode Canvas.Pixels[x,y] ist ziemlich langsam besser ist es mit Scanline.

Delphi-Quellcode:

var Bild1: TBitmap; //Erstes Bild
    Bild2: TBitmap; //Zweites Bild
    Linie1,linie2: PByteArray; 
...

line1 := Bild1.Scanline[x]; //Zeiger auf die x. Zeile von Bild1
line2 := Bild2.Scanline[x]; //Zeiger auf die x. Zeile von Bild2

//Auslesen:
pixelAnDer5Stelle := line1[4];

Mfg
Flips

[Khabarakh]

Delphi-Quellcode:

//Auslesen:
pixelAnDer5Stelle := line1[4];

Das wäre aber der R-Kanal des ersten / der G-Kanal des zweiten Pixels (je nach PixelFormat). Ich würde PRGBTriple bzw. PRGBQuad verwenden.