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

[Gargoyl]

Um das Problem mit WVXY zu lösen könntest du am Anfang einmal die maximale Breite eines Buchstaben ermitteln und dann spätestens nach dieser maximalen Breite abschneiden. Ich habe mit das mal angesehen, und das ist wirklich ein Ärgernis weil WV und VW sind schwierig auseinander zu halten. Da musst du dann prüfen wenn du bei einer max. breite Abscheidest und keine Übereinstimmung findest (z.B. bei VW weil da noch ein halbes W mit abgeschnitten wird), dann wird es kompliziert, dann musst du halt kucken ob der Anfang deines Bildes mit einem Buchstaben eine Übereinstimmung gibt um dann (hoffentlich) das V findest und da dann abschneidest.

Wenn du bei der Font aber noch mehr solche komischen Konstrukte findest, dann endet dein Algorithmus in einer Sammlung von Sonderfällen. Auch die korrekte Erkennung von (_) könnte problematisch sein auch Kombinationen mit 'II' 'Il' 'lI' und 'll' sehen Problematisch aus.

Aber sieh es so, selbst professionelle OCR Programme haben bei 'I' und 'l' Probleme.

Aber eine maximale Breite für Buchstaben einführen für die Trennung könnte zumindest helfen.

Und ich sehe gerade bei 'LM' klebt auch manchmal zusammen, aber auch nicht immer. Manchmal ist zwischen 'L' und 'M' eine vertikale Linie und manchmal nicht.


[EDIT] Die Idee von jfheins ist auch nicht schlecht. Allerdings würde da evtl. bei einem 'W' fälschlicherweise ein 'V' erkannt und hinterher wird kein Treffer mehr gefunden. Idee ist aber gut, muss man vielleicht sogar weniger Sonderfälle behandeln. z.B. bei dem Problem mit dem 'W': Wenn das 'V' erkannt wird, und danach kein Treffer mehr gefunden werden kann, dann einfach das 'V' verwerfen und weitermachen, dann dürfte er das 'W' erkennen und danach (hoffentlich) auch weitere Treffer. das gleiche Problem hat man dann bei einem 'L' weil erst ein 'I' oder 'l' erkannt wird. Wobei das 'I' und 'l' so ein Problem für sich ist. [/EDIT]

[EDIT2] Das Problem mit dem 'I' und 'l': 'Ich' und 'lecker' wie willst du das unterscheiden? da brauchst du ja fast schon ein Wörterbuch um das zu erkennen dass 'Iecker' kein dt. Wort ist und es also 'lecker' heißen muss. selbes mit 'lch' und 'Ich'[/EDIT2]

[jaenicke]

Ich verstehe weiterhin nicht, warum das ganze besser sein soll als den Text direkt bei der Ausgabe abzufangen, aber gut, nicht mein Problem. Bei mir jedenfalls ging das sehr viel besser wie angesprochen mit Hooks.

[Medium]

@Gargoyl: Wie gesagt, mit etwas Glück stellt sich das Problem mit VW und Konsorten erst garnicht. Da diese Lösung Maßgeschneidert ist muss sie am Ende nirgend wo anders funktionieren.

Die Idee von jfheins klingt auch lustig! Aber auch hier stellt sich das Problem dass man erst zerteilen müsste, da manche Buchstaben mitten drin so aussehen wie ein anderer am Anfang z.B.. Ich glaube der Gewinn durch die gesparten Vergleiche würde hier einer ziemlich komplexen Logik drum herum geopfert.

Aaaaaber nun zu dir jaenicke! Ich muss zugeben dein erstes Posting nicht genug beachtet zu haben. Was für Möglichkeiten habe ich da? Das wichtigste ist dabei, dass ich irgendwie auch an die Koordinaten heran komme um den String zuzuordnen. Zudem ist die Frage in welchem Bezug die Koordinaten sind. Zum obersten Fenster, oder zum Control auf dem sie letztlich erscheinen usw.
Da ich bislang auch noch keine APIs gehooked habe, würde mich hier auch stückchen Code evtl. schon weiter bringen um zu sehen ob das nicht evtl. wirklich die geniale Lösung wäre.

[omata]

klick

[jaenicke]

Zitat von Medium:

Was für Möglichkeiten habe ich da? Das wichtigste ist dabei, dass ich irgendwie auch an die Koordinaten heran komme um den String zuzuordnen.

Dabei hilft dir dies:
http://omorphia.cvs.sourceforge.net/...allCollection/

Wenn es um eine zeitnahe Lösung gibt, dann bietet sich eine fertige Lösung vermutlich an. Hier gibt es so etwas, auch für Delphi, eine Firmenlizenz kostet im Moment 199€, das sollte machen was du brauchst (getestet habe ich es nicht, ich habe es selbst gerade erst gefunden):
http://www.hook-api.com/ (Text Capture Source)

[Medium]

Danke euch beiden, ich werde mir beide Varianten mal zu Gemüte führen, und dann meinen Chef nochmal fragen ob diese Funktion - da ja egal wie doch recht aufwendig - zwingend ist, bzw. ob es dem Kunden das wert wäre. Ich vermute es ist sich vorher keiner so wirklich bewusst gewesen was das alles mit sich bringt, mir inklusive.

[quantum]

Wenn du die genauen Anfangskoordinaten und den Zeichensatz kennst, brauchst du nur jedes sichtbare Zeichen des Zeichensatzes per Pixel zu vergleichen.
Hast du den ersten Buchstaben, dann kennst du die Breite und kannst mit dem nächsten Zeichen fortfahren.

Zur Beschleunigung könntest du dir vom Zeichensatz für jedes Zeichen eine Pixel-Checksumme bilden und die Breite vormerken.
Dann berechnest du an der aktuellen Position und Breite die Checksumme der Pixel und vergleichst sie mit der vorbereiteten Liste der Checksummen/Zeichenbreiten.

Evtl. müsstest du in der Liste manche Zeichen umsortieren, damit zB ein "W" nicht als "V" erkannt wird.

Pseudocode:

Delphi-Quellcode:

function TextLineAtBitmapPos(Bitmap: TBitmap; XPos, YPos: Integer): String;
  result := '';

  repeat
    for width := MINWIDTH to MAXWIDTH do begin
      checksum := CalcPixelChecksum(Bitmap, XPos, YPos, width);
      foundChar := FindInList(width, checksum);
      if foundChar <> #0 then begin
        result := result + foundChar;        
        Inc(XPos, width);
        break;
      end;    
    end;
  until foundChar = #0;
end;

Nur so eine Idee...

[Medium]

Durch deinen Beitrag kam mir gerade irgendwie in den Sinn, warum mein erster Ansatz performancemäßig seltsam war, obgleich du es nicht explizit geschrieben hast. Ich hatte immer Kandidaten für Zeichen in ein temporäres Bitmap gezeichnet (dass ich vorher immer resizen musste), und dieses dann mit den Templates vom Zeichensatz verglichen. Ich müsste ja lediglich die Koordinaten anpassen und kann direkt im ursprünglichen Bild vergleichen
Die Idee mit der Prüfsumme gefällt mir auch gut! Ist ansatzweise ähnlich der Idee von jfheins weiter vorne. Ich bin gespannt was ich letztlich einbauen soll - die Entscheidung muss ich wohl weiter geben.

[quendolineDD]

Interessant ist aber auch der Ansatz von dem vorgeschlagenen Programm, welches für bestimmte Fenster die Windows APIs zum zeichnen von Texten etc. hooked. Das wäre dann ganz weg vom OCR und für dein Anwendungsfall auch eine passende Lösung.

[Spiderpig_GER_15]

ich hab jetzt nicht alle Beiträge in voller länge durchgelesen, aber so schwer stelle ich mir das nicht vor:

Schritt Eins:
Programm schreibt das Alphabet mit der Schriftart und wendet die Buchstabenextrahiermethode (Weiße Linie) an. Für jeden Buchstaben zählt es die Anzahl der schwarzen Pixel. Ich Denke, Vorrausgesetzt das Schicksal meint es nicht alzu schlecht mit dir, das in jedem Buchstaben eine andere Anzahl schwarzer Pixel ist.

Findest du jetzt einen breiteren Buchstaben als gewöhnlich ( Bsp.:WW ) Der darauf zurückzuführen ist, dass sich zwei Buchstaben berühren, so rechnest du die schwarze Pixelzahl aus, und schaust welche beiden Buchstaben das Ergeben könnten. Bei ganz dreisten zusammenhängenden 3er Buchstaben, wird das etwas rechenintensiver.

Man bedenke aber die Arbeit am Anfang nur einmal ausgeführt werden muss, weshalb man finde ich sagen kann, dass das auch ein älterer PC packt


Gruß

Spiderpig