Hallo zusammen,
ich arbeite gerade an einem Konzept für eine "automatische
Textkontrolle" von Anzeigedisplays auf Basis eines Mikrocontrollers.
Dieser soll Anzeigetexte auf einem Display erkennen und auf Korrektheit
überprüfen.
Beispiel:
Eine Messung dauert 10 Sekunden. Innerhalb dieser Zeit muss kontrolliert
werden, ob ein definierter Anzeigetext vom Testgegenstand (Display)
gezeigt wurde oder nicht. Es werden 100 Messungen durchgeführt,
Anzeigetext Nr. 1 ist "Test1", Anzeigetext Nr. 2 ist "Test2" (...)
Anzeigetext Nr. 100 ist "Test100".
Nun hätte ich am Ende gerne eine Textdatei zur Auswertung generiert:
Test1: TRUE
Test2: TRUE
Test3: FALSE
...
Die Daten am Ende vom Mikrocontroller auf den PC in eine .txt zu
schreiben bekomme ich selber hin.
Meine Frage:
Wie mache ich das mit der Erkennung eines Textes? Ich bräuchte quasi
eine Kamera, die für einen Zeitraum die Anzeige eines Displays
"mitfilmt" und als plausibles Ergebnis in Form eines Textes an den
Mikrocontroller sendet.
Gibt es für sowas fertige Hard -und Softwarelösungen? Wenn ja welche? Da
verschiedene Displays getestet werden müssen, darf keine Problematik bei
der Texterkennung aufgrund verschiedener Anzeigefonts, Schriftgrößen,
... entstehen.
Kosten sollte alles wie immer so wenig wie möglich :-D Vielen Dank für
Eure Gedanken zu dem Thema.
Gruß Simon
Für Fertiglösungen ist "Smartcamera" das Stichwort. Davon gibt es einige
in der Industrie. Fangen aber im vierstelligen Preisbereich an.
Mit einem Microcontroler sind die Aussichten eher bescheiden. Viel eher
ein Raspberry Pi:
https://hackaday.io/project/9669-texteye-raspberry-pi-zero-mobile-textreader
Übrigens, die technik bezeichnet man als "OCR". Optical Character
Recognition.
Alex G. schrieb:> SmartcameraAlex G. schrieb:> Für Fertiglösungen ist "Smartcamera" das Stichwort. Davon gibt es> einige> in der Industrie. Fangen aber im vierstelligen Preisbereich an.> Mit einem Microcontroler sind die Aussichten eher bescheiden. Viel eher> ein Raspberry Pi:> https://hackaday.io/project/9669-texteye-raspberry-pi-zero-mobile-textreader> Übrigens, die technik bezeichnet man als "OCR". Optical Character> Recognition.
Hallo Alex,
danke für die Denkansätze. Ich habe mal ein wenig google durchstöbert -
alles zu teuer.
Die Idee mit dem Rasperry ist eher das, was ich gesucht habe. Was hälst
du von folgendem Konzept:
Rasperry PI + Pi Camera module (Summe < 50€) zur Aufnahme der Videos -->
Übertragung an einen PC mit LabView (ist in der Firma vorhanden, bietet
anscheinend die OCR Möglichkeit). Hier habe ich auch die Möglichkeit,
alle Daten sauber zu exportieren.
Spricht was dagegen? Macht das alles Sinn? :-)
Blick auf die Startseite schrieb:> Das da könnte der Aufgabe gewachsen sein:> Beitrag "ESP32-CAM Entwicklungskit"
Hört sich auch gut an, danke für den Tipp.
Mir stellt sich die Frage, wie gut die Auflösung/Eigenschaften der
Kamera sein muss, damit das OCR Programm (welches auch immer) die Texte
noch zuverlässig erkennt.
Simon schrieb:> Rasperry PI + Pi Camera module (Summe < 50€) zur Aufnahme der Videos -->> Übertragung an einen PC mit LabView (ist in der Firma vorhanden, bietet> anscheinend die OCR Möglichkeit). Hier habe ich auch die Möglichkeit,> alle Daten sauber zu exportieren.>> Spricht was dagegen? Macht das alles Sinn? :-)
Da könntest du doch genau so gut eine Webcam am PC nehmen, oder mit dem
Smartphone/Camcorder aufnehmen.
Der Sinn des Raspis wäre schon dass der auch selber die Analyse der
Bilder macht.
Da du von Firma sprichst.. wollt ihr irgendwelche Schriftstücke
massenweise digitalisieren?
Dafür gibt es Dokumentenscanner welche höhere Qualität liefern als
normale Kameras.
Sönke P. schrieb:> Muss die Erkennung in "Echtzeit" erfolgen?>> Wenn nicht, dann könnte Amaz*n Mechanical Turk (https://www.mturk.com/)> eine gute Möglichkeit sein.
Also OCR braucht jetzt nicht sooo viel Rechenleistung als dass man auf
solche externen Resourcen zurückgreifen müsste.
OK, Raspi mit Kamera und OCR.
- Wie groß ist die Erkennungsgenauigkeit?
- Was ist mit dem üblichen Digit-Fehler?
- Wogegen wird auf TRUE, oder FALSE getestet?
Muss man sich was ausdenken!
Dagegen ist die Auswertung von String-Sequenzen wie
"Test x : TRUE / FALSE" doch lächerlich, da würde auch
"XYZ" reichen.
X = 0...100 (ein Hex-Byte für die Test-Nummer)
Y = '0', oder '1', oder 0, oder 1 (FALSE/TRUE) und
Z = irgendein Trenn-Zeichen reichen.
Womit sich die Ausgabe auch leichter verarbeiten ließe.
"Löst mir mal mein großes Problem, das kleine Problem hab
ich auch schon nicht im Griff"....
Anzeigedisplay ist ja NOCH schlimmer, als LCD-Display!
Der weiße Schimmel wiehert!
Das erste sagt Anzeige-Anzeige,
das zweite bringt immerhin noch LC zur Anzeige-Anzeige...
> OK, Raspi mit Kamera und OCR.>> - Wie groß ist die Erkennungsgenauigkeit?>> - Was ist mit dem üblichen Digit-Fehler?>> - Wogegen wird auf TRUE, oder FALSE getestet?>> Muss man sich was ausdenken!>> Dagegen ist die Auswertung von String-Sequenzen wie> "Test x : TRUE / FALSE" doch lächerlich, da würde auch> "XYZ" reichen.> X = 0...100 (ein Hex-Byte für die Test-Nummer)> Y = '0', oder '1', oder 0, oder 1 (FALSE/TRUE) und> Z = irgendein Trenn-Zeichen reichen.> Womit sich die Ausgabe auch leichter verarbeiten ließe.>> "Löst mir mal mein großes Problem, das kleine Problem hab> ich auch schon nicht im Griff"....
Hallo Jacko,
mit Merkmalen wie Erkennungsgenauigkeit, Digit-Fehler etc. habe ich mich
noch nicht beschäftigt. Mir geht es vorerst nur um´s Prinzip. Auch die
Auswertung der Zeichenketten werde bekomme ich hin.
Mir geht es primär um die OCR Thematik.
>Der Sinn des Raspis wäre schon dass der auch selber die Analyse der>Bilder macht.
Das Ding ist, dass neben dem übertragenem Kamerabild auch noch andere
Sensorik/Aktorik aus LabView heraus gesteuert werden soll. Zum Beispiel
ein Motor, der die Kamera in die richtige Position fährt. Dazu möchte
ich den Rasperry oder auch ein anderes Board nutzen. Die Auswertung der
Kameraaufnahmen sollte ebenfalls durch LabView passieren, ich denke das
macht am meisten Sinn da es hierfür schon fertige Tools gibt.
Somit machen meiner Meinung nach folgende 2 Konzepte Sinn:
1.: LabView <---> Rasperry <---> Sensorik/Aktorik
LabView <--- Kamera
ODER
2.: LabView <---> Rasperry <--> Kamera/Sensorik/Aktorik
Bei Konzept 2 werden die ganzen Videodatenmengen noch über den Rasperry
gejagt....macht eigentlich keinen Sinn oder?
Konzept 1 hat meiner Meinung nach folgende Vorteile:
- LabView Lizenz vorhanden mit einer komfortablen OCR Möglichkeit
- Kostet nicht viel
Letzte Frage: Nach welchen Kriterien sollte die Kamera ausgewählt
werden? Gibt es da günstige Lösungen auf "Platinenbasis" ?
Gruß Simon
Was mir gerade noch einfällt:
Man könnte doch bestimmt auch ein Smartphone einspannen und dessen
Kamerabild nach LabView übertragen...wieder was gespart :-D
Weil es sich bei der Texterkennung auf einem Display quasi um
"originale", perfekt dargestellte Zeichen handelt, die unter optimalen
Bedingungen aufgenommen werden, sind die Ansprüche an das OCR nicht
übermäßig hoch.
Im Gegensatz zu den Schwierigkeiten, mit denen ein OCR bei gescannten
Doukumenten klarkommen muss (schlechte Drucke, farbige Hintergründe,
schräge Zeilen, unvollständige Buchstaben, Knicke und Wellen im Papier
usw.), sind das ja hier "himmlische" Bedinungen ...
In der Open Source Welt geistert seit Jahren das Projekt "Tesseract"
herum, eine einstmals abgebrochene HP-Entwicklung.
