Bilderkennung

[zobien123]

Hallo Zusammen:),

ich versuche mich gerade an der Bilderkennung. Das Ziel ist es, Kreise in einem Bild zu zählen. Dabei muss man noch von anderen Formen unterscheiden, welche im Bild sind (siehe Bsp Bild).

Jedoch hakt es bereits wie ich in einem Bild überhaupt mal einen Kreis erkenne. Ich habe leider im Internet keinen anstoß gefunden, welcher mich weiter bringt oder wo ich mich einlesen kann.


Schonmal vor ab, vielen Dank für jede Hilfe!:)

Edit: Das ist eine Übungsaufgabe aus dem Internet. https://0xf.at/play/35?pw= Wer es selbst mal versuchen möchte ;)

[Redeemer]

Eigentlich nicht schwer, da kann man von der Zeilenzahl einstellig bleiben.

Code:

FUNKTION Kreiserkennung(VARIABLE Ergebnis: Integer);
  GEHE Bild VON oben NACH unten DURCH
    GEHE Bild VON links NACH rechts DURCH
      WENN Farbe NICHT weiß DANN
        WENN Farbe ein Pixel links unten NICHT weiß DANN // ggf. Abfrage für ganz links bzw. oben
          ERHÖHE Ergebnis;
        FÜLLE BEREICH an aktueller Position MIT weiß;

VCL.Graphics.TCanvas

Code:

Irgendwas := 0;
Kreiserkennung(Irgendwas);

[himitsu]

@Redeemer: Damit zählst du auch die Rechtecke, obwohl er nur die Kreise haben will.
* Außenkannte des gefundenen Bereichs suchen und schauen welche Form er hat

Da fehlt dann noch die Delphi Mustererkennung.

[Headbucket]

Ein kurzer vllt etwas naiver Denkanstoß, wie ich an die Sache rangehen würde:

Ich würde alle Pixel von Links oben der Reihe nach durchgehen.
Wenn ich farbiges Pixel finde, dann würde ich zunächst die Höhe des Objektes herausfinden, indem ich Pixel nach unten gehe, bis kein farbiges Pixel mehr auftaucht. Dann würde nach folgendem "Konstrukt" suchen:


Reihe X: Anzahl der farbigen Pixel in aktueller Reihe
Reihe X+1: Anzahl der farbigen Pixel in vorheriger Reihe + Bestimmten Faktor
Reihe X+2: Anzahl der farbigen Pixel in vorheriger Reihe + Bestimmten Faktor
...
Reihe X+y: Maximale Anzahl farbiger Pixel
...
Reihe X+n-2: Anzahl der farbigen Pixel in dritter Reihe
Reihe X+n-1: Anzahl der farbigen Pixel in zweiter Reihe
Reihe X+n: Anzahl der farbigen Pixel in erster Reihe


Da man einen Kreis leicht unterschiedlich zeichen kann, sollte die Auswertung der Pixelbreite etwas flexibel bleiben. Gerade flexibel genug, um einen Kreis von einer Ellipse zu unterschieden :-)

Wie gesagt - nur mein erster Gedanke. Vllt bringt dich das auf neue Gedanken.

Grüße
Headbucket

[hanvas]

Zitat:

Zitat von zobien123 (Beitrag 1398000)

Hallo Zusammen:),
Jedoch hakt es bereits wie ich in einem Bild überhaupt mal einen Kreis erkenne. Ich habe leider im Internet keinen anstoß gefunden, welcher mich weiter bringt oder wo ich mich einlesen kann.

Kreise mit unterschiedlichen Radien lassen sich am besten mit Hilfe der sog. Hough-Transform(ation) erkennen. Einfach mal "Hough Transform Circle" mit oder ohne Delphi in eine Suchmaschine Deiner Wahl eingeben.

cu Ha-Joe

[himitsu]

Wenn nur Kreis oder Rechteckt, dann "einfach" auf Rechteck prüfen, also wenn überall gleich hoch und/oder breit, dann ist es ein Rechteck.

Oder auf "ich bin kein Kreis" und das Pixel bei (x-1, y+1) ist weiß. (der gefundene Anfangspunkt ist eine Ecke)
Oder auf "ich bin eventuell ein Kreis" und das Pixel bei (x-1, y+1) ist nicht weiß. (der gefundene Anfangspunkt ist rechteckig)
> Bei

Delphi-Quellcode:

for y :=0 to ... do for x := 0 to ...

... wenn Schleifen/Suchmuster andersrum, dann bei (x+1, y+1).

[jobo]

Ich hab mich noch nie damit beschäftigt, aber könnte man nicht ein paar benachbarte Pixel auswerten (ala Kreissegment) und den Mittelpunkt zu dem Stück finden?
Je unendlicher es entfernt ist, desto mehr ist es eine Gerade statt eines Kreises. Sind Kreise größer als das Bild (oder unvollständige) überhaupt gefragt?
Aber vielleicht ist das schon viel zu aufwändig.

[Redeemer]

Zitat:

Zitat von himitsu (Beitrag 1398007)

@Redeemer: Damit zählst du auch die Rechtecke, obwohl er nur die Kreise haben will.

Nö, tue ich nicht. Da steht doch, dass ich unten links unter dem aktuellen Pixel gucke, ob es weiß ist. Ist es da weiß, handelt es sich um ein Rechteck.

[KodeZwerg]

Wenn es von dem Ablauf her Erlaubt wäre eine "Hintergrund" Farbe zu bestimmen um die Objekte rauszufiltern (oder basierend darauf ein Raster erstellen?) würde das Vorhaben die übriggebliebenen Objekte einer Form zuzuorden weitaus einfacher machen.
Vielleicht könntest Du auch diese Komponente umbiegen das Sie nach Kreisen und Rechtecken sucht?

[Neutral General]

Zitat:

Zitat von Redeemer (Beitrag 1398059)

Zitat:

Zitat von himitsu (Beitrag 1398007)

@Redeemer: Damit zählst du auch die Rechtecke, obwohl er nur die Kreise haben will.

Nö, tue ich nicht. Da steht doch, dass ich unten links unter dem aktuellen Pixel gucke, ob es weiß ist. Ist es da weiß, handelt es sich um ein Rechteck.

Ich meine in dem Vorschaubild da sollte das sogar funktionieren aber falls andere Bilder da einen Hauch anders/komplexer sind dann klappt das nicht mehr.

Delphi-Quellcode:

// Wie viele Kreise sind (laut deinem Algorithmus) in diesem Bild?
# # # # # # #
 # # # # # # #
# # # # # # #

Antwort: Zu viele

[Jasocul]

Mal mein Brainstorming-Senf dazu, weil mir gerade danach war:

Voraussetzung:
1. Alle grafischen Objekte sind komplett freigestellt. D.h.: keine Berührungen oder Überschneidungen der Objekte.
2. Es soll eine Positiv-Erkennung geben. Also nicht prüfen, ob ein Objekt kein Kreis ist. Es könnte ja sein, dass später noch andere Objekte dazu kommen (Dreiecke, Polyeder, etc.)

Das Problem würde ich in 2 Schritten angehen.
1. Alle Objekte (farbige, zusammenhängende Bereiche) ermitteln
2. Die Objekte prüfen

zu 1:
Die Grafik nach Pixeln untersuchen, die nicht mit der Hintergrundfarbe übereinstimmen. Zusammenhängende Bereiche bestimmen und diese in einer Objekt-Liste speichern.

zu 2:
Vorüberlegung:
Was sind Kreise? Es sind Objekte, die durch ihren Radius/Durchmesser bestimmt sind. Also genügt es, diesen zu bestimmen. Für die weiteren Prüfungen wird der Durchmesser verwendet. Der Radius (also Durchmesser durch 2) könnte in weiteren Prüfungen Rundungsfehler verursachen. Da es potentiell noch mehr Rundungsprobleme geben kann, sollten diese sich nicht akkumulieren.
Bei der Prüfung der Objekt kann man einfach den obersten Punkt bestimmen. Dazu wird der tiefste senkrecht darunter liegende bestimmt. Die Länge ergibt den Durchmesser, falls es ein Kreis ist.
Erste Prüfung (kann auch entfallen):
Analog zum senkrechten Durchmesser kann der horizontale Durchmesser bestimmt werden. Diese müssen gleich sein. Vorsicht: Auch bei einem Quadrat ist das so. Bei einer Ellipse allerdings nicht, es sei denn es ist eine gedrehte Ellipse. Zumindest dient es als erste einfache Prüfung. Den Sonderfall, dass die Grafik auf einem 4:3-Monitor erstellt wurde und jetzt auf einen 16:10-Monitor dargestellt wird (Verzerrung) ignoriere ich mal.
Zweite Prüfung (nur, falls erste Prüfung erfolgreich):
Jetzt muss der Mittelpunkt bestimmt werden. Dies klingt erstmal einfach, ist aber es nicht. Bei sehr großen Kreisen hat man auch an den äußersten Punkten mehrere Pixel auf der selben Linie liegen. Also muss man das zusätzlich prüfen und dort die Mitte finden. Bei gerader Anzahl von Pixeln sind jetzt schon Probleme abzusehen, da bei allen weiteren Prüfungen geringfügige Abweichungen/Rundungsfehler berücksichtigt werden müssen.
Es steht jetzt alles zur Verfügung, um einen Kreis zu definieren (Mittelpunkt und Durchmesser). Auf dieser Basis wird nun ein Kreis "erzeugt", der im Idealfall deckungsgleich mit dem Prüfobjekt ist. Es sollte genügen, den Kreisrand zu prüfen.
Allerdings darf man die Rundungsprobleme nicht außer acht lassen und muss entsprechende Toleranzen einplanen.

Besondere Probleme:
- Rundungsfehler
- besonders große Kreise (wie weiter oben schon angedeutet)
- besonders kleine Kreise: Ist ein einzelnes Pixel eine Kreis oder ein Quadrat? :wink:

[Redeemer]

Zitat:

Zitat von Neutral General (Beitrag 1398076)

Zitat:

Zitat von Redeemer (Beitrag 1398059)

Zitat:

Zitat von himitsu (Beitrag 1398007)

@Redeemer: Damit zählst du auch die Rechtecke, obwohl er nur die Kreise haben will.

Nö, tue ich nicht. Da steht doch, dass ich unten links unter dem aktuellen Pixel gucke, ob es weiß ist. Ist es da weiß, handelt es sich um ein Rechteck.

Ich meine in dem Vorschaubild da sollte das sogar funktionieren aber falls andere Bilder da einen Hauch anders/komplexer sind dann klappt das nicht mehr.

Delphi-Quellcode:

// Wie viele Kreise sind (laut deinem Algorithmus) in diesem Bild?
# # # # # # #
 # # # # # # #
# # # # # # #

Antwort: Zu viele

Die Frage ist für 1x1 und 2x2 Pixel nicht lösbar. Wenn die Anforderung des TE ist, die verlinkte Frage zu lösen, dann ist mein Algorithmus dazu in der Lage. Das Bild enthält nämlich nur mindestens 7x7 große Objekte. Mein Algorithmus ist zudem, wie ich auch ausdrücklich geschrieben habe, nicht in der Lage, Objekte zu unterscheiden, die ganz links (im Original hatte ich noch "oben" geschrieben, aber das stimmt nicht) am Bildrand sind, was bei der verlinkten Frage nicht auftritt.

[Neutral General]

Zitat:

Zitat von Redeemer (Beitrag 1398097)

Die Frage ist für 1x1 und 2x2 Pixel nicht lösbar.

"0 Kreise" ist für mich auch eine Lösung ;)

Zitat:

Zitat von Redeemer (Beitrag 1398097)

Wenn die Anforderung des TE ist, die verlinkte Frage zu lösen, dann ist mein Algorithmus dazu in der Lage.

Das stimmt.
Weswegen ich was gesagt hab, ist weil deine Lösung sich für mich ein bisschen wie "cheaten" anfühlt.
Es erfüllt zwar für das vorgegebene Bild seine Aufgabe aber für mich ist es kein "richtiger" Algorithmus um Kreise zu erkennen/zählen (weil es mit fast allen anderen Bildern nicht klappen wird)
Aber ich schätze dass ist mehr mein als dein Problem :mrgreen:

[freimatz]

Kreis zu erkennen ist etwas was man in der Messtechnik ständig tut. Was mir hier noch fehlt ist eine Definition was ein Kreis sein soll. Nach einer mathematischen Definition sind es gar keine Kreise sondern Haufen von Pixeln. Welchen Fehler mag man tolerieren?
Man könnte sich alle farbigen Pixel raussuchen die beieinander und neben weißen Pixel liegen, also alle Pixel die außen liegen. Die Position der Pixel kann man dann in die üblichen Ausgleichsrechnungen (Hüll, Pferch, Gauss oder Tschebyscheff) reingeben und bekommt dann Kreise.
Diese Kreise bekommt man aber auch bei den "Quadraten" nur ist da halt die sogenannte Spannweite größer.

[KodeZwerg]

Das Bild auf zwei Farben (Monochrom) reduzieren, theoretisch sollte dann nur noch weiß als Hintergrund und Schwarz für alle Objekte bleiben (oder andersrum), Außenkante von allem Schwarzen Bereichen checken, was längere Geraden hat sollte kein Kreis sein oder mittels Radius Vorschläge von hier Gegenprüfen.
Wäre das ein Ansatz?

[jfheins]

Falls du Zugang zu MATLAB hast (oder bereit mist, dir das als trial zu installieren) gibt es dafür schon was fertiges: https://de.mathworks.com/help/images...ndcircles.html

Hough-Transformation ist das richtige Stichwort, aber selber machen muss man das heutzutage eigentlich nicht mehr ;-)

[himitsu]

Neuronale Netzwerke?

Bild in S/W umwandeln,
die einzelnen Formen suchen,
gefundene Form auschneiden (den Bereich der Form in ein eigenes Bild kopieren)
und dann die Form erkennen lassen

[Amateurprofi]

Zitat:

Zitat von KodeZwerg (Beitrag 1398117)

Das Bild auf zwei Farben (Monochrom) reduzieren, theoretisch sollte dann nur noch weiß als Hintergrund und Schwarz für alle Objekte bleiben (oder andersrum), Außenkante von allem Schwarzen Bereichen checken, was längere Geraden hat sollte kein Kreis sein oder mittels Radius Vorschläge von hier Gegenprüfen.
Wäre das ein Ansatz?

Ich finde, eine Umwandlung in Monochrom (Schwarz/Weiß) ist zwar nicht schädlich aber überflüssig.
Wenn bei der Umwandlung alles, was nicht weiß ist, in Schwarz resultiert, und alles was weiß ist, auch weiß bleibt, dann kann ich doch auch das Originalbild nehmen und alles was nicht weiß ist, als farbig, also zur "Figur" gehörend interpretieren.
Wo liegt da der Vorteil einer monochromen Bitmap?

[Neutral General]

Zitat:

Zitat von Amateurprofi (Beitrag 1398198)

Ich finde, eine Umwandlung in Monochrom (Schwarz/Weiß) ist zwar nicht schädlich aber überflüssig.
Wenn bei der Umwandlung alles, was nicht weiß ist, in Schwarz resultiert, und alles was weiß ist, auch weiß bleibt, dann kann ich doch auch das Originalbild nehmen und alles was nicht weiß ist, als farbig, also zur "Figur" gehörend interpretieren.
Wo liegt da der Vorteil einer monochromen Bitmap?

Wenn der Hintergrund ausschließlich pures Weiß ist (255,255,255) dann macht es keinen Unterschied. Monochrom bringt was wenn man keinen komplett einfarbigen Hintergrund hat sondern einer der aus verschiedenen (hellen) Grau/Farbtönen besteht. Die würden dann bei der Konvertierung nach monochrom zu Weiß "aufgerundet" werden.

[KodeZwerg]

Mein Gedanke war halt nur mit zwei Farben hantieren zu müssen, Schwarz und Weiß bietet sich da gut an, das Bild sollte ja nicht so gezeichnet werden, nur virtuell um eine Form-Erkennung zu vereinfachen. Wenn man nur zwei Farben hat, brauch man nur nach einer der beiden Farben suchen um Kanten zu bestimmen die letztendlich eine Form ergeben.
Alternativ fällt mir noch so etwas wie ein Farben-Scanner ein, der ein Bild in viele virtuelle splittet wo jeweils nur eine Farbe vorkommt. (Also Routine schreiben die einem die vorhandenen Farben zählt und für jede ein Bild erstellt, beim erstellen darauf achten das nur zusammenhängende Farben ein Objekt entsprechen oder halt mehrere Bilder für mehrere Objekte. Aber da gibt es immer das Problem mit Antialiasing oder Schattierungs-Effekten die einem nie einen ganzen Kreis erfassen lassen wegen Farbabweichungen, deswegen lande ich an dieser Stelle wieder bei Variante 1 alles erst einmal Schwarz-Weiß.)

[bernhard_LA]

um Kreise in einem Bild zu finden eignet sich der Hough-Algorithmus ( freie Implementierung gibt es hier . https://sourceforge.net/projects/houghtransforma/ )


Für ein Bild mit unterschiedlichen Radien der Kreise - am besten für einen Radius Hough über das Bild laufen lassen und dann die Maxima auswerten - weiter verwenden

Linien kann man mit dem Hough Line Algorithmus finden, wo man Linien Findet kann im Suchbild kein Kreis sein - diese Logik muss man dann im obigem Demo Beispiel ergänzen

Die Theorie zum Hough Algo gibt es auf Wiki ....