OCR für Arme, und ich bin noch ärmer

[Medium]

...an zündenden Ideen.

Aloah!

Ich bin darum gebeten worden (=Anweisung von oben ) eine kleine Texterkennung für Bildschirmtext zu basteln. Hintergrund ist eine Anwendung bei einem Kunden, deren Ausgabe überwacht werden soll, die jedoch nicht über Messages erreichbare WinControls dargestellt wird.
Das Bild der Anwendung zu bekommen ist kein Problem, auch die Positionen und Ausmaße der jeweiligen Stellen sind bekannt, ebenso die Schriftart und -größe. Das heisst ich kann bereits 1a zugeschnittene Bildstreifchen erzeugen die es dann zu analysieren gilt. Es gibt auch keine Probleme mit den Farben, das ganze ist S/W ohne Firlefanz.

Das Problem ist bei mir nun nur das prinzipielle Vorgehen, diese Bildchen in einen String zu verwursten (es gibt nicht einmal Zeilenumbrüche). Das Ganze soll jedoch auf einer nicht mehr soooo aktuellen Kiste laufen, und einen möglichst schlanken Fuß machen, da ich doch einige Stellen und relativ schnell auswerten muss, so dass es mir wiederstrebt da nun Pixel für Pixel jede x-Position jeweils mit Bitmaps aller möglichen Buchstaben zu vergleichen, was ja durchaus schnell in mehrere tausende Vergleiche für einen kleinen pupeligen String ausartet - und zudem fehleranfällig ist: Ich erkenne im Moment z.B. ein kleines 'd' als 'dl', weil der Strich vom 'd' von seiner x-Position aus gesehen genau wie das 'l' ausschaut.

Was für Anzätze gäbe es das a) effizienter und b) robuster zu erledigen?

[jfheins]

Das könnte sehr gut mit NN gehen

NN steht für neuronale Netze - Beispiel ist hier: http://www.delphipraxis.net/internal...t.php?t=119641

[Medium]

Ich hab ja befürchtet dass NNs auf den Tisch kommen - aber nicht so schnell

Problem 1: Ich habe null,keine Ahnung wie NNs funktionieren, und letztlich wie sie arbeiten. Der Lernaufwand wäre gigantisch, was der Terminerfüllung evtl. nicht ganz so gut täte.
Problem 2: Auch bei NNs muss ich denke ich das Bild in seine einzelnen Buchstaben zerlegen, wofür ich im Vorfeld aber erstmal erkennen muss wo genau diese sind. Dafür muss ich schon jeden Pixel anfassen, und danach erneut ins NN einführen. Mit schwebte etwas vor, bei dem man nach Möglichkeit jeden Pixel maximal 1 Mal "anfassen" muss.

Und zu guter letzt kann ich mir gut vorstellen dass es einen performanteren und naiveren Weg geben muss, da ja die Randbedingungen exakt bekannt sind. Es muss ja im Grunde nichts durch Abstrahierung wirklich erkannt werden, sondern lediglich verglichen (denke ich).

So reizvoll das Thema NNs ist, ich fürchte dass ich den Aufand da im Moment nicht hineinstecken kann, und vor allem die Angepasstheit an das Problem bezweifle. (Kanonen -> Spatzen *poof* )

[jaenicke]

Also das nachträglich zu erkennen wird schon kompliziert, wie dir ja wohl schon klar ist...

Vorschlag: Der Text muss so oder so ausgegeben werden. Die entsprechenden Routinen (DrawText usw.) könntest du vielleicht einfach hooken und anhand deren Aufrufe die Textausgaben mitloggen.
Das wäre in jedem Fall einfacher.

[Dax]

Wenn alle Parameter bekannt sind, könntest du das Bild in einzelne Teile, die nur einen Buchstaben enthalten, auftrennen. Am Ende hast du dann einzelne Teile, die noch von weissen Pixeln umgeben sind/sein können, diese Pixel solltest du beim auftrennen nach Möglichkeit auch schon rauswerfen. Dann hashst du alle einzelnen Teile mit einer für die Buchstabenmenge eineindeutigen Funktion, deren Ergebnis du für eine Lookuptabelle verwenden kannst - done. Das Auftrennen sollte auch ganz einfach sein: weisse Spalten beenden den aktuellen Schnipsel, leere Schnipsel und weisse Spalten werden verworfen. Das fasst jeden Pixel nur ein Mal an.

[Gargoyl]

Hi,

ich würde deinen Bild-String erstmal in einzelne Buchstaben trennen bzw. kleine Bildchen für die Buchstaben. Also für jeden Buchstaben ein Bild. Einfach als Trennsymbol eine Vertikale weiße Linie = Neuer Buchstabe. So bekommst du für jeden Buchstaben/Symbol ein kleines Bildchen. Du hast vermutlich inzwischen von jedem Buchstaben/Symbol ein kleines Bildchen angelegt mit denen du vergleichst. Damit du pro Buchstabe nicht alle Bildchen vergleichen muss, kannst du die Anzahl der möglichen Buchstaben ja nochmal ein schränken. Wenn dein 'Prüfsymbol' z.B. 2 Pixel breit ist, dann reicht es ja mit allen Buchstaben zu vergleichen die nur 2 Pixel Breit sind. so kannst du dir Vergleiche mit breiteren Buchstaben wie dem 'm' gleich mal sparen. Dann kommt es auch nicht zu deinem Problem mit dem 'd' dass als 'dl' erkannt wird, weil du mit dem 'l' gar nicht mehr vergleichst da es nicht breit genug ist und somit von vorneherein aussortiert wird. Zum anderen kannst du überprüfen wie viele Pixel des 'Prüfling' mit dem Potentiellen Buchstaben übereinstimmen. ein 'd' hat dann sicher keine 100%ige Übereinstimmung mit dem 'l'. Oder du machst eine XOR verknüpfung der beiden Bilder. Wenn das Ergebnis dann ein einfarbiges Bild ergibt hast du einen Treffer. Und bei 'd' und 'l' gibt das dann kein einfarbiges Ergebnis bei einer XOR Verknüpfung.
Ok, mehrere weiße Vertikale Linien sind dann eben ein Leerzeichen. Da muss man noch aufpassen

Wobei der Ansatz einer Überarbeitung bedarf wenn die Zeichen alle gleich breit sind wie z.B. bei 'Courier New' oder anderen Mono Space Schriftarten.

kleiner Schönheitsfehler bei der Idee: Das Zeichen " (Doppelte Anführungszeichen) wird als evtl. als '' (Zwei Apostrophe) erkannt, oder gar nicht. Da muss man dann einen Sonderfall einbauen.

Btw: mal was anderes... welche Font hast du? Da kann es je nach Font zu Problemen kommen. Ein großes 'I' und ein kleines 'L' sehen in Arial z.B. gleich aus.

Ich hoffe die Idee hilft dir weiter.

Gargoyl

[EDIT]Oh während ich getippt habe, war Dax schon mit der gleichen Idee schneller [/EDIT]

[Namenloser]

Zitat von Dax:

Das Auftrennen sollte auch ganz einfach sein: weisse Spalten beenden den aktuellen Schnipsel

Da könnte ClearType aber unter Umständen in die Quere kommen.

[Dax]

Zitat von NamenLozer:

Da könnte ClearType aber unter Umständen in die Quere kommen.

Zitat von Medium:

Es gibt auch keine Probleme mit den Farben, das ganze ist S/W ohne Firlefanz.

Vermutlich ist ClearType da nicht vorhanden oder einfach ausgeschaltet. Und selbst wenn es CT geben würde, könnte man es immer noch halbwegs zurückrechnen und einfach einen Schwellwert für Weiss annehmen, der noch eine Zerlegung ermöglich, deren Ergebnsise sich durch eineindeutige Funktionen beschreiben lassen.

[Medium]

Danke für euren Input erstmal!

Cleartype spielt keine Rolle hierbei - das würde es wirklich ganz schön verkomplizieren. Die Schriftart is MS Sans Serif in 11pt, und hier sind tatsächlich 'I' und 'l' identisch. Das kann ich aber umgehen in dem ich bei Wortanfängen einen Großbuchstaben voraussetze (bislang habe ich noch kein mit kleinem l anfangendes Wort entdeckt). Ich hoffe das bleibt so, dann ist das ausreichend.

Ein Problem ist hingegen evtl. das Zerschneiden in einzelne Buchstaben. Wenn man in der Schriftart und -größe mal "VWXY" hintereinander schreibt, fällt auf dass zwischen den Buchstaben kein "weisser" Streifen bleibt den ich als Trennung heranziehen könnte. Das fiel mir erst auf als ich mein Alphabet-Bitmap für die Vergleiche gemacht habe, und ich fürchte daher nun dass ich allgemein nicht nach diesem Kriterium schneiden kann. Auch sind Leerzeichen mal 2 und mal 3 Pixel breit

Ich könnte moglicherweise alle Buchstabenkombinationen mit ohne Trennung als Einheit verarbeiten, aber bis ich da alle möglichen Kombinationen (es gibt auch Sonderzeichen wie / und () und mehr) erstellt und durchgesehen habe ist Weihnachten 2015 - und dann habe ich noch immer nicht die möglichen 3er+ Kombis durch.

Wenn mein Chef wüsste was er mir da angetan hat


\\Edit: Okay, Kombis wie oben genannt kommen so weit nicht vor, so dass ich es mit Zerschneiden versuchen könnte. Neckischerweise aber gibt es durchaus Kombis bei denen 2 Buchstaben 2px Abstand haben, was jedoch kein Leerzeichen ist - das ja auch in 2px vorkommt. "Se" ist z.B. so eine Kombi. Arghs

\\Edit2: Ich hab mich vertan. Leerzeichen sind 3-4px breit. Ich sollte wohl doch lieber in den Mai tanzen gehen statt zu arbeiten =)
Ich werde das Schnippeln mal ausprogrammieren und schauen ob uns das performance-technisch genügt. Danke euch nochmal!

[jfheins]

Ich hätte da noch ne Idee

Und zwar folgendes: Deine 11pt Schrift dürfte maximal ungefähr 16 Pixel hoch sein.

Du könntest jetzt eventuell das Bild spaltenweise durchgehen und für jede Pixelspalte einen Wert berechnen. Der einfachheit halber z.B. eine Zahl. (16 bit Zahl, oberster Pixel ist LSB und unterster Pixel ist MSB)
Dann erhältst du für jede Spalte eine Zahl.

Jetzt kannst du das Bild als Zahlenabfolge darstellen. (Eine Zahl entspricht einer Bildspalte)

Für jeden Buchstaben, den du erkennen möchtest, musst du (vorher) ebenfalls mit dem gleichen verfahren Zahlenfolgen abspeichern.

Du hast also eine lange Zahlenfolge und viele kurze (die Buchstaben) - jetzt gehst du jeden Buchstaben durch und schaust, ob dessen Zahlenfolge am Anfang steht. Wenn ja: Buchstaben vorne wegnehmen und weiter gehts.
Wenn nein: Vorderste Zahl entfernen und weiter gehts (Buchstabe wurde nicht erkannt)

Also statt Pixel vergleichen, Words vergleichen (halt immer 16 Pixel auf einmal)