Canny edge algorithmus und Sobel Matrix

[Medium]

Das sieht doch schon sehr richtig aus! Nett.

Darf man fragen, was du mit den Kanten nachher vor hast? So von Nachtschwärmer zu Nachtschwärmer

[Gutelo]

Jepp

Ich schreib ein Programm welches folgendes machen soll:

1.) Mittels Kamera ein Dokument auf einem Tisch aufnehmen (Webcam oder Handy)
2.) Perspektivische Verzerrung rausrechnen, so dass quasi eine Aufnahme "von oben" erhalten wird
3.) Einlesen von Zahlen mittels OCR

1. und 2. sind soweit fertig.

Den Canny+Hough brauche ich um die Eckpunkte des Dokuments im verzerrten Bild automatisch zu finden.

Fuer die OCR werde ich wohl ein einfaches Pixel-matching verwenden: Einmal perfekt mit Flachbettscanner einscannen und fuer jede Zahl von 0 bis 9 eine Referenz anfertigen. Dann die gescannten Zahlen ueber die Referenzen durchschieben und den maximalen Match bestimmen. Das sollte eigentlich ganz gut funktionieren wenn man Hoehe/Breite (Pixelaufloesung) einigermassen waehlt. Vielleicht kommen auch Neuronale Netze in Frage, obwohl mich die Treffsicherheit der simplen OCR Implementationen mittels NN die ich im Internet gefunden habe nicht wirklich ueberzeugt haben.

Eigentlich kam mir bei der ganzen Canny Geschichte folgendes in den Sinn bezueglich der OCR: Man koennte doch ueber jede gescannte Zahl den Canny laufen lassen und anschliessend die Gradientenrichtungen (Statistik ueber Gradienten in 0,45,90,.. Grad Richtung) der Kannten benutzen um die Zahl zu bestimmen. Was haelst du von dieser Idee? Koennte man auch mit dem Pixel-matching kombinieren.

Gutelo

Warum das in der urpruenglichen Version nicht funktioniert hat ist mir aber immer noch raetselhaft, da ich dort im Grunde ja das gleiche mache bis zu den Sx und Sy. Ich glaube aber dass es eventuell an der Normierung liegt. Wenn ich bei der aktuellen Version bereits die Pixel Arrays der Sx und Sy normiere, dann ist der Effekt nicht ganz so stark ausgepraegt als wenn ich erst am Ende nach dem Sobel normiere. Ein anderes Problem der alten Version ist der nicht behandelte Rand. Dieser verfaelscht die Skala. In der neuen Version werden die Raender abgeschnitten nach der Filteranwendung.

[Medium]

Das klingt verdammt spannend! Und beeindruckend oben drauf.
Bei OCR bin ich nicht so sehr im Thema, aber die Idee das anhand der "Winkellisten" zu vergleichen finde ich zumindest schon mal höchst kreativ - und gar nicht mal so abwegig. Da könnte es dann spannend werden einen Vergleichsmechanismus zu finden, der 2 Listen potenziell unterschiedlicher Länge ein geeignetes Ähnlichkeitsmaß zuordnet. Das wirklich interessante bei dem Ansatz ist vor allem, dass man im Prinzip ohne ROI auskommen kann. Einfach alle Gradientenlisten durchgehen und gut. Fies wird es da allerdings wohl bei Zahlen, die in mehere Listen zerfallen können. Also die beiden, die gekreuzte Linien haben können: 4 und 8. Da müsste man sich was überlegen.

Zum Sobel bzw. dessen Nicht-Funktion vorher: Da ich nicht so ganz durch deine Normierungsmethode steige gerade, weiss ich auch nicht genau was da schief lief. Grundsätzlich bin ich aber wegen solchen potenziellen Problemen eher dazu geneigt, die Container den Daten anzupassen als umgekehrt

[Gutelo]

Oh ich dachte eigentlich nur an ein Haufigkeitsdiagram, also Häufigkeit über Richtung. Aber deine "Liste" ist noch viel besser. Man nimmt einfach die äusserste Kante die zusammenhängend die Zahl umschliesst und läuft die Kannte Pixel fûr Pixel ab und macht ein Array mit den Gradientrichtungen. Die Sprûnge in den Richtungen und die Länge der Liste sind charakteristisch für die Zahl. Probleme mit 4 und 8 gibt es dann auch nicht. Gute Idee.

Wofür steht ROI?

Edit: ah. Region of interest. Das Problem auch die Zahlen zu separieren liegt nicht an der Kreuzung sondern dass 4 und 8 mehrere geschlossene Kanten haben. Aber die Zahlen zu separieren ist nicht so wild, das hab ich schon fertig.

[Medium]

Ha, in dieser Form hatte ich an die Listen jetzt auch nicht gedacht Aber das klingt gut, im Grunde eine Hüllkurvenauswertung. Könnte nur bei 6, 8 und 9 je nach Font knifflig werden, aber ausprobierenswert. Vor allem wenn du die Separierung schon hast - das ist der wichtigste Schritt überhaupt. Alles danach lässt sich dann ja recht einfach ausprobieren und verfeinern.

[Gutelo]

Mit 8 und 6/9 sollte es kein Problrm geben. 6 und 9 haben etwa gleiche Aenderungen. Hier muss man dann einen festen Startpunkt wählen, z.B. immer beim nördlichsten Punkt anfangen.

Ich muss erst noch die NMS, Hysteresis und Hough fertig machen dann kümmer ich mich um die OCR idee. Halte dich auf dem Laufenden

[Gutelo]

Hallo,

Non-Maximum Suppression (NMS) und Hysteresis arbeiten jetzt auch. Ich haenge ein kleines Demo-Projekt fuer Lazarus an dieses Post. Laeuft alles schnell genug, kann aber auch noch reichlich optimiert werden. Soll nur als ein Grundgeruest dienen fuer Leute die Aehnliches vor haben. Ich habe den Code reichlich kommentiert. Das Binary ist leider elendig gross geworden (28mb). Lazarus scheint noch mehr aufzublaehen als Delphi. Ferner nicht wundern wenn nach dem Verlassen des kompilierten Programms der Debugger meckert. Ein leidiges Lazarus Problem bei Verwendung von OpenDialog. Am besten einmal kompilieren und dann das Program ausserhalb der IDE aufrufen.

WICHTIG: >>> geht NUR mit *.bmp bitmaps, keine jpg, keine gif, ... <<<

Naechste Schritte:

1) Ich muss alle kurzen Kanten entfernen und nur die Langen ueberleben lassen, d.h. Kannten reduzieren.
2) Ich brauche Hough um Geraden und Ecken zu identifizieren.

Gutelo