Compare commits
33 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 24ba707d3c | |||
| 1a23225e95 | |||
| ad88641b97 | |||
| 46e4fcaa04 | |||
| 4c7860e332 | |||
| 24c92fd599 | |||
| 1d243baf11 | |||
| 565352e0ec | |||
| 0e8481e084 | |||
| 7cf04bbb84 | |||
| ea0ee2e256 | |||
| f22421dec4 | |||
| 078fadb253 | |||
| 8b97feed08 | |||
| e7e146ee5a | |||
| 5bd4d45d6a | |||
| 5de11eb600 | |||
| a2550ef7fa | |||
| df57390764 | |||
| da240bebcd | |||
| 84b13e3c9c | |||
| 72c8d4ee5a | |||
| 0551aa4ace | |||
| aa8f6eb8f7 | |||
| ceb827643d | |||
| 5b621e0d80 | |||
| 51ce74be05 | |||
| a486e1663d | |||
| 788f0b9bd7 | |||
| fd6198e809 | |||
| 1fac9a4661 | |||
| c96fd9117e | |||
| 267bb6aee8 |
Vendored
+7
@@ -55,3 +55,10 @@ Catmull-Rom
|
||||
Hermite
|
||||
Hermite-Interpolation
|
||||
Nearest-Neighbor
|
||||
unimodalen
|
||||
Nachbearbeitungskette
|
||||
schlagwortbasierten
|
||||
Screenshotdaten
|
||||
zenon-Produktpalette
|
||||
Processings
|
||||
Filterungsschritte
|
||||
|
||||
Vendored
+3
@@ -0,0 +1,3 @@
|
||||
COPA-DATA
|
||||
thresholding
|
||||
binarization
|
||||
@@ -1,11 +1,9 @@
|
||||
\chapter{Kurzfassung}
|
||||
|
||||
Optische Texterkennung ist in der heutigen Zeit von immer größerer Bedeutung und wird in vielen Industrien dafür genutzt, effizient textuelle Informationen aus Fotos und digitalen Bildern zu gewinnen. Diese Bachelorarbeit widmet sich einem der Anwendungsgebiete von optischer Texterkennung, der Erkennung von Textdaten in Oberflächenscreenshots, und versucht, die Menge und Qualität der gewonnenen Daten zu maximieren. Dazu werden verschiedene Vorgehensweisen zur Aufbereitung der Bilder, sowie der Nachbearbeitung der erkannten Textdaten exemplarisch miteinander verglichen und anhand festgelegter Qualitätskriterien analysiert.
|
||||
Diese Bachelorarbeit konzentriert sich auf eines der vielen Anwendungsgebiete der optischen Texterkennung: Extraktion von Textdaten aus digitalen Screenshots. Das Ziel ist es, die Menge und Qualität der gewonnenen Daten zu maximieren, um die Verwaltung von grafischen Ressourcen für die Produktdokumentation von COPA-DATA zu vereinfachen.
|
||||
|
||||
Die zentrale Fragestellung der Arbeit zielt darauf ab, die beste Methodik für die Texterkennung zu identifizieren und die Resultate zu optimieren. Somit wird die Verwaltung der Produktdokumentation von COPA-DATA vereinfacht und gleichzeitig ein Beitrag zur Forschung im Bereich der Texterkennung in grafischen Oberflächen geleistet.
|
||||
Dazu wird eine Auswahl von Bildverarbeitungsmethoden wie Resampling oder Binarisierung für die Aufbereitung der Bilder getroffen. Ebenso werden die Filterungsschritte für die Ergebnisdaten der Texterkennung mittels Techniken aus dem Bereich des Natural Language Processings, beispielsweise Normalisierung oder einfache sprachspezifische Filter, ausgewählt. Die Algorithmen werden in ihrer Grundfunktion erklärt und ihr Einfluss auf die Ergebnisse der Texterkennung anhand gängiger Metriken für die Sprach- und Texterkennung objektiv miteinander verglichen.
|
||||
|
||||
Um die Forschungsfrage zu beantworten, wird eine Auswahl von Algorithmen für die Bild- und Textbearbeitung getroffen. Diese Algorithmen werden in ihrer Grundfunktion erklärt und die Ergebnisse der Texterkennung anhand einer Stichprobe untersucht. Durch die Anwendung gängiger Metriken für die Sprach- und Texterkennung werden die jeweiligen Algorithmen objektiv miteinander verglichen und in einen automatisch generierten Bericht eingetragen. Dieser beinhaltet eine detaillierte Übersicht aller Ergebnisse der Texterkennung und bildet die Grundlage für die Auswertung.
|
||||
Die Analyse verschiedener Bilder mit nur einem Verfahren führt nicht immer zu optimalen Ergebnissen. Besonders bei Anwendung der unterschiedlichen Schwellenwertverfahren müssen die Parameter individuell auf die unterschiedlichen Bildmerkmale angepasst werden, um keine wichtigen Details zu verlieren. Basierend auf den in dieser Bachelorarbeit angestellten Vergleichen kann das Texterkennungssystem für die COPA-DATA Produktdokumentation so parametriert werden, dass bei Verarbeitung unterschiedlicher Eingangsbilder möglichst viele Details eingefangen werden und das Endergebnis der Texterkennung innerhalb des Bildes optimiert werden kann.
|
||||
|
||||
Die Analyse aller Ergebnisdaten im Bericht erteilt Aufschluss darüber, welche Algorithmen in welchen Szenarien die besten Ergebnisse liefern. Die größte Auswirkung auf die Ergebnisdaten hat der Austausch des Thresholding- \bzw Binarisierungsverfahrens: Werden unpassende Parameter oder Verfahren genutzt, wird nur ein Bruchteil des verfügbaren Texts erkannt. Wird das passende Verfahren gewählt, wird ein Großteil der Daten korrekt vom Texterkennungssystem erkannt.
|
||||
|
||||
Für weitere Forschung oder Anpassung an spezifische Anforderungen kann die protoypischen Implementierung \bzw die jeweiligen Komponenten wiederverwendet werden. Durch den modularen Aufbau des automatischen Vergleichssystems kann selbst nach Änderung der Anzeigesprache oder einer farblichen Neugestaltung der grafischen Oberfläche stets mit wenig Aufwand die ideale Vorgehensweise zur Texterkennung ermittelt werden.
|
||||
Für weitere Forschung oder Anpassung an spezifische Anforderungen kann die prototypische Implementierung \bzw deren Komponenten wiederverwendet werden. Durch den modularen Aufbau ist es möglich, neue Funktionalität hinzuzufügen oder bestehende zu verändern. Somit kann selbst nach Änderung der Anzeigesprache oder einer farblichen Neugestaltung der grafischen Oberfläche stets mit wenig Aufwand die ideale Vorgehensweise zur Texterkennung ermittelt werden. Auch weitere Schritte zur Verbesserung der Texterkennung, beispielsweise Kantendetektion in der Bildverarbeitung oder "Fuzzy Matching" zur Erfassung der Ergebnisdaten sind aufgrund der flexiblen Struktur realisierbar.
|
||||
@@ -1,12 +1,11 @@
|
||||
\chapter{Abstract}
|
||||
\begin{english}
|
||||
Optical text recognition is becoming increasingly important in today's world and is used in many industries to efficiently extract textual information from photos and digital images. This bachelor thesis is dedicated to one of the application areas of optical text recognition, the recognition of text data in user-interface screenshots, and attempts to maximize the quantity and quality of the data obtained. For this purpose, different procedures for the preparation of the images, as well as the post-processing of the recognized text data are compared with each other and analyzed based on defined quality criteria.
|
||||
|
||||
The central question of the thesis aims to identify the best methodology for text recognition and optimize the results. The management of of COPA-DATA's product documentation will be simplified and at the same time a contribution to research in the field of text recognition in graphical user interfaces is being made.
|
||||
This bachelor's thesis focuses on one of the many fields of optical character recognition: the extraction of textual data from digital screenshots. The goal is to maximize the amount and quality of the resulting data, hence simplifying the management of graphical resources for COPA-DATA's product documentation.
|
||||
|
||||
In order to answer the central question, a selection of algorithms for image and text processing is made. The basic function of these algorithms is explained and the results of text recognition are examined using a sample. By applying common metrics for speech and text recognition, the respective algorithms are objectively compared with each other and entered into an automatically generated report. This report contains a detailed overview of all text recognition results and forms the basis for the evaluation.
|
||||
For this purpose, a selection of algorithms including resampling or binarization for image processing is chosen. For filtering the resulting data, natural language processing techniques, for instance normalization or basic language-specific filtering methods are being selected. After explaining the algorithms in their basic function, they are objectively compared using common metrics for speech and text recognition.
|
||||
|
||||
The analysis of all result data in the report provides information, showing which algorithms deliver the best results in which scenarios. The greatest impact on the result data is the replacement of the thresholding or binarization method: If unsuitable parameters or methods are being used, only a fraction of the available text is recognized. If the appropriate method is selected on the other hand, the majority of the data is correctly recognized by the text recognition system.
|
||||
Analyzing different pictures using just one method does not always lead to satisfying results. To avoid losing important details, specifically when working with binarization techniques such as thresholding, the chosen parameters must match the individual characteristics of the picture. Based on the comparisons conducted in this bachelor thesis, the text recognition system for the COPA-DATA product documentation can be parameterized in such a way that it captures as many details as possible when processing different input images, optimizing the end result of text recognition within the image.
|
||||
|
||||
For further research or adaptation to specific requirements, the prototypical implementation and the respective components can be reused. Thanks to the modular structure of the automatic comparison system, the ideal procedure for text recognition can always be determined with little effort, even after changing the display language or redesigning the color of the graphical user interface.
|
||||
The prototypical implementation and its respective components are designed to be reusable for further research or adaptation to specific requirements. Due to the modular structure of the automated comparison system, it is possible to add new functionality and to edit existing features. As a result, a satisfying text recognition approach can always be determined with little effort, even after changing the display language or after a complete redesign of the graphical user interface. Further steps to improve text recognition, such as edge detection in image processing or "fuzzy matching" to capture result data, are feasible due to the flexible structure.
|
||||
\end{english}
|
||||
@@ -1,4 +0,0 @@
|
||||
\section{Fragestellung}
|
||||
\label{fragestellung}
|
||||
|
||||
Ziel dieser Bachelorarbeit ist es, herauszufinden, welche Vorgehensweisen bei der Texterkennung zu den besten Ergebnissen führen. Dazu werden die Resultate der Bild- und Textverarbeitung anhand gängiger Fehlermetriken für Texterkennungssysteme verglichen.
|
||||
@@ -1,8 +1,6 @@
|
||||
\section{Ziele}
|
||||
\section{Zielsetzung}
|
||||
\label{ziele}
|
||||
|
||||
Das Ziel dieser Bachelorarbeit ist das Ermitteln einer Vorgehensweise für Texterkennung in Screenshots von grafischen Oberflächen. Verschiedene Algorithmen zur Bildbearbeitung vor der Texterkennung sowie Nachbearbeitung \bzw Filterung der Ergebnisdaten sollen evaluiert werden. Die Ergebnisdaten sollen anschließend anhand von festgelegten Qualitätskriterien aus der programmatischen Sprach- und Schrifterkennung, beispielsweise der \hyperref[metriken_cer]{Zeichenfehler-} oder \hyperref[metriken_wer]{Wortfehlerrate}, analysiert und miteinander verglichen \mcite{karpinski2018metrics} werden.
|
||||
|
||||
|
||||
Das Ziel dieser Bachelorarbeit ist das Ermitteln einer Vorgehensweise für Texterkennung in Screenshots von grafischen Oberflächen. Verschiedene Algorithmen zur Bildbearbeitung vor der Texterkennung oder Nachbearbeitung \bzw Filterung der Ergebnisdaten werden evaluiert und anhand von festgelegten Qualitätskriterien analysiert.
|
||||
|
||||
Die prototypische Implementierung dient als Basis für jegliche Tests und Analysen, anhand derer die Algorithmen automatisch verglichen werden. Die entwickelten Komponenten werden als Bibliotheken zur Verfügung gestellt, um die Texterkennung inklusive automatischer Bildverarbeitung und Filterung der erkannten Inhalte \bzw Schlagworte später in anderen Anwendungen weiterverwenden zu können.
|
||||
Eine prototypische Implementierung dient als Basis für die nachfolgenden Tests und Analysen, anhand derer die Algorithmen automatisch evaluiert werden sollen. Alle entwickelten Komponenten sollen als Bibliotheken zur Verfügung gestellt werde, um die Texterkennung inklusive automatischer Bildverarbeitung und Filterung der erkannten Inhalte \bzw Schlagworte später in anderen Anwendungen weiterverwenden zu können.
|
||||
@@ -3,4 +3,4 @@
|
||||
|
||||
\input{chapters/c10_einleitung/motivation}
|
||||
\input{chapters/c10_einleitung/herausforderungen}
|
||||
\input{chapters/c10_einleitung/fragestellung}
|
||||
\input{chapters/c10_einleitung/vorgehensweise}
|
||||
@@ -1,12 +1,31 @@
|
||||
\section{Motivation}
|
||||
\label{motivation}
|
||||
|
||||
Die in Salzburg ansässige COPA-DATA GmbH bietet die Softwareplattform zenon an, die als umfassende Gesamtlösung Unternehmen in zahlreichen Anwendungsgebieten bei der Automatisierung ihrer Herstellungsprozesse unterstützt.
|
||||
Die in Salzburg ansässige COPA-DATA GmbH bietet die Softwareplattform zenon an, die als umfassende Gesamtlösung Unternehmen in zahlreichen Anwendungsgebieten bei der Automatisierung ihrer Herstellungsprozesse unterstützt \mcite{copa-data_zenon}.
|
||||
|
||||
Die zenon-Plattform kann sowohl vom Kunden selbst, als auch durch das Professional Services Team individuell auf Kundenanforderungen zugeschnitten und in bestehende Prozesse eingebunden werden. Den Grundstein für die hohe Anpassbarkeit bildet die Produktdokumentation, in der Schnittstellendokumentation, Anleitungen und Beispiele in verschiedensten Sprachen, Formaten und mit kundenspezifischen Erweiterungen umfassend sowohl für Mitarbeiter, als auch für Kunden festgehalten sind.
|
||||
Die zenon-Plattform kann sowohl vom Kunden selbst, als auch durch das Professional Services Team individuell auf Kundenanforderungen zugeschnitten und in bestehende Prozesse eingebunden werden. Den Grundstein für die hohe Anpassungsfähigkeit bildet die Produktdokumentation, in der Schnittstellendokumentation, Anleitungen und Beispiele in verschiedensten Sprachen, Formaten und mit kundenspezifischen Erweiterungen umfassend sowohl für Mitarbeiter, als auch für Kunden festgehalten sind.
|
||||
|
||||
In der Produktdokumentation werden, besonders in Hinblick auf die grafischen Tools wie die zenon Engineering Studio Entwicklungsumgebung oder die zenon Service Engine, zahlreiche Grafiken verwendet, um Beispiele verständlicher zu machen und Anleitungen übersichtlicher zu gestalten. Um bei dem großen Funktionsumfang der zenon-Tools, den vielen Sprachen, Anpassungen und den unterschiedlichen Themengebieten innerhalb der Dokumentation nicht den Überblick zu verlieren, benötigt das interne "Technical Content and Translation" Team unterstützend zu dem intern verwendeten CMS eine dedizierte Anwendung zur Verwaltung von sprachabhängigen Bilddateien.
|
||||
In der Produktdokumentation werden, besonders in Hinblick auf die grafischen Werkzeuge wie die zenon Engineering Studio Entwicklungsumgebung oder die zenon Service Engine, zahlreiche Grafiken wie \autoref{bild_eigenschaften_beispiel} verwendet, um Beispiele verständlicher zu machen und Anleitungen übersichtlicher zu gestalten. Um bei dem großen Funktionsumfang der zenon-Produktpalette, den vielen Sprachen, Anpassungen und den unterschiedlichen Themengebieten innerhalb der Dokumentation den Überblick zu behalten, benötigt das interne "Technical Content and Translation"-Team unterstützend zu dem intern verwendeten Inhaltsverwaltungssystem eine dedizierte Anwendung zur Verwaltung von sprachabhängigen Bilddateien.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\begin{minipage}{0.50\textwidth}
|
||||
\includegraphics[width=\textwidth]{include/screenshots/historian_assistent_001.png}
|
||||
\end{minipage}
|
||||
\hfill
|
||||
\begin{minipage}{0.49\textwidth}
|
||||
\begin{minipage}{\textwidth}
|
||||
\includegraphics[width=\textwidth]{include/screenshots/driver_brpvi_offlineimport_004.png}
|
||||
\end{minipage}\hfill
|
||||
\vfill
|
||||
\begin{minipage}{\textwidth}
|
||||
\includegraphics[width=\textwidth]{include/screenshots/driver_archdrv_variablendefinition_001.png}
|
||||
\end{minipage}\hfill
|
||||
\end{minipage}
|
||||
\caption{Beispielhafte Auswahl typischer Dialogscreenshots.}
|
||||
\label{bild_eigenschaften_beispiel}
|
||||
\end{figure}
|
||||
|
||||
Während das Programm auch die Basisfunktionalität, das Speichern, Bearbeiten, Löschen, Abrufen beziehungsweise das generelle Verwalten von Screenshots und der zugehörigen Metainformation abdecken soll, konzentriert sich diese Bachelorarbeit primär auf die Kategorisierungsfunktionalität der Bildinhalte.
|
||||
|
||||
Mithilfe von optischer Texterkennung (engl. optical character recognition, "OCR") soll es den Mitarbeitern möglich gemacht werden, hochgeladene Screenshots und Grafiken aufgrund ihrer Inhalte zu verschlagworten, um sie später anhand dieser suchen zu können.
|
||||
Mithilfe von optischer Texterkennung (\engl{Optical Character Recognition}, \kurz{OCR}) sollen Mitarbeiter hochgeladene Screenshots und Grafiken aufgrund ihrer Inhalte verschlagworten können, um sie später anhand dieser zu finden.
|
||||
@@ -0,0 +1,10 @@
|
||||
\section{Aufbau}
|
||||
\label{aufbau}
|
||||
|
||||
In \autoref{grundlagen} wird der technische Grundstein für die Bachelorarbeit gelegt. Informationen zur Vorgehensweise und zu den wichtigsten Punkten bei der \hyperref[grundlagen_preprocessing]{Vorverarbeitung} und \hyperref[grundlagen_postprocessing]{Nachbearbeitung} werden erarbeitet und dienen als Basis für die spätere Entscheidungsfindung in \autoref{konzept}. Weiters werden die Metriken erklärt, die für den Vergleich der Qualität der Texterkennungsergebnisse notwendig sind.
|
||||
|
||||
Sind die Rahmenbedingungen geklärt, ist gemäß \autoref{konzept} eine begründete Auswahl an verwendeten \hyperref[algorithmen_preprocessing]{Algorithmen} und \hyperref[konzept_texterkennungssystem]{Technologien} zu treffen. Verschiedene Algorithmen werden verglichen und auf ihre Stärken und Schwächen in Bezug auf Screenshot\-daten untersucht. Die geeigneten Algorithmen werden anschließend in \autoref{implementierung} für den Vergleich verwendet.
|
||||
|
||||
Basierend auf dem Konzept wird in der prototypischen \hyperref[implementierung]{Implementierung} ein Programm geschaffen, welches verschiedene Algorithmen anhand einer Stichprobe, bestehend aus beispielhaft ausgewählten Screenshots, vergleicht. Mittels der flexiblen Komponenten soll eine spätere Anpassung des Programmablaufs \bzw die Implementierung weiterer Algorithmen einfach sein, was schnelles Prototyping und Testen fördern soll. Das Ergebnis ist ein automatisch generierter Bericht, anhand dessen die Ergebnisdaten untersucht werden können.
|
||||
|
||||
Schlussendlich müssen die in \hyperref[implementierung]{Implementierung} generierten Daten evaluiert werden. Dazu werden die jeweiligen Sektionen des Berichts in \autoref{evaluierung} einzeln betrachtet und die Ergebnisse verglichen.
|
||||
@@ -1,5 +1,9 @@
|
||||
\chapter{Grundlagen}
|
||||
\label{Grundlagen}
|
||||
\chapter{Optische Texterkennung}
|
||||
\label{grundlagen}
|
||||
|
||||
\input{chapters/c20_grundlagen/stand_der_technik}
|
||||
\input{chapters/c20_grundlagen/technologien}
|
||||
Für einen technischen Überblick und als Grundlage für die Auswahl der innerhalb dieser Bachelorarbeit verwendeten Algorithmen wird im folgenden Kapitel näher auf \hyperref[grundlagen_texterkennungssysteme]{Texterkennungssysteme}, Grundlagen zur \hyperref[grundlagen_preprocessing]{Vorverarbeitung}, \hyperref[grundlagen_postprocessing]{Nachbearbeitung} sowie die verwendeten \hyperref[metriken]{Metriken} zum Vergleich eingegangen.
|
||||
|
||||
\input{chapters/c20_grundlagen/texterkennungssysteme}
|
||||
\input{chapters/c20_grundlagen/preprocessing}
|
||||
\input{chapters/c20_grundlagen/postprocessing}
|
||||
\input{chapters/c20_grundlagen/metriken}
|
||||
+15
-13
@@ -1,18 +1,19 @@
|
||||
\subsection{Metriken}
|
||||
\section{Metriken}
|
||||
\label{metriken}
|
||||
|
||||
Um die erkannten Ergebnisse unter Verwendung der verschiedenen Pre- und Postprocessing Schritte mittels eines einheitlichen Systems vergleichen zu können, wird auf die in der optischen Texterkennung gängigen Metriken "Character Metric", auch bekannt als "Character Error Rate" und "Word metric" oder "Word Error Rate" (\kurz{WER}) \mcite{karpinski2018metrics}, basierend auf der Levenshtein-Distanz \mcite{levenshtein1966binary} zurückgegriffen.
|
||||
Um die erkannten Ergebnisse unter Verwendung der verschiedenen Pre- und Postprocessing Schritte mittels eines einheitlichen Systems vergleichen zu können, wird auf die in der optischen Texterkennung gängigen Metriken "Character Metric", auch bekannt als "Character Error Rate" und "Word metric" \bzw "Word Error Rate" \mcite{karpinski2018metrics}, basierend auf der Levenshtein-Distanz \mcite{levenshtein1966binary} zurückgegriffen.
|
||||
|
||||
Sowohl die Character- als auch die Word Error Rate sind häufig genutzte Vergleichswerte, die ihren Ursprung in der computergestützten Sprachverarbeitung \bzw automatischen Spracherkennung haben \mcite{wang2003word}. Da die optische Texterkennung und die automatische Spracherkennung jeweils darauf abzielen, maschinenlesbaren Text aus nicht-strukturierten Daten zu extrahieren, sind die Prinzipien dieser Metriken auch auf die optische Texterkennung anwendbar \mcite{tong1996statistical}.
|
||||
|
||||
\subsubsection{Word Error Rate}
|
||||
\subsection{Word Error Rate}
|
||||
\label{metriken_wer}
|
||||
|
||||
Die Wortfehlerrate (\engl{Word Error Rate}, \kurz{WER}) beschreibt den prozentualen Anteil der falsch erkannten oder fehlenden Wörter eines Textes im Vergleich zu einer Referenz, welche im Falle der folgenden Vergleiche immer alle sichtbaren Texte im Bild repräsentiert. Je niedriger die WER, desto genauer ist der OCR-Vorgang. Um die WER zu berechnen, bildet man die Summe aller notwendigen Ersetzungen, Entfernungen und Einfügungen, um aus dem erkannten Text den Referenztext bilden zu können und setzt sie mit der Gesamtwortanzahl im Referenztext in Verhältnis \mcite{levenshtein1966binary, park2008empirical, karpinski2018metrics}.
|
||||
Die Wortfehlerrate (\engl{Word Error Rate}, \kurz{WER}) beschreibt den prozentualen Anteil der falsch erkannten oder fehlenden Wörter eines Textes im Vergleich zu einer Referenz, welche im Falle der folgenden Vergleiche immer alle sichtbaren Texte im Bild repräsentiert. Je niedriger die WER, desto genauer ist der OCR-Vorgang. Um die WER zu berechnen, bildet man die Summe aller notwendigen Ersetzungen, Entfernungen und Einfügungen, um aus dem erkannten Text den Referenztext bilden zu können und setzt sie mit der Gesamtwortanzahl im Referenztext in Verhältnis. \mcite{levenshtein1966binary, park2008empirical, karpinski2018metrics}
|
||||
|
||||
\subsubsubsection{Berechnung}
|
||||
\subsubsection{Berechnung}
|
||||
|
||||
Die mathematische Formel für die Word Error Rate lautet wie folgt \mcite{karpinski2018metrics}:
|
||||
|
||||
Die mathematische Formel für die Word Error Rate lautet somit wie folgt:
|
||||
\begin{center}
|
||||
\[
|
||||
\text{WER} = \frac{S + D + I}{N}
|
||||
@@ -27,20 +28,21 @@ wobei die einzelnen Komponenten folgende Größen darstellen:
|
||||
\item \(N\) beschreibt die Gesamtanzahl der Wörter in der Referenz
|
||||
\end{itemize}
|
||||
|
||||
\subsubsubsection{Vorteile und Nachteile}
|
||||
\subsubsection{Vorteile und Nachteile}
|
||||
|
||||
Die WER spiegelt ohne großen Rechenaufwand direkt wider, wie stark die erkannten Texte der Referenz gleichen. Hierbei werden fehlerhafte Einsetzungen, Löschungen und falsch erkannte Wörter \bzw Teilwörter gleichermaßen gewichtet. Es ist jedoch nicht möglich, die korrekte Reihenfolge der erkannten Wörter darzustellen oder bestimmte wichtige Stellen im Text höher zu gewichten als andere. Zudem werden fehlerhaft erkannte Wörter als vollwertige Ersetzung wahrgenommen, auch wenn nur ein einzelnes Zeichen falsch ist. Dadurch wird das Ergebnis stark beeinflusst.
|
||||
|
||||
Um die Verfälschung der Ergebniswerte durch die WER möglichst gering zu halten, muss mindestens eine weitere weitere Fehlermetrik zum Vergleich verwendet werden.
|
||||
Um die Verfälschung der Ergebniswerte durch die WER möglichst gering zu halten, muss mindestens eine weitere Fehlermetrik, beispielsweise die \hyperref[metriken_cer]{Character Error Rate}, zum Vergleich verwendet werden.
|
||||
|
||||
\subsubsection{Character Error Rate}
|
||||
\subsection{Character Error Rate}
|
||||
\label{metriken_cer}
|
||||
|
||||
Die Zeichenfehlerrate (\engl{Character Error Rate}, \kurz{CER}) beschreibt die Anzahl der falsch erkannten oder fehlenden Zeichen im Vergleich zu einem Referenzwort und basiert wie die \hyperref[metriken_wer]{Word Error Rate} auf der Levenshtein-Distanz \mcite{levenshtein1966binary}. Je niedriger die CER, desto genauer ist der OCR-Vorgang. Ähnlich wie die WER wird die CER aus der Summe aller Ersetzungen, Entfernungen und Einfügungen, notwendig um aus dem erkannten Wort die Referenz bilden zu können, gebildet \mcite{levenshtein1966binary}. Diese Summe wird anschließend durch die Zeichananzahl des Referenzwortes geteilt \mcite{park2008empirical, karpinski2018metrics}.
|
||||
|
||||
\subsubsubsection{Berechnung}
|
||||
\subsubsection{Berechnung}
|
||||
|
||||
Das Verfahren zur Ermittlung der CER gleicht im Wesentlichen dem der WER, bezieht sich allerdings auf die einzelnen Zeichen eines Wortes. Die mathematische Formel lautet wie folgt \mcite{karpinski2018metrics}:
|
||||
|
||||
Das Verfahren zur Ermittlung der CER gleicht im Wesentlichen dem der WER. Die mathematische Formel lautet somit wie folgt:
|
||||
\begin{center}
|
||||
\[
|
||||
\text{CER} = \frac{S + D + I}{N}
|
||||
@@ -55,8 +57,8 @@ wobei die einzelnen Komponenten folgende Größen darstellen:
|
||||
\item \(N\) beschreibt die Gesamtanzahl der Zeichen in der Referenz
|
||||
\end{itemize}
|
||||
|
||||
\subsubsubsection{Vorteile und Nachteile}
|
||||
\subsubsection{Vorteile und Nachteile}
|
||||
|
||||
Die CER fasst in einem Wert zusammen, wie viele Änderungen auf Zeichenebene notwendig sind, um aus dem erkannten Wort das Referenzwort zu bilden. Es ist dabei wie bei der WER nicht relevant, in welcher Reihenfolge diese Zeichen auftreten. Ebenso gibt es keine gesonderte Gewichtung für Ersetzungen, Löschungen oder Einfügungen, wodurch besonders bei kurzen Wörtern auch kleinere Abweichungen bereits zu einer hohen CER führen können.
|
||||
|
||||
Durch den detaillierten Vergleich der einzelnen Wörter auf Zeichenebene stellt die CER jedenfalls ein ausreichend gutes Komplement zur WER dar, um in den folgenden Vergleichen genutzt werden zu können.
|
||||
Durch den detaillierten Vergleich der einzelnen Wörter auf Zeichenebene stellt die CER ein ausreichend gutes Komplement zur WER dar und wird in den folgenden Vergleichen ebenfalls verwendet werden.
|
||||
@@ -0,0 +1,33 @@
|
||||
\section{Nachbearbeitung}
|
||||
\label{grundlagen_postprocessing}
|
||||
|
||||
Auch die Nachbearbeitung der erkannten Textdaten spielt eine wesentliche Rolle. Hier werden Konzepte aus dem Themengebiet des Natural Language Processings angewandt, welches sich mit der Interaktion zwischen menschlicher Sprache und Computern beschäftigt. Durch die Kombination von Techniken aus der Informatik, Linguistik und dem maschinellen Lernen werden beispielsweise Textanalyse, Übersetzungen, Spracherkennung oder Dialogsysteme möglich \mcite{chowdhary2020natural}. Durch die große Aufmerksamkeit und die vielseitige Nutzung der Technologien sowie dem Aufkommen von neuronalen Netzwerken wurden in diesem Forschungsgebiet immer wieder Fortschritte erzielt \mcite{kalyanathaya2019advances, church1995}
|
||||
|
||||
Dadurch gibt es zahlreiche wissenschaftliche Ressourcen, welche als Grundlage für die Vorgehensweise zur Interpretation und Extraktion relevanter Schlagworte aus den erkannten Freitextdaten dienen.
|
||||
|
||||
\subsection{Schlagworte}
|
||||
\label{grundlagen_schlagworte}
|
||||
|
||||
Für die spätere Suche von Screenshots sollen relevante Schlagworte aus den erkannten Textdaten extrahiert werden. Ein Wort eignet sich dann als Schlagwort, wenn es in relevantem Bezug zum jeweiligen Bild steht und dabei eine wichtige Aktion oder Information widerspiegelt. Inhalte, die direkt in der grafischen Benutzeroberfläche ersichtlich sind, haben daher einen hohen Informationsgehalt und eignen sich besonders gut als Suchworte. Um die Schlagwortmenge so aussagekräftig wie möglich zu halten, müssen Wörter mit geringer Bedeutung entfernt werden. Beispielsweise haben sogenannte Stoppwörter (\engl{Stop words}) wie \textit{und} oder \textit{oder} keine besondere Semantik und fördern aufgrund ihrer Häufigkeit das Auftreten von Verwechslungen \mcite{wilbur1992automatic}.
|
||||
|
||||
\subsection{Mehrsprachigkeit}
|
||||
\label{grundlagen_mehrsprachigkeit}
|
||||
|
||||
Das Textverarbeitungssystem muss in der Lage sein, mehrsprachige Bilddateien einlesen und interpretieren zu können. So sollen beispielsweise Bilder mit englischen, deutschen oder italienischen Inhalten zugeführt und die Ergebnisdaten richtig verarbeitet werden können. Um eine Filterung für verschiedene Zeichensätze zu ermöglichen und eine Unterstützung für Sprachen mit nicht-lateinischen Schriften zu gewährleisten, werden dynamische Sprachfilter verwendet, die individuell an die jeweilige Sprache angepasst werden können. Für die weitere Beschreibung der generellen Vorgehensweise und Tests wird sich in den folgenden Schritten jedoch auf deutsche und englische Inhalte beschränkt.
|
||||
|
||||
\subsubsection{Filtern von Symbolen}
|
||||
|
||||
Bei der Texterkennung kann es vorkommen, dass grafische Elemente als diverse Unicode-Symbole erkannt werden. Wie in \autoref{fig:screenshot_postprocessing} versuchen Texterkennungssysteme oftmals, grafische Dekorationselemente textuell nachzubilden. Auch finden sich in den ungefilterten Ergebnisdaten Aufzählungszeichen wie "•" oder unterschiedliche Varianten von Bindestrichen "‒". Diese Zeichen sind gemäß Anwendungsanforderungen nicht relevant für die Schlagwortsuche und können somit entfernt \bzw ignoriert werden.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\begin{minipage}{0.45\textwidth}
|
||||
\includegraphics[width=0.90\textwidth]{include/postprocessing/source.png}
|
||||
\end{minipage}
|
||||
\hfill
|
||||
\begin{minipage}{0.5\textwidth}
|
||||
\lstinputlisting[firstnumber=100,linerange={100-110}]{include/postprocessing/source.json}
|
||||
\end{minipage}
|
||||
\caption{Auszug aus den ungefilterten Ergebnisdaten bei Durchführung der Texterkennung in dem gezeigten Screenshot.}
|
||||
\label{fig:screenshot_postprocessing}
|
||||
\end{figure}
|
||||
@@ -0,0 +1,23 @@
|
||||
\section{Vorverarbeitung}
|
||||
\label{grundlagen_preprocessing}
|
||||
|
||||
Im Folgenden wird beschrieben, wie die zu verarbeitenden Bilddaten für optimale OCR-Ergebnisse vorzubereiten sind.
|
||||
|
||||
\subsection{Eigenschaften von Screenshots}
|
||||
\label{grundlagen_bild_eigenschaften}
|
||||
|
||||
Die zu verarbeitenden Bilder im Kontext dieser Bachelorarbeit sind ausschließlich digitale Bildschirmaufnahmen von grafischen Benutzeroberflächen. Es kann daher angenommen werden, dass die Screenshots keine Transparenz aufweisen, die Perspektive der Aufnahme nicht verzerrt ist und im Normalfall nicht mit Bildrauschen zu rechnen ist, weshalb Rauschfilterung \mcite{kumar2017noise} nicht notwendig ist. Auch wird angenommen, dass der Kontrast in den meisten Fällen ausreicht, die relevanten Inhalte zu erkennen. Weiters ist bei der Bildverarbeitung auf farbige Hintergrundflächen zu achten, mit deren Unterstützung Bildschirmelemente oft markiert, gruppiert oder getrennt werden. Nach Sichtung des zu verarbeitenden Bilddatensatzes fällt auf, dass manche Screenshots durch das Selektieren mit der Maus sehr eng abgeschnitten wurden. Das ist bei der Datenverarbeitung ebenfalls zu berücksichtigen. Eine beispielhafte Auswahl typischer Screenshots findet sich in \autoref{bild_eigenschaften_beispiel}.
|
||||
|
||||
\subsection{Optimieren von Daten für Tesseract}
|
||||
\label{bild_optimal}
|
||||
|
||||
Für die Verwendung von Tesseract ist es wichtig, unabhängig von der Diversität der Ausgangsdaten möglichst einheitliche Bilder zu erzeugen \mcite{tessdoc}. Während störende Elemente wie Bildrauschen aus dem Bild entfernt werden, sollen Texte ohne Einfluss der eigentlichen Hinter- bzw. Vordergrundfarbe gut zu erkennen sein. Auch eine deutliche Abgrenzung von Formen oder grafischen Symbolen ist von großer Wichtigkeit \mcite{sporici2020improving} \mcite{mursari2021effectiveness}. Wie in \autoref{fig:screenshot_comparison_optimal} gezeigt, sollen farbige Hintergrundflächen und grafische Dekorationselemente verschwinden, während nur der gut lesbare textuelle Inhalt des Bildes übrig bleiben soll.
|
||||
|
||||
\begin{figure}[hb]
|
||||
\centering
|
||||
\fbox{\includegraphics[width=0.45\textwidth]{include/screenshots/command-processing_screentypes_controlgroup_005.png}}
|
||||
\hfill
|
||||
\fbox{\includegraphics[width=0.45\textwidth]{\detokenize{include/results/ThresholdProcessor(40\%).00.command-processing_screentypes_controlgroup_005.png}}}
|
||||
\caption{Ein optimales Ergebnisbild. Jegliche farblichen Flächen wurden durch die Bildverarbeitung entfernt. Übrig bleibt klar lesbarer Text mit einem hohen Kontrast zum Hintergrund.}
|
||||
\label{fig:screenshot_comparison_optimal}
|
||||
\end{figure}
|
||||
@@ -1,14 +0,0 @@
|
||||
\section{Stand der Technik}
|
||||
\label{technik}
|
||||
|
||||
\subsection{Texterkennungssysteme}
|
||||
|
||||
Optische Texterkennung wird in der Informationstechnik eingesetzt, um Textinhalte aus gedruckten oder digital rasterisierten Medien zu extrahieren. Dieses Verfahren kann für diverse Anwendungsgebiete genutzt werden, wie beispielsweise für Handschrifterkennung oder für das Ablesen von Nummernschildern eines Autos \mcite{asif2014overview}. Auf dem Markt gibt es dafür bereits viele kommerzielle Komplettlösungen wie "IronOCR", "Google Cloud Vision", "Amazon Textract" oder "Microsoft Azure Computer Vision", die oftmals gute Ergebnisse mit geringen Fehlerraten erzielen und sich in bestehende Prozesse oder Anwendungen integrieren lassen \mcite{the_old_bailey_and_ocr, cc_platforms_comparison}.
|
||||
|
||||
Heutige Texterkennungssysteme arbeiten oft mit einer Kombination aus neuralen Netzwerken und fortgeschrittenen Bildverarbeitungsalgorithmen, um Texte zu erkennen. Während es zahlreiche wissenschaftliche Werke zur grundlegenden Funktionsweise von optischen Texterkennungswerkzeugen gibt (beispielsweise \fluentcite{eikvil1993optical} oder \fluentcite{islam2017survey}), werden die genauen Schritte zur richtigen Vorbereitung der Bilddaten -- besonders in Bezug auf Screenshots -- oftmals nur oberflächlich behandelt.
|
||||
|
||||
\subsection{Filterung der Ergebnisdaten}
|
||||
|
||||
Das Themengebiet des Natural Language Processing beschäftigt sich mit der Interaktion zwischen menschlicher Sprache und Computern. Techniken aus der Informatik, Linguistik und dem maschinellen Lernen werden kombiniert, um mit menschlicher Sprache umzugehen und beispielsweise Textanalyse, Übersetzungen, Spracherkennung oder Dialogsysteme möglich zu machen \mcite{chowdhary2020natural}. Durch die große Aufmerksamkeit und die vielseitige Nutzung der Technologien -- von automatischer Rechtschreibkontrolle bis hin zu digitalen Sprachassistenten -- sowie dem Aufkommen von neuronalen Netzwerken wurden in diesem Forschungsgebiet in den letzten Jahren immer wieder Fortschritte erzielt \mcite{kalyanathaya2019advances, 10.1145/219717.219778}.
|
||||
|
||||
Dadurch gibt es zahlreiche wissenschaftliche Ressourcen, die als Grundlage für die Vorgehensweise zur Interpretation und Extraktion relevanter Schlagworte aus den erkannten Freitextdaten dienen.
|
||||
@@ -1,12 +0,0 @@
|
||||
\section{Verwendete Technologien}
|
||||
\label{technologien}
|
||||
|
||||
\subsection{Texterkennungssystem}
|
||||
\label{texterkennungssystem}
|
||||
|
||||
Die Nutzung der in \autoref{einleitung} erwähnten Anwendungen \bzw Dienstleistungen ist kostenpflichtig und die genaue innere Vorgehensweise dieser Programme ist nicht öffentlich bekannt \mcite{textract_pricing, gcv_pricing, azurevision_pricing}. Aufgrund dieser Tatsachen ist die Wahl des Texterkennungssystems für die prototypische Implementierung dieser Bachelorarbeit auf die seit 2005 unter der Freie-Software-Lizenz "Apache 2.0" veröffentlichten "Tesseract Open Source OCR Engine" (kurz: Tesseract) gefallen \mcite{Smith2007}. Diese basiert seit der Major-Version 4 auf einem neuronalen Netz, durch welches mithilfe von sprachspezifischen Trainingsdaten Texte in Bildern erkannt werden können \mcite{tessdoc}.
|
||||
|
||||
\subsection{Bildbearbeitungswerkzeug}
|
||||
\label{bildbearbeitungswerkzeug}
|
||||
|
||||
Als Werkzeug für die Durchführung der notwendigen Bildbearbeitungsschritte wurde die Softwarebibliothek "ImageMagick" \mcite{imagemagick} gewählt. Sie ist umfassend dokumentiert, flexibel und kann Dank der Unterstützung für eine Vielzahl von Programmiersprachen direkt in Programme eingebunden werden. Viele in der Bildverarbeitung genutzte Operationen sind bereits implementiert, was schnelles Prototyping vereinfacht und die Bibliothek zu einer idealen Wahl für die Realisierung von Bildbearbeitungsschritten in der prototypischen Implementierung macht.
|
||||
@@ -0,0 +1,9 @@
|
||||
\section{Überblick Texterkennungssysteme}
|
||||
\label{grundlagen_texterkennungssysteme}
|
||||
|
||||
Optische Texterkennung wird in der Informationstechnik eingesetzt, um Textinhalte aus gedruckten oder digital rasterisierten Medien zu extrahieren. Dieses Verfahren kann für diverse Anwendungsgebiete genutzt werden, wie beispielsweise für Handschrifterkennung \mcite{rakshit2010recognition} oder für das Ablesen von Nummernschildern eines Autos \mcite{asif2014overview, anyline_home}. Auf dem Markt gibt es dafür kommerzielle Komplettlösungen wie "Anyline" \mcite{anyline_home}, "IronOCR" \mcite{ironocr_home}, "Google Cloud Vision" \mcite{gcv_home}, "Amazon Textract" \mcite{textract_home} oder "Microsoft Azure Computer Vision" \mcite{azurevision_home}, die oftmals gute Ergebnisse mit geringen Fehlerraten erzielen und sich in bestehende Prozesse oder Anwendungen integrieren lassen \mcite{the_old_bailey_and_ocr, cc_platforms_comparison}.
|
||||
|
||||
Ein Beispiel für Open-Source-Software zur Texterkennung ist die "Tesseract Open Source OCR Engine" (kurz: Tesseract). Das zugehörige Repository hat verfügt neben über 56000 Sternen auf GitHub auch über eine aktive Community, die das Projekt ständig weiterentwickelt \mcite{tessrepo}. Tesseract ist seit 2005 unter der Freie-Software-Lizenz "Apache 2.0" lizenziert \mcite{Smith2007} und basiert seit der Major-Version 4 auf einem neuronalen Netz, durch welches mithilfe von sprachspezifischen Trainingsdaten Texte in Bildern erkannt werden können \mcite{tessdoc}.
|
||||
|
||||
Aktuelle Texterkennungssysteme arbeiten oft mit einer Kombination aus neuralen Netzwerken und fortgeschrittenen Bildverarbeitungsalgorithmen, um Texte zu erkennen. Zahlreiche wissenschaftliche Werke wie beispielsweise \mcite{eikvil1993optical} oder \mcite{islam2017survey} erklären die grundlegende Funktionsweise von optischen Texterkennungswerkzeugen. Die genauen Schritte zur richtigen Vorbereitung der Bilddaten -- besonders in Bezug auf Screenshots -- werden jedoch oftmals nur oberflächlich behandelt.
|
||||
|
||||
@@ -1,5 +1,3 @@
|
||||
\section{Verwendete Algorithmen}
|
||||
\label{algorithmen}
|
||||
|
||||
\input{chapters/c30_konzept/algorithmen/preprocessing}
|
||||
\pagebreak
|
||||
\input{chapters/c30_konzept/algorithmen/postprocessing}
|
||||
@@ -1,66 +1,65 @@
|
||||
\pagebreak
|
||||
\subsection{Postprocessing}
|
||||
\section{Algorithmen zur Nachbearbeitung}
|
||||
\label{algorithmen_postprocessing}
|
||||
|
||||
Die extrahierten Textdaten aus den verarbeiteten Bilddaten werden später in einer schlagwortbasierten Suchfunktion verwendet. Um Redundanz innerhalb des Datensets zu reduzieren und falsch erkannte Ergebnisdaten zu verhindern, müssen die Ergebnisdaten der Texterkennung im Rahmen des Postprocessings weiterverarbeitet werden.
|
||||
Die extrahierten Textdaten aus den verarbeiteten Bilddaten werden in einer schlagwortbasierten Suchfunktion verwendet. Um Redundanz innerhalb des Datensets zu reduzieren und falsch erkannte Ergebnisdaten zu verhindern, müssen die Ergebnisdaten der Texterkennung im Rahmen der Nachbearbeitung (\engl{Postprocessing}) gemäß \autoref{grundlagen_postprocessing} weiterverarbeitet werden.
|
||||
|
||||
\subsubsection{Filterung anhand der Genauigkeit}
|
||||
\subsection{Filterung anhand der Genauigkeit}
|
||||
\label{algorithmen_confidence}
|
||||
|
||||
Tesseract stellt im Rahmen der Texterkennung neben den erkannten Texten auch die jeweiligen Metadaten zur Verfügung. Auch die geschätzte Genauigkeit (\engl{Confidence}) wird für jedes erkannte Wort mit angegeben. Sie bestimmt, mit welcher Sicherheit ein Texterkennungssystem das jeweilige Wort erkannt hat, wobei Wörter mit hoher Confidence eher richtig, mit niedriger Confidence eher falsch erkannt wurden.
|
||||
Tesseract stellt im Rahmen der Texterkennung neben den erkannten Texten die jeweiligen Metadaten zur Verfügung. Auch die geschätzte Genauigkeit (\engl{Confidence}) wird für jedes erkannte Wort mit angegeben. Sie bestimmt, mit welcher Sicherheit ein Texterkennungssystem das jeweilige Wort erkannt hat, wobei Wörter mit hoher Confidence eher richtig, mit niedriger Confidence eher falsch erkannt wurden.
|
||||
|
||||
Wie in \autoref{fig:screenshot_postprocessing_confidence} gezeigt, prüft der Confidence-Filter die jeweiligen Wörter auf ihre Metadaten und verwirft jene, deren Confidence unter einem fixen Schwellenwert liegt. Je nach Einstellung \bzw "Härte" des Filters wird die Anzahl der falsch erkannten Inhalte innerhalb der Schlagwortmenge drastisch reduziert. Ist der Filter zu streng eingestellt, werden jedoch insgesamt weniger Worte in die Ergebnisse mit aufgenommen und es kann vorkommen, dass auch ursprünglich korrekt erkannte Wörter aufgrund eines niedrigen Confidence-Wertes verworfen werden.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\begin{minipage}{0.49\textwidth}
|
||||
\lstinputlisting[firstnumber=2,linerange={2-14}]{include/postprocessing/source.detailed.json}
|
||||
\lstinputlisting[firstnumber=82,linerange={82-93}]{include/postprocessing/source.detailed.json}
|
||||
\end{minipage}
|
||||
\hfill
|
||||
\begin{minipage}{0.49\textwidth}
|
||||
\lstinputlisting[firstnumber=2,linerange={2-14}]{include/postprocessing/confidence.detailed.json}
|
||||
\lstinputlisting[firstnumber=58,linerange={58-69}]{include/postprocessing/confidence.detailed.json}
|
||||
\end{minipage}
|
||||
\caption{Auszug aus den Ergebnisdaten der Texterkennung aus \ref{fig:screenshot_postprocessing} nach der Confidence-Filterung. Alle Wörter unter dem Schwellenwert werden entfernt.}
|
||||
\label{fig:screenshot_postprocessing_confidence}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Normalisierung}
|
||||
\subsection{Normalisierung}
|
||||
\label{algorithmen_normalisierung}
|
||||
|
||||
Um die aus der Texterkennung gewonnenen Daten zunächst für die weitere Filterung vorzubereiten, ist es sinnvoll, die Redundanz der Daten möglichst zu reduzieren und die einzelnen Wörter zu normalisieren \bzw zu standardisieren. Beispielsweise kann durch das Umwandeln aller Textdaten in Kleinbuchstaben die Variation der Daten eingeschränkt werden, ohne jedoch für die Suche relevante Information zu verlieren. Diese Methode wurd auch in \autoref{fig:screenshot_postprocessing_normalisierung} angewandt.
|
||||
Um die aus der Texterkennung gewonnenen Daten zunächst für die weitere Filterung vorzubereiten, ist es sinnvoll, die Redundanz der Daten möglichst zu reduzieren und die einzelnen Wörter zu normalisieren. Beispielsweise kann durch das Umwandeln aller Textdaten in Kleinbuchstaben die Variation der Daten eingeschränkt werden, ohne jedoch für die Suche relevante Information zu verlieren. Diese Methode wurd auch in \autoref{fig:screenshot_postprocessing_normalisierung} angewandt.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\begin{minipage}{0.49\textwidth}
|
||||
\lstinputlisting[firstnumber=2,linerange={2-14}]{include/postprocessing/confidence.json}
|
||||
\lstinputlisting[firstnumber=14,linerange={14-19}]{include/postprocessing/confidence.json}
|
||||
\end{minipage}
|
||||
\hfill
|
||||
\begin{minipage}{0.49\textwidth}
|
||||
\lstinputlisting[firstnumber=2,linerange={2-14}]{include/postprocessing/normalize.json}
|
||||
\lstinputlisting[firstnumber=14,linerange={14-19}]{include/postprocessing/normalize.json}
|
||||
\end{minipage}
|
||||
\caption{Auszug aus den Ergebnisdaten der Texterkennung aus \ref{fig:screenshot_postprocessing} nach der Normalisierung. Alle Wörter beinhalten nun ausschließlich Kleinbuchstaben.}
|
||||
\label{fig:screenshot_postprocessing_normalisierung}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Vermeidung von Duplikaten}
|
||||
\subsection{Entfernung von Duplikaten}
|
||||
\label{algorithmen_duplikate}
|
||||
|
||||
Nach der Normalisierung werden Duplikate innerhalb der erkannten Textdaten entfernt, um die Effizienz der nachfolgenden Filterverfahren zu erhöhen. In den Daten aus \autoref{fig:screenshot_postprocessing_duplikate} wird die Liste an erkannten Wörtern stark gekürzt und die Redundanz damit verringert. Es treten keine Duplikate mehr auf.
|
||||
Nach der Normalisierung werden Duplikate innerhalb der erkannten Textdaten entfernt, um die Effizienz der nachfolgenden Filterverfahren zu erhöhen. In den Daten aus \autoref{fig:screenshot_postprocessing_duplikate} wird die Liste an erkannten Wörtern stark gekürzt und die Redundanz damit verringert.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\begin{minipage}{0.49\textwidth}
|
||||
\lstinputlisting[firstnumber=33,linerange={33-41}]{include/postprocessing/normalize.json}
|
||||
\lstinputlisting[firstnumber=33,linerange={33-40}]{include/postprocessing/normalize.json}
|
||||
\end{minipage}
|
||||
\hfill
|
||||
\begin{minipage}{0.49\textwidth}
|
||||
\lstinputlisting[firstnumber=14,linerange={14-22}]{include/postprocessing/duplicates.json}
|
||||
\lstinputlisting[firstnumber=14,linerange={14-18}]{include/postprocessing/duplicates.json}
|
||||
\end{minipage}
|
||||
\caption{Auszug aus den Ergebnisdaten der Texterkennung aus \ref{fig:screenshot_postprocessing} nach der Duplikatentfernung.}
|
||||
\label{fig:screenshot_postprocessing_duplikate}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Filterung anhand der Wortlänge}
|
||||
\subsection{Filterung anhand der Wortlänge}
|
||||
\label{algorithmen_wortlänge}
|
||||
|
||||
Verarbeitet das Texterkennungssystem Texte mit unregelmäßigen Abständen oder grafischen Artefakten in der Schrift, werden statt des eigentlichen Wortes fälschlicherweise oft kurze Symbolkombinationen erkannt. Um diese Kombinationen aus den Ergebnisdaten zu entfernen, können Zeichenketten, wie in \autoref{fig:screenshot_postprocessing_wortlänge} gezeigt, mithilfe des Wortlängenfilters ungeachtet ihres Inhaltes verworfen werden.
|
||||
@@ -70,29 +69,29 @@ Zusätzlich kann dieser Filter an die Anforderung des Zielsystems angepasst werd
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\begin{minipage}{0.49\textwidth}
|
||||
\lstinputlisting[firstnumber=14,linerange={14-22}]{include/postprocessing/duplicates.json}
|
||||
\lstinputlisting[firstnumber=16,linerange={16-20}]{include/postprocessing/duplicates.json}
|
||||
\end{minipage}
|
||||
\hfill
|
||||
\begin{minipage}{0.49\textwidth}
|
||||
\lstinputlisting[firstnumber=11,linerange={11-19}]{include/postprocessing/wordlength.json}
|
||||
\lstinputlisting[firstnumber=15,linerange={15-18}]{include/postprocessing/wordlength.json}
|
||||
\end{minipage}
|
||||
\caption{Auszug aus den Ergebnisdaten der Texterkennung aus \ref{fig:screenshot_postprocessing} nach der Wortlängenfilterung. Alle Wörter, die kürzer sind als der Schwellenwert, werden aus den Ergebnisdaten entfernt.}
|
||||
\label{fig:screenshot_postprocessing_wortlänge}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Sprachabhängige Filterung mittels Regular Expressions}
|
||||
\subsection{Sprachabhängige Filterung mittels Regular Expressions}
|
||||
\label{algorithmen_regex}
|
||||
|
||||
Nachdem die zu filternden Textdaten durch vorherige Schritte vorverarbeitet wurden, werden die Ergebnisdaten ein letztes Mal mithilfe von regulären Ausdrücken (\engl{Regular Expressions}) durchsucht. Aufgrund der dynamischen Erweiterbarkeit der Regular Expressions kann für jede Sprache ein individueller Filter angelegt werden, der den jeweiligen Zeichensatz beschriftet und unbekannte Sonderzeichen oder Symbole entfernt. So sind beispielsweise im Deutschen Umlaute erlaubt, während häufig auftretende, jedoch unerwünschte Symbole wie das phonetische Zeichen "æ" oder mehrere hintereinandergereihte Leerzeichen explizit entfernt werden können. Die Anwendung des deutschen Sprachfilters wird in \autoref{fig:screenshot_postprocessing_regex} gezeigt.
|
||||
Nachdem die zu filternden Textdaten durch vorherige Schritte vorverarbeitet wurden, werden die Ergebnisdaten ein letztes Mal mithilfe von regulären Ausdrücken (\engl{Regular Expressions}) durchsucht. Aufgrund der dynamischen Erweiterbarkeit der Regular Expressions kann für jede Sprache ein individueller Filter angelegt werden, der den jeweiligen Zeichensatz beschriftet und unbekannte Sonderzeichen oder Symbole entfernt. So sind beispielsweise im Deutschen Umlaute erlaubt, während häufig auftretende, jedoch unerwünschte Symbole wie das phonetische Zeichen "æ" oder mehrere hintereinandergereihte Leerzeichen explizit entfernt werden können. Die Anwendung eines simplen deutschen Sprachfilters (\lstinline|[\w'\-äöüÄÖÜß]{2,}|) wird in \autoref{fig:screenshot_postprocessing_regex} gezeigt.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\begin{minipage}{0.49\textwidth}
|
||||
\lstinputlisting[firstnumber=7,linerange={7-19}]{include/postprocessing/duplicates.json}
|
||||
\lstinputlisting[firstnumber=14,linerange={14-19}]{include/postprocessing/duplicates.json}
|
||||
\end{minipage}
|
||||
\hfill
|
||||
\begin{minipage}{0.49\textwidth}
|
||||
\lstinputlisting[firstnumber=2,linerange={2-14}]{include/postprocessing/regex.json}
|
||||
\lstinputlisting[firstnumber=10,linerange={10-15}]{include/postprocessing/regex.json}
|
||||
\end{minipage}
|
||||
\caption{Auszug aus den Ergebnisdaten der Texterkennung aus \ref{fig:screenshot_postprocessing} nach der Filterung mit Regular Expressions. Findet der sprachabhängige Filter keine Treffer, wird das Wort aus den Ergebnisdaten entfernt.}
|
||||
\label{fig:screenshot_postprocessing_regex}
|
||||
|
||||
@@ -1,13 +1,14 @@
|
||||
\subsection{Preprocessing}
|
||||
|
||||
\section{Algorithmen zur Vorverarbeitung}
|
||||
\label{algorithmen_preprocessing}
|
||||
|
||||
Beim sogenannten "Preprocessing" werden die zu verarbeitenden Bilder für die Texterkennung vorbereitet, um die Qualität der erkannten Textdaten zu verbessern.
|
||||
Wie bereits in \autoref{grundlagen_preprocessing} beschrieben, werden die zu verarbeitenden Bilder bei der Vorverarbeitung (\engl{Preprocessing}) für die Texterkennung vorbereitet, um die Qualität der erkannten Textdaten zu verbessern.
|
||||
|
||||
Verwendet man moderne Tesseract-Implementierungen, sind in diesen oft bereits rudimentäre Bildverarbeitungswerkzeuge verfügbar \mcite{tessdoc}. Mit diesen Werkzeugen werden die eingespeisten Bilder -- sofern nicht bereits im richtigen Format -- automatisch für die Texterkennung vorbereitet. Ohne weitere Einstellungen zu treffen, bewirkt diese Bildverarbeitung zwar ein Umwandeln der Eingangsgrafiken in ein meist gut für Tesseract geeignetes Bild. Es ist jedoch zu beachten, dass die Bildverarbeitungsschritte individuell auf die erwarteten Eingangsdaten anzupassen sind. So können die Bilddaten den in \autoref{annahmen_bild_optimal} definierten optimalen Tesseract-Eingangsdaten angenähert werden.
|
||||
In einigen Tesseract-Implementierungen sind bereits rudimentäre Bildverarbeitungswerkzeuge verfügbar \mcite{tessdoc}. Mit diesen Werkzeugen werden die eingespeisten Bilder -- sofern nicht bereits im richtigen Format vorhanden -- automatisch für die Texterkennung vorbereitet. Ohne weitere Einstellungen zu treffen, bewirkt diese Bildverarbeitung ein Umwandeln der Eingangsgrafiken in ein meist gut für Tesseract geeignetes Bild. Es ist jedoch zu beachten, dass die Bildverarbeitungsschritte individuell auf die erwarteten Eingangsdaten anzupassen sind. So können die Bilddaten den in \autoref{bild_optimal} definierten optimalen Tesseract-Eingangsdaten angenähert werden.
|
||||
|
||||
Die folgenden Preprocessing-Schritte basieren auf der empfohlenen Vorgehensweise zur Verbesserung der Output-Qualität laut Tesseract-Dokumentation \mcite{tessdoc}. Gemäß den obigen Annahmen werden jedoch weder perspektivische Fehler, noch ein eventuelles Rauschen korrigiert. Konkret werden folgende Bildverarbeitungsschritte verglichen:
|
||||
Die folgenden Vorverarbeitungsschritte basieren auf der empfohlenen Vorgehensweise zur Verbesserung der Output-Qualität laut Tesseract-Dokumentation \mcite{tessdoc}. Gemäß den Annahmen in \autoref{grundlagen} werden jedoch weder perspektivische Fehler, noch ein eventuelles Rauschen korrigiert.
|
||||
|
||||
\subsubsection{Resampling}
|
||||
\subsection{Resampling}
|
||||
\label{algorithmen_resampling}
|
||||
|
||||
Bei Resampling wird die Bildauflösung durch Interpolation verändert. Interpolation beschreibt die Methode, fehlende Pixelwerte zwischen bekannten Punkten mittels eines festgelegten Verfahrens zu ergänzen. Abhängig vom gewählten Verfahren ist das Ergebnis meist ein glattes und kontinuierliches Bild. Um die für Tesseract optimale Mindestauflösung von 300 dpi \mcite{tessdoc} zu gewährleisten, muss das Eingangsbild, sofern es die Mindestauflösung unterschreitet, zunächst entsprechend vergrößert werden.
|
||||
@@ -17,30 +18,30 @@ Da Tesseract auf klare und scharfe Kontraste angewiesen ist, um Text korrekt zu
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\subcaptionbox
|
||||
{Original}
|
||||
{\fbox{\includegraphics[width=0.15\textwidth]{include/resampling/source.png}}}
|
||||
{Original}
|
||||
{\fbox{\includegraphics[width=0.15\textwidth]{include/resampling/source.png}}}
|
||||
\hspace{0.005\textwidth}
|
||||
\subcaptionbox
|
||||
{Nearest-Neighbor}
|
||||
{\fbox{\includegraphics[width=0.24\textwidth]{include/resampling/Nearest.png}}}
|
||||
{Nearest-Neighbor}
|
||||
{\fbox{\includegraphics[width=0.24\textwidth]{include/resampling/Nearest.png}}}
|
||||
\hspace{0.005\textwidth}
|
||||
\subcaptionbox
|
||||
{Hermite}
|
||||
{\fbox{\includegraphics[width=0.24\textwidth]{include/resampling/Hermite.png}}}
|
||||
{Hermite}
|
||||
{\fbox{\includegraphics[width=0.24\textwidth]{include/resampling/Hermite.png}}}
|
||||
\hspace{0.005\textwidth}
|
||||
\subcaptionbox
|
||||
{Lanczos}
|
||||
{\fbox{\includegraphics[width=0.24\textwidth]{include/resampling/Lanczos.png}}}
|
||||
{Lanczos}
|
||||
{\fbox{\includegraphics[width=0.24\textwidth]{include/resampling/Lanczos.png}}}
|
||||
\caption{Ein Vergleich unterschiedlicher Resampling-Filter. Durch die Aufteilung der Fehler auf mehrere Pixel bleiben Details und Konturen bei Anwendung des Lanczos-Filters vergleichsweise gut erhalten und der Text ist gut lesbar.}
|
||||
\label{fig:algorithmen_resampling_vergleich}
|
||||
\end{figure}
|
||||
|
||||
Nach einigen Tests fällt auf, dass Bilder, die mittels des Spline-Verfahrens oder der Hermite-Interpolation skaliert wurden, weiche Konturen ohne harte Farbübergänge aufweisen. Tesseract profitiert jedoch stark von klaren Texten und hohen Kontrasten, weswegen diese Art des Resamplings keine ideale Basis für das Preprocessing bietet. Deswegen wird für die weiteren Schritte die Interpolation nach Lanczos für das Resampling verwendet.
|
||||
Nach einigen Tests fällt auf, dass Bilder, die mittels des Spline-Verfahrens \mcite{briand2018theory,unser1999splines} oder der Hermite-Interpolation \mcite{seta2009digital} skaliert wurden, weiche Konturen ohne harte Farbübergänge aufweisen. Tesseract profitiert jedoch stark von klaren Texten und hohen Kontrasten, weswegen diese Art des Resamplings keine ideale Basis für das Preprocessing bietet. Deswegen wird für die weiteren Schritte die Interpolation nach Lanczos \mcite{fadnavis2014image} für das Resampling verwendet.
|
||||
|
||||
\subsubsection{Rahmen}
|
||||
\subsection{Rahmen}
|
||||
\label{algorithmen_rahmen}
|
||||
|
||||
Befindet sich Text zu nah am Rand des Bildes, kommt es vor, dass dieser oft nicht richtig erkannt wird. Ebenso kann auch ein zu großer einfärbiger Rahmen am Rand des Bildes die Texterkennung stören. Bei Rahmengrößen wie in \autoref{fig:rahmen_groß} kommt es vor, dass Bildsektionen fälschlicherweise als "leer" erkannt und übersprungen werden, wodurch der zu erkennende Text nicht in die Ergebnisdaten mit aufgenommen wird.
|
||||
Befindet sich Text zu nah am Rand des Bildes, wird dieser nicht immer richtig erkannt. Ebenso kann auch ein zu großer einfärbiger Rahmen am Rand des Bildes die Texterkennung stören. Bei Rahmengrößen wie in \autoref{fig:rahmen_groß} kommt es vor, dass Bildsektionen fälschlicherweise als "leer" erkannt und übersprungen werden, wodurch der zu erkennende Text nicht in die Ergebnisdaten mit aufgenommen wird.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
@@ -49,17 +50,27 @@ Befindet sich Text zu nah am Rand des Bildes, kommt es vor, dass dieser oft nich
|
||||
\label{fig:rahmen_groß}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Binarisierung}
|
||||
Für die weitere Vorgehensweise ist es sinnvoll, alle Bilder mit einem schmalen Rahmen zu umgeben. So wird sichergestellt, dass sich die Texte nicht zu nah am Bildrand befinden und Fehler in der Texterkennung werden reduziert.
|
||||
|
||||
\subsection{Binarisierung}
|
||||
\label{algorithmen_binarisierung}
|
||||
|
||||
Das Erzeugen eines Binärbildes ist durch Anwendung von Segmentierungsverfahren möglich. Schwellenwertverfahren (\engl{Thresholding}) bilden eine Untergruppe der Segmentierungsverfahren und werden genutzt, um Graustufenbilder Pixel für Pixel in binarisierte Ergebnisbilder mit zwei Segmenten, also einem Vordergrund und einem Hintergrund umzuwandeln. Der dazu notwendige Schwellenwert kann entweder fest definiert oder anhand von verschiedensten Algorithmen automatisch \bzw halbautomatisch ermittelt werden. Ziel ist es, durch die Binarisierung textuelle Bildinhalte unabhängig von der eigentlichen Vorder- und Hintergrundfarbe mit ausreichendem Kontrast darzustellen. Dadurch ist das Texterkennungssystem in der Lage, die einzelnen Textelemente und deren Inhalte besser zu identifizieren und zu verarbeiten. ImageMagick bietet eine Vielzahl an Thresholding-Algorithmen, deren Eignung in \autoref{vergleich} verglichen wird.
|
||||
Das Erzeugen eines Binärbildes ist durch Anwendung von Segmentierungsverfahren möglich. Schwellenwertverfahren (\engl{Thresholding}) bilden eine Untergruppe der Segmentierungsverfahren und werden genutzt, um Graustufenbilder Pixel für Pixel in binarisierte Ergebnisbilder mit zwei Segmenten, also einem Vordergrund und einem Hintergrund umzuwandeln. Der dazu notwendige Schwellenwert kann entweder fest definiert oder anhand von verschiedensten Algorithmen automatisch \bzw halbautomatisch ermittelt werden. Ziel ist es, durch die Binarisierung textuelle Bildinhalte unabhängig von der eigentlichen Vorder- und Hintergrundfarbe mit ausreichendem Kontrast darzustellen. Dadurch ist das Texterkennungssystem in der Lage, die einzelnen Textelemente und deren Inhalte besser zu identifizieren und zu verarbeiten. ImageMagick bietet eine Vielzahl an Schwellenwert-Algorithmen, von denen nachfolgend jene genauer beschrieben werden:
|
||||
|
||||
\subsubsubsection{Feste Schwellenwertmethode}
|
||||
\begin{itemize}
|
||||
\item Feste Schwellenwertmethode
|
||||
\item Adaptive Schwellenwertmethode
|
||||
\item Dreiecks Schwellenwertmethode
|
||||
\item Schwellenwertmethode nach Otsu
|
||||
\item Schwellenwertmethode nach Kapur
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Feste Schwellenwertmethode}
|
||||
\label{thresholding_fixed}
|
||||
|
||||
Ein häufig für die Bildsegmentierung genutztes Verfahren ist die feste Schwellenwertmethode, auf Englisch auch "Fixed Thresholding" genannt. Bei diesem Bildverarbeitungsverfahren wird ein manuell vordefinierter Grenzwert auf das gesamte Bild angewandt. Liegt ein Pixelwert über dem festgelegten Schwellenwert, gilt dieser als Teil des Vordergrunds, andernfalls als Hintergrund \mcite{sahoo1988survey}. Somit können Objekte, also die einzelnen Buchstaben in den Grafikdateien, von ihrem Hintergrund getrennt werden.
|
||||
Ein häufig für die Bildsegmentierung genutztes Verfahren ist die feste Schwellenwertmethode, im Englischen auch "Fixed Thresholding" genannt. Bei diesem Bildverarbeitungsverfahren wird ein manuell vordefinierter Grenzwert auf das gesamte Bild angewandt. Liegt ein Pixelwert über dem festgelegten Schwellenwert, gilt dieser als Teil des Vordergrunds, andernfalls als Hintergrund \mcite{sahoo1988survey}. Somit können Objekte, also die einzelnen Buchstaben in den Grafikdateien, von ihrem Hintergrund getrennt werden.
|
||||
|
||||
Das fixe Thresholding benötigt durch den fest definierten Schwellenwert einen geringen Berechnungsaufwand und weist eine hohe Performance auf. Besonders bei Screenshotdateien kann es vorkommen, dass die eigentlich bunten grafischen Elemente der Benutzeroberfläche aufgrund ihrer Helligkeit über dem Schwellenwert liegen. Dadurch werden sie, genau wie der Text, als Vordergrund wahrgenommen und die gesamte Fläche wird einfärbig. Somit können jegliche Texte innerhalb dieser Fläche nicht vom Texterkennungssystem erkannt werden und die Qualität und Menge der erkannten Daten wird stark reduziert. Der Unterschied der Ergebnisdaten ist besonders im Vergleich von \autoref{thresholding_fixed_vergleich_gut} \bzw \autoref{thresholding_fixed_vergleich_schlecht} ersichtlich.
|
||||
Durch den globalen, fixen Schwellenwert ohne Berücksichtigung von Pixelnachbarschaften weist das fixe Schwellenwertfahren einen geringen Berechnungsaufwand und daher eine hohe Performance auf \mcite{sahoo1988survey}. Besonders bei Screenshotdateien kann es vorkommen, dass die eigentlich bunten grafischen Elemente der Benutzeroberfläche aufgrund ihrer Helligkeit über dem Schwellenwert liegen. Dadurch werden sie, genau wie der Text, als Vordergrund wahrgenommen und die gesamte Fläche wird einfärbig. Somit können jegliche Texte innerhalb dieser Fläche nicht vom Texterkennungssystem erkannt werden und die Qualität und Menge der erkannten Daten wird stark reduziert. Der Unterschied der Ergebnisdaten ist besonders im Vergleich von \autoref{thresholding_fixed_vergleich_gut} und \autoref{thresholding_fixed_vergleich_schlecht} ersichtlich.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
@@ -79,18 +90,18 @@ Das fixe Thresholding benötigt durch den fest definierten Schwellenwert einen g
|
||||
\label{thresholding_fixed_vergleich_schlecht}
|
||||
\end{figure}
|
||||
|
||||
\subsubsubsection{Adaptive Schwellenwertmethode}
|
||||
\subsection{Adaptive Schwellenwertmethode}
|
||||
\label{thresholding_adaptive}
|
||||
|
||||
Die adaptive Schwellenwertmethode gehört zu den halbautomatischen Schwellenwertalgorithmen. Bei diesem Verfahren wird der Schwellenwert auf Basis der lokalen Eigenschaften eines Bildbereichs angepasst, der durch die manuell festgelegte sogenannte "Blockgröße" definiert wird. Diese bestimmt die Seitenlänge des Rechtecks, innerhalb dessen ein fester Schwellenwert ermittelt wird \mcite{sahoo1988survey}. Durch diese dynamische Berechnung können im Gegensatz zur \hyperref[thresholding_fixed]{festen Schwellenwertmethode} verschiedenfarbige Texte auf Hintergründen unterschiedlicher Helligkeit besser abgegrenzt werden und die Menge an erkanntem Text wird erhöht, wie in \autoref{thresholding_adaptive_vergleich_gut} ersichtlich. Wir die Blockgröße falsch gewählt, können jedoch Artefakte auftreten, welche bei entsprechender Menge, wie im Falle von \autoref{thresholding_adaptive_vergleich_schlecht}, die Texterkennung negativ beeinflusst.
|
||||
Die adaptive Schwellenwertmethode gehört zu den halbautomatischen Schwellenwertalgorithmen. Bei diesem Verfahren wird der Schwellenwert auf Basis der lokalen Eigenschaften eines Bildbereichs angepasst, der durch die manuell festgelegte sogenannte "Blockgröße" definiert wird. Diese bestimmt die Seitenlänge des Rechtecks, innerhalb dessen ein fester Schwellenwert ermittelt wird. Durch diese dynamische Berechnung können im Gegensatz zur \hyperref[thresholding_fixed]{festen Schwellenwertmethode} verschiedenfarbige Texte auf Hintergründen unterschiedlicher Helligkeit besser abgegrenzt werden und die Menge an erkanntem Text wird erhöht, wie in \autoref{thresholding_adaptive_vergleich_gut} ersichtlich. Wird die Blockgröße falsch gewählt, können jedoch Artefakte auftreten, welche bei entsprechender Menge, wie im Falle von \autoref{thresholding_adaptive_vergleich_schlecht}, die Texterkennung negativ beeinflussen \mcite{sahoo1988survey}.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\fbox{\includegraphics[width=0.49\textwidth]{include/screenshots/zrs_REPORTS_EfficencyClass_009.png}}
|
||||
\hfill
|
||||
\fbox{\includegraphics[width=0.49\textwidth]{\detokenize{include/results/ThresholdAdaptiveProcessor(20_20).00.zrs_REPORTS_EfficencyClass_009.png}}}
|
||||
|
||||
\caption{Anwendung der adaptiven Schwellenwertmethode auf einen Beispielscreenshot. Die Blockgröße ist gut an den Bildinhalt angepasst und alle Details bleiben erhalten. Dieses Verfahren punktet hier besonders bei den Farbigen "Energy Labels", deren Textinhalte sonst mittels keinem anderen Verfahren komplett erkannt wurden.}
|
||||
|
||||
\caption{Anwendung der adaptiven Schwellenwertmethode auf einen Beispielscreenshot. Die Blockgröße ist gut an den Bildinhalt angepasst und alle Details bleiben erhalten. Dieses Verfahren punktet hier besonders bei den farbigen "Energy Labels", deren Textinhalte sonst mittels keinem anderen Verfahren komplett erkannt wurden.}
|
||||
\label{thresholding_adaptive_vergleich_gut}
|
||||
\end{figure}
|
||||
|
||||
@@ -103,10 +114,17 @@ Die adaptive Schwellenwertmethode gehört zu den halbautomatischen Schwellenwert
|
||||
\label{thresholding_adaptive_vergleich_schlecht}
|
||||
\end{figure}
|
||||
|
||||
\subsubsubsection{Dreiecks-Schwellenwertmethode}
|
||||
\subsection{Dreiecks-Schwellenwertmethode}
|
||||
\label{thresholding_triangle}
|
||||
|
||||
Das Dreiecks-Schwellenwertverfahren verwendet die Häufigkeitsverteilung der Helligkeitswerte eines Bildes, um einen globalen Schwellenwert zu ermitteln \mcite{zack1977automatic}. Werden diese Helligkeitswerte in einem Diagramm dargestellt, spricht man von einem Histogramm. Für das Thresholding wird innerhalb des Histogramms eine Linie vom Höchstwert (\engl{Peak}) zum Minimum gezeichnet und die Normale mit der maximalen Länge ermittelt. Dieses Verfahren erzielt die besten Ergebnisse, wenn die zu extrahierenden Elemente Intensitätswerte aufweisen, die an der Basis des ermittelten Peaks liegen. Für Screenshots von UI-Elementen mit komplexer Struktur und farblich stark variierenden Komponenten ist es eher nicht geeignet.
|
||||
Das Dreiecks-Schwellenwertverfahren verwendet die Häufigkeitsverteilung der Helligkeitswerte eines Bildes, um einen globalen Schwellenwert zu ermitteln \mcite{zack1977automatic}. Werden diese Helligkeitswerte in einem Diagramm dargestellt, spricht man von einem Histogramm, wie in \autoref{unimodal_histogram} zu sehen. Für dieses Schwellenwertverfahren wird innerhalb des Histogramms eine Linie vom Höchstwert (\engl{Peak}) zum Minimum gezeichnet und die Normale mit der maximalen Länge ermittelt. Dieses Verfahren erzielt die besten Ergebnisse, wenn die zu extrahierenden Elemente Intensitätswerte aufweisen, die an der Basis des ermittelten Peaks liegen. Für Screenshots von UI-Elementen mit komplexer Struktur und farblich stark variierenden Komponenten ist es eher nicht geeignet.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\fbox{\includegraphics[width=0.49\textwidth]{include/images_external/unimodal-histogram.png}}
|
||||
\caption{Beispiel eines unimodalen Histogramms mit einem deutlichen Spitzenwert \mcite{unimodal-histogram}}
|
||||
\label{unimodal_histogram}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
@@ -126,10 +144,10 @@ Das Dreiecks-Schwellenwertverfahren verwendet die Häufigkeitsverteilung der Hel
|
||||
\label{thresholding_triangle_vergleich_schlecht}
|
||||
\end{figure}
|
||||
|
||||
\subsubsubsection{Schwellenwertmethode nach Otsu}
|
||||
\subsection{Schwellenwertmethode nach Otsu}
|
||||
\label{thresholding_otsu}
|
||||
|
||||
Das Schwellenwertverfahren nach Otsu ermittelt einen globalen Schwellenwert durch Einteilung des Bildes in zwei Klassen (Vordergrund und Hintergrund). Dazu wird für jede Position des Schwellenwerts im Histogramm die Varianz der beiden dadurch entstehenden Klassen ermittelt. Der Schwellenwert ist dann optimal, wenn die Varianz der jeweiligen KLassen minimal ist \mcite{otsu1979threshold}. Aufgrund dieser Eigenschaften funktioniert das Verfahren am besten, wenn das Histogramm des Bildes wie in \autoref{bimodal_histogram} eine bimodale Verteilung aufweist, also zwei klare Spitzen hat.
|
||||
Das Schwellenwertverfahren nach Otsu ermittelt einen globalen Schwellenwert durch Einteilung des Bildes in zwei Klassen (Vordergrund und Hintergrund). Dazu wird für jede Position des Schwellenwerts im Histogramm die Varianz der beiden dadurch entstehenden Klassen ermittelt. Der Schwellenwert ist dann optimal, wenn die Varianz der jeweiligen Klassen minimal ist \mcite{otsu1979threshold}. Aufgrund dieser Eigenschaften funktioniert das Verfahren am besten, wenn das Histogramm des Bildes wie in \autoref{bimodal_histogram} eine bimodale Verteilung aufweist, also zwei klare Spitzen hat.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
@@ -138,14 +156,14 @@ Das Schwellenwertverfahren nach Otsu ermittelt einen globalen Schwellenwert durc
|
||||
\label{bimodal_histogram}
|
||||
\end{figure}
|
||||
|
||||
Enthält ein Bild jedoch starkes Hintergrundrauschen, oder weist es lokale Helligkeitsunterschiede auf, wie es bei grafischen Oberflächen mit ihren unterschiedlich eingefärbten Oberflächensektionen oft der Fall ist, wird ein Schwellenwert ermittelt, der nicht immer für alle Inhalte des Bildes optimal ist. Dank der Bestimmung eines einzelnen globalen Wertes für das gesamte Bild entstehen ähnliche Probleme wie bei der \hyperref[thresholding_fixed]{fixen Schwellenwertmethode} und die Texterkennung liefert Ergebnisse mit geringem Informationsgehalt. Die Unterschiede zwischen den Ergebnissen für gut geeignete Bilder im Vergleich zu Bildern mit großen lokalen Unterschieden sind in \autoref{thresholding_otsu_vergleich_gut} \bzw \autoref{thresholding_otsu_vergleich_schlecht} ersichtlich.
|
||||
Enthält ein Bild jedoch starkes Hintergrundrauschen oder weist es lokale Helligkeitsunterschiede auf, wie es bei grafischen Oberflächen mit ihren unterschiedlich eingefärbten Oberflächensektionen oft der Fall ist, wird ein Schwellenwert ermittelt, der nicht immer für alle Inhalte des Bildes optimal ist. Dank der Bestimmung eines einzelnen globalen Wertes für das gesamte Bild entstehen ähnliche Probleme wie bei der \hyperref[thresholding_fixed]{fixen Schwellenwertmethode}. Die Texterkennung liefert Ergebnisse mit geringem Informationsgehalt. Die Unterschiede zwischen den Ergebnissen für gut geeignete Bilder im Vergleich zu Bildern mit großen lokalen Unterschieden sind in \autoref{thresholding_otsu_vergleich_gut} \bzw \autoref{thresholding_otsu_vergleich_schlecht} ersichtlich.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\fbox{\includegraphics[width=0.49\textwidth]{include/screenshots/runtime_function_create_002.png}}
|
||||
\hfill
|
||||
\fbox{\includegraphics[width=0.49\textwidth]{\detokenize{include/results/AutoThresholdProcessor(OTSU).00.runtime_function_create_002.png}}}
|
||||
\caption{Anwendung der Schwellenwertmethode nach Otsu auf einen Beispielscreenshot. Wird ein passender Schwellenwert ermittelt, lässt sich der Text gut vom Hintergrund trennen.}
|
||||
\caption{Anwendung der Schwellenwertmethode nach Otsu \mcite{otsu1979threshold} auf einen Beispielscreenshot. Wird ein passender Schwellenwert ermittelt, lässt sich der Text gut vom Hintergrund trennen.}
|
||||
\label{thresholding_otsu_vergleich_gut}
|
||||
\end{figure}
|
||||
|
||||
@@ -154,14 +172,14 @@ Enthält ein Bild jedoch starkes Hintergrundrauschen, oder weist es lokale Helli
|
||||
\fbox{\includegraphics[width=0.49\textwidth]{include/screenshots/editor_windows_position_006.png}}
|
||||
\hfill
|
||||
\fbox{\includegraphics[width=0.49\textwidth]{\detokenize{include/results/AutoThresholdProcessor(OTSU).00.editor_windows_position_006.png}}}
|
||||
\caption{Anwendung der Schwellenwertmethode nach Otsu auf einen Beispielscreenshot. Bei komplexen Strukturen im User-Interface gehen aufgrund des globalen Schwellenwerts Details verloren.}
|
||||
\caption{Anwendung der Schwellenwertmethode nach Otsu \mcite{otsu1979threshold} auf einen Beispielscreenshot. Bei komplexen Strukturen im User-Interface gehen aufgrund des globalen Schwellenwerts Details verloren.}
|
||||
\label{thresholding_otsu_vergleich_schlecht}
|
||||
\end{figure}
|
||||
|
||||
\subsubsubsection{Schwellenwertmethode nach Kapur}
|
||||
\subsection{Schwellenwertmethode nach Kapur}
|
||||
\label{thresholding_kapur}
|
||||
|
||||
Die Schwellenwertmethode nach Kapur, Sahoo und Wong zielt darauf ab, einen Schwellenwert zu finden, der die Entropie zwischen den Vorder- und Hintergrundregionen maximiert \mcite{kapur1985new}. Wie in \autoref{thresholding_kapur_vergleich_gut} und \autoref{thresholding_kapur_vergleich_schlecht} zu sehen, liefert die Verwendung dieses Schwellenwertverfahrens gute Ergebnisse bei Bildern mit starker Varianz der Vorder- und Hintergrundkontraste \bzw einer breiten Helligkeitsverteilung.
|
||||
Die Schwellenwertmethode nach Kapur \mcite{kapur1985new} zielt darauf ab, einen Schwellenwert zu finden, der die Entropie zwischen den Vorder- und Hintergrundregionen maximiert. Wie in \autoref{thresholding_kapur_vergleich_gut} und \autoref{thresholding_kapur_vergleich_schlecht} zu sehen, liefert die Verwendung dieses Schwellenwertverfahrens gute Ergebnisse bei Bildern mit starker Varianz der Vorder- und Hintergrundkontraste \bzw einer breiten Helligkeitsverteilung.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
|
||||
@@ -1,75 +0,0 @@
|
||||
\section{Annahmen}
|
||||
\label{annahmen}
|
||||
|
||||
Um die Texterkennung mittels Tesseract und die anschließende Filterung der Ergebnisdaten zu verbessern, werden anwendungsspezifische Annahmen für den Verarbeitungsablauf festgelegt.
|
||||
|
||||
\subsection{Preprocessing}
|
||||
\label{annahmen_preprocessing}
|
||||
|
||||
\subsubsection{Eigenschaften von Screenshots}
|
||||
\label{annahmen_bild_eigenschaften}
|
||||
|
||||
Die zu verarbeitenden Bilder im Kontext dieser Bachelorarbeit sind ausschließlich digitale Bildschirmaufnahmen von grafischen Benutzeroberflächen. Es kann also angenommen werden, dass die Screenshots keine Transparenz aufweisen, die Perspektive der Aufnahme nicht verzerrt ist. Im Großteil der evaluierten Fälle ist auch der Kontrast ausreichend, um die relevanten Inhalte zu erkennen. Weiters ist bei der Bildverarbeitung auf farbige Hintergrundflächen zu achten, mit deren Unterstützung Bildschirmelemente in modernen grafischen Oberflächen oft markiert, gruppiert oder getrennt werden. Nach Sichtung des zu verarbeitenden Bilddatensatzes fällt auf, dass manche Screenshots durch das Selektieren mit der Maus sehr eng abgeschnitten wurden. Das ist bei dem Preprocessing ebenfalls zu berücksichtigen. Eine beispielhafte Auswahl typischer Screenshots findet sich in \autoref{annahmen_bild_eigenschaften_beispiel}.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\begin{minipage}{0.66\textwidth}
|
||||
\includegraphics[width=\textwidth]{include/screenshots/driver_brpvi_offlineimport_004.png}
|
||||
\end{minipage}
|
||||
\hfill
|
||||
\begin{minipage}{0.3\textwidth}
|
||||
\begin{minipage}{\textwidth}
|
||||
\includegraphics[width=\textwidth]{include/screenshots/historian_assistent_001.png}
|
||||
\end{minipage}\hfill
|
||||
\vfill
|
||||
\begin{minipage}{\textwidth}
|
||||
\includegraphics[width=\textwidth]{include/screenshots/driver_archdrv_variablendefinition_001.png}
|
||||
\end{minipage}\hfill
|
||||
\end{minipage}
|
||||
\caption{Beispielhafte Auswahl typischer Dialogscreenshots.}
|
||||
\label{annahmen_bild_eigenschaften_beispiel}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Optimieren von Daten für Tesseract}
|
||||
\label{annahmen_bild_optimal}
|
||||
|
||||
Für die Verwendung von Tesseract ist es wichtig, unabhängig von der Diversität der Ausgangsdaten möglichst einheitliche Bilder zu erzeugen \mcite{tessdoc}. Während störende Elemente wie Bildrauschen aus dem Bild entfernt werden, sollen Texte ohne Einfluss der eigentlichen Hinter- bzw. Vordergrundfarbe gut zu erkennen sein. Auch eine deutliche Abgrenzung von Formen oder grafischen Symbolen ist von großer Wichtigkeit. \mcite{sporici2020improving} \mcite{mursari2021effectiveness}. Wurde ein Screenshot ideal vorbereitet, wie in \autoref{fig:screenshot_comparison_optimal} gezeigt, verschwinden farbige Hintergrundflächen und grafische Dekorationselemente. Übrig bleibt nur der gut lesbare textuelle Inhalt des Bildes.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\fbox{\includegraphics[width=0.45\textwidth]{include/screenshots/command-processing_screentypes_controlgroup_005.png}}
|
||||
\hfill
|
||||
\fbox{\includegraphics[width=0.45\textwidth]{\detokenize{include/results/ThresholdProcessor(40\%).00.command-processing_screentypes_controlgroup_005.png}}}
|
||||
\caption{Ein optimales Ergebnisbild. Jegliche farblichen Flächen wurden durch die Bildverarbeitung entfernt. Übrig bleibt klar lesbarer Text mit einem hohen Kontrast zum Hintergrund.}
|
||||
\label{fig:screenshot_comparison_optimal}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Postprocessing}
|
||||
\label{annahmen_postprocessing}
|
||||
|
||||
\subsubsection{Filtern von Symbolen}
|
||||
|
||||
Bei der Texterkennung kann es vorkommen, dass grafische Elemente als diverse Unicode-Symbole erkannt werden. Wie in \autoref{fig:screenshot_postprocessing}, wird oftmals versucht, grafische Dekorationselemente textuell nachzubilden. Auch finden sich in den ungefilterten Ergebnisdaten oft Aufzählungszeichen wie "•" oder unterschiedliche Varianten von Bindestrichen "‒". Diese Zeichen sind gemäß Anwendungsanforderungen nicht relevant für die Schlagwortsuche und können somit entfernt \bzw ignoriert werden.
|
||||
|
||||
\begin{figure}[t]
|
||||
\centering
|
||||
\begin{minipage}{0.45\textwidth}
|
||||
\includegraphics[width=0.90\textwidth]{include/postprocessing/source.png}
|
||||
\end{minipage}
|
||||
\hfill
|
||||
\begin{minipage}{0.5\textwidth}
|
||||
\lstinputlisting[firstnumber=100,linerange={100-110}]{include/postprocessing/source.json}
|
||||
\end{minipage}
|
||||
\caption{Auszug aus den ungefilterten Ergebnisdaten bei Durchführung der Texterkennung in dem gezeigten Screenshot.}
|
||||
\label{fig:screenshot_postprocessing}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Mehrsprachigkeit}
|
||||
\label{annahmen_mehrsprachigkeit}
|
||||
|
||||
Das Textverarbeitungssystem muss in der Lage sein, mehrsprachige Bilddateien Einlesen und Interpretieren zu können. So sollen beispielsweise Bilder mit englischen, deutschen oder italienischen Inhalten zugeführt und die Ergebnisdaten richtig verarbeitet werden können. Um eine Filterung für verschiedene Zeichensätze zu ermöglichen und eine Unterstützung für Sprachen mit nicht-lateinischen Schriften zu gewährleisten, werden dynamische Sprachfilter verwendet, die individuell an die jeweilige Sprache angepasst werden können. Für die weitere Beschreibung der generellen Vorgehensweise und Tests werden in den folgenden Schritten jedoch nur deutsche oder englische Inhalte verwendet.
|
||||
|
||||
\subsubsection{Schlagworte}
|
||||
\label{annahmen_schlagworte}
|
||||
|
||||
Für die spätere Suche von Screenshots sollen relevante Schlagworte aus den erkannten Textdaten extrahiert werden. Ein Wort eignet sich dann als Schlagwort, wenn es in relevantem Bezug zum jeweiligen Bild steht und dabei eine wichtige Aktion oder Information widerspiegelt. Inhalte, die direkt in der grafischen Benutzeroberfläche ersichtlich sind, haben daher einen hohen Informationsgehalt und eignen sich besonders gut als Suchworte. Um die Schlagwortmenge so aussagekräftig wie möglich zu halten, müssen Wörter mit geringer Bedeutung entfernt werden. Beispielsweise haben sogenannte Stoppwörter (\engl{Stop words}) wie "und" oder "oder" keine besondere Semantik und fördern aufgrund ihrer Häufigkeit das Auftreten von Verwechslungen \mcite{wilbur1992automatic}.
|
||||
@@ -1,6 +1,8 @@
|
||||
\chapter{Konzept}
|
||||
\label{konzept}
|
||||
|
||||
\input{chapters/c30_konzept/annahmen}
|
||||
\input{chapters/c30_konzept/vergleich/index}
|
||||
\input{chapters/c30_konzept/algorithmen/index}
|
||||
Im folgenden Kapitel wird eine Auswahl an verwendeten \hyperref[konzept_texterkennungssystem]{Technologien} und \hyperref[algorithmen_preprocessing]{Algorithmen} getroffen. Auch wird der Grundstein für den \hyperref[konzept_testaufbau]{Testaufbau} gelegt, anhand dessen später die prototypische Implementierung erfolgt.
|
||||
|
||||
\input{chapters/c30_konzept/technologien}
|
||||
\input{chapters/c30_konzept/algorithmen/index}
|
||||
\input{chapters/c30_konzept/testaufbau}
|
||||
@@ -0,0 +1,9 @@
|
||||
\section{Texterkennungssystem}
|
||||
\label{konzept_texterkennungssystem}
|
||||
|
||||
Wie bereits in \autoref{grundlagen_texterkennungssysteme} beschrieben, ist die Nutzung vieler OCR-Anwendungen \bzw Dienstleistungen kostenpflichtig und die genaue innere Vorgehensweise dieser Programme ist nicht öffentlich bekannt \mcite{textract_pricing, gcv_pricing, azurevision_pricing}. Aufgrund dieser Tatsachen wird als Texterkennungssystems für die prototypische Implementierung dieser Bachelorarbeit die quelloffene und kostenlose Tesseract Open Source OCR Engine verwendet.
|
||||
|
||||
\section{Bildbearbeitungswerkzeug}
|
||||
\label{konzept_bildbearbeitungswerkzeug}
|
||||
|
||||
Als Werkzeug für die Durchführung der notwendigen Bildbearbeitungsschritte wurde aufgrund persönlicher Erfahrungen die Softwarebibliothek "ImageMagick" \mcite{imagemagick} gewählt. Sie ist umfassend dokumentiert, flexibel und kann aufgrund der Unterstützung für eine Vielzahl von Programmiersprachen direkt in Programme eingebunden werden. Viele für die Bildverarbeitung notwendige Operationen sind bereits implementiert, was schnelles Prototyping vereinfacht. Deshalb wird die Bibliothek für die Realisierung von Bildbearbeitungsschritten in der prototypischen Implementierung verwendet, kann jedoch auch durch eine andere Implementierung ersetzt werden.
|
||||
@@ -0,0 +1,6 @@
|
||||
\section{Testaufbau}
|
||||
\label{konzept_testaufbau}
|
||||
|
||||
Der Testaufbau soll ein dynamisches Verketten von unterschiedlichen Bildverarbeitungs- und Textfilterungsschritten erlauben.
|
||||
|
||||
Für einen objektiven Vergleich zwischen den verschiedenen Vorgehensweisen und Algorithmen wird eine Grundabfolge der jeweiligen Schritte in einer "Processing-Pipeline" definiert. Diese Grundabfolge kann anschließend mit den jeweiligen zu vergleichenden Algorithmen erweitert werden. Die Ergebnisse können schließlich anhand der in \autoref{metriken} beschriebenen Fehlermetriken mit einer durch den Menschen verschlagworteten Vergleichsmenge abgeglichen werden.
|
||||
@@ -1,5 +0,0 @@
|
||||
\section{Vergleich}
|
||||
\label{vergleich}
|
||||
|
||||
\input{chapters/c30_konzept/vergleich/metriken}
|
||||
\input{chapters/c30_konzept/vergleich/testaufbau}
|
||||
@@ -1,4 +0,0 @@
|
||||
\subsection{Testaufbau}
|
||||
\label{testaufbau}
|
||||
|
||||
Der Testaufbau im Rahmen der Implementierung, beschrieben in \autoref{implementierung}, erlaubt ein dynamisches Verketten von unterschiedlichen Bildverarbeitungs- und Textfilterungsschritten. Für einen objektiven Vergleich zwischen den verschiedenen Vorgehensweisen und Algorithmen wird eine Grundabfolge der jeweiligen Schritte in einer "Processing-Pipeline" definiert. Die Ergebnisse können schließlich anhand der in \autoref{metriken} beschriebenen Fehlermetriken mit einer durch den Menschen verschlagworteten Vergleichsmenge abgeglichen werden.
|
||||
@@ -1,330 +0,0 @@
|
||||
\section{Implementierung}
|
||||
\label{implementierung}
|
||||
|
||||
\subsection{Vergleichsdaten}
|
||||
|
||||
Als Ausgangsdaten für die Durchführung wurde eine zufällige Auswahl an Dokumentationsscreenshots, wie in \autoref{fig:screenshot_beispiel_gut} abgebildet, getroffen. Zusätzlich wurden auch Bilder wie in \autoref{fig:screenshot_beispiel_schlecht} in die Stichprobe mit aufgenommen, die beispielsweise aufgrund ihrer Auflösung oder Kontrastverhältnisse schwer lesbar sind.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\fbox{\includegraphics[width=.7\textwidth]{include/screenshots/driver_SEL_Options_002.png}}
|
||||
\caption{Ein gut für die Texterkennung geeigneter Screenshot. Die wesentlichen Inhalte weisen einen guten Kontrast zum Hintergrund auf und befinden sich in Bereichen mit gleichmäßiger Helligkeit.}
|
||||
\label{fig:screenshot_beispiel_gut}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\fbox{\includegraphics[width=.7\textwidth]{include/screenshots/editor_startpage_project-exist_001.png}}
|
||||
\caption{Ein schlecht lesbarer Screenshot. Aufgrund der vielen Symbole und der bunten Flächen stellt dieses Bild eine Herausforderung für das Texterkennungssystem dar.}
|
||||
\label{fig:screenshot_beispiel_schlecht}
|
||||
\end{figure}
|
||||
|
||||
Die textuellen Inhalte aller ausgewählten Bilder wurden anschließend manuell extrahiert und für den programmatischen Vergleich in einer Datei im selben Verzeichnis wie die Quellbilddatei festgehalten. Ein Beispiel dafür ist der Screenshot "zrs\_ZAMS\_filter-alarmgroup\_001" in \autoref{fig:screenshot_verschlagwortet}, welches insgesamt 15 verschiedene Wörter beinhaltet.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\begin{minipage}{0.5\textwidth}
|
||||
\includegraphics[width=0.99\textwidth]{include/screenshots/zrs_ZAMS_filter-alarmgroup_001.png}
|
||||
\end{minipage}
|
||||
\hfill
|
||||
\begin{minipage}{0.45\textwidth}
|
||||
\lstinputlisting[numbers=none]{include/screenshots/zrs_ZAMS_filter-alarmgroup_001.json}
|
||||
\end{minipage}
|
||||
\caption{Ein Screenshot und die daraus manuell extrahierten Schlagworte.}
|
||||
\label{fig:screenshot_verschlagwortet}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Verwendete Bibliotheken}
|
||||
\label{components}
|
||||
|
||||
\subsubsection{Fremdbibliotheken}
|
||||
\label{components_external}
|
||||
|
||||
In der prototypischen Implementierung, geschrieben in der Programmiersprache \csharp, wurden in Referenz an die in \autoref{technologien} vorgestellten Technologien und Werkzeuge folgende NuGet-Bibliotheken als Basis für die Implementierung verwendet:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Magick.NET}\\Version: 13.1.0\\Lizenz: Apache-2.0\\\url{https://www.nuget.org/packages/Magick.NET.Core}
|
||||
\item \textbf{Tesseract}\\Version: 5.2.0\\Lizenz: Apache-2.0\\\url{https://www.nuget.org/packages/Tesseract}
|
||||
\end{itemize}
|
||||
|
||||
\subsubsection{Verarbeitungsketten}
|
||||
\label{components_processorchain}
|
||||
|
||||
Beim Entwurf des Verarbeitungssystems für die unterschiedlichen Bild- und Textverarbeitungsschritte wurde bewusst auf Flexibilität geachtet. Mithilfe von Interfaces und Builder-Methoden ist es möglich, Verarbeitungsschritte gemäß Programm \ref{prg:processor_interface} als Prozessoren (\engl{Processors}) zu definieren. So stellt beispielsweise das Normalisieren eines durch Tesseract erkannten Wortes einen Verarbeitungsschritt dar, wie in Programm \ref{prg:processor_implementation} gezeigt.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
public interface IProcessor
|
||||
{
|
||||
IEnumerable Process(IEnumerable inputs);
|
||||
}
|
||||
|
||||
public interface IProcessor<in TInput, out TOutput> : IProcessor
|
||||
{
|
||||
IEnumerable<TOutput> Process(IEnumerable<TInput> inputs);
|
||||
|
||||
new IEnumerable Process(IEnumerable inputs)
|
||||
{
|
||||
return Process((IEnumerable<TInput>)inputs);
|
||||
}
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "IProcessor.cs": Schnittstelle eines Prozessors.}
|
||||
\label{prg:processor_interface}
|
||||
\end{program}
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
public class ToLowerProcessor
|
||||
: Processor<ScanResult, ScanResult>
|
||||
{
|
||||
public override IEnumerable<ScanResult> Process(
|
||||
IEnumerable<ScanResult> inputs
|
||||
)
|
||||
{
|
||||
foreach (var kv in inputs)
|
||||
{
|
||||
kv.Word.Text = kv.Word.Text.ToLower();
|
||||
yield return kv;
|
||||
}
|
||||
}
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "ToLowerProcessor.cs": Normalisieren als einzelner Verarbeitungsschritt.}
|
||||
\label{prg:processor_implementation}
|
||||
\end{program}
|
||||
|
||||
Sollen mehrere Schritte verbunden werden, bietet das Processing-Framework die Möglichkeit, eine Verarbeitungskette aufzubauen. Gemäß der Schnittstellendefinition in Programm \ref{prg:processor_chain_interface} können Delegates oder komplette Prozessoren dynamisch als einzelne Schritte aneinandergereiht werden. Die Typensicherheit wird durch das generische Typensystem von \csharp stets gewahrt.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
public interface IProcessorChainConfiguration<TInput, TOutput>
|
||||
: IProcessorChain<TInput, TOutput>
|
||||
{
|
||||
IProcessorChainConfiguration<T, TOutput, TInput, TOutput> Use<T>(
|
||||
IProcessor<TInput, T> processor);
|
||||
|
||||
IProcessorChainConfiguration<T, TOutput, TInput, TOutput> Use<T>(
|
||||
Func<IEnumerable<TInput>, IEnumerable<T>> processorFunc);
|
||||
|
||||
IProcessorChainConfiguration<TInput, TOutput> Complete(
|
||||
IProcessor<TInput, TOutput> processor);
|
||||
|
||||
IProcessorChainConfiguration<TInput, TOutput> Complete(
|
||||
Func<IEnumerable<TInput>, IEnumerable<TOutput>> processorFunc);
|
||||
}
|
||||
|
||||
public interface IProcessorChainConfiguration<TInput, TOutput, TInChain, TOutChain>
|
||||
{
|
||||
IProcessorChainConfiguration<T, TOutput, TInChain, TOutChain> Use<T>(
|
||||
IProcessor<TInput, T> processor);
|
||||
|
||||
IProcessorChainConfiguration<T, TOutput, TInChain, TOutChain> Use<T>(
|
||||
Func<IEnumerable<TInput>, IEnumerable<T>> processorFunc);
|
||||
|
||||
IProcessorChain<TInChain, TOutChain> Complete(
|
||||
IProcessor<TInput, TOutput> processor);
|
||||
|
||||
IProcessorChain<TInChain, TOutChain> Complete(
|
||||
Func<IEnumerable<TInput>, IEnumerable<TOutput>> processorFunc);
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "IProcessorChainConfiguration.cs": Schnittstelle zur Konfiguration einer Verarbeitungskette}
|
||||
\label{prg:processor_chain_interface}
|
||||
\end{program}
|
||||
|
||||
Ist die Aufbauphase abgeschlossen, kann die Verarbeitungskette, konfiguriert in Programm \ref{prg:processor_chain_implementation}, gestartet werden.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
var postProcessor = new ProcessorChainConfiguration<ScanResult, ScanResult>()
|
||||
.Use(new ConfidenceFilter(50))
|
||||
.Use(new ToLowerProcessor())
|
||||
.Use(new DuplicateFilter())
|
||||
.Complete(new RegexFilter(WordRegex));
|
||||
|
||||
// ...
|
||||
|
||||
postProcessor.Process(data);
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "ImageViewModel.cs": Konfiguration und Starten einer Verarbeitungskette.}
|
||||
\label{prg:processor_chain_implementation}
|
||||
\end{program}
|
||||
|
||||
Abhängig von den verwendeten Prozessoren können also Eingangsdaten jeglichen Typs, in diesem Fall Bildobjekte der Magick.NET Bibliothek oder Ergebnisdaten des Texterkennungsvorgangs dynamisch verarbeitet werden.
|
||||
|
||||
\subsubsubsection{Bildverarbeitungskette}
|
||||
\label{processor_chain_image}
|
||||
|
||||
Für den Ablauf der Bildverarbeitung und der anschließenden Ergebnisfilterung werden die Erkenntnisse aus \autoref{konzept} mithilfe des in \autoref{components_processorchain} beschriebenen Processing-Frameworks angewandt. Die Resultierende Konfiguration ist in Programm \ref{prg:preprocessor_definition} und Programm \ref{prg:postprocessor_definition} definiert.
|
||||
|
||||
Angefangen mit einem Ausgangsbild, welches über die Softwarebibliothek Magick.NET geladen wurde, beginnt die Bildverarbeitung zunächst mit dem Resampling. Falls der geladene Screenshot die Mindestauflösung von 300 dpi unterschreitet, wird es mittels Lanczos2-Verfahren, eine von Magick.NET mitgelieferte Implementierung des Lanczos2-Algorithmus mit leichter Schärfung \mcite{imagemagick}, auf die Mindestauflösung vergrößert. Anschließend wird das Bild normalisiert, in Graustufen umgewandelt und jegliche Transparenz durch einen weißen Hintergrund ersetzt. Danach wird es mittels Schwellwertverfahren binarisiert. Rund um das Bild wird ein Rahmen mit einer Dicke von 10px eingefügt. Um Texterkennungsfehler durch falsche Vorder- \bzw Hintergrundfarben auszuschließen, wird das Bild gemeinsam mit einer farblich invertierten Version an das Texterkennungssystem weitergegeben.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
var preprocessing = new ProcessorChainConfiguration<MagickImage, MagickImage>()
|
||||
.Use(new CloneImageProcessor())
|
||||
.Use(new ResizeProcessor(FilterType.Lanczos2Sharp, PixelInterpolateMethod.Mesh))
|
||||
.Use(new NormalizeProcessor())
|
||||
.Use(_thresholdProcessor)
|
||||
.Use(new AddBorderProcessor(10))
|
||||
.Use(new BinarizeProcessor())
|
||||
.Use(new NegateCloneProcessor())
|
||||
.Complete(OnPreprocessed);
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "EvaluationProcessor.cs": Definition der Preprocessing-Kette.}
|
||||
\label{prg:preprocessor_definition}
|
||||
\end{program}
|
||||
|
||||
Wurde der übergebene Screenshot vom Texterkennungssystem verarbeitet, müssen nun die Ergebnisse gefiltert werden. Dazu werden zunächst die Metadaten der einzelnen Wörter betrachtet und alle Elemente mit einer Confidence unter einem Schwellenwert von 50\% verworfen. Danach werden die erkannten Texte mittels der \csharp-Funktion ToLower() normalisiert und anschließend auf Duplikate untersucht. Sind alle Duplikate verworfen, werden die Wörter mittels sprachabhängigen Regular Expressions -- in diesem Fall gibt es gemäß den Annahmen in \autoref{annahmen_mehrsprachigkeit} einen Sprachfilter für Englisch und Deutsch -- gefiltert.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
var postprocessing = new ProcessorChainConfiguration<ScanResult, ScanResult>()
|
||||
.Use(new ConfidenceFilter(50))
|
||||
.Use(new ToLowerProcessor())
|
||||
.Use(new DuplicateFilter())
|
||||
.Complete(new RegexFilter(wordRegex));
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "EvaluationProcessor.cs": Definition der Postprocessing-Kette.}
|
||||
\label{prg:postprocessor_definition}
|
||||
\end{program}
|
||||
|
||||
\subsubsection{Lookup}
|
||||
|
||||
Die "Lookup" Bibliothek abstrahiert das Speichern von Schlüssel-Wert-Paaren. Dabei kann flexibel zwischen verschiedenen Speicherimplementierungen gewechselt werden. So ist es beispielsweise möglich, die Werte in einer Listenstruktur im Arbeitsspeicher, in einer Datei oder -- mittels der EntityFramework-Bibliothek, welche von der .NET Foundation entwickelt wird -- in einer Datenbank persistent abzulegen. Unabhängig von der Ablagestruktur im Hintergrund können Lookups mittels einer gemeinsamen Schnittstelle, abgebildert in Programm \ref{prg:lookup_interface}, manipuliert werden.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
public interface ILookup<TKey, TValue>
|
||||
: ILookup,
|
||||
IDictionary<TKey, ICollection<TValue>>,
|
||||
IDisposable
|
||||
{
|
||||
ICollection<TValue> Add(TKey key);
|
||||
|
||||
public void Add(TKey key, TValue value);
|
||||
|
||||
public void AddRange(TKey key, IEnumerable<TValue> values);
|
||||
|
||||
public bool Remove(TKey key, TValue value);
|
||||
|
||||
public ICollection<TValue> GetOrAdd(TKey key);
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "ILookup.cs": Definition der gemeinsamen Schnittstelle für Lookups}
|
||||
\label{prg:lookup_interface}
|
||||
\end{program}
|
||||
|
||||
\subsubsection{OCR}
|
||||
|
||||
Die "OCR" Bibliothek enthält elementare Komponenten für die Texterkennung mittels der oben genannten Komponenten. Sie enthält Funktionen zur Bearbeitung von Bildern mittels Magick.NET inklusive anschließender Verarbeitung mittels Tesseract. Kernkomponenten wie das Texterkennungssystem werden automatisch auf Basis der Eingabeparameter konfiguriert und die Verwendung der Ergebnisdaten in externen Programmteilen wird durch die Zurverfügungstellung von Datenmodellen für die Ergebnisdaten vereinfacht. Außerdem enthält die Bibliothek eine Reihe von vordefinierten Verarbeitungsketten \bzw Prozessoren für die Bild- und Textverarbeitung.
|
||||
|
||||
\subsubsection{Automatische Berichterstellung}
|
||||
\label{components_reportgenerator}
|
||||
|
||||
Mithilfe des ReportGenerator-Frameworks wird die automatische Berichterstellung für unterschiedlichste Ausgabeformate abstrahiert. Durch die mitgelieferten Schnittstellendefinitionen ist es möglich, eigene Ausgabeformate zu definieren. Der gesamte Funktionsumfang des ReportGenerators, beispielsweise das Erstellen von Tabellen oder das Anlegen und Überschriften, kann durch die Implementerung von Interfaces wie Programm \ref{prg:reportgenerator_interface} an die jeweilige Syntax und Dokumentstruktur angepasst werden.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
public interface IDocumentGenerator : IStreamWriter
|
||||
{
|
||||
IDocumentGenerator Append(string? text = default);
|
||||
|
||||
IDocumentGenerator AppendLine(string? text = default);
|
||||
|
||||
IDocumentGenerator AppendParagraph(string? text = default);
|
||||
|
||||
IDocumentGenerator AppendHeading(int level, string text);
|
||||
|
||||
IDocumentGenerator AppendTable(int columns, Action<ITableGenerator> table);
|
||||
|
||||
string FormatImage(string path, IBounds? bounds = default);
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "IDocumentGenerator.cs": Hauptschnittstelle für den ReportGenerator}
|
||||
\label{prg:reportgenerator_interface}
|
||||
\end{program}
|
||||
|
||||
\subsection{Programmablauf}
|
||||
|
||||
Die prototypische Implementierung besteht neben den oben genannten Komponenten aus einem ausführbaren Kommandozeilenprogramm zur Texterkennung und einem Programm zum Vergleich der Ergebnisse mit den manuell verschlagworteten Soll-Daten. Alle relevanten Daten werden in entsprechenden Ausgabeverzeichnissen festgehalten und dadurch für den jeweiligen nächsten Schritt verfügbar gemacht.
|
||||
|
||||
\subsubsection{Texterkennung}
|
||||
|
||||
Zu Beginn der Ausführung des Kommandozeilenprogramms wird für jedes zu verarbeitende Bild abhängig von den definierten Schwellenwertverfahren eine Reihe von Prozessoren angelegt. Dazu wurde der statische Teil der Bildverarbeitungskette gemäß \autoref{processor_chain_image} innerhalb der "EvaluationProcessor" Klasse definiert, wie in Programm \ref{prg:processor_definition_dynamic} auszugsweise dargestellt. Lediglich die zu evaluierenden Prozessoren für die jeweiligen Schwellwertverfahren können außerhalb der klasse dynamisch definiert werden. Der EvaluationProcessor legt die erzeugten Ergebnisdaten, bestehend aus den gefundenen Wörtern und zugehörigen Metadaten wie die Confidence, auf Dateiebene ab. Um überprüfen zu können, welches Bild schlussendlich an das Texterkennungssystem übergeben wurde, werden auch die verarbeiteten Bilder nach der Binarisierung gespeichert.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
private static IEnumerable<EvaluationProcessor> MakeThresholdVariations()
|
||||
{
|
||||
for (int i = 4; i <= 24; i += 4)
|
||||
{
|
||||
yield return new(new ThresholdAdaptiveProcessor(i));
|
||||
}
|
||||
|
||||
for (int i = 20; i <= 80; i += 10)
|
||||
{
|
||||
yield return new(new ThresholdProcessor(i));
|
||||
}
|
||||
|
||||
yield return new(new AutoThresholdProcessor(AutoThresholdMethod.Kapur));
|
||||
yield return new(new AutoThresholdProcessor(AutoThresholdMethod.OTSU));
|
||||
yield return new(new AutoThresholdProcessor(AutoThresholdMethod.Triangle));
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "Program.cs": Definition der Thresholding Prozessoren.}
|
||||
\label{prg:processor_definition_dynamic}
|
||||
\end{program}
|
||||
|
||||
Ist die Erstellung der Bildbearbeitungsprozessoren abgeschlossen, wird jeder einzelne Prozessor über die Systembibliothek "System.Threading.Tasks" als eigene Ausführungseinheit (\engl{Task}) gestartet. In der Kommandozeile wird anschließend der aktuelle Status jedes Tasks angezeigt. Wurden alle Tasks abgeschlossen, wird das Programm beendet.
|
||||
|
||||
\subsubsection{Vergleich mit Soll-Daten}
|
||||
|
||||
Wurden die in den jeweiligen Screenshots erkannten Textdaten abgelegt, werden diese Daten im zweiten Kommandozeilenprogramm "ReportGenerator" nun mit den manuell verschlagworteten Daten verglichen und die Ergebnisse in einen Bericht (\engl{Report}) gespeichert.
|
||||
|
||||
Als zentrale Komponente für den Vergleich spielt die Berechnung der in \autoref{metriken} erklärten Metriken eine wesentliche Rolle. Wie in Programm \ref{prg:distance_levenshtein} ersichtlich, wird die Distanz zwischen zwei \csharp-Enumerables, seien es zwei Strings oder zwei Listen, über das Verfahren nach Levenshtein berechnet.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
public static double GetDistance<T>(T reference, T? hypothesis)
|
||||
where T : IEnumerable
|
||||
{
|
||||
var refArr = reference.Cast<object>().ToArray();
|
||||
var hypArr = hypothesis?.Cast<object>().ToArray() ?? Array.Empty<object>();
|
||||
|
||||
var distance = new int[refArr.Length + 1, hypArr.Length + 1];
|
||||
|
||||
for (var x = 0; x <= refArr.Length; x++)
|
||||
{
|
||||
distance[x, 0] = x;
|
||||
}
|
||||
|
||||
for (var y = 0; y <= hypArr.Length; y++)
|
||||
{
|
||||
distance[0, y] = y;
|
||||
}
|
||||
|
||||
for (var x = 0; x < refArr.Length; x++)
|
||||
{
|
||||
for (var y = 0; y < hypArr.Length; y++)
|
||||
{
|
||||
var cost = Equals(refArr[x], hypArr[y]) ? 0 : 1;
|
||||
|
||||
var c1 = distance[x, y] + cost; // Bottom left
|
||||
|
||||
var c2 = distance[x, y + 1] + 1; // Top left
|
||||
var c3 = distance[x + 1, y] + 1; // Bottom right
|
||||
|
||||
distance[x + 1, y + 1] = Min(c1, c2, c3); // Top right
|
||||
}
|
||||
}
|
||||
|
||||
return distance[refArr.Length, hypArr.Length];
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "Calculator.cs": Berechnung der Levenshtein-Distanz.}
|
||||
\label{prg:distance_levenshtein}
|
||||
\end{program}
|
||||
|
||||
Nach der Ermittlung der jeweiligen Distanzen auf Wort- \bzw Bildbasis werden sie mit den jeweiligen Ursprungsbildern, Prozessoren und den verwendeten Algorithmen in Bezug gesetzt. Die so aufbereiteten Ergebnisse werden anschließend an den ReportGenerator übergeben und in einen Bericht zusammengefasst.
|
||||
@@ -1,5 +1,355 @@
|
||||
\chapter{Durchführung}
|
||||
\label{durchführung}
|
||||
\chapter{Prototypische Implementierung}
|
||||
\label{implementierung}
|
||||
|
||||
\input{chapters/c40_durchführung/implementierung}
|
||||
\input{chapters/c40_durchführung/analyse}
|
||||
In der prototypischen Implementierung werden die in \autoref{grundlagen} \bzw \autoref{konzept} angeführten Algorithmen zu Verarbeitungsketten zusammengefügt. Anhand einer Stichprobe wird ein automatisierter Bericht generiert, welcher detaillierte Informationen über Gesamtergebnisse der Texterkennung mit den jeweiligen Bildern und den verwendeten Algorithmen in Bezug setzt.
|
||||
|
||||
\section{Komponenten und Bibliotheken}
|
||||
\label{components}
|
||||
|
||||
Die für die prototypische Implementierung verwendeten Bibliotheken stellen Komponenten zur Verarbeitung von Screenshotdaten zur Verfügung. Um die Funktionalität flexibel auf unterschiedliche Anforderungen anpassen zu können, sind die Komponenten möglichst lose miteinander gekoppelt. Ein beispielhafter Ablauf eines Texterkennungsprogramms unter Nutzung der Bibliotheken ist in \autoref{fig:overview_diagram} abgebildet.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{include/flowcharts/flow_overview.png}
|
||||
\caption{Beispielhafter Ablauf eines Texterkennungsprogramms}
|
||||
\label{fig:overview_diagram}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Fremdbibliotheken}
|
||||
\label{components_external}
|
||||
|
||||
Die prototypische Implementierung erfolgt in \csharp .NET. Entsprechend der in \autoref{grundlagen} und \autoref{konzept} vorgestellten Technologien und Werkzeuge werden folgende NuGet-Bibliotheken als Basis für die Implementierung verwendet:
|
||||
|
||||
\begin{itemize}
|
||||
\item\textbf{Magick.NET} \mcite{nuget_magicknet}\\Version: 13.1.0\\Lizenz: Apache-2.0\\
|
||||
\item\textbf{Tesseract} \mcite{nuget_tesseract}\\Version: 5.2.0\\Lizenz: Apache-2.0\\
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Verarbeitungsketten}
|
||||
\label{components_processorchain}
|
||||
|
||||
Beim Entwurf des Verarbeitungssystems für die unterschiedlichen Bild- und Textverarbeitungsschritte wurde bewusst auf Flexibilität geachtet. Mithilfe von Interfaces und Builder-Methoden ist es möglich, Verarbeitungsschritte gemäß Programm \ref{prg:processor_interface} als Prozessoren (\engl{Processors}) zu definieren. So stellt beispielsweise das Normalisieren eines durch Tesseract erkannten Wortes einen Verarbeitungsschritt dar, wie in Programm \ref{prg:processor_implementation} gezeigt.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
public interface IProcessor
|
||||
{
|
||||
IEnumerable Process(IEnumerable inputs);
|
||||
}
|
||||
|
||||
public interface IProcessor<in TInput, out TOutput> : IProcessor
|
||||
{
|
||||
IEnumerable<TOutput> Process(IEnumerable<TInput> inputs);
|
||||
|
||||
new IEnumerable Process(IEnumerable inputs)
|
||||
{
|
||||
return Process((IEnumerable<TInput>)inputs);
|
||||
}
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "IProcessor.cs": Schnittstelle eines Prozessors.}
|
||||
\label{prg:processor_interface}
|
||||
\end{program}
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
public class ToLowerProcessor
|
||||
: Processor<ScanResult, ScanResult>
|
||||
{
|
||||
public override IEnumerable<ScanResult> Process(
|
||||
IEnumerable<ScanResult> inputs
|
||||
)
|
||||
{
|
||||
foreach (var kv in inputs)
|
||||
{
|
||||
kv.Word.Text = kv.Word.Text.ToLower();
|
||||
yield return kv;
|
||||
}
|
||||
}
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "ToLowerProcessor.cs": Normalisieren als einzelner Verarbeitungsschritt.}
|
||||
\label{prg:processor_implementation}
|
||||
\end{program}
|
||||
|
||||
Sollen mehrere Schritte verbunden werden, bietet das Processing-Framework die Möglichkeit, eine Verarbeitungskette aufzubauen. Gemäß der Schnittstellendefinition in Programm \ref{prg:processor_chain_interface} können Delegates oder komplette Prozessoren dynamisch als einzelne Schritte aneinandergereiht werden. Die Typensicherheit wird durch das generische Typensystem von \csharp stets gewahrt.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
public interface IProcessorChainConfiguration<TInput, TOutput>
|
||||
: IProcessorChain<TInput, TOutput>
|
||||
{
|
||||
IProcessorChainConfiguration<T, TOutput, TInput, TOutput> Use<T>(
|
||||
IProcessor<TInput, T> processor);
|
||||
|
||||
IProcessorChainConfiguration<T, TOutput, TInput, TOutput> Use<T>(
|
||||
Func<IEnumerable<TInput>, IEnumerable<T>> processorFunc);
|
||||
|
||||
IProcessorChainConfiguration<TInput, TOutput> Complete(
|
||||
IProcessor<TInput, TOutput> processor);
|
||||
|
||||
IProcessorChainConfiguration<TInput, TOutput> Complete(
|
||||
Func<IEnumerable<TInput>, IEnumerable<TOutput>> processorFunc);
|
||||
}
|
||||
|
||||
public interface IProcessorChainConfiguration<TInput, TOutput, TInChain, TOutChain>
|
||||
{
|
||||
IProcessorChainConfiguration<T, TOutput, TInChain, TOutChain> Use<T>(
|
||||
IProcessor<TInput, T> processor);
|
||||
|
||||
IProcessorChainConfiguration<T, TOutput, TInChain, TOutChain> Use<T>(
|
||||
Func<IEnumerable<TInput>, IEnumerable<T>> processorFunc);
|
||||
|
||||
IProcessorChain<TInChain, TOutChain> Complete(
|
||||
IProcessor<TInput, TOutput> processor);
|
||||
|
||||
IProcessorChain<TInChain, TOutChain> Complete(
|
||||
Func<IEnumerable<TInput>, IEnumerable<TOutput>> processorFunc);
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "IProcessorChainConfiguration.cs": Schnittstelle zur Konfiguration einer Verarbeitungskette}
|
||||
\label{prg:processor_chain_interface}
|
||||
\end{program}
|
||||
|
||||
Ist die Aufbauphase abgeschlossen, kann die Verarbeitungskette, konfiguriert in Programm \ref{prg:processor_chain_implementation}, gestartet werden.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
var postProcessor = new ProcessorChainConfiguration<ScanResult, ScanResult>()
|
||||
.Use(new ConfidenceFilter(50))
|
||||
.Use(new ToLowerProcessor())
|
||||
.Use(new DuplicateFilter())
|
||||
.Complete(new RegexFilter(WordRegex));
|
||||
|
||||
// ...
|
||||
|
||||
postProcessor.Process(data);
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "ImageViewModel.cs": Konfiguration und Starten einer Verarbeitungskette.}
|
||||
\label{prg:processor_chain_implementation}
|
||||
\end{program}
|
||||
|
||||
Abhängig von den verwendeten Prozessoren können also Eingangsdaten jeglichen Typs, in diesem Fall Bildobjekte der Magick.NET Bibliothek oder Ergebnisdaten des Texterkennungsvorgangs dynamisch verarbeitet werden.
|
||||
|
||||
\subsubsection{Bildverarbeitungskette}
|
||||
\label{processor_chain_image}
|
||||
|
||||
Für den Ablauf der Bildverarbeitung und der anschließenden Ergebnisfilterung werden die Erkenntnisse aus \autoref{konzept} mithilfe des in \autoref{components_processorchain} beschriebenen Processing-Frameworks angewandt. Die resultierende Konfiguration folgt dem Ablauf aus \autoref{fig:preprocessor_diagram} und \autoref{fig:postprocessor_diagram} und ist in Programm \ref{prg:preprocessor_definition} \bzw \ref{prg:postprocessor_definition} definiert.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{include/flowcharts/flow_preprocessing.png}
|
||||
\caption{Beispielhafter Ablauf der Vorverarbeitungskette}
|
||||
\label{fig:preprocessor_diagram}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\includegraphics[width=\textwidth]{include/flowcharts/flow_postprocessing.png}
|
||||
\caption{Beispielhafter Ablauf der Nachbearbeitungskette}
|
||||
\label{fig:postprocessor_diagram}
|
||||
\end{figure}
|
||||
|
||||
Angefangen mit einem Ausgangsbild, welches über die Softwarebibliothek Magick.NET geladen wurde, beginnt die Bildverarbeitung zunächst mit dem Resampling. Falls der geladene Screenshot die Mindestauflösung von 300 dpi unterschreitet, wird es mittels Lanczos2-Verfahren, eine von Magick.NET mitgelieferte Implementierung des Lanczos2-Algorithmus mit leichter Schärfung \mcite{imagemagick}, auf die Mindestauflösung vergrößert. Anschließend wird das Bild normalisiert, in Graustufen umgewandelt und jegliche Transparenz durch einen weißen Hintergrund ersetzt. Danach wird es mittels Schwellwertverfahren binarisiert. Rund um das Bild wird ein Rahmen mit einer Dicke von 10px eingefügt. Um Texterkennungsfehler durch falsche Vorder- \bzw Hintergrundfarben auszuschließen, wird das Bild gemeinsam mit einer farblich invertierten Version an das Texterkennungssystem weitergegeben.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
var preprocessing = new ProcessorChainConfiguration<MagickImage, MagickImage>()
|
||||
.Use(new CloneImageProcessor())
|
||||
.Use(new ResizeProcessor(FilterType.Lanczos2Sharp, PixelInterpolateMethod.Mesh))
|
||||
.Use(new NormalizeProcessor())
|
||||
.Use(_thresholdProcessor)
|
||||
.Use(new AddBorderProcessor(10))
|
||||
.Use(new BinarizeProcessor())
|
||||
.Use(new NegateCloneProcessor())
|
||||
.Complete(OnPreprocessed);
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "EvaluationProcessor.cs": Definition der Preprocessing-Kette.}
|
||||
\label{prg:preprocessor_definition}
|
||||
\end{program}
|
||||
|
||||
Nach Verarbeitung des übergebenen Screenshots durch das Texterkennungssystem werden die Ergebnisse gefiltert. Dazu werden zunächst die Metadaten der einzelnen Wörter betrachtet und alle Elemente mit einer Confidence unter einem Schwellenwert von 50\% verworfen. Danach werden die erkannten Texte mittels der \csharp-Funktion \lstinline{ToLower()} normalisiert und anschließend auf Duplikate untersucht. Wurden alle Duplikate verworfen, werden die Wörter mittels sprachabhängigen Regular Expressions untersucht. Gemäß den Rahmenbedingungen in \autoref{grundlagen_mehrsprachigkeit} wird ein simpler englischer (\lstinline|[\w'\-]{2,}|) sowie deutscher (\lstinline|[\w'\-äöüÄÖÜß]{2,}|) Sprachfilter festgelegt.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
var postprocessing = new ProcessorChainConfiguration<ScanResult, ScanResult>()
|
||||
.Use(new ConfidenceFilter(50))
|
||||
.Use(new ToLowerProcessor())
|
||||
.Use(new DuplicateFilter())
|
||||
.Complete(new RegexFilter(wordRegex));
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "EvaluationProcessor.cs": Definition der Postprocessing-Kette.}
|
||||
\label{prg:postprocessor_definition}
|
||||
\end{program}
|
||||
|
||||
\subsection{Lookup}
|
||||
|
||||
Die "Lookup" Bibliothek abstrahiert das Speichern von Schlüssel-Wert-Paaren. Dabei kann flexibel zwischen verschiedenen Speicherimplementierungen gewechselt werden. So ist es beispielsweise möglich, die Werte in einer Listenstruktur im Arbeitsspeicher, in einer Datei oder -- mittels der .NET EntityFramework-Bibliothek -- in einer Datenbank persistent abzulegen. Unabhängig von der Ablagestruktur im Hintergrund können Lookups mittels einer gemeinsamen Schnittstelle, abgebildet in Programm \ref{prg:lookup_interface}, manipuliert werden.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
public interface ILookup<TKey, TValue>
|
||||
: ILookup,
|
||||
IDictionary<TKey, ICollection<TValue>>,
|
||||
IDisposable
|
||||
{
|
||||
ICollection<TValue> Add(TKey key);
|
||||
|
||||
public void Add(TKey key, TValue value);
|
||||
|
||||
public void AddRange(TKey key, IEnumerable<TValue> values);
|
||||
|
||||
public bool Remove(TKey key, TValue value);
|
||||
|
||||
public ICollection<TValue> GetOrAdd(TKey key);
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "ILookup.cs": Definition der gemeinsamen Schnittstelle für Lookups}
|
||||
\label{prg:lookup_interface}
|
||||
\end{program}
|
||||
|
||||
\subsection{Optische Texterkennung}
|
||||
|
||||
Die OCR-Bibliothek beinhaltet elementare Funktionen für die Texterkennung. Sie enthält Funktionen zur Bearbeitung von Bildern mittels Magick.NET inklusive anschließender Verarbeitung mittels Tesseract. Kernkomponenten wie das Texterkennungssystem werden automatisch auf Basis der Eingabeparameter konfiguriert und die Verwendung der Ergebnisdaten in externen Programmteilen wird durch die zur Verfügung gestellten Modelle für die Ergebnisdaten vereinfacht. Außerdem enthält die Bibliothek eine Reihe von vordefinierten Verarbeitungsketten \bzw Prozessoren für die Bild- und Textverarbeitung.
|
||||
|
||||
\subsection{Automatische Berichterstellung}
|
||||
\label{components_reportgenerator}
|
||||
|
||||
Mithilfe des ReportGenerator-Frameworks wird die automatische Berichterstellung für unterschiedlichste Ausgabeformate abstrahiert. Durch die mitgelieferten Schnittstellendefinitionen ist es möglich, eigene Ausgabeformate zu definieren. Der gesamte Funktionsumfang des ReportGenerators, beispielsweise das Erstellen von Tabellen oder das Anlegen von Überschriften, kann durch die Implementierung von Interfaces wie in Programm \ref{prg:reportgenerator_interface} an die jeweilige Syntax und Dokumentstruktur angepasst werden.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
public interface IDocumentGenerator : IStreamWriter
|
||||
{
|
||||
IDocumentGenerator Append(string? text = default);
|
||||
|
||||
IDocumentGenerator AppendLine(string? text = default);
|
||||
|
||||
IDocumentGenerator AppendParagraph(string? text = default);
|
||||
|
||||
IDocumentGenerator AppendHeading(int level, string text);
|
||||
|
||||
IDocumentGenerator AppendTable(int columns, Action<ITableGenerator> table);
|
||||
|
||||
string FormatImage(string path, IBounds? bounds = default);
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "IDocumentGenerator.cs": Hauptschnittstelle für den ReportGenerator}
|
||||
\label{prg:reportgenerator_interface}
|
||||
\end{program}
|
||||
|
||||
\section{Vergleichsdaten}
|
||||
|
||||
Als Ausgangsdaten für die Durchführung wurde eine zufällige Auswahl an Dokumentationsscreenshots getroffen, wie in \autoref{fig:screenshot_beispiel_gut} abgebildet. Zusätzlich wurden auch Bilder wie in \autoref{fig:screenshot_beispiel_schlecht} in die Stichprobe mit aufgenommen, die beispielsweise aufgrund ihrer Auflösung oder Kontrastverhältnisse schwer lesbar sind.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\fbox{\includegraphics[width=.5\textwidth]{include/screenshots/driver_SEL_Options_002.png}}
|
||||
\caption{Ein gut für die Texterkennung geeigneter Screenshot. Die wesentlichen Inhalte weisen einen guten Kontrast zum Hintergrund auf und befinden sich in Bereichen mit gleichmäßiger Helligkeit.}
|
||||
\label{fig:screenshot_beispiel_gut}
|
||||
\end{figure}
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\fbox{\includegraphics[width=\textwidth]{include/screenshots/editor_startpage_project-exist_001.png}}
|
||||
\caption{Ein schlecht lesbarer Screenshot. Aufgrund der vielen Symbole und der bunten Flächen stellt dieses Bild eine Herausforderung für das Texterkennungssystem dar.}
|
||||
\label{fig:screenshot_beispiel_schlecht}
|
||||
\end{figure}
|
||||
|
||||
Die textuellen Inhalte aller ausgewählten Bilder wurden manuell extrahiert und für den programmatischen Vergleich in einer Datei im selben Verzeichnis wie die Quellbilddatei festgehalten. Ein Beispiel dafür ist der Screenshot "zrs\_ZAMS\_filter-alarmgroup\_001" in \autoref{fig:screenshot_verschlagwortet}, welcher insgesamt 15 verschiedene Wörter beinhaltet.
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\begin{minipage}{0.5\textwidth}
|
||||
\includegraphics[width=0.99\textwidth]{include/screenshots/zrs_ZAMS_filter-alarmgroup_001.png}
|
||||
\end{minipage}
|
||||
\hfill
|
||||
\begin{minipage}{0.45\textwidth}
|
||||
\lstinputlisting[numbers=none]{include/screenshots/zrs_ZAMS_filter-alarmgroup_001.json}
|
||||
\end{minipage}
|
||||
\caption{Ein Screenshot und die daraus manuell extrahierten Schlagworte.}
|
||||
\label{fig:screenshot_verschlagwortet}
|
||||
\end{figure}
|
||||
|
||||
\section{Programmablauf}
|
||||
|
||||
Die prototypische Implementierung besteht neben den oben genannten Komponenten aus einem ausführbaren Kommandozeilenprogramm zur Texterkennung und einem Programm zum Vergleich der Ergebnisse mit den manuell verschlagworteten Soll-Daten. Alle relevanten Daten werden in entsprechenden Ausgabeverzeichnissen festgehalten und dadurch für den jeweiligen nächsten Schritt verfügbar gemacht.
|
||||
|
||||
\subsection{Texterkennung}
|
||||
|
||||
Zu Beginn der Ausführung des Kommandozeilenprogramms wird für jedes zu verarbeitende Bild abhängig von den definierten Schwellenwertverfahren eine Reihe von Prozessoren angelegt. Dazu wird der statische Teil der Bildverarbeitungskette gemäß \autoref{processor_chain_image} innerhalb der "EvaluationProcessor" Klasse definiert, wie in Programm \ref{prg:processor_definition_dynamic} auszugsweise dargestellt. Lediglich die zu evaluierenden Prozessoren für die jeweiligen Schwellwertverfahren können außerhalb der Klasse dynamisch definiert werden. Der EvaluationProcessor legt die erzeugten Ergebnisdaten, bestehend aus den gefundenen Wörtern und zugehörigen Metadaten wie die Confidence, auf Dateiebene ab. Um überprüfen zu können, welches Bild an das Texterkennungssystem übergeben wird, werden auch die verarbeiteten Bilder nach der Binarisierung gespeichert.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
private static IEnumerable<EvaluationProcessor> MakeThresholdVariations()
|
||||
{
|
||||
for (int i = 4; i <= 24; i += 4)
|
||||
{
|
||||
yield return new(new ThresholdAdaptiveProcessor(i));
|
||||
}
|
||||
|
||||
for (int i = 20; i <= 80; i += 10)
|
||||
{
|
||||
yield return new(new ThresholdProcessor(i));
|
||||
}
|
||||
|
||||
yield return new(new AutoThresholdProcessor(AutoThresholdMethod.Kapur));
|
||||
yield return new(new AutoThresholdProcessor(AutoThresholdMethod.OTSU));
|
||||
yield return new(new AutoThresholdProcessor(AutoThresholdMethod.Triangle));
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "Program.cs": Definition der Thresholding Prozessoren.}
|
||||
\label{prg:processor_definition_dynamic}
|
||||
\end{program}
|
||||
|
||||
Ist die Erstellung der Bildbearbeitungsprozessoren abgeschlossen, wird jeder einzelne Prozessor über die Systembibliothek "System.Threading.Tasks" als eigene Ausführungseinheit (\engl{Task}) gestartet. In der Kommandozeile wird anschließend der aktuelle Status jedes Tasks angezeigt. Wurden alle Tasks abgeschlossen, wird das Programm beendet.
|
||||
|
||||
\subsection{Vergleich mit Soll-Daten}
|
||||
|
||||
Wurden die in den jeweiligen Screenshots erkannten Textdaten abgelegt, werden diese Daten im zweiten Kommandozeilenprogramm "ReportGenerator" mit den manuell verschlagworteten Daten verglichen und die Ergebnisse in einen Bericht (\engl{Report}) gespeichert.
|
||||
|
||||
Als zentrale Komponente für den Vergleich spielt die Berechnung der in \autoref{metriken} erklärten Metriken eine wesentliche Rolle. Wie in Programm \ref{prg:distance_levenshtein} ersichtlich, wird die Distanz zwischen zwei \csharp-Enumerables, seien es zwei Strings oder zwei Listen, über das Verfahren nach Levenshtein berechnet.
|
||||
|
||||
\begin{program}[!ht]
|
||||
\begin{CsCode}[numbers=none]
|
||||
public static double GetDistance<T>(T reference, T? hypothesis)
|
||||
where T : IEnumerable
|
||||
{
|
||||
var refArr = reference.Cast<object>().ToArray();
|
||||
var hypArr = hypothesis?.Cast<object>().ToArray() ?? Array.Empty<object>();
|
||||
|
||||
var distance = new int[refArr.Length + 1, hypArr.Length + 1];
|
||||
|
||||
for (var x = 0; x <= refArr.Length; x++)
|
||||
{
|
||||
distance[x, 0] = x;
|
||||
}
|
||||
|
||||
for (var y = 0; y <= hypArr.Length; y++)
|
||||
{
|
||||
distance[0, y] = y;
|
||||
}
|
||||
|
||||
for (var x = 0; x < refArr.Length; x++)
|
||||
{
|
||||
for (var y = 0; y < hypArr.Length; y++)
|
||||
{
|
||||
var cost = Equals(refArr[x], hypArr[y]) ? 0 : 1;
|
||||
|
||||
var c1 = distance[x, y] + cost; // Bottom left
|
||||
|
||||
var c2 = distance[x, y + 1] + 1; // Top left
|
||||
var c3 = distance[x + 1, y] + 1; // Bottom right
|
||||
|
||||
distance[x + 1, y + 1] = Min(c1, c2, c3); // Top right
|
||||
}
|
||||
}
|
||||
|
||||
return distance[refArr.Length, hypArr.Length];
|
||||
}
|
||||
\end{CsCode}
|
||||
\caption{Auszug aus Datei "Calculator.cs": Berechnung der Levenshtein-Distanz.}
|
||||
\label{prg:distance_levenshtein}
|
||||
\end{program}
|
||||
|
||||
Nach der Ermittlung der jeweiligen Distanzen auf Wort- \bzw Bildbasis werden sie mit den jeweiligen Ursprungsbildern, Prozessoren und den verwendeten Algorithmen in Bezug gesetzt. Die so aufbereiteten Ergebnisse werden anschließend an den ReportGenerator übergeben und in einem Bericht zusammengefasst.
|
||||
@@ -1,32 +1,29 @@
|
||||
\section{Analyse}
|
||||
\label{analyse}
|
||||
\chapter{Evaluierung}
|
||||
\label{evaluierung}
|
||||
|
||||
Nachdem die vorbereiteten Bilddaten an das Texterkennungssystem gemäß \autoref{implementierung} übergeben und die Ergebnisse ermittelt wurden, werden die extrahierten Textdaten nun mit den manuell erstellten "Soll-Daten" verglichen. Anhand der Statistik kann festgestellt werden, welche Vorgehensweise zu der besten Qualität führt. Um die Ergebnisse zu visualisieren, erstellt der in \autoref{components_reportgenerator} beschriebene "ReportGenerator" auf Basis der Bilddateinamen automatisch einen Bericht mit den Vergleichsdaten in Tabellenform. Der erstellte Bericht wird in verschiedene Kategorien unterteilt.
|
||||
Nachdem die vorbereiteten Bilddaten an das Texterkennungssystem gemäß \autoref{implementierung} übergeben und die Ergebnisse ermittelt wurden, werden die extrahierten Textdaten mit den manuell erstellten "Soll-Daten" verglichen. Anhand der Statistik kann festgestellt werden, welche Vorgehensweise zu der besten Qualität führt. Um die Ergebnisse zu visualisieren, erstellt der in \autoref{components_reportgenerator} beschriebene "ReportGenerator" auf Basis der Bilddateinamen automatisch einen Bericht mit den Vergleichsdaten in Tabellenform. Der erstellte Bericht wird in verschiedene Kategorien unterteilt.
|
||||
|
||||
\subsection{Vergleich im Detail}
|
||||
\label{report_detailed}
|
||||
\section{Verarbeitungsstatistik}
|
||||
|
||||
\subsubsection{Processor Stats}
|
||||
|
||||
In der Sektion "Processor Stats", siehe \autoref{tbl:report_detailed_processorstats}, wird die Gesamtwortfehlerrate pro Bild mit dem jeweiligen Prozessor in Verhältnis gesetzt. Anhand der Metriken ist zu erkennen, dass gewisse Bilder aufgrund ihrer Eigenschaften (niedrige Auflösung, schwierige Farbgebung, etc.) von allen Prozessoren gleichermaßen schlecht erkannt werden. Jedoch fallen auch Spezialfälle auf: So werden beispielsweise die Textdaten in den Dialog-Knöpfen des Bilds "worldview\_zoom\_steps\_001" Dank eines falsch gewählten Schwellenwerts unkenntlich gemacht. Die Texterkennung schlägt fehl.
|
||||
In der Sektion "Processor Stats" (siehe \autoref{tbl:report_detailed_processorstats}), welche die Verarbeitungsstatistik enthält, wird die Gesamtwortfehlerrate pro Bild mit dem jeweiligen Prozessor in Verhältnis gesetzt. Anhand der Metriken ist zu erkennen, dass gewisse Bilder aufgrund ihrer Eigenschaften (niedrige Auflösung, schwierige Farbgebung) von allen Prozessoren gleichermaßen schlecht erkannt werden. Jedoch fallen auch Spezialfälle auf: So werden beispielsweise die Textdaten in den Dialog-Knöpfen des Bilds "worldview\_zoom\_steps\_001" aufgrund eines falsch gewählten Schwellenwerts unkenntlich gemacht. Die Texterkennung schlägt fehl.
|
||||
|
||||
\begin{table}[!ht]
|
||||
\centering
|
||||
\input{include/figures/fig_AutoThresholdProcessor(Kapur)_1.tex}
|
||||
\caption{Auszug aus der "Processor Stats" Tabelle im generierten Bericht. Die Eigenschaften der Originalbilder im Vergleich zu den verarbeiteten Bildern geben Aufschluss über die Arbeitsweise und Effektivität des Prozessors.}
|
||||
\caption{Auszug aus der "Processor Stats" Tabelle im generierten Bericht. Die Eigenschaften der Originalbilder im Vergleich zu den verarbeiteten Bildern geben Aufschluss über die Arbeitsweise und Effektivität des Prozessors. Im obersten Bild sind die Inhalte gut zu erkennen, wogegen in der untersten Reihe nach der Filterung nur wenige Artefakte zurückbleiben.}
|
||||
\label{tbl:report_detailed_processorstats}
|
||||
\end{table}
|
||||
|
||||
\subsubsection{Scan Results}
|
||||
\section{Ergebnisse}
|
||||
|
||||
Die Sektion "Scan Results" bildet den Abschluss des Detailvergleichs. Hier werden alle Verfahrenskombinationen einzeln und mit allen verfügbaren Daten aufgeführt.
|
||||
Die Sektion "Scan Results" (siehe \autoref{tbl:report_detailed_scanresults_stats} \bzw \autoref{tbl:report_detailed_scanresults_words}) zeigt die Verarbeitungsergebnisse auf Metrik- \bzw Wortbasis und bildet den Abschluss des Detailvergleichs. Hier werden alle Verfahrenskombinationen einzeln und mit allen verfügbaren Daten aufgeführt.
|
||||
|
||||
\begin{table}[!ht]
|
||||
\begin{sidewaystable}[!ht]
|
||||
\centering
|
||||
\input{include/figures_modified/fig_command-processing_screentypes_controlgroup_005_1.I.tex}
|
||||
\caption{Auszug aus der "Scan Results" Tabelle im generierten Bericht. Für jede Ausgabedatei werden sämtliche Statistiken aufgelistet.}
|
||||
\label{tbl:report_detailed_scanresults_stats}
|
||||
\end{table}
|
||||
\end{sidewaystable}
|
||||
|
||||
\begin{table}[!ht]
|
||||
\centering
|
||||
@@ -35,28 +32,28 @@ Die Sektion "Scan Results" bildet den Abschluss des Detailvergleichs. Hier werde
|
||||
\label{tbl:report_detailed_scanresults_words}
|
||||
\end{table}
|
||||
|
||||
\subsection{Prozessoren im Überblick}
|
||||
\section{Prozessoren im Überblick}
|
||||
\label{report_processingsummary}
|
||||
|
||||
Neben dem Detailvergleich beinhaltet der generierte Bericht auch die "Processing Summary". Diese Kategorie zeigt eine kurze Übersicht aller Ergebnisse. Je nach Rubrik wird jeweils der Median \bzw Durchschnitt der \hyperref[metriken_cer]{Character Error Rate} und \hyperref[metriken_wer]{Word Error Rate} berechnet.
|
||||
Neben dem Detailvergleich beinhaltet der generierte Bericht auch die "Processing Summary". Diese Kategorie zeigt eine kurze Übersicht aller Ergebnisse. Je nach Rubrik wird jeweils der Median \bzw Durchschnitt der \hyperref[metriken_cer]{Character Error Rate} undder \hyperref[metriken_wer]{Word Error Rate} berechnet.
|
||||
|
||||
Auf Basis der Daten in \autoref{tbl:report_summary_wer}, \autoref{tbl:report_summary_cer} und \autoref{tbl:report_summary_time} lässt sich der Gesamterfolg der Bildvorbereitung \bzw der darauf folgenden Filterung feststellen.
|
||||
|
||||
Beispielsweise eignet sich die Dreiecks-Schwellenwertmethode, wie in \autoref{thresholding_triangle} vermutet, nicht für die Texterkennung. In der Detailübersicht zeigt sich, dass für die Bilder oft ein Schwellenwert gewählt wurde, der die Texterkennung unmöglich macht. Bei Anwendung des fixen Schwellenwertverfahrens werden mit dem richtigen Schwellenwert durchschnittlich sehr gute Ergebnisse erzielt \bzw beim Verfahren nach Otsu oft ein geeigneter Schwellenwert gewählt, wodurch ein gutes Ausgangsbild für die Texterkennung entsteht.
|
||||
Die Dreiecks-Schwellenwertmethode, wie in \autoref{thresholding_triangle} vermutet, eignet sich beispielsweise nicht für die Texterkennung. In der Detailübersicht zeigt sich, dass für die Bilder oft ein Schwellenwert gewählt wird, der die Texterkennung unmöglich macht. Bei Anwendung des fixen Schwellenwertverfahrens werden mit dem richtigen Schwellenwert durchschnittlich sehr gute Ergebnisse erzielt. Beim Verfahren nach Otsu wird oft ein geeigneter Schwellenwert gewählt, wodurch in den meisten Fällen ein gutes Ausgangsbild für die Texterkennung entsteht.
|
||||
|
||||
Während die Fehlerquoten der Texterkennung mit Vorbereitung der Daten die der Texterkennung ohne Vorbereitung in den meisten Fällen unterbieten, ist das Ergebnis insgesamt unzufriedenstellend. Selbst bei Verwendung des fixen Thresholdingverfahrens mit einem Schwellenwert von 40 \% werden durchschnittlich Ergebnisse mit einer Wortfehlerrate von mindestens 46 \% \bzw 1,5 falsch erkannten Zeichen pro Wort erreicht. Die relativ hohe Standardabweichung von 26 \% lässt auf eine hohe Streuung der Ergebnisdaten, also unregelmäßig gute Erfolge schließen.
|
||||
Obwohl die Fehlerquoten der Texterkennung mit Vorbereitung der Daten niedriger sind als die der Texterkennung ohne Vorbereitung, ist das Ergebnis insgesamt unzufriedenstellend. Selbst bei Verwendung des fixen Schwellenwertverfahrens mit einem Wert von 40 \% werden durchschnittlich Ergebnisse mit einer Wortfehlerrate von mindestens 46 \% \bzw 1,5 falsch erkannten Zeichen pro Wort erreicht. Die relativ hohe Standardabweichung von 26 \% lässt auf eine hohe Streuung der Ergebnisdaten, also unregelmäßig gute Erfolge schließen.
|
||||
|
||||
\begin{table}[!ht]
|
||||
\centering
|
||||
\input{include/figures/fig_WER_1}
|
||||
\caption{Auszug aus der "Processing Summary" Tabelle im generierten Bericht: Auflistung der Verfahren mit den durchschnittlich besten und schlechtesten Ergebnissen auf Basis der Word Error Rate. Die jeweilige Verarbeitungsmethode ist in der Spalte "Processor" zu finden, die Wortfehlerrate und die Standardabweichung in "Time" und "Deviation".}
|
||||
\caption{Auszug aus der "Processing Summary" Tabelle im generierten Bericht: Auflistung der Verfahren mit den durchschnittlich besten und schlechtesten Ergebnissen auf Basis der Word Error Rate. Die jeweilige Verarbeitungsmethode ist in der Spalte "Processor" zu finden, die Wortfehlerrate und die Standardabweichung in "Error" und "Deviation".}
|
||||
\label{tbl:report_summary_wer}
|
||||
\end{table}
|
||||
|
||||
\begin{table}[!ht]
|
||||
\centering
|
||||
\input{include/figures/fig_CER_1}
|
||||
\caption{Auszug aus der "Processing Summary" Tabelle im generierten Bericht: Auflistung der Verfahren mit den durchschnittlich besten und schlechtesten Ergebnissen auf Basis der Character Error Rate. Die jeweilige Verarbeitungsmethode ist in der Spalte "Processor" zu finden, die Zeichenfehlerrate und die Standardabweichung in "Time" und "Deviation".}
|
||||
\caption{Auszug aus der "Processing Summary" Tabelle im generierten Bericht: Auflistung der Verfahren mit den durchschnittlich besten und schlechtesten Ergebnissen auf Basis der Character Error Rate. Die jeweilige Verarbeitungsmethode ist in der Spalte "Processor" zu finden, die Zeichenfehlerrate und die Standardabweichung in "Changes" und "Deviation".}
|
||||
\label{tbl:report_summary_cer}
|
||||
\end{table}
|
||||
|
||||
@@ -1,18 +1,8 @@
|
||||
\chapter{Zusammenfassung}
|
||||
\label{zusammenfassung}
|
||||
|
||||
\section{Fazit}
|
||||
Im Rahmen dieser Bachelorarbeit setzt sich mit der Anwendung von optischer Texterkennung für die Verschlagwortung von Oberflächenscreenshots auseinandergesetzt. Das Ziel, eine Vorgehensweise für die automatisierte Verschlagwortung von Bilddateien zu entwickeln und die Anwendbarkeit verschiedener Algorithmen zur Bildbearbeitung und Texterkennung zu evaluieren, wurde erreicht. Insgesamt wurden die Grundlagen moderner Bildverarbeitung \bzw der Funktionsweise von Texterkennungssystemen aufgearbeitet. Das Ergebnis ist ein universelles System zur Analyse der Vergleichswerte, das auch die Integration weiterer Algorithmen ermöglicht. Dies erlaubt eine kontinuierliche Verbesserung und Anpassung des Texterkennungssystems an neue Anforderungen.
|
||||
|
||||
Im Rahmen dieser Bachelorarbeit wurde sich intensiv mit der Anwendung von optischer Texterkennung für die Verschlagwortung von Oberflächenscreenshots auseinandergesetzt.
|
||||
Aufgrund der Auswahl und Parametrisierung der ersten Tests beträgt die resultierende Fehlerrate in etwa 40\%. Nach Abschluss der Bachelorarbeit wird es weitere Optimierungsversuche geben. Das nächste Ziel ist es, eine Wortfehlerrate von 20\% nicht zu überschreiten, um eine zuverlässige Erkennung der Texte zu gewährleisten. Dazu werden weitere Bildbearbeitungsmethoden, beispielsweise Kantendetektoren \mcite{liu2006multiscale} in Verbindung mit sogenanntem "Fuzzy Matching" \mcite{cayrol1982fuzzy} für die Erkennung der Schlagworte verwendet. Ebenso gibt es unter Verwendung der bereits implementierten Algorithmen noch Verbesserungspotential. Beispielsweise könnten mehrfach gefundene Wörter, die in der aktuellen Version des Prototyps einfach verworfen werden, zur Ermittlung der Wichtigkeit eines Schlagwortes genutzt werden.
|
||||
|
||||
Das Ziel, eine Vorgehensweise für die automatisierte Verschlagwortung von Bilddateien zu entwickeln und die Anwendbarkeit verschiedener Algorithmen zur Bildbearbeitung und Texterkennung zu evaluieren, wurde erfolgreich umgesetzt. Obwohl die Wahl und Parametrisierung der ersten Tests, resultierend in einer Fehlerrate von ca. 40\%, noch Raum für Verbesserungen bieten, wurde ein universelles System zur Analyse der Vergleichswerte geschaffen, das auch die Integration weiterer Algorithmen ermöglicht. Dies erlaubt eine kontinuierliche Verbesserung und Anpassung des Texterkennungssystems an neue Anforderungen.
|
||||
|
||||
\section{Erkenntnisse}
|
||||
|
||||
Durch die detaillierte Auseinandersetung mit den unterschiedlichen Bild- und Textverarbeitungsverfahren und dem Vergleich mittels diverser Metriken habe ich ein besseres Verständnis für die Bildverarbeitung und die Funktionsweise von Texterkennungssystemen erlangt. Dieses gewonnene Wissen wird weiter in den Screenshot-Manager einfließen und möglicherweise auch in zukünftigen Kundenprojekten mit Fokus auf optischer Texterkennung Anwendung finden.
|
||||
|
||||
\section{Nächste Schritte und Ausblick}
|
||||
|
||||
Nach Abschluss der Bachelorarbeit wird die Texterkennungsfunktionalität in das Screenshot-Manager Tool integriert. Durch Verwendung der entwickelten Bibliotheken bleibt das System konfigurierbar und kann weiter optimiert werden. Das nächste Ziel ist es, eine Wortfehlerrate von 20\% nicht zu überschreiten, um eine zuverlässige Erkennung der Textdaten zu gewährleisten. Dazu werden weitere Bildbearbeitungsmethoden, beispielsweise Kantendetektoren, in Verbindung mit sogenanntem "Fuzzy Matching" für die Erkennung der Schlagworte verwendet.
|
||||
|
||||
Ich freue mich bereits darauf, meinen Kollegen den Arbeitsalltag durch die Verwendung der Texterkennungsfunktionalität im Screenshot-Manager ein wenig zu erleichtern.
|
||||
Nach Abschluss der Optimierungsversuche wird das gewonnene Wissen weiter in den Schreenshot-Manager einfließen und die Texterkennungsfunktionalität in das Programm integriert. Die gefundenen mehrsprachigen Schlagworte werden in Zukunft für jedes Bild ermittelt und in einer Datenbank abgelegt, um ein einfaches und effizientes Suchen innerhalb der Anwendung zu ermöglichen.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 4.8 KiB After Width: | Height: | Size: 5.7 KiB |
@@ -1,12 +1,12 @@
|
||||
\begin{tabular}{|l|c|c|}
|
||||
\hline
|
||||
\textbf{Image} & \textbf{Preview} & \textbf{Distance} \\ \hline
|
||||
zrs\_ZAMS\_scatter\_002.png & \includegraphics[width=3cm,height=2cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.zrs\_ZAMS\_scatter\_002.png}} & 0,09 \\ \hline
|
||||
command-pro...oup\_005.png & \includegraphics[width=3cm,height=2cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.command-processing\_screentypes\_controlgroup\_005.png}} & 0,11 \\ \hline
|
||||
historian\_a...ent\_001.png & \includegraphics[width=3cm,height=2cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.historian\_assistent\_001.png}} & 0,19 \\ \hline
|
||||
runtime\_fun...ate\_002.png & \includegraphics[width=3cm,height=2cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.runtime\_function\_create\_002.png}} & 0,21 \\ \hline
|
||||
editor\_mult...ple\_007.png & \includegraphics[width=3cm,height=2cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.editor\_multimonitor\_example\_007.png}} & 1,00 \\ \hline
|
||||
report\_exam...ime\_001.png & \includegraphics[width=3cm,height=2cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.report\_example\_data-time\_001.png}} & 1,00 \\ \hline
|
||||
worldview\_z...eps\_001.png & \includegraphics[width=3cm,height=2cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.worldview\_zoom\_steps\_001.png}} & 1,00 \\ \hline
|
||||
zrs\_Metadat...les\_001.png & \includegraphics[width=3cm,height=2cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.zrs\_MetadataEditor\_variables\_001.png}} & 1,00 \\ \hline
|
||||
zrs\_ZAMS\_scatter\_002.png & \includegraphics[width=6cm,height=2.4cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.zrs\_ZAMS\_scatter\_002.png}} & 0,09 \\ \hline
|
||||
command-pro...oup\_005.png & \includegraphics[width=6cm,height=2.4cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.command-processing\_screentypes\_controlgroup\_005.png}} & 0,11 \\ \hline
|
||||
historian\_a...ent\_001.png & \includegraphics[width=6cm,height=2.4cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.historian\_assistent\_001.png}} & 0,19 \\ \hline
|
||||
runtime\_fun...ate\_002.png & \includegraphics[width=6cm,height=2.4cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.runtime\_function\_create\_002.png}} & 0,21 \\ \hline
|
||||
editor\_mult...ple\_007.png & \includegraphics[width=6cm,height=2.4cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.editor\_multimonitor\_example\_007.png}} & 1,00 \\ \hline
|
||||
report\_exam...ime\_001.png & \includegraphics[width=6cm,height=2.4cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.report\_example\_data-time\_001.png}} & 1,00 \\ \hline
|
||||
worldview\_z...eps\_001.png & \includegraphics[width=6cm,height=2.4cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.worldview\_zoom\_steps\_001.png}} & 1,00 \\ \hline
|
||||
zrs\_Metadat...les\_001.png & \includegraphics[width=6cm,height=2.4cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Kapur).00.zrs\_MetadataEditor\_variables\_001.png}} & 1,00 \\ \hline
|
||||
\end{tabular}
|
||||
|
||||
+8
-8
@@ -1,12 +1,12 @@
|
||||
\begin{tabular}{|l|c|c|c|c|c|}
|
||||
\hline
|
||||
\textbf{Processor} & \textbf{Elapsed} & \textbf{WER} & \textbf{CER (avg)} & \textbf{Matches} & \textbf{Image} \\ \hline
|
||||
ThresholdProcessor(30\%) & 0,6ms & 0,0\% & 0,00 & 9 / 9 & \includegraphics[width=2cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdProcessor(30\%).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
ThresholdProcessor(40\%) & 0,6ms & 0,0\% & 0,00 & 9 / 9 & \includegraphics[width=2cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdProcessor(40\%).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
ThresholdProcessor(70\%) & 0,7ms & 0,0\% & 0,00 & 9 / 9 & \includegraphics[width=2cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdProcessor(70\%).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
ThresholdProcessor(60\%) & 1,1ms & 0,0\% & 0,00 & 9 / 9 & \includegraphics[width=2cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdProcessor(60\%).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
ThresholdAd...ssor(12\_12) & 0,5ms & 77,8\% & 3,00 & 2 / 9 & \includegraphics[width=2cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdAdaptiveProcessor(12\_12).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
ThresholdAd...ssor(04\_04) & 1,0ms & 88,9\% & 3,22 & 1 / 9 & \includegraphics[width=2cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdAdaptiveProcessor(04\_04).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
ThresholdAd...ssor(08\_08) & 0,6ms & 100,0\% & 5,89 & 0 / 9 & \includegraphics[width=2cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdAdaptiveProcessor(08\_08).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
AutoThresho...r(Triangle) & 12,8ms & 100,0\% & 5,89 & 0 / 9 & \includegraphics[width=2cm,height=2cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Triangle).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
ThresholdProcessor(30\%) & 0,6ms & 0,0\% & 0,00 & 9 / 9 & \includegraphics[width=6cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdProcessor(30\%).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
ThresholdProcessor(40\%) & 0,6ms & 0,0\% & 0,00 & 9 / 9 & \includegraphics[width=6cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdProcessor(40\%).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
ThresholdProcessor(70\%) & 0,7ms & 0,0\% & 0,00 & 9 / 9 & \includegraphics[width=6cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdProcessor(70\%).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
ThresholdProcessor(60\%) & 1,1ms & 0,0\% & 0,00 & 9 / 9 & \includegraphics[width=6cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdProcessor(60\%).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
ThresholdAd...ssor(12\_12) & 0,5ms & 77,8\% & 3,00 & 2 / 9 & \includegraphics[width=6cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdAdaptiveProcessor(12\_12).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
ThresholdAd...ssor(04\_04) & 1,0ms & 88,9\% & 3,22 & 1 / 9 & \includegraphics[width=6cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdAdaptiveProcessor(04\_04).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
ThresholdAd...ssor(08\_08) & 0,6ms & 100,0\% & 5,89 & 0 / 9 & \includegraphics[width=6cm,height=2cm,keepaspectratio]{\detokenize{include/results/ThresholdAdaptiveProcessor(08\_08).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
AutoThresho...r(Triangle) & 12,8ms & 100,0\% & 5,89 & 0 / 9 & \includegraphics[width=6cm,height=2cm,keepaspectratio]{\detokenize{include/results/AutoThresholdProcessor(Triangle).00.command-processing\_screentypes\_controlgroup\_005.png}} \\ \hline
|
||||
\end{tabular}
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
flowchart LR
|
||||
OCR["Texterkennung\n(Tesseract)"]
|
||||
Pre -->|Bilddaten| OCR
|
||||
OCR -->|Schlagworte| Post
|
||||
Post -->|Schlagworte| Lookup
|
||||
Lookup -->|Schlagworte| Bericht
|
||||
|
||||
subgraph Pre[Vorverarbeitung]
|
||||
direction TB
|
||||
Pre1[Skalierung] --> Pre2
|
||||
Pre2[" ... "] --> Pre3
|
||||
Pre3[Binarisierung]
|
||||
end
|
||||
|
||||
subgraph Post[Nachbearbeitung]
|
||||
direction TB
|
||||
Post1[Normalisierung] --> Post2
|
||||
Post2[" ... "] --> Post3
|
||||
Post3[RegEx-Filterung]
|
||||
end
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 12 KiB |
@@ -0,0 +1,8 @@
|
||||
flowchart LR
|
||||
subgraph Post[Nachbearbeitung]
|
||||
direction LR
|
||||
Post1[Confidence-Filter] --> Post2
|
||||
Post2[Normalisieren] --> Post3
|
||||
Post3[Duplikatentfernung] --> Post4
|
||||
Post4[RegEx-Filterung]
|
||||
end
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 4.8 KiB |
@@ -0,0 +1,10 @@
|
||||
flowchart LR
|
||||
subgraph Pre[Vorverarbeitung]
|
||||
direction LR
|
||||
Pre1[Skalieren] --> Pre2
|
||||
Pre2[Normalisieren] --> Pre3
|
||||
Pre3[Thresholding] --> Pre4
|
||||
Pre4[Rand hinzufügen] --> Pre5
|
||||
Pre5[Binarisieren] --> Pre6
|
||||
Pre6[Negieren]
|
||||
end
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 5.5 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
Binary file not shown.
Binary file not shown.
@@ -16,6 +16,7 @@
|
||||
|
||||
\usepackage{nameref}
|
||||
\usepackage{hyperref}
|
||||
\usepackage{rotating}
|
||||
|
||||
% Enable to remove floats for testing
|
||||
|
||||
@@ -52,9 +53,9 @@
|
||||
|
||||
\newcommand*{\fullref}[1]{\hyperref[{#1}]{\autoref*{#1} \nameref*{#1}}}
|
||||
|
||||
\newcommand{\csharp}{C\#}
|
||||
\newcommand{\engl}[1]{engl. "#1"}
|
||||
\newcommand{\kurz}[1]{kurz: "#1"}
|
||||
\newcommand{\csharp}{C\#\ }
|
||||
\newcommand{\engl}[1]{engl. \textit{#1}}
|
||||
\newcommand{\kurz}[1]{kurz: \textit{#1}}
|
||||
\newcommand{\fluentcite}[1]{\citetitle{#1}, \citeauthor{#1} \citeyear{#1} \mcite{#1}}
|
||||
|
||||
%%%-----------------------------------------------------------------------------
|
||||
@@ -90,9 +91,9 @@
|
||||
\frontmatter % Titelei (röm. Seitenzahlen)
|
||||
%%%-----------------------------------------------------------------------------
|
||||
|
||||
\includepdf[pages=1-2]{include/title.pdf}
|
||||
\tableofcontents
|
||||
\includepdf[pages=1-2]{include/title/title.pdf}
|
||||
\include{chapters/c00_frontmatter/abstract/index}
|
||||
\tableofcontents
|
||||
|
||||
%%%-----------------------------------------------------------------------------
|
||||
\mainmatter % Hauptteil (ab hier arab. Seitenzahlen)
|
||||
@@ -102,12 +103,16 @@
|
||||
\include{chapters/c20_grundlagen/index}
|
||||
\include{chapters/c30_konzept/index}
|
||||
\include{chapters/c40_durchführung/index}
|
||||
\include{chapters/c50_evaluierung/index}
|
||||
\include{chapters/c80_zusammenfassung/index}
|
||||
|
||||
%%%-----------------------------------------------------------------------------
|
||||
\backmatter % Schlussteil (Quellenverzeichnis und dgl.)
|
||||
%%%-----------------------------------------------------------------------------
|
||||
|
||||
\listoffigures
|
||||
\listoftables
|
||||
|
||||
\MakeBibliography % Quellenverzeichnis
|
||||
|
||||
%%%-----------------------------------------------------------------------------
|
||||
|
||||
+335
-311
@@ -1,56 +1,72 @@
|
||||
@book{2007Crs,
|
||||
title = {Character recognition systems : a guide for students and practioners},
|
||||
author = {Cheriet, Mohamed},
|
||||
year = 2007,
|
||||
isbn = 9780471415701,
|
||||
url = {https://permalink.obvsg.at/fho/AC06408992},
|
||||
urldate = {2023-06-12},
|
||||
language = {eng},
|
||||
keywords = {Optical character recognition devices}
|
||||
@article{asif2014overview,
|
||||
title = {An overview and applications of optical character recognition},
|
||||
author = {Asif, AMAM and Hannan, Shaikh Abdul and Perwej, Yusuf and Vithalrao, Mane Arjun},
|
||||
year = 2014,
|
||||
journal = {International Journal of Advance Research In Science And Engineering},
|
||||
volume = 3,
|
||||
number = 7,
|
||||
urldate = {2024-02-18}
|
||||
}
|
||||
@book{2022Scas,
|
||||
title = {Soft computing and signal processing : : proceedings of 4th ICSCSP 2021},
|
||||
author = {Reddy, V. Sivakumar},
|
||||
year = 2022,
|
||||
series = {Advances in Intelligent Systems and Computing ;},
|
||||
isbn = {981-16-7088-9},
|
||||
url = {https://search-fho.obvsg.at/permalink/f/19351jn/FHO_alma5134174850004527},
|
||||
urldate = {2023-06-12},
|
||||
language = {eng},
|
||||
keywords = {Signal processing ; Congresses}
|
||||
}
|
||||
@book{BlahaMichael2013U:dm,
|
||||
title = {UML : database modeling workbook},
|
||||
author = {Blaha, Michael},
|
||||
year = 2013,
|
||||
isbn = 9781935504511,
|
||||
url = {https://permalink.obvsg.at/fho/AC11105171},
|
||||
urldate = {2023-06-12},
|
||||
edition = {1. print..},
|
||||
@online{azurevision_home,
|
||||
title = {Azure AI Vision - Homepage},
|
||||
author = {Microsoft Corporation},
|
||||
url = {https://azure.microsoft.com/en-us/products/ai-services/ai-vision},
|
||||
urldate = {2024-02-18},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@book{BoochGrady1999Tuml,
|
||||
title = {The unified modeling language user guide : UML},
|
||||
author = {Booch, Grady},
|
||||
year = 1999,
|
||||
series = {Addison-Wesley object technology series},
|
||||
isbn = {0201571684},
|
||||
url = {https://permalink.obvsg.at/fho/AC08768402},
|
||||
urldate = {2023-06-12},
|
||||
edition = {3. print..},
|
||||
language = {eng},
|
||||
keywords = {Computer software ; Development}
|
||||
@online{azurevision_pricing,
|
||||
title = {Azure AI Vision - Pricing},
|
||||
author = {Microsoft Corporation},
|
||||
url = {https://azure.microsoft.com/en-gb/pricing/details/cognitive-services/computer-vision/},
|
||||
urldate = {2024-02-18},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@book{ChaudhuriArindam2017OCRS,
|
||||
title = {Optical Character Recognition Systems for Different Languages with Soft Computing},
|
||||
author = {Chaudhuri, Arindam},
|
||||
year = 2017,
|
||||
series = {Studies in Fuzziness and Soft Computing 352},
|
||||
isbn = 9783319502526,
|
||||
url = {https://permalink.obvsg.at/fho/AC12323924},
|
||||
urldate = {2023-06-12},
|
||||
language = {eng},
|
||||
keywords = {Engineering}
|
||||
@image{bimodal-histogram,
|
||||
title = {Example of a histogram exhibiting bimodalty},
|
||||
author = {Wikimedia Commons},
|
||||
year = 2014,
|
||||
url = {https://commons.wikimedia.org/wiki/File:Bimodal-histogram.png},
|
||||
urldate = {2024-02-18}
|
||||
}
|
||||
@inbook{cc_platforms_comparison,
|
||||
title = {Comparison of Different Cloud Computing Platforms for Data Analytics},
|
||||
author = {Gupta, Urvashi and Sharma, Rohit},
|
||||
year = 2023,
|
||||
month = {09},
|
||||
doi = {10.1007/978-981-99-3716-5_7},
|
||||
isbn = {978-981-99-3715-8}
|
||||
}
|
||||
@article{chowdhary2020natural,
|
||||
title = {Natural language processing},
|
||||
author = {Chowdhary, K.R.},
|
||||
year = 2020,
|
||||
journal = {Fundamentals of artificial intelligence},
|
||||
publisher = {Springer}
|
||||
}
|
||||
@article{church1995,
|
||||
title = {Commercial Applications of Natural Language Processing},
|
||||
author = {Church, Kenneth W. and Rau, Lisa F.},
|
||||
year = 1995,
|
||||
journal = {Commun. ACM},
|
||||
publisher = {Association for Computing Machinery},
|
||||
address = {New York, NY, USA},
|
||||
volume = 38,
|
||||
number = 11,
|
||||
doi = {church1995},
|
||||
issn = {0001-0782},
|
||||
url = {https://doi.org/church1995},
|
||||
urldate = {2024-02-18},
|
||||
numpages = 9
|
||||
}
|
||||
@online{copa-data_zenon,
|
||||
title = {COPA-DATA zenon - Homepage},
|
||||
author = {Ing. Punzenberger COPA-DATA GmbH},
|
||||
url = {https://www.copadata.com/en/product/zenon-software-platform-for-industrial-automation-energy-automation/},
|
||||
urldate = {2024-02-18},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@book{DingXiaoqing2012AiCR,
|
||||
title = {Advances in Character Recognition},
|
||||
@@ -60,150 +76,10 @@
|
||||
doi = {10.5772/2575},
|
||||
isbn = {953-51-5669-1},
|
||||
url = {https://www.intechopen.com/books/2182},
|
||||
urldate = {2023-06-12},
|
||||
abstract = {This book presents advances in character recognition, and it consists of 12 chapters that cover wide range of topics on different aspects of character recognition. Hopefully, this book will serve as a reference source for academic research, for professionals working in the character recognition field and for all interested in the subject.},
|
||||
urldate = {2024-02-18},
|
||||
language = {eng},
|
||||
keywords = {Optical character recognition}
|
||||
}
|
||||
@book{HayDavidC2011U,
|
||||
title = {UML \& data modeling : a reconciliation},
|
||||
author = {Hay, David C},
|
||||
year = 2011,
|
||||
isbn = 1935504193,
|
||||
url = {https://permalink.obvsg.at/fho/YC00337386},
|
||||
urldate = {2023-06-12},
|
||||
language = {eng},
|
||||
keywords = {Data structures (Computer science)}
|
||||
}
|
||||
@inproceedings{Hyyr2003PracticalMF,
|
||||
title = {Practical Methods for Approximate String Matching},
|
||||
author = {Heikki Hyyr{\"o}},
|
||||
year = 2003,
|
||||
url = {https://www.semanticscholar.org/paper/Practical-Methods-for-Approximate-String-Matching-Hyyr%C3%B6/3b2227ae166cbe90b20408da3f2feb75f95afd9c},
|
||||
urldate = {2023-06-12}
|
||||
}
|
||||
@book{KemperAlfons2015D:eE,
|
||||
title = {Datenbanksysteme : eine Einführung},
|
||||
author = {Kemper, Alfons},
|
||||
year = 2015,
|
||||
series = {De-Gruyter-Oldenbourg-Studium},
|
||||
isbn = 9783110443752,
|
||||
url = {https://permalink.obvsg.at/fho/AC12661940},
|
||||
urldate = {2023-06-12},
|
||||
edition = {10., aktualisierte u. erw. Aufl..},
|
||||
language = {ger},
|
||||
keywords = {Datenbanksystem}
|
||||
}
|
||||
@article{Navarro2000,
|
||||
title = {A Guided Tour to Approximate String Matching},
|
||||
author = {Navarro, Gonzalo},
|
||||
year = 2000,
|
||||
month = {04},
|
||||
journal = {ACM Computing Surveys},
|
||||
volume = 33,
|
||||
doi = {10.1145/375360.375365},
|
||||
url = {https://www.researchgate.net/publication/2375410_A_Guided_Tour_to_Approximate_String_Matching},
|
||||
urldate = {2023-06-12}
|
||||
}
|
||||
@book{SaakeGunter2011D-I:,
|
||||
title = {Datenbanken - Implementierungstechniken : [Architekturprinzipien, Datenstrukturen und Algorithmen, Transaktionsverwaltung und Recovery]},
|
||||
author = {Saake, Gunter},
|
||||
year = 2011,
|
||||
isbn = 9783826691560,
|
||||
url = {https://permalink.obvsg.at/fho/AC08815950},
|
||||
urldate = {2023-06-12},
|
||||
edition = {3. Aufl..},
|
||||
language = {ger},
|
||||
keywords = {Datenbanksystem}
|
||||
}
|
||||
@inproceedings{Smith2007,
|
||||
title = {An Overview of the Tesseract OCR Engine},
|
||||
author = {Smith R.},
|
||||
url = {https://ieeexplore.ieee.org/document/4376991},
|
||||
urldate = {2023-06-12},
|
||||
date = 2007,
|
||||
langid = {ngerman}
|
||||
}
|
||||
@online{tessdoc,
|
||||
title = {Tesseract Documentation},
|
||||
url = {https://tesseract-ocr.github.io/},
|
||||
urldate = {2023-06-12},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{imagemagick,
|
||||
title = {ImageMagick Homepage},
|
||||
url = {https://www.imagemagick.org/},
|
||||
urldate = {2023-06-12},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{textract_pricing,
|
||||
title = {Amazon Textract - Pricing},
|
||||
url = {https://aws.amazon.com/textract/pricing/},
|
||||
urldate = {2023-06-12},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{gcv_pricing,
|
||||
title = {Google Cloud Vision - Pricing},
|
||||
url = {https://cloud.google.com/vision/pricing},
|
||||
urldate = {2023-06-12},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{azurevision_pricing,
|
||||
title = {Azure AI Vision - Pricing},
|
||||
url = {https://azure.microsoft.com/en-gb/pricing/details/cognitive-services/computer-vision/},
|
||||
urldate = {2023-06-12},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{tessrepo,
|
||||
title = {Tesseract Repository},
|
||||
url = {https://github.com/tesseract-ocr/tesseract},
|
||||
urldate = {2024-01-04},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@article{asif2014overview,
|
||||
title = {An overview and applications of optical character recognition},
|
||||
author = {Asif, AMAM and Hannan, Shaikh Abdul and Perwej, Yusuf and Vithalrao, Mane Arjun},
|
||||
year = 2014,
|
||||
journal = {Int. J. Adv. Res. Sci. Eng},
|
||||
volume = 3,
|
||||
number = 7,
|
||||
pages = {261--274}
|
||||
}
|
||||
@inbook{cc_platforms_comparison,
|
||||
title = {“Comparison of Different Cloud Computing Platforms for Data Analytics”},
|
||||
author = {Gupta, Urvashi and Sharma, Rohit},
|
||||
year = 2023,
|
||||
month = {09},
|
||||
pages = {67--78},
|
||||
doi = {10.1007/978-981-99-3716-5_7},
|
||||
isbn = {978-981-99-3715-8}
|
||||
}
|
||||
@online{tessdoc,
|
||||
title = {Tesseract Documentation},
|
||||
url = {https://tesseract-ocr.github.io/},
|
||||
urldate = {2023-06-12},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@inproceedings{the_old_bailey_and_ocr,
|
||||
title = {The Old Bailey and OCR: Benchmarking AWS, Azure, and GCP with 180,000 Page Images},
|
||||
author = {William Ughetta and Kernighan, {Brian W.}},
|
||||
year = 2020,
|
||||
month = sep,
|
||||
day = 29,
|
||||
booktitle = {Proceedings of the ACM Symposium on Document Engineering, DocEng 2020},
|
||||
publisher = {Association for Computing Machinery, Inc},
|
||||
series = {Proceedings of the ACM Symposium on Document Engineering, DocEng 2020},
|
||||
doi = {10.1145/3395027.3419595},
|
||||
keywords = {Amazon Web Services, Google Cloud Platform, Historical Documents, Microsoft Azure, Old Bailey, Optical Character Recognition},
|
||||
language = {English (US)}
|
||||
}
|
||||
@article{eikvil1993optical,
|
||||
title = {Optical character recognition},
|
||||
author = {Eikvil, Line},
|
||||
@@ -211,71 +87,217 @@
|
||||
journal = {citeseer. ist. psu. edu/142042. html},
|
||||
volume = 26
|
||||
}
|
||||
@online{gcv_home,
|
||||
title = {Google Cloud Vision - Homepage},
|
||||
author = {Google LLC},
|
||||
url = {https://cloud.google.com/vision},
|
||||
urldate = {2024-02-18},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{gcv_pricing,
|
||||
title = {Google Cloud Vision - Pricing},
|
||||
author = {Google LLC},
|
||||
url = {https://cloud.google.com/vision/pricing},
|
||||
urldate = {2024-02-18},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{imagemagick,
|
||||
title = {ImageMagick Homepage},
|
||||
author = {ImageMagick Studio LLC},
|
||||
url = {https://www.imagemagick.org/},
|
||||
urldate = {2024-02-18},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{ironocr_home,
|
||||
title = {IronOCR for .NET - Homepage},
|
||||
author = {Iron Software LLC},
|
||||
url = {https://ironsoftware.com/csharp/ocr/},
|
||||
urldate = {2024-02-18},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{anyline_home,
|
||||
title = {Anyline - Homepage},
|
||||
author = {Anyline GmbH},
|
||||
url = {https://anyline.com},
|
||||
urldate = {2024-02-18},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{nuget_magicknet,
|
||||
title = {Magick.NET - NuGet},
|
||||
url = {https://www.nuget.org/packages/Magick.NET.Core},
|
||||
urldate = {2024-02-18},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{nuget_tesseract,
|
||||
title = {Tesseract - NuGet},
|
||||
url = {https://www.nuget.org/packages/Tesseract},
|
||||
urldate = {2024-02-18},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@article{islam2017survey,
|
||||
title = {A survey on optical character recognition systems},
|
||||
author = {Islam, Islam, Noor},
|
||||
author = {Islam, Noman and Islam, Zeeshan and Noor, Nazia},
|
||||
year = 2017,
|
||||
journal = {arXiv preprint arXiv:1710.05703}
|
||||
}
|
||||
@article{chowdhary2020natural,
|
||||
title = {Natural language processing},
|
||||
author = {Chowdhary, KR1442 and Chowdhary, KR},
|
||||
year = 2020,
|
||||
journal = {Fundamentals of artificial intelligence},
|
||||
publisher = {Springer},
|
||||
pages = {603--649}
|
||||
}
|
||||
@article{10.1145/219717.219778,
|
||||
title = {Commercial Applications of Natural Language Processing},
|
||||
author = {Church, Kenneth W. and Rau, Lisa F.},
|
||||
year = 1995,
|
||||
month = {nov},
|
||||
journal = {Commun. ACM},
|
||||
publisher = {Association for Computing Machinery},
|
||||
address = {New York, NY, USA},
|
||||
volume = 38,
|
||||
number = 11,
|
||||
pages = {71–79},
|
||||
doi = {10.1145/219717.219778},
|
||||
issn = {0001-0782},
|
||||
url = {https://doi.org/10.1145/219717.219778},
|
||||
issue_date = {Nov. 1995},
|
||||
numpages = 9
|
||||
journal = {arXiv preprint},
|
||||
url = {https://doi.org/10.48550/arXiv.1710.05703},
|
||||
urldate = {2024-02-18}
|
||||
}
|
||||
@article{kalyanathaya2019advances,
|
||||
title = {Advances in natural language processing--a survey of current research trends, development tools and industry applications},
|
||||
title = {Advances in natural language processing: a survey of current research trends, development tools and industry applications},
|
||||
author = {Kalyanathaya, Krishna Prakash and Akila, D and Rajesh, P},
|
||||
year = 2019,
|
||||
journal = {International Journal of Recent Technology and Engineering},
|
||||
volume = 7,
|
||||
number = {5C},
|
||||
pages = {199--202}
|
||||
number = {5C}
|
||||
}
|
||||
@inproceedings{tong1996statistical,
|
||||
title = {A statistical approach to automatic OCR error correction in context},
|
||||
author = {Tong, Xiang and Evans, David A},
|
||||
year = 1996,
|
||||
booktitle = {Fourth workshop on very large corpora}
|
||||
@article{kapur1985new,
|
||||
title = {A new method for gray-level picture thresholding using the entropy of the histogram},
|
||||
author = {Kapur, Jagat Narain and Sahoo, Prasanna K and Wong, Andrew KC},
|
||||
year = 1985,
|
||||
journal = {Computer vision, graphics, and image processing},
|
||||
publisher = {Elsevier},
|
||||
volume = 29,
|
||||
number = 3
|
||||
}
|
||||
@inproceedings{karpinski2018metrics,
|
||||
title = {Metrics for complete evaluation of ocr performance},
|
||||
author = {Karpinski, Romain and Lohani, Devashish and Belaid, Abdel},
|
||||
year = 2018,
|
||||
booktitle = {IPCV'18-The 22nd Int'l Conf on Image Processing, Computer Vision, \& Pattern Recognition}
|
||||
}
|
||||
@article{approximate_string_matching,
|
||||
title = {A Guided Tour to Approximate String Matching},
|
||||
author = {Navarro, Gonzalo},
|
||||
year = 2000,
|
||||
month = {04},
|
||||
journal = {ACM Computing Surveys},
|
||||
volume = 33,
|
||||
pages = {},
|
||||
doi = {10.1145/375360.375365}
|
||||
booktitle = {IPCV'18 - The 22nd Int'l Conf on Image Processing, Computer Vision, \& Pattern Recognition},
|
||||
url = {https://inria.hal.science/hal-01981731}
|
||||
}
|
||||
@inproceedings{levenshtein1966binary,
|
||||
title = {Binary codes capable of correcting deletions, insertions, and reversals},
|
||||
author = {and others}
|
||||
author = {Levenshtein, Vladimir I and others},
|
||||
year = 1966,
|
||||
booktitle = {Soviet physics doklady},
|
||||
volume = 10,
|
||||
number = 8,
|
||||
pages = {707--710},
|
||||
organization = {Soviet Union}
|
||||
}
|
||||
@article{mursari2021effectiveness,
|
||||
title = {The effectiveness of image preprocessing on digital handwritten scripts recognition with the implementation of OCR Tesseract},
|
||||
author = {Mursari, Lily Rojabiyati and Wibowo, Antoni},
|
||||
year = 2021,
|
||||
journal = {Computer Engineering and Applications Journal},
|
||||
volume = 10,
|
||||
number = 3
|
||||
}
|
||||
@article{otsu1979threshold,
|
||||
title = {A threshold selection method from gray-level histograms},
|
||||
author = {Otsu, Nobuyuki},
|
||||
year = 1979,
|
||||
journal = {IEEE transactions on systems, man, and cybernetics},
|
||||
publisher = {IEEE},
|
||||
volume = 9,
|
||||
number = 1,
|
||||
doi = {10.1109/TSMC.1979.4310076},
|
||||
url = {https://ieeexplore.ieee.org/document/4310076},
|
||||
urldate = {2024-02-18}
|
||||
}
|
||||
@inproceedings{park2008empirical,
|
||||
title = {An empirical analysis of word error rate and keyword error rate.},
|
||||
author = {Park, Youngja and Patwardhan, Siddharth and Visweswariah, Karthik and Gates, Stephen C},
|
||||
year = 2008,
|
||||
month = 9,
|
||||
doi = {10.21437/Interspeech.2008-537}
|
||||
}
|
||||
@article{sahoo1988survey,
|
||||
title = {A survey of thresholding techniques},
|
||||
author = {Sahoo, Prasanna K and Soltani, SAKC and Wong, Andrew KC},
|
||||
year = 1988,
|
||||
journal = {Computer vision, graphics, and image processing},
|
||||
publisher = {Elsevier},
|
||||
volume = 41,
|
||||
number = 2
|
||||
}
|
||||
@inproceedings{Smith2007,
|
||||
title = {An Overview of the Tesseract OCR Engine},
|
||||
author = {Smith, Ray},
|
||||
booktitle = {Ninth international conference on document analysis and recognition (ICDAR 2007)},
|
||||
volume = 2,
|
||||
url = {https://ieeexplore.ieee.org/document/4376991},
|
||||
urldate = {2024-02-18},
|
||||
date = 2007,
|
||||
organization = {IEEE},
|
||||
langid = {ngerman}
|
||||
}
|
||||
@article{sporici2020improving,
|
||||
title = {Improving the accuracy of Tesseract 4.0 OCR engine using convolution-based preprocessing},
|
||||
author = {Sporici, Dan and Cușnir, Elena and Boiangiu, Costin-Anton},
|
||||
year = 2020,
|
||||
journal = {Symmetry},
|
||||
publisher = {MDPI},
|
||||
volume = 12,
|
||||
number = 5
|
||||
}
|
||||
@online{tessdoc,
|
||||
title = {Tesseract Documentation},
|
||||
url = {https://tesseract-ocr.github.io/},
|
||||
urldate = {2024-02-18},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{tessrepo,
|
||||
title = {Tesseract Repository},
|
||||
author = {tesseract-ocr},
|
||||
url = {https://github.com/tesseract-ocr/tesseract},
|
||||
urldate = {2024-01-04},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{textract_home,
|
||||
title = {Amazon Textract - Homepage},
|
||||
author = {Amazon Web Services, Inc.},
|
||||
url = {https://aws.amazon.com/textract},
|
||||
urldate = {2024-02-18},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@online{textract_pricing,
|
||||
title = {Amazon Textract - Pricing},
|
||||
author = {Amazon Web Services, Inc.},
|
||||
url = {https://aws.amazon.com/textract/pricing/},
|
||||
urldate = {2024-02-18},
|
||||
date = {2023-05-23},
|
||||
language = {eng}
|
||||
}
|
||||
@inproceedings{the_old_bailey_and_ocr,
|
||||
title = {The Old Bailey and OCR: Benchmarking AWS, Azure, and GCP with 180,000 Page Images},
|
||||
author = {William Ughetta and Kernighan, {Brian W.}},
|
||||
year = 2020,
|
||||
month = 9,
|
||||
day = 29,
|
||||
publisher = {Association for Computing Machinery, Inc},
|
||||
doi = {10.1145/3395027.3419595},
|
||||
keywords = {Amazon Web Services, Google Cloud Platform, Historical Documents, Microsoft Azure, Old Bailey, Optical Character Recognition},
|
||||
language = {English (US)}
|
||||
}
|
||||
@inproceedings{tong1996statistical,
|
||||
title = {A Statistical Approach to Automatic OCR Error Correction in Context},
|
||||
author = {Tong, Xiang and Evans, David A.},
|
||||
year = 1996,
|
||||
month = 6,
|
||||
booktitle = {Fourth Workshop on Very Large Corpora},
|
||||
publisher = {Association for Computational Linguistics},
|
||||
address = {Herstmonceux Castle, Sussex, UK},
|
||||
url = {https://aclanthology.org/W96-0108},
|
||||
editor = {Scott, Donia}
|
||||
}
|
||||
@image{unimodal-histogram,
|
||||
title = {Histogram of tips given in a restaurant},
|
||||
author = {Wikimedia Commons},
|
||||
year = 2014,
|
||||
url = {https://commons.wikimedia.org/wiki/File:Tips-histogram1.png},
|
||||
urldate = {2024-02-18}
|
||||
}
|
||||
@inproceedings{wang2003word,
|
||||
title = {Is word error rate a good indicator for spoken language understanding accuracy},
|
||||
@@ -285,87 +307,89 @@
|
||||
pages = {577--582},
|
||||
organization = {IEEE}
|
||||
}
|
||||
@inproceedings{park2008empirical,
|
||||
title = {An empirical analysis of word error rate and keyword error rate.},
|
||||
author = {Park, Youngja and Patwardhan, Siddharth and Visweswariah, Karthik and Gates, Stephen C},
|
||||
year = 2008,
|
||||
booktitle = {Interspeech},
|
||||
volume = 2008,
|
||||
pages = {2070--2073}
|
||||
}
|
||||
@article{sporici2020improving,
|
||||
title = {Improving the accuracy of Tesseract 4.0 OCR engine using convolution-based preprocessing},
|
||||
author = {Sporici, Dan and Cușnir, Elena and Boiangiu, Costin-Anton},
|
||||
year = 2020,
|
||||
journal = {Symmetry},
|
||||
publisher = {MDPI},
|
||||
volume = 12,
|
||||
number = 5,
|
||||
pages = 715
|
||||
}
|
||||
@article{mursari2021effectiveness,
|
||||
title = {The effectiveness of image preprocessing on digital handwritten scripts recognition with the implementation of OCR Tesseract},
|
||||
author = {Mursari, Lily Rojabiyati and Wibowo, Antoni},
|
||||
year = 2021,
|
||||
journal = {Computer Engineering and Applications Journal},
|
||||
volume = 10,
|
||||
number = 3,
|
||||
pages = {177--186}
|
||||
}
|
||||
@image{bimodal-histogram,
|
||||
author = "Wikimedia Commons",
|
||||
title = "Example of a histogram exhibiting bimodalty",
|
||||
year = "2014",
|
||||
urldate = {2023-06-12},
|
||||
url = "https://commons.wikimedia.org/wiki/File:Bimodal-histogram.png",
|
||||
@article{wilbur1992automatic,
|
||||
title = {The automatic identification of stop words},
|
||||
author = {Wilbur, W John and Sirotkin, Karl},
|
||||
year = 1992,
|
||||
journal = {Journal of information science},
|
||||
publisher = {Sage Publications Sage CA: Thousand Oaks, CA},
|
||||
volume = 18,
|
||||
number = 1
|
||||
}
|
||||
@article{zack1977automatic,
|
||||
title={Automatic measurement of sister chromatid exchange frequency.},
|
||||
author={Zack, Gregory W and Rogers, William E and Latt, Samuel A},
|
||||
journal={Journal of Histochemistry \& Cytochemistry},
|
||||
volume={25},
|
||||
number={7},
|
||||
pages={741--753},
|
||||
year={1977},
|
||||
publisher={SAGE Publications Sage CA: Los Angeles, CA}
|
||||
title = {Automatic measurement of sister chromatid exchange frequency.},
|
||||
author = {Zack, Gregory W and Rogers, William E and Latt, Samuel A},
|
||||
year = 1977,
|
||||
journal = {Journal of Histochemistry \& Cytochemistry},
|
||||
publisher = {SAGE Publications Sage CA: Los Angeles, CA},
|
||||
volume = 25,
|
||||
number = 7
|
||||
}
|
||||
@article{kapur1985new,
|
||||
title={A new method for gray-level picture thresholding using the entropy of the histogram},
|
||||
author={Kapur, Jagat Narain and Sahoo, Prasanna K and Wong, Andrew KC},
|
||||
journal={Computer vision, graphics, and image processing},
|
||||
volume={29},
|
||||
number={3},
|
||||
pages={273--285},
|
||||
year={1985},
|
||||
publisher={Elsevier}
|
||||
@inproceedings{seta2009digital,
|
||||
title={Digital image interpolation method using higher-order Hermite interpolating polynomials with compact finite-difference},
|
||||
author={Seta, Ryo and Okubo, Kan and Tagawa, Norio},
|
||||
booktitle={Proceedings: APSIPA ASC 2009: Asia-Pacific Signal and Information Processing Association, 2009 Annual Summit and Conference},
|
||||
pages={406--409},
|
||||
year={2009},
|
||||
organization={Asia-Pacific Signal and Information Processing Association}
|
||||
}
|
||||
@article{otsu1979threshold,
|
||||
title={A threshold selection method from gray-level histograms},
|
||||
author={Otsu, Nobuyuki},
|
||||
journal={IEEE transactions on systems, man, and cybernetics},
|
||||
volume={9},
|
||||
number={1},
|
||||
pages={62--66},
|
||||
year={1979},
|
||||
@article{briand2018theory,
|
||||
title={Theory and practice of image B-spline interpolation},
|
||||
author={Briand, Thibaud and Monasse, Pascal},
|
||||
journal={Image Processing On Line},
|
||||
volume={8},
|
||||
pages={99--141},
|
||||
year={2018}
|
||||
}
|
||||
@article{unser1999splines,
|
||||
title={Splines: A perfect fit for signal and image processing},
|
||||
author={Unser, Michael},
|
||||
journal={IEEE Signal processing magazine},
|
||||
volume={16},
|
||||
number={6},
|
||||
pages={22--38},
|
||||
year={1999},
|
||||
publisher={IEEE}
|
||||
}
|
||||
@article{sahoo1988survey,
|
||||
title={A survey of thresholding techniques},
|
||||
author={Sahoo, Prasanna K and Soltani, SAKC and Wong, Andrew KC},
|
||||
journal={Computer vision, graphics, and image processing},
|
||||
volume={41},
|
||||
@article{fadnavis2014image,
|
||||
title={Image interpolation techniques in digital image processing: an overview},
|
||||
author={Fadnavis, Shreyas},
|
||||
journal={International Journal of Engineering Research and Applications},
|
||||
volume={4},
|
||||
number={10},
|
||||
pages={70--73},
|
||||
year={2014}
|
||||
}
|
||||
@inproceedings{liu2006multiscale,
|
||||
title={Multiscale edge-based text extraction from complex images},
|
||||
author={Liu, Xiaoqing and Samarabandu, Jagath},
|
||||
booktitle={2006 IEEE International Conference on Multimedia and Expo},
|
||||
pages={1721--1724},
|
||||
year={2006},
|
||||
organization={IEEE}
|
||||
}
|
||||
@article{cayrol1982fuzzy,
|
||||
title={Fuzzy pattern matching},
|
||||
author={Cayrol, M and Farreny, H and Prade, H},
|
||||
journal={Kybernetes},
|
||||
volume={11},
|
||||
number={2},
|
||||
pages={233--260},
|
||||
year={1988},
|
||||
publisher={Elsevier}
|
||||
pages={103--116},
|
||||
year={1982},
|
||||
publisher={MCB UP Ltd}
|
||||
}
|
||||
@article{wilbur1992automatic,
|
||||
title={The automatic identification of stop words},
|
||||
author={Wilbur, W John and Sirotkin, Karl},
|
||||
journal={Journal of information science},
|
||||
volume={18},
|
||||
@article{rakshit2010recognition,
|
||||
title={Recognition of handwritten textual annotations using tesseract open source ocr engine for information just in time (ijit)},
|
||||
author={Rakshit, Sandip and Basu, Subhadip and Ikeda, Hisashi},
|
||||
journal={arXiv preprint arXiv:1003.5893},
|
||||
year={2010}
|
||||
}
|
||||
@article{kumar2017noise,
|
||||
title={Noise removal and filtering techniques used in medical images},
|
||||
author={Kumar, Nalin and Nachamai, M},
|
||||
journal={Oriental Journal of Computer Science and Technology},
|
||||
volume={10},
|
||||
number={1},
|
||||
pages={45--55},
|
||||
year={1992},
|
||||
publisher={Sage Publications Sage CA: Thousand Oaks, CA}
|
||||
pages={103--113},
|
||||
year={2017}
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user