Bestimmte Farbe auf dem Desktop suchen

[speedy]

Hi,

versuche mich gerade daran einen Punkt mit einer bestimmten Farbe irgendwo auf dem Desktop zu finden.

Hab das mal mit zwei Schleifen und der GetPixel Funktion versucht, die den Monitor zeilenweise "scannen", bis der Integer-Wert von GetPixel mit dem gesuchten Wert übereinstimmt.
Das Ganze funktioniert prinzipiell auch, nur ist das so brutal langsam, dass der schon ne halbe Minute für eine einzelne Zeile braucht. Selbst wenn ich den zu untersuchenden Bereich auf etwa 50x50 Pixel verkleinere dauert das noch ein paar Sekunden...

Weiß da jemand da eine schnellere Methode?

Hab irgendwann mal vor ein Live-Video von einer Webcam auf einen bestimmten Farbbereich zu scannen. So soll z.B. eine farbige Kugel auf einem weißen Tisch verfolgt werden. Nur macht das natürlich bei der Geschwindigkeit nicht wirklich Sinn.


Danke und schöne Grüße
speedy

[s.h.a.r.k]

Hm, ich glaube, du machst da irgendwas übelst falsch, denn sonst wäre das nicht so lahm :gruebel: Zeig mal deinen Code her.

[Bora4d]

Mach mit Desktop-Canvas Bildschirmkopie in ein TBitmap und verwenden Scanline-Eigenschaft von TBitmap.
Das ist der übliche Weg und auch schnelste. Verglichen mit GetPixel ist es wie ein Umstieg von Trabi auf Ferrari :-D

[speedy]

Das ist der verwendete Code:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var cx1, cy1, cx2, cy2, buffer : integer;
    dc : hdc;
begin
  dc := createdc('DISPLAY',nil,nil,nil);
  cy1 := strtoint(edit2.Text);           //start y
  cx2 := strtoint(edit3.Text);           //ende x
  cy2 := strtoint(edit4.Text);           //ende y
  while cy1 < cy2 do
    begin
      cx1 := strtoint(edit1.Text);        //start x
      while cx1 < cx2 do
        begin
          buffer := getpixel(dc,cx1,cy1);
          cx1 := cx1 + 1;
          if (buffer > 2300000) and (buffer < 2400000) then memo1.Lines.Add(inttostr(cx1)+' '+inttostr(cy1));  //genauer wert: 2302444
        end;
      memo1.Lines.Add('zeile '+inttostr(cy1));    //nur zum testen
      cy1 := cy1 + 3;                     //3 zeilen weiter springen
    end;
end;

Das seltsame ist auch, dass die CPU Auslastung gerade mal um 5 - 8 % ansteigt während er arbeitet.

Werde dann mal die Methode mit Scanline testen...

Gruß
speedy

[rollstuhlfahrer]

Dein Buffer ist ein Farbwert vom Typ TColor. Da liegen die Farben im Hex-Format ala $00RRGGBB (RR = Rot, GG = Grün, BB = Blau) drin. Deine Bereichsprüfung findet jetzt nicht nur Stellen, wo deine gewünschte Farbe drin ist, sondern auch noch alle stellen, die etwas mehr oder weniger Blau haben und weil dein Bereich so groß ist, darf sich der Wert von Grün auch noch dramatisch ändern und es fällt durch.

Bernhard

[DeddyH]

War das nicht anders herum (BGR)?

[stahli]

RGB stimmt.

[DeddyH]

Dann bin ich farbenblind.

Delphi-Quellcode:

procedure TForm5.FormCreate(Sender: TObject);
begin
  Color := $00FF0000;  //wäre demnach reines Rot
end;

Mein Formular wird aber blau.

[Wolfgang Mix]

@Detlef:
RGB war schon richtig. Du hast 2 Nullen zuviel!
So wird es richtig (grün)

Delphi-Quellcode:

Color := $00FF00;

[DeddyH]

Natürlich wird das grün, wenn ich bei 3 Teilen die beiden äußeren tausche und danach auf den mittleren zugreife :roll:

[stahli]

Zitat:

Zitat von Aus der Hilfe

Wenn Sie zur Festlegung von TColor nicht die Konstanten aus der Unit Graphics, sondern eine 4-Byte-Hexadezimalzahl verwenden, geben die drei niederwertigen Bytes die RGB-Farbintensität für Blau, Grün und Rot an. Der Wert $00FF0000 (Delphi) bzw. 0x00FF0000 (C++) entspricht einem reinen Blau mit voller Intensität, der Wert $0000FF00 (Delphi) bzw. 0x0000FF00 (C++) einem reinen Grün und der Wert $000000FF (Delphi) bzw. 0x000000FF (C++) einem reinen Rot. $00000000 (Delphi) bzw. 0x00000000 (C++) gibt Schwarz und $00FFFFFF (Delphi) bzw. 0x00FFFFFF (C++) Weiß an.

DeddyH hat recht, sorry.
Die Bezeichung des Farbtyps ist RGB aber der Farbwert wird vom Lo-Byte an genutzt.

[Wolfgang Mix]

Ok, sorry, hatte das Dollarzeichen überlesen :(

[DeddyH]

Immer diese Ausreden :mrgreen:

[BUG]

Kann es sein, dass die Endianness wieder mal verwirrend zugeschlagen hat? :mrgreen:

Code:

Speicher (LOW ... HIGH):
0xRR | 0xGG | 0xBB | 0x00

Als Little-Endian-Integer:
0x00BBGGRR

[DeddyH]

Jepp, das kann einen manchmal in den Wahnsinn treiben :)

[himitsu]

Zitat:

Delphi-Quellcode:

cx1 := strtoint(edit1.Text)

Reicht es nicht, wenn man das ur einmal umwandelt? (außerhalb der Schleife)

und ein Memo ist arschlangsam, vorallem dann, wenn man viele Zeilen dort einfügt und das auch noch ohne BeginUpdate.

[speedy]

Wegen der Farbe in Hex: Mit der Farbangabe klappt das ohne Probleme, das ist ja auch nicht das Problem. Langsam ist es auch, wenn ich nur eine einzelne Farbe zum Vergleichen angebe...

Und auch ohne Memo braucht das Ding ewig. Der schreibt ja nur so alle 3 Sekunden bei nem 100x100 Pixel Bereich ne neue Zeile.
cx1 := strtoint(edit1.text) ist die Anweisung, dass der die X-Position wieder auf den Anfang setzt, sonst bleibt diese ja immer am rechten Rand.

[Aphton]

Zitat:

Zitat von BUG (Beitrag 1101972)

Kann es sein, dass die Endianness wieder mal verwirrend zugeschlagen hat? :mrgreen:

Code:

Speicher (LOW ... HIGH):
0xRR | 0xGG | 0xBB | 0x00

Als Little-Endian-Integer:
0x00BBGGRR

Pappalapapp!
Das hat doch nichts mit Endianness zu tun :P
Wenn man sagt, R steht - jetzt im Zehnersystem - an der Einserstelle, G an der Zehnerstelle und B an der Hunderterstelle, dann schreibt mans genauso an: 321:
R = 1
G = 2
B = 3

Genauso verhält es sich mit HEX
R steht an erster Stelle (Einserstelle), G an Sechtzehnerstelle, B an der 256'er Stelle!
Thus BGR!
Endianness hat nichts damit zu tun :P
Hier zumindest nicht!

[BUG]

Zitat:

Zitat von Aphton (Beitrag 1102041)

Endianness hat nichts damit zu tun :P
Hier zumindest nicht!

Doch, zumindest an der Stelle, wo man sich nicht einig ist, ob man bei der Reihenfolgenbezeichnung RGB die Reihenfolge im Speicher oder die Reihenfolge in einer aufgeschriebenen 32bit Zahl meint. Diese sind hier ja unterschiedlich.

Aber ich glaube nicht, dass uns diese Diskusion zu irgendetwas Nützlichem führt, zumal der TE kein Problem mit diesem Thema zu haben scheint :wink: