# Quadrat in einem Bild erkennen



## Kampfzwereg (3. Apr 2012)

Hallo zusammen,

ich hab  eine Methode entworfen, die theoretisch durch ein Bild laufen soll und in diesem nach einem grünen Pixel suchen soll.Dann soll er checken, ob dieser Pixel teil eines Quadrates ist.
Ich gehe erstmal davon aus, dass wenn etwas vorhanden ist, es auch ein Quadrat ist.
Das programm wird mit einem Button gestartet, und gibt , mittels system.out.println , die Bestätigung , dass es geklappt hat. nur wenn ich den Button drücke, friert dieser ein und es passiert nix. Vielleicht könntet ihr mal drüber gucken und mir sagen ob die Methode sinnvoll ist.

Lg Kampfzwereg


```
public Quadrat quadratChecken(BufferedImage image)
  {
    int x=0;
    int y=0;
    Color color;
    Color color2;
    Color color3;
    Color color4;

    do
    {
      do
      {
         color = new Color(image.getRGB(x, y));

      }while(x<image.getWidth() && (color.getBlue()>80 || color.getBlue()<70 &&
                                    color.getRed()>40 || color.getRed()<30 &&
                                    color.getGreen()>180 || color.getGreen()<170));

    }while(y<image.getHeight() &&  (color.getBlue()>80 || color.getBlue()<70 &&
                                    color.getRed()>40 || color.getRed()<30 &&
                                    color.getGreen()>180 || color.getGreen()<170));

     int xRoben = x;
     int yRoben = y;
     red = color.getRed();
     green = color.getGreen();
     blue = color.getBlue();

     do
     {
        color2 = new Color(image.getRGB(xRoben, yRoben));
        xRoben++;
     }while(color2.getRed() == red && color2.getGreen()==green && color2.getBlue()== blue);

     int xRunten = xRoben;
     int yRunten = yRoben;

     do
     {
        color3 = new Color(image.getRGB(xRoben, yRoben));
        yRunten++;
     }while(color3.getRed() == red && color3.getGreen()==green && color3.getBlue()== blue);
     
     int xLunten = x;
     int yLunten = y;
     
     do
     {
        color4 = new Color(image.getRGB(xRoben, yRoben));
        yLunten++;
     }while(color4.getRed() == red && color4.getGreen()==green && color4.getBlue()== blue);
     
     return new Quadrat(new Koordinate(x,y), new Koordinate(xRoben,yRoben), new Koordinate(xRunten,yRunten), new Koordinate(xLunten,yLunten));
     

  }
```

Die Klasse Quadrat speichert lediglich 4 Objekte deer Klasse Koordinate, die zwei Int´s speichert.


----------



## Marco13 (3. Apr 2012)

Er hängt in einer der while-Schleifen, beim Überfliegen:

```
do
     {
        color3 = new Color(image.getRGB(xRoben, yRoben));
        yRunten++;
     }while(color3.getRed() == red && color3.getGreen()==green && color3.getBlue()== blue);
```

yRunten zu ändern ändert nichts an der Schleifenbedinung. Notfalls durch System.out.println's prüfen, was er macht. Zum Vorgehen an sich... könnte man SO VIEL mehr schreiben, ... hab' gerade nicht so viel Zeit.


----------



## Kampfzwereg (3. Apr 2012)

er bleibt schon in der ersten schleifen zum suchen des Pixels stecken anscheinend . hm komisch :-/


----------



## Michael... (3. Apr 2012)

Kampfzwereg hat gesagt.:


> er bleibt schon in der ersten schleifen zum suchen des Pixels stecken anscheinend . hm komisch :-/



komisch? in den ersten beiden Schleifen wird weder x noch y verändert!
Absehen davon, das mir der Sinn der ersten Schleifen nicht ganz klar ist, würde ich hier zwei for Schleifen verschachteln und den Vergleich der Farbwerte einmalig mit einer if Abfrage in der inneren Schleife implementieren.


----------



## Kampfzwereg (3. Apr 2012)

oh ja * räusper *....warum ich while schleifen genommen habe . weil er bei for schleifen is zum ende desmBildes durchgehen würde. er soll aber nur bis zu dem gesuchten Pixel gehen.


----------



## Kampfzwereg (30. Apr 2012)

hm also ich hab nochmal lange drüber nachgedacht und dran rumgeknobelt und bin zu diesem entschluss/ zu dieser Frage gekommen:

nach einer Farbe suchen und zu umständlich bzw sinnlos. Die Farbwert sind meinermeinung nach sehr Lebhaft. Man braucht nicht glauben, dass wenn man mit nem Filschstift auf nen Blatt nen roten Punkt macht,was mein Ziel war,  dass dann alle Pixel die gleichen Werte haben. Genause kann beim suchen mal ne pore vom Blatt oder nen Schatten dazwischen  kommen und das Teil schlägt sofort an. 

Auch zu sagen ok Pixel (0,0) ist mein StartPixel und alles was nicht so aussieht wie er ist dann das was ich suche, da da immer was dazwischen kommen kann. --> bsp links im Bild ist schatten rechst nicht.

Meine Frage wäre jetzt, ob man zB sagen kann, ge solange weiter bis Pixel(x,y) nicht mehr ungefähr gleich Pixel (x-1,y-1) entsprich . Wäre das eurer Meinung nach sinnvoll und lässt sich sowas realisieren?
Wäre über Tipps und Hilfe sehr dankbar.

LG Kampfzwereg


----------



## vimar (30. Apr 2012)

-image segmentation
-farb histrogramme

würd ich als ansatz machen


----------



## Marco13 (30. Apr 2012)

Ganz pragmatisch: Man könnte versuchen, einen Threshold einzuführen. Z.B: Wenn eine Komponente der HSB-Farbdarstellung eines Pixels um >10% vor der vorherigen abweicht, gehört er nicht mehr dazu. Aber allgemein wird an diesem Thema noch geforscht, d.h. alles, was du mit intensiven Studien innerhalb der nächsten 5 Jahre hinbekommen kannst, wird höchstens an der Oberfläche kratzen...


----------



## Kampfzwereg (30. Apr 2012)

ja du .... das is nen einmonatiges Projekt. also geht das wohl nicht :-D 



> -image segmentation
> -farb histrogramme
> 
> würd ich als ansatz machen


Sind das komplizierte Verfahren? Oder sind die für einen Schüler in der 12. klasse zu bewältigen?


----------



## GUI-Programmer (30. Apr 2012)

Ohne jetzt mal auf den weiteren Verlauf dieses Threads eingzugehen:


Kampfzwereg hat gesagt.:


> oh ja * räusper *....warum ich while schleifen genommen habe . weil er bei for schleifen is zum ende desmBildes durchgehen würde. er soll aber nur bis zu dem gesuchten Pixel gehen.



Das kannst du doch, indem du die Schleife mit 
	
	
	
	





```
break;
```
 verlässt.


----------



## Kampfzwereg (30. Apr 2012)

ich will aber nicht unsauber Pogrammieren ;-)


----------



## vimar (30. Apr 2012)

musst du wissen, ich würd mich in der 12ten klasse nicht an image processing wagen


----------



## Gast2 (30. Apr 2012)

Kampfzwereg hat gesagt.:


> ich will aber nicht unsauber Pogrammieren ;-)


wer erzählt das break unsauber ist??
???:L


----------



## irgendjemand (1. Mai 2012)

zu diesem thema fällt mir noch "OCR" und "Hough-Transformation" ein ...
ist in ein paar hundert zeile implementiert


----------



## Kampfzwereg (1. Mai 2012)

> musst du wissen, ich würd mich in der 12ten klasse nicht an image processing wagen


ja ich dachte nicht dass das so schrierig ist. weil eigentlich muss man ja nur gucken, ob irgenwo ne farbe ist, wenn sonst überall nur weiß ist...



> wer erzählt das break unsauber ist??


break zählt , soweit ich weiß, zu den "unsauberen" ausdrücken, die zwar ein bisschen weniger zeilen code verschlingen aber, wie gesagt, unsauber sind.
genauso wie man 2 ints in einer zeile zuweisen kann. weiß nicht mehr wie genau das jetzt ging.



> zu diesem thema fällt mir noch "OCR" und "Hough-Transformation" ein ...
> ist in ein paar hundert zeile implementiert


Das das nen paar hunder zeilen code sind ist mir nicht so wichtig, aber ich muss es auch verstehen können. und DAS ist glaub ich das Problem dabei .... -.-'


----------



## irgendjemand (1. Mai 2012)

Hough-Transform ist schon nicht ganz einfach ... und alles ziemlich abstrakt ...
einfach mal die hunderte zeile posten wäre kein thema ... aber auch ich hab mir das erlich gesagt teils auch nur zusammenkopiert und hab auch nur so n groben überblick was da genau läuft ... das ganze komplett zu verstehen ... puh .. da müsste man sich erstmal genau mit den ganzen mathematischen grundlagen befassen ...


----------



## Kampfzwereg (1. Mai 2012)

das issses halt.... ich denke mal das sind sehr komplizierte mathematische sachen , die ich mit sicherheit nicht verstehen werde.

also ich habs jetzt einfach mal so gemacht, dass ich mir nen blanco blatt genommen hab und eins was komplett in der "zielfarbe" ist. dann bin ich mit ner methode alle pixel durchgegangen und habe den jeweiligen durchschnitts wert vom rot-, grün- und blauanteil der Beiden Farbe ( blanco blatt und zielfarbe) errechnet. jetzt werd ich gucken, dass ich das so einstelle, dass die pixel nach denen ich suche maximal um 20 abweichen....müsste doch gehen oder ? oder ist 20 da schon zu viel ?


----------



## Gast2 (1. Mai 2012)

Moin,



Kampfzwereg hat gesagt.:


> break zählt , soweit ich weiß, zu den "unsauberen" ausdrücken, die zwar ein bisschen weniger zeilen code verschlingen aber, wie gesagt, unsauber sind.


dann streiche mal break aus den unsauberen Methoden - ohne break wirst Du nie ein vernüftiges switch hinbekommen



> genauso wie man 2 ints in einer zeile zuweisen kann. weiß nicht mehr wie genau das jetzt ging.




```
int a = 3; int b = 4; // *scnr* ich weis was Du meinst :) -- int c = a = 4 -- oder so ähnlich
```




Kampfzwereg hat gesagt.:


> also ich habs jetzt einfach mal so gemacht, dass ich mir nen blanco blatt genommen hab und eins was komplett in der "zielfarbe" ist. dann bin ich mit ner methode alle pixel durchgegangen und habe den jeweiligen durchschnitts wert vom rot-, grün- und blauanteil der Beiden Farbe ( blanco blatt und zielfarbe) errechnet. jetzt werd ich gucken, dass ich das so einstelle, dass die pixel nach denen ich suche maximal um 20 abweichen....müsste doch gehen oder ? oder ist 20 da schon zu viel ?


Vergiss einfach RGB und rechne das Bild auf HSV um. Damit ist Farberkennung wesentlich einfacher (Rot etwas tricky). Außerdem kannst Du dann auch gleich die Helligkeit etc. mit beachten

hand, mogel


----------



## GUI-Programmer (1. Mai 2012)

Nochmals dazu:





> genauso wie man 2 ints in einer zeile zuweisen kann. weiß nicht mehr wie genau das jetzt ging.



Ich glaube hier wird das gemeint:

```
int a = 5, b = 8, c = 23;
```

[OT]Aber sowas
	
	
	
	





```
int a = 5;
```
finde ich dann wohl doch schöner als
	
	
	
	





```
int a;
a = 5;
```
[/OT]


----------



## Kampfzwereg (2. Mai 2012)

> dann streiche mal break aus den unsauberen Methoden - ohne break wirst Du nie ein vernüftiges switch hinbekommen


frag mich nicht. mein lehrer meinte zu den standard-syntax gehört nen break ,ist mir auch klar, aber sonst halt nicht.



> Vergiss einfach RGB und rechne das Bild auf HSV um. Damit ist Farberkennung wesentlich einfacher (Rot etwas tricky). Außerdem kannst Du dann auch gleich die Helligkeit etc. mit beachten


ok gibts da irgendwelche tutotirals.....aoder wie meinst du das ? wie würdst du vorgehen? ....mit 2 for-schleifen durch das ganze bild und alles 1zu1  in hvm übersetzten?


----------



## cmrudolph (2. Mai 2012)

Das sollte schon helfen:
HSV-Farbraum ? Wikipedia

Dann ermittelst du die Farbdistanz und kannst mit Schwellwerten arbeiten.


Es gibt auch Leute die sind der Ansicht, dass man nur ein return Statement pro Methode haben sollte.
Meiner Meinung nach führt das aber häufig zu unübersichtlicherem Code. Und dank try finally Block kann man sogar die Aufräumarbeiten noch zentral machen, wenn man mehrere return statements hat.
Probleme kann es dann allerdings noch geben, wenn man die Methode erweitert und nicht berücksichtigt, dass die zu erweiternde Stelle gar nicht mehr aufgerufen wird, weil die Methode vorher verlassen wurde.
Aber ich denke, da muss jeder seinen eigenen Stil finden.


----------



## skummy (2. Mai 2012)

Muss es unbedingt Java sein?

Bei Bilderkennung und Bildbearbeitung fällt mir immer wieder OpenCV ein, womit solche Dinge, die du vor hast, wunderbar mit einem Methoden-Aufruf machbar sind.

Edit: Und für Java gibt es das inzwischen auch: javacv - Java interface to OpenCV and more - Google Project Hosting


----------



## Kampfzwereg (2. Mai 2012)

> Muss es unbedingt Java sein?



ja wir lernen nur Java in der Schule , ich kann noch nichts anderes.
OpenCV ist dochaber sowas wie Java Media Framework oder ? 

Das mit den HSV Farben find ich aber , nach einigen Überlegungen, doch nicht so sonnvoll. Ich muss ja nur einen Roten Ball auf einem Blancoblatt finden. Bin zu der Lösung gekommen, dass man ja einfach nur danach suchen muss, ob der Rot und Blau wert des Pixel unter, sagen wir mal 50 liegt. Da ein Weißer Pixel irgendwas um 255 255 255 haben muss. Viel einfacher .


----------



## skummy (2. Mai 2012)

Mit HSV ist aber die Farberkennung (wie schon mal gesagt) viel einfacher. Und warum ist es auf einmal ein roter Ball?


----------



## Gast2 (2. Mai 2012)

skummy hat gesagt.:


> Mit HSV ist aber die Farberkennung (wie schon mal gesagt) viel einfacher.


Weil die Jugend schon immer den offensichtlich einfacheren und kürzeren Weg genommen hat - um am Ende festzustellen das der Weg mehr Zeit in Anspruch nimmt. Wenn er der Meinung ist das man aus den RGB-Werten sauber immer Rot erkennt, dann soll er machen und Zeit in den Sand setzen.



> Und warum ist es auf einmal ein roter Ball?


:bahnhof:


----------



## Marco13 (2. Mai 2012)

Die Suche nach http://www.java-forum.org/allgemeine-java-themen/98209-moeglichkeiten-bild-schnell-auszuwerten.html ...


----------



## Kampfzwereg (2. Mai 2012)

> Und warum ist es auf einmal ein roter Ball?


weil ich gerade nen roten Bundstift zur hand hatte.....

chillt mal jungs.... meiner Meinung macht es mehr sinn ,in eine Zeile ,als Bedingung für die if-Verzweigung zu schreiben, dass der BLAU und GRÜN wert nicht unter 70 fallen darf anstatt mich erst noch über HSV zu informieren ?!


----------



## Marco13 (2. Mai 2012)

Die Be_grün_dung (pun intended) zu HSV hatte ich schonmal in diesem Beitrag beschrieben. Ich würde #004500 html color code jedenfalls noch als "Grün" bezeichnen. Wenn das auf deinen Fall nicht übertragbar (oder da nicht notwendig) ist, liegen die unpassenden Antworten vielleicht an einer nicht genau genug beschriebenen Problemstellung. Rechteck oder Kreis ist ein wichtiger Unterschied, Kugel (mit Farbverlauf) oder einfarbiger Kreis ist SEHR wichtig, HSV oder RGB ist evtl. wichtig, wo das Bild herkommt und ob es Rauschen enthält ist wichtig, ... nur Rot oder Grün ist nicht soooo wichtig, abgesehen davon, dass Menschen viel mehr Farben als "Grün" bezeichnen, als als "Rot":





(von Color Survey Results | xkcd )


----------



## Kampfzwereg (13. Mai 2012)

hm ok ich verstehe was du meinst, Marco13. 
gut ich werds mal probieren zu konkretisieren.

ich hab hier nen blancoblatt ,auf dass ich mit einem roten Filsstift ein Viereck gemalt habe, ein nicht ausgefülltes Viereck.
Mit dem Programm hier finde ich auch schon dieses Viereck, bzw die Koordinate links-oben, Punkt A. Aber dann soll er aber die Linien des Vierecks weiterlaufen ,um so die anderen Punkte zu finden. Das macht er nich -.-'
Hier mal das Programm:


```
public Quadrat checkGebilde(BufferedImage image, Koordinate koordinate)
  {
      int xZaehler =koordinate.getXWert();
      int yZaehler =koordinate.getYWert();        
      Color color;      
      do
      {
         color = new Color(image.getRGB(xZaehler, yZaehler));
         xZaehler++;
                  
      }while(xZaehler < image.getWidth() && color.getGreen() < 80 && color.getBlue() < 80);      
      Koordinate b = new Koordinate(xZaehler-1, yZaehler);
      do
      {
         color = new Color(image.getRGB(xZaehler-1, yZaehler));
         yZaehler++;
         
      }while(yZaehler < image.getHeight() && color.getGreen() < 80 && color.getBlue() < 80);      
      Koordinate c = new Koordinate(xZaehler-1, yZaehler-1);
      do
      {
         color = new Color(image.getRGB(xZaehler-1, yZaehler-1));
         xZaehler--;
         
      }while(xZaehler > 0 && color.getGreen() < 80 && color.getBlue() < 80);      
      Koordinate d = new Koordinate(xZaehler+1, yZaehler-1);      
      return new Quadrat(koordinate, b, c, d);
      
  }
```


----------



## Marco13 (13. Mai 2012)

Das klingt aus mehreren Gründen ... "optimistisch". 

Wenn man so ein Viereck malt, wird die linke obere Ecke, wo man den Stift ansetzt, in der Vergrößerung vermutlich irgendwie so aussehen

```
YYYY
         XXXXXX
        XXXXXXXXXXXX        XXXXXXXXXXXXXXXXXXX
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        XXXXXXXXXXXXXXXXXX
         XXXXXXXXX
          XXXXX
          XXXX
          XXX 
          XXXX
           XXX
           XXX
           XXX
           XXX
           XXX
           XXX
```

Und dass man da nur die Y-Pixel erkennt, wenn man einfach nach rechts läuft, ist klar. Es ist wohl kaum möglich, mit einem Fil*z*stift auf Papier Linien zu malen, die in Pixeln ein ...

```
XXXXXXXXXXXX
    X          X
    X          X
    X          X
    X          X
    XXXXXXXXXXXX
```
perfektes Rechteck bilden. Was nun passieren soll, wenn das Rechteck eben doch so aussieht...

```
XXXXXXXXXXXX
    X          XXXXXXXXXXX         XXXXXXXXXXXX
    X                    XXXXXXXXXXX           XXXXXXXXX
    XX                                                 X
     X                                                 X
     X                                                 X
     X                                                 X
     X                                                 X
     X                                                 X
     XX                                                XX
      X                                                 X
      X                                                 X
      X                                                 X
      X                                                 X
      X                                                 X
      X                                                 X
      XXXXXXXXXXXX                                      X
                 XXXXXXXXXXX         XXXXXXXXXXXX       X 
                           XXXXXXXXXXX           XXXXXXXX
```
... ist auch nicht klar.                 

Wie schon oben gesagt: Um sowas "gut" und "robust" zu machen, muss man mit Werkzeugen da dran gehen, die sowohl rein konzeptuell-mathematisch, als auch in bezug auf die Implementierung zeimlich aufwändig sind. Man könnte Punktmengen bestimmen und Regressionslinien bestimmen, oder den Hough drüberlaufen lassen (womit man aber auch erstmal nur Geraden bestimmt, aber keine Liniensegmente und damit kein Rechteck), oder oder oder....

In Bezug auf den Code... welche Funktion die "Koordinate"-Klasse hat (im Vergleich zu einem java.awt.Point) weiß ich nicht, und Color-Objekte zu verwenden wird der Performance sicher nicht zuträglich sein, aber das sind im Vergleich zu den angedeuteten Fragen nur Details....

Was "relativ leicht" sein könnte, wäre, alle Pixel zu bestimmen, die "vermutlich" zum Rechteck gehören, und aus der Menge dieser Pixel dann zu "raten", wie das Rechteck wohl aussehen könnte. Ähnlich zu dem Ansatz bei den Kreisen, den ich in http://www.java-forum.org/allgemeine-java-themen/98209-moeglichkeiten-bild-schnell-auszuwerten.html beschrieben hatte. Aber ob das reicht...?


----------



## Kampfzwereg (13. Mai 2012)

Das war mir klar, aber ich wollte es iergendwie nicht wahr haben :-D 

hm ok. also das hört sich zu hoch für nen Schüler in der 12 Klasse an . Naja .
Die sache ist, dass ich vor hatte, dieses Quadrat dann mit ner cam zu Filme. Dann, wenn man halt nen Finger in das gefunden Quadrat legt, soll er sageb, dass er da nen Finger sieht. 


Könnte man das so regeln, dass man einfach zählt, wieviel relativ rote Pixel es in dem Bild gibt , und wenn die Zahl rapide sinkt, dass dann das Quadrat verdeckt ist?


----------



## Marco13 (13. Mai 2012)

Die Frage, wie aufwändig/schwierig das ist, hängt (wie oben AUCH schon angedeutet) von der genauen Problemstellung ab. Man könnte auch sagen: Es hängt davon ab, wie sehr man sich einschränken will. Wenn es NUR darum geht, perfekte pixel-Rechtecke mit einer perfekten Farbe zu erkennen, ist es so trivial, dass der Code reichen würde, den du gepostet hast. Wenn die Farbe ein bißchen schwankt, geht der auch noch. Wenn die Liniendicke schwankt (also NICHT immer genau EIN Pixel ist) wird es schon deutlich schwieriger. Und spätestens, wenn das Bild (womit man bei einem Kamerabild wohl rechnen muss) leicht gedreht oder perspektivisch verzerrt ist, IST das, was man sieht, schon kein Rechteck mehr, und dann wird's richtig kompliziert. Auch wenn man von einem "sehr guten" Kamerabild ausgeht, kann so ein Finger, den man da drüberlegt, das ganze schon schwieriger machen. Auf sowas ähnlichem baiseren Captchas: 




Computer können gut rechnen, und mit OCR recht gut Schreibmaschinentext erkennen. Aber an so einem Bild beißen sie sich trotzdem die Zähne aus.

Was genau da am Ende rauskommen soll, ist zwar immernoch nicht klar. Es klingt aber wie das "drücken von virtuellen Knöpfen". Und spätestens wenn zwei Knöpfe übereinander angeordnet sind, und man den oberen drückt, werden um unteren MEHR Pixel verdeckt, d.h. mit deiner angedeuteten Strategie, pixel zu "zählen", kommt man da auch nicht weit. 

Ein "schönes" Rechteck mit vordefinierter Farbe aus einem "guten" Kamerabild zu erkennen könnte noch relativ leicht sein: Man schaut sich alle Pixel mit dieser Farbe an, und schaut, ob die etwa ein Rechteck bilden. Z.B. könnte man die Bounding Box aller dieser Pixel bestimmen, und dann schauen, ob 90% der Pixel im 10%-Rand dieser Bounding Box liegen oder so. Wenn es mehrere Rechtecke geben kann, wird's aufwändiger... und auch bei jeder anderen Abweichung vom einfachst-möglichen setting.

Das mit dem Finger ... ist wieder so schwammig, dass man kaum einen Ansatz nennen kann...


----------



## Kampfzwereg (14. Mai 2012)

ja du hast recht. es läuft auf eine virtuelle Tastatur hinaus . Mir reicht aber erstmal EIN virtueller Knopf. Dann müsste doch eigentlich meine bneschrieben Methode mit dem Zählen der roten pixel funtlionieren oder ? 

ich hatte mal probiert das so zu realisieren.


```
public void checkBild()
  {
       
      int vergleichsobjekt = checkBild2(myGrabber.getImage());
      while(ausloeser)
      {
          int tempObjekt = checkBild2(myGrabber.getImage());
          if(tempObjekt-10 < vergleichsobjekt)
          {
              System.out.println("Taste ist gedrückt");
          }
          else
          {
             System.out.println("Taste ist nicht gedrückt"); 
          }
          waiting(10);
      }
  }
```


```
public int checkBild2(Image img)
  {
    //Image in ein BufferedImage konvertieren
    Label myLabel = new Label();
    int width = img.getWidth(myLabel);
    int height = img.getHeight(myLabel);
    BufferedImage pImage = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB);
    pImage.getGraphics().drawImage(img, 0, 0, myLabel);      
    

    int zaehler = 0;
    Color color;
    for (int x = 0; x < pImage.getWidth(); x++)
        {
          for (int y = 0; y < pImage.getHeight(); y++)
          {
              color = new Color(pImage.getRGB(x, y));
              if(color.getGreen() < 80 && color.getBlue() < 80)
              {
                  zaehler++;
              }
          }
        }
      return zaehler;      
  }
```


```
public static void waiting (int n)
   {
            try {
                Thread.sleep(n);
            } catch (InterruptedException e) 
            {
                System.out.println(e);
            }
   }
```


----------



## Marco13 (14. Mai 2012)

Hmja, theoretisch könnte sowas in der Art funktionieren (man könnte es noch effizienter impelementieren, aber ...) ... solange man weiß, dass das ohenhin nur für einen künstlichen Testfall funktionieren wird, weiß ich nicht, wie viel Aufwand man da reinstecken sollte. (BTW: Mehrere Tasten unterscheiden könnte man evtl. indem man jeder Taste ein andere Farbe gibt ... aber da muss man natürlich trotzdem noch tricksen)


----------

