Technical Sciences Brassersplein 2 2612 CT Delft Postbus 5050 2600 GB Delft
TNO-rapport
www.tno.nl T +31 88 866 70 00 F +31 88 866 70 57
[email protected]
FlashReader Tekstextractie uit Flashwebsites en beeldmateriaal van het internet
Datum
8 september 2011
Auteurs
TNO
Aantal pagina's Opdrachtgever Projectnaam Projectnummer
34 Ministerie van Veiligheid en Justitie / NCTV FlashReader & OCR voor OOV 053.01092
Alle rechten voorbehouden. Niets uit deze uitgave mag worden vermenigvuldigd en/of openbaar gemaakt door middel van druk, foto-kopie, microfilm of op welke andere wijze dan ook, zonder voorafgaande toestemming van TNO. Indien dit rapport in opdracht werd uitgebracht, wordt voor de rechten en verplichtingen van opdrachtgever en opdrachtnemer verwezen naar de Algemene Voorwaarden voor opdrachten aan TNO, dan wel de betreffende terzake tussen de partijen gesloten overeenkomst. Het ter inzage geven van het TNO-rapport aan direct belang-hebbenden is toegestaan. © 2012 TNO
TNO-rapport |
2 / 34
Managementsamenvatting Dit rapport presenteert de onderzoeksresultaten die voortvloeien uit het project FlashReader dat onderdeel is van het programma "Herkenning digitale informatie en fingerprinting" van de NCTV. Dit programma richt zich op de herkenning van relevante informatie in digitale bronnen. Een van de belangrijkste informatiebronnen voor maatschappelijke veiligheidsdoeleinden is het internet. Om zoveel mogelijk informatie van het internet te verkrijgen moet zoveel mogelijk tekst uit websites kunnen worden verkregen. In het geval van standaard websites is dat geen enkel probleem, maar zodra tekst is gevat in een Flash website of in beeldmateriaal, dan wordt het automatisch extraheren van tekst een stuk gecompliceerder. Dit rapport presenteert een inventarisatie van oplossingen en oplossingsrichtingen om deze tekst te uit het bronmateriaal te kunnen extraheren. De belangrijkste resultaten betreffen: Flash websites en tekst in beeldmateriaal zijn twee voorbeelden om tekstuele content te presenteren, waarvoor tekstextractie lastig is. Andere gecompliceerde voorbeelden zijn HTML5, Ajax of Java gebaseerde websites. Het aantal websites dat gebaseerd is op deze technologieën groeit, waardoor het extraheren van tekst voor steeds meer websites een probleem wordt. Een virtuele gebruiker die automatisch alle klikbare elementen aanklikt in een website die gebaseerd kan zijn op de verschillende technieken is een essentieel onderdeel om meer tekstuele informatie van websites te verkrijgen. Vervolgens is de vraag op welke wijze een website volledig is te indexeren. Deze virtuele gebruiker moet er uiteindelijk voor zorgen, dat zoveel mogelijk elementen van een website worden gedownload. Dit rapport concludeert dat een virtuele gebruiker die gebaseerd is op browsertechnologie de meest belovende benadering is. De virtuele gebruiker moet alle content downloaden, zodat vervolgens ieder element op eigen wijze kan worden verwerkt om tekst te extraheren. Voor HTML is dit proces bekend, voor Flash componenten kan de statische informatie eenvoudig verkregen worden door het Flash object te decompileren en in het geval van beeldmateriaal met tekst kan deze door middel van OCR worden verkregen. Het OCR onderzoek laat zien dat dit niet triviaal is. Tekst in beeldmateriaal kan goed herkend worden met bestaande OCR technologie als de tekst kenmerken heeft van een traditioneel tekst document. Dit betreft: computer lettertype, donkere tekst tegen een lichte achtergrond, horizontale oriëntatie van de regels en de karakters moeten voldoende resolutie hebben. Door middel van beeldverbetering kan de herkenningskwaliteit enorm toenemen. Dit rapport heeft laten zien dat veel tekst in beeldmateriaal op het internet te weinig resolutie heeft voor goede herkenning. Experimenten hebben laten zien dat opschalen van het beeldmateriaal met een factor 2 de herkenningskwaliteit kan doen verbeteren van 0% naar 100% correcte resultaten.
TNO-rapport |
3 / 34
Inhoudsopgave Managementsamenvatting ..................................................................................... 2 1
Inleiding .................................................................................................................... 4
2 2.1 2.2 2.3 2.4
Flash objecten en Flash gebruik ............................................................................ 6 Achtergrond van SWF ............................................................................................... 6 Statische en dynamische (tekstuele) content ............................................................ 7 Flash gebruik ............................................................................................................. 7 Conclusies ............................................................................................................... 10
3 3.1 3.2 3.3 3.4
Oplossingen voor tekstextractie uit SWF objecten ........................................... 11 Bestaande oplossingen ........................................................................................... 11 Virtual user – geautomatiseerd een website verkennen ......................................... 12 Virtual user – tekst extractie .................................................................................... 15 Conclusies met betrekking tot de oplossingsrichtingen........................................... 18
4 4.1 4.2 4.3
Tekst in afbeeldingen op het internet .................................................................. 19 Inventarisatie van tekst in afbeeldingen op het internet .......................................... 19 Contactinformatie in beeldmateriaal ........................................................................ 20 Conclusies ............................................................................................................... 21
5 5.1 5.2 5.3 5.4 5.5 5.6
Tekstextractie met OCR technologie ................................................................... 22 Introductie OCR technologie ................................................................................... 22 OCR technologie toegepast op de use-cases ......................................................... 23 Beeldverbetering voor optimaal OCR resultaat ....................................................... 26 Relevante instellingen in de OCR software ............................................................. 27 TNO research tooling............................................................................................... 28 Conclusies ............................................................................................................... 29
6 6.1 6.2 6.3
Tesseract of FineReader ....................................................................................... 30 Kwalitatieve vergelijking op basis van de use-case marktplaats ............................. 30 Vergelijking op basis van lettertype en lettergrootte voor de use-case B ............... 31 Conclusies en Uitdagingen ...................................................................................... 32
7
Conclusies .............................................................................................................. 34
TNO-rapport |
1
4 / 34
Inleiding Dat het Internet een zodanig gigantische omvang zou krijgen had eind jaren tachtig van de vorige eeuw waarschijnlijk niemand durven te voorspellen. Vandaag de dag zijn er wereldwijd meer dan 2 miljard mensen met toegang tot het internet. Het is daarom niet verbazingwekkend dat steeds meer mensen online activiteiten ontplooien. Helaas is een deel van deze activiteiten strafbaar. Internet recherche is erop gericht om strafbare activiteiten op het internet te identificeren en aan te pakken. Het is een relatief nieuwe vorm van recherche die binnen Nederland wordt uitgevoerd door enkele overheidsdiensten. Een belangrijke activiteit bij internet recherche is het onderzoeken en selecteren van websites die mogelijk in strijd zijn met de wet, of blijk geven van mogelijke strafbare feiten. Omdat het aantal websites dat bekeken moet worden gigantisch is, is het efficiënt om dit proces te automatiseren. Hiertoe worden vaak crawlers ingezet. Crawlers bezoeken op een systematische manier een website, bepalen alle links op de pagina en bezoeken vervolgens alle pagina’s waar naar verwezen wordt. Van elke bezochte pagina wordt de broncode geanalyseerd en eventueel opgeslagen. Tijdens de analyse van de broncode wordt de weergegeven tekst van de opmaak en programmacode gescheiden. De verkregen informatie wordt bijvoorbeeld gebruikt om website te classificeren als relevant voor een bepaalde case, zoals Figuur 1 illustreert.
WWW WWW
WWW WWW
WWW WWW
WWW internet
WWW
WWW
automatische identificatie van relevante websites Slim filter
WWW
WWW WWW Of handmatige identificatie van relevante websites (= duur)
WWW
WWW
automatische monitoring van veranderingen
Figuur 1. Internet recherche richt zich op het identificeren en monitoren van relevante websites (de rode www’s).
Het scheiden van de weergegeven tekst, ook wel parsen genoemd, is bij “kale” HTML pagina’s relatief eenvoudig. De opkomst van nieuwe technieken als AJAX, Flash en Silverlight zorgt ervoor dat steeds minder pagina’s door crawlers kunnen worden geparsed, waardoor de relevante informatie niet uit de pagina’s kan worden geëxtraheerd. We onderscheiden drie klassen van objecten waar crawlers niet zondermeer informatie uit kunnen extraheren: 1 HTML5 / AJAX pagina’s – dit zijn HTML pagina’s die veel gebruik maken van 2 JavaScript en dynamisch content laden en weergeven. 3 Rich Internet Applications (RIA’s) – dit zijn webapplicaties die veelal in de browser draaien met behulp van een speciale plugin. Voorbeelden zijn Adobe 4 5 6 Flash , JavaFX en Microsoft Silverlight . 1 2
http://dev.w3.org/html5/spec/Overview.html http://www.w3schools.com/js/default.asp
TNO-rapport |
5 / 34
Audiovisueel materiaal – dit zijn objecten zoals afbeeldingen, audio en video waarin de informatie niet tekstueel gerepresenteerd is.
Figuur 2. Website bezoekers “zien” teksten anders dan computers.
Het extraheren van informatie uit een pagina die veel gebruik maakt van JavaScript is lastig omdat de weergegeven informatie veelal niet aanwezig is in de broncode. In plaats daarvan wordt de informatie ingeladen op het moment dat de gebruiker de pagina bekijkt of ermee interacteert. Hetzelfde geldt voor Rich Internet Applications zoals Flash. Deze RIA’s hebben bovendien vaak een bestandsformaat dat niet tekstueel maar binair is waardoor zelfs de programmacode niet door de crawler te lezen is. De laatste klasse van objecten is slecht leesbaar voor crawlers omdat de tekst bijvoorbeeld is vastgelegd in pixels in plaats van door de computer leesbare karakters, zoals Figuur 2 laat zien. Het doel van dit onderzoek is te onderzoeken of met nieuwe technologie deze websites wel of gedeeltelijk geïndexeerd kunnen worden. Een groot aantal verschillende oplossingsrichtingen is mogelijk. Om enige richting te houden is gefocust op een aantal use-cases. De onderzoeksresultaten worden gepresenteerd aan de hand van zes onderzochte cases, waar bij iedere case een onderzoeksvraag centraal stond. Deze onderzoeksvragen betroffen: 1. Hoe wordt Flash gebruikt op een aantal Nederlandse internetpagina’s? 2. Wat zijn verschillende oplossingsrichtingen om een SWF object te indexeren? 3. Hoe wordt tekst gebruikt in beeldmateriaal op het internet? 4. Hoe kan tekst uit afbeeldingen geëxtraheerd worden met OCR technologie? 5. Wat is het verschil tussen Tesseract of FineReader, dus tussen open source of commerciële software?
3
http://nl.wikipedia.org/wiki/Rich_Internet_Application http://www.adobe.com/products/flashplayer/ 5 http://javafx.com/ 6 http://www.microsoft.com/silverlight/ 4
TNO-rapport |
2
6 / 34
Flash objecten en Flash gebruik Dit hoofdstuk geeft inzicht in de wijze waarop Flash objecten gemaakt worden en hoe deze gebruikt worden op het internet. Daartoe zijn twee cases onderzocht: auto websites en webshops. Deze verkregen inzichten maken het belang duidelijk van het extraheren van tekst uit Flash objecten.
2.1
Achtergrond van SWF Een SWF object is een bestand dat is bedoeld om op een zo compact (qua aantal bytes) mogelijke manier afbeeldingen, tekst, audio, video en animaties over het internet bij een gebruiker te krijgen. SWF bestanden zijn niet bedoeld om dit type content uit te wisselen tussen de makers ervan. Een SWF bestand wordt afgespeeld met behulp van de Adobe Flash Player of Adobe AIR software. Deze software kan gratis worden gedownload en gebruikt. De Adobe Flash Player is beschikbaar als stand-alone applicatie en als plugin voor alle gangbare webbrowsers. Adobe Integrated Runtime (AIR) is een platform onafhankelijke runtime environment primair bedoeld voor het uitvoeren van AIR applicaties. AIR applicaties zijn desktop applicaties die geïnstalleerd moeten worden, voordat ze gebruikt kunnen worden. Met AIR kunnen ook SWF objecten worden uitgevoerd.
Figuur 3: Verschillende manieren om SWF en AIR applicaties te creëren en uit te voeren
Er zijn verschillende manieren om SWF (en ook AIR) objecten te creëren. De twee meest gangbare applicaties die worden gebruikt voor het maken van Flash animaties en applicaties zijn Adobe Flash en Adobe Flex Builder (tegenwoordig Adobe Flash Builder genaamd). Adobe Flash wordt vooral gebruikt om Flash animaties te creëren en Adobe Flash Builder is beter geschikt om webapplicaties en cross-platform desktop applicaties te ontwikkelen. De wijze waarop het eindresultaat tot stand komt is heel verschillend. Met Flash Builder wordt de applicatie grotendeels geprogrammeerd, terwijl met Flash de animatie vooral wordt getekend en geanimeerd op een tijdslijn. Flash Builder maakt gebruik van Adobe’s Flex SDK, een software development kit om met behulp van ActionScript en MXML
TNO-rapport |
7 / 34
Flash applicaties te bouwen. Deze SDK is in 2008 door Adobe vrijgegeven in de open-source community. Onderdeel van de SDK is een compiler waarmee SWF objecten gecompileerd kunnen worden. De broncode van deze compiler is dus vrij 7 beschikbaar . Het beeld dat ontstaat op basis van onze inventarisatie is dat het aantal internet applicaties gebaseerd op Flex steigt, maar nog altijd verreweg het meerendeel van de SWF objecten is gebaseerd op Flash.
2.2
Statische en dynamische (tekstuele) content De informatie die wordt weergegeven door de Flash Player wanneer een SWF object wordt uitgevoerd is veelal een combinatie van statische en dynamische informatie. Statische informatie wordt aan een grafisch element zoals een tekstveld of button toegevoegd op het moment dat het Flashobject wordt gecreëerd (compiletime). Dynamische informatie is informatie die van buiten het Flashobject komt en wordt geladen en weergegeven op het moment dat het object wordt afgespeeld of naar aanleiding van een actie van een gebruiker (run-time). Deze informatie kan bestaan uit tekst, maar ook uit afbeeldingen of audiovisueel materiaal. Wanneer de informatie die door het SWF object moet worden weergegeven regelmatig veranderd, zoals bij het aanbod van artikelen in een webshop het geval is, dan wordt er veelal voor gekozen deze informatie dynamisch te maken. In dat geval leest het Flashobject de informatie veelal uit een database. Een andere reden om informatie dynamisch te downloaden is om de grootte van het SWF object in de hand te houden. Als bijvoorbeeld een grote hoeveelheid beeldmateriaal meegenomen moet worden, dan zorgt dat voor een groot SWF object, dat minder plezierig in gebruik is. Deze externe informatiebronnen zijn erg relevant en is het belangrijk om deze informatie te kunnen ontsluiten.
2.3
Flash gebruik Flash is een veel gebruikte techniek op het Internet. Meer dan 98% van de op het internet aangesloten desktop computers heeft een Flash Player geïnstalleerd. Daarnaast zijn meer dan 800 miljoen mobiele apparaten in staat om Flash af te 8 spelen . Om, zonder naar volledige representativiteit te streven, een indruk te krijgen van het gebruik van deze technologie, heeft TNO onderzocht hoe vaak Flash gebruikt wordt op websites van autohandelaren en webshops. Daarnaast is onderzocht om welk type SWF objecten het gaat en welke technologie is gebruikt om de SWF objecten te creëren. Omdat ook vaak standaard (open-source) Flash objecten en bibliotheken (libraries) worden gebruikt zijn deze ook meegenomen in de inventarisatie. Om inzichtelijk te maken hoe het Flash landschap eruit ziet zijn voor twee type websites: autohandelaren (4062 websites) en webwinkels (1052 websites), een groot aantal sites geanalyseerd en zijn alle Flashobjecten gedownload. Deze objecten zijn stuk voor stuk beoordeeld tot welke categorie dit Flash object behoord en of het object een standaard component betrof of gebruik maakt van bepaalde bibliotheken. Er is onderscheid gemaakt in de volgende 9 categorieën:
7 8
http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK http://www.adobe.com/devnet/swf.html
TNO-rapport |
8 / 34
1. Banner – Een Flash animatie waarin iets wordt aangeprijsd. Bevat vaak een soort logische verhaallijn. 2. Header – Een geanimeerde kop voor de website 3. Intro – Een animatie die de gebruiker verwelkomt en vervolgens doorstuurt naar de website 4. Movie / -player – Een Flash object dat een (streaming) video laat zien of bevat 5. Navigation – Een geanimeerd object dat wordt gebruikt om de gebruiker door de website te laten navigeren 6. Site – Een volledig in Flash gemaakte (veelal schermvullende) website 7. Slideshow / gallery / scroller – Een object dat achtereenvolgens (al dan niet dynamisch geladen) foto’s en afbeeldingen toont 8. Anders – Een Flash object dat niet in een van de hierboven genoemde categorieën valt, bijvoorbeeld een digitaal formulier of een countdown timer 9. Onbekend – Een flash object waarvan niet kon worden vastgesteld in welke van de hierboven genoemde categorieën het valt, omdat het bijvoorbeeld een error bevatte en niet kon worden afgespeeld
2.3.1
Case: autohandelaren Verschillende websites faciliteren de aankoop en verkoop van nieuwe en gebruikte auto’s. Een dergelijke website geeft overzicht van een groot aantal autobedrijven met links naar hun website. In april 2011 telde dit overzicht 4062 autobedrijven. Met 9 behulp van de website copier HTTrack zijn de Flash objecten op de websites van al deze bedrijven opgeslagen. Hierbij zijn alleen de SWF objecten op de homepage meegenomen. Dit resulteerde in een totaal van 1221 bestanden. Uit Tabel 1 blijkt dat het grootste deel van de SWF objecten op de homepages van de bezochte autobedrijven uit slideshows bestaat. Veel garagebedrijven geven hun bezoekers graag een indruk van het uitgebreide assortiment door foto’s in een slideshow te tonen. Ook headers worden veel gebruikt om mooie afbeeldingen van auto’s te presenteren. Uit de inventarisatie blijkt dat 2,5% van de Flash objecten een volledige Flash website betreft. Dit houdt in dat 14 van de 4062 (0.3%) autobedrijven een website heeft die volledig in Flash gemaakt is.
Tabel 1: Categorisatie SWF objecten op websites autobedrijven
Type Banner Header Intro Movie / -player Navigation Site Slideshow / gallery / scroller Anders Onbekend Totaal
9
http://www.httrack.com/
Aantal
Percentage 64 100 48 14 96 14 135 37 59 567
11,3 17,6 8,5 2,5 16,9 2,5 23,8 6,5 10,4 100
TNO-rapport |
2.3.2
9 / 34
Case: webshops Een tweede case die is onderzocht betreffen de webshops. Thuiswinkel.org behartigt de belangen van webshop eigenaren en heeft als een van haar doelen het vertrouwen in kopen op afstand te vergroten. Op de website van Thuiswinkel.org staat een overzicht van alle in totaal 1221 leden (in april 2011). Met behulp van HTTrack zijn de Flash objecten op de homepages van alle leden opgeslagen. Dit resulteerde in een totaal van 197 SWF bestanden. Deze bestanden zijn vervolgens handmatig geclassificeerd op basis van bron (Flex of Flash) en het type animatie. Tabel 2: Categorisatie SWF objecten van webshops
Type Banner Header Intro Movie / -player Navigation Site Slideshow / gallery / scroller Anders Onbekend Totaal
Aantal
Percentage 39 32 1 3 48 0 29 11 34 197
19,8 16,2 0,5 1,5 24,4 0 14,7 5,6 17,3 100
Tabel 2 laat zien dat op de websites van de onderzochte webshops vooral Flash wordt gebruikt voor navigatie en banners. Ook headers en slideshows komen veel voor. Het is opvallend dat er geen enkele webshop volledig in Flash gemaakt is, ondanks dat Flash zich daar uitstekend voor leent.
2.3.3
Standaard componenten Sommige functionaliteit, zoals het weergeven van een slideshow of het aftellen tot een bepaalde datum, is vrij generiek. Het Flashobject dat nodig is om de computer een set aan foto’s te laten presenteren is onafhankelijk van de foto’s die moeten worden weergegeven. Er zijn verschillende partijen die voor dergelijke doeleinden standaard componenten ontwikkelen en deze (gratis) aanbieden. Door het instellen van een paar parameters zijn deze componenten aan te passen op de website waarop ze gebruikt worden, zoals Figuur 4 laat zien. <embed src="imagerotator.swf" width="470" height="160" allowscriptaccess="always" allowfullscreen="true" flashvars="file=imagerotator.xml&transition=blocks" /> Figuur 4. HTML code voor het embedden van een standaard component
TNO-rapport |
10 / 34
Het is goed mogelijk om de informatie uit dergelijke objecten te halen, omdat exact bekend is hoe het object in elkaar zit. Het slideshow component Cu3er heeft bijvoorbeeld een parameter “xml_location” welke als waarde de locatie van het configuratie bestand krijgt. In dit configuratie bestand staan de adressen van alle weergegeven foto’s. c. b. a.
d.
e. f.
Figuur 5. Standaard componenten die veel gebruikt worden: a. Loader [ref]; Slide of image shows: b. DigRotate; c. Image Slider; d. Mono SlideShow; e. JW Image Rotator; f. JSN ImageShow.
Uit de casestudies blijkt dat de volgende standaard componenten regelmatig worden gebruikt (zie ook Figuur 5): Digrotate Cu3er ImageRotator ImageShow Loader Mono Slideshow Bz Animation Odo Counter
2.4
Conclusies Het feit dat 2,5% van de SWF objecten van autohandelaren een volledige website betreft is al significant. Daarnaast heeft 8,5% van deze bedrijven een Flashanimatie, voordat de site geopend wordt. Een crawler moet voorbij deze objecten, voordat de site daadwerkelijk geopend kan worden. Naast het gebruik van Flash is het belangrijk op te merken dat andere technologieën, zoals HTML5 en Silverlight groeien als middel om rich internet applications te ontwikkelen. Evenals voor Flash websites zijn deze op dit moment slecht te indexeren.
TNO-rapport |
3
11 / 34
Oplossingen voor tekstextractie uit SWF objecten Dit hoofdstuk presenteert verschillende oplossingsrichtingen voor de extractie van tekst uit een SWF object. Deze richtingen zijn gebaseerd op een aantal experimenten die zijn uitgevoerd door TNO en een workshop georganiseerd door 10 PSIC . Tijdens deze workshop zijn verschillende oplossingsrichtingen in kaart gebracht. De oplossingsrichtingen kunnen aangrijpen op verschillende systeem-, programma- of procesniveaus die bij het afspelen van een SWF object betrokken zijn, zoals het operating system, de webbrowser, de SWF player, het SWF object of verschillende mee te compileren componenten. Figuur 6 presenteert de geneste structuur van deze verschillende niveaus.
Componenten SWF object SWF player Webbrowser OS Client
Figuur 6. Verschillende oplossingsrichtingen kunnen op verschillende niveaus ingrijpen of aanhaken.
Dit hoofdstuk is als volgt georganiseerd. Eerst worden twee bestaande concepten gepresenteerd die een mogelijke oplossing zijn voor het extraheren van informatie uit SWF objecten. Deze oplossingen hebben echter verschillende beperkingen, waardoor alternatieve oplossingsrichtingen worden gepresenteerd voor een virtuele gebruiker die een volledige website bezoekt en vervolgens de tekst extraheert.
3.1
Bestaande oplossingen Er zijn twee oplossingsrichtingen die relevant zijn benoemen op dit punt. De methode die Google hanteert voor het indexeren van SWF objecten en Adobe Wallaby, een tool om Flash om te zetten naar HTML5 wordt toegelicht.
3.1.1
Adobe’s “headless Flash player” Voor veel eigenaren van websites is het bijzonder belangrijk dat gebruikers hun website kunnen vinden via de gangbare zoekmachines. Het werd dan ook als een nadeel van Flash applicaties gezien dat ze niet konden worden geïndexeerd. Voor Adobe was het belangrijk om dit probleem te verhelpen en ze hebben daarom in samenwerking met Google aan een oplossing gewerkt. In 2008 kondigde Google aan dat het nu in staat is om bepaalde Flash websites te indexeren. Met behulp van 10
PSIC - http://www.psic.eu
TNO-rapport |
12 / 34
een “headless Flash player”, een Flash player zonder grafische output, worden SWF objecten uitgevoerd alsof er een gebruiker mee interacteert. Alle tekst die normaal gesproken op het scherm zou worden getoond wordt opgeslagen en geïndexeerd. Noch Adobe, noch Google heeft echter de headless Flash player beschikbaar gesteld aan derden en over de precieze werking van de player is weinig informatie te vinden. Het is daarom onduidelijk welke informatie de player wel en niet uit SWF objecten kan extraheren. Zeker is wel dat Google niet in staat is om alle Flash websites vindbaar te maken. Deze benadering biedt gedeeltelijk een oplossing, waarbij het idee om vanuit de SWF player tekst te extraheren zeer interessant is. 3.1.2
Adobe Wallaby De laatste jaren is het gebruik van smart phones en andere mobiele apparaten zoals tablet computers enorm toegenomen. Deze apparaten hebben allemaal toegang tot het internet, maar bieden niet allemaal ondersteuning voor Flash. De bekendste voorbeelden hiervan zijn de iPhone, iPad en iPod Touch van Apple. Daarnaast is er een trend naar het gebruik van open formaten, terwijl Flash grotendeels een gesloten formaat is. Dit leidt ertoe dat alternatieven voor Flash steeds populairder worden. Eén van de belangrijkste alternatieven is HTML5, een W3C standaard voor het structureren en presenteren van webcontent. Adobe speelt op deze trend in door ondersteuning voor HTML5 in haar producten aan te bieden. Daarnaast werkt Adobe aan een Flash naar HTML5 converter, waarvan de eerste experimentele versie op 8 maart 2011 is vrijgegeven onder de naam Wallaby. Wallaby biedt alleen (gedeeltelijke) ondersteuning voor Flash CS5 bestanden. 11
Zoals Duda et. al. al in 2008 beschreven is het crawlen en indexeren van web 2.0 websites die veel gebruik maken van AJAX en Javascript technologie helaas ook niet triviaal. Bovendien kan Wallaby alleen Flash bronbestanden omzetten naar HTML5 en geen SWF objecten. Dit betekent dat het SWF object eerst geconverteerd moet worden naar Flash. Kortom, deze oplossingsrichting behoud de problematiek van het indexeren, dan dat het een oplossing biedt. Het maakt ook duidelijk dat het niet alleen Flash of SWF is waar de tekstextractie problemen voor aan de orde zijn.
3.2
Virtual user – geautomatiseerd een website verkennen Om SWF objecten goed te ontsluiten is het van belang zoveel mogelijk tekst te extraheren uit deze websites. Dit is niet triviaal, maar niet onmogelijk. Een normale crawler, zoals HTTrack, doorloopt een volledige website door alle links te volgen. Dit is een vrij technische aanpak om het gedrag van een gebruiker te simuleren die alle pagina’s van een website bezoekt. Om een SWF object te indexeren moeten zoveel mogelijk pagina’s bezocht worden, maar in dit geval zijn niet alle links beschikbaar zoals in een normale HTML pagina. Om dit doel te realiseren moet de virtuele user verschillende pagina’s kunnen vinden. Dit vereist kennis over de posities van de verschillende links waarbij een klik leidt naar een andere pagina. Vervolgens is het essentieel te weten of een 11
AJAXSearch: Crawling, Indexing and Searching Web 2.0 Applications, Cristian Duda, Gianny Frey, Donald Kossmann and Chong Zhou, 2008. In Proceedings of the VLDB Endowment 1, 2 (August 2008)
TNO-rapport |
13 / 34
pagina al bezocht is, zodat alle pagina’s worden bezocht en het aantal dubbelen beperkt wordt. Dit is het tweede belangrijke aspect naast het herkennen van klikbare gebieden. Om vast te stellen dat een pagina is bezocht, betekent dat de toestand van het SWF object gedefinieerd moet zijn. Deze sectie presenteert drie benaderingen die ingrijpen op verschillende niveaus, zoals Figuur 6 inzichtelijk maakt. De verschillende oplossingsrichtingen worden uiteindelijk tegen de volgende eisen aangehouden: Toekomstbestendig – dit betreft het aspect of de oplossing aangepast moet worden als er een update van Flash of nieuwe technologie wordt geïntroduceerd. Mate van automatisering – dit betreft de mate waarin de oplossing handwerk vereist, dan wel volledig automatisch opereert. Volledigheid met betrekking tot aantal pagina´s – dit betreft de mate waarin een website volledig doorzocht kan worden. Schaalbaarheid – dit betreft de mate waarin de oplossing op grote schaal toepasbaar is, dit is vooral afhankelijk van de rekenintensiviteit van de oplossing. Toepasbaarheid – dit betreft het relatieve aantal cases dat de oplossing van toepassing is. Complexiteit van de oplossing – dit betreft de benodigde inzet die nodig is om de oplossing te realiseren.
3.2.1
Pixel-klikken De meest eenvoudige aanpak klikt geautomatiseerd met de muis ieder pixel van het SWF object aan. In dit geval bestaat de virtuele user op het niveau van het operating system. Deze brute-force benadering houdt alleen bij of een pixel is aangeklikt of niet. Nadeel van deze “clickbot” is dat direct een nieuwe pagina wordt bezocht, zodra een aangeklikt pixel een link bevat. Daardoor worden andere links genegeerd. Dit is belangrijk, omdat er geen logische “back”-functie is. Een benadering om dit probleem te ontwijken is de pixels niet één-voor-één als scanlijn aan te klikken, maar bijvoorbeeld random door het scherm te laten klikken. In dat geval worden niet alle klikbare elementen in kaart gebracht, maar kan na verloop van tijd worden vastgesteld dat een aanzienlijk deel van de website is geïndexeerd. Deze benadering is niet geschikt voor monitoring doeleinden, maar alleen om een relevante website te identificeren op basis van beschikbare teksten. Belangrijk nadeel van deze benadering zijn websites, waar gescrolld kan worden naar andere informatie. Het is op dit moment ook onduidelijk hoe een toestand gedefinieerd kan worden om vast te stellen of een pagina al bezocht is. Mogelijk kan hier het screenshot van de pagina voor gebruikt worden die met beeldherkenning gerelateerd kan worden aan andere screenshots.
3.2.2
Virtuele gebruiker door hergebruik van browsertechnologie Een meer geavanceerde clickbot weet waar de links aanwezig zijn in het SWF object. Deze informatie is ook beschikbaar in de webbrowser en wordt zichtbaar doordat bijvoorbeeld de modus van de muispointer veranderd in een hand als de muis over een link schuift. De webbrowser heeft meer kennis over de content in een webpagina en zou op deze manier een alternatieve wijze van crawlen kunnen opleveren. Het is nog een onderzoeksvraag in hoeverre dit leidt tot een structurele
TNO-rapport |
14 / 34
oplossing, maar het is duidelijk dat browsertechnologie veel mogelijkheden biedt. Een drietal specifieke vragen zal beantwoord moeten worden: 1. Op welke manier is bekend in een webbrowser waar “clickable regions” zijn? Wat is een geschikte open source webbrowser? 2. Hoe kan voor iedere pagina een toestand gedefinieerd worden? 3. In hoeverre kan een SWF object volledig doorzocht worden? Deze oplossing kan leiden tot een plugin, extensie of add-on in een browser die deze functionaliteit biedt. Het grote voordeel van deze benadering is, dat de browsertechnologie hergebruikt kan worden en dat updates automatisch geïnstalleerd kunnen worden, waardoor de oplossing toekomstbestendig is. Mogelijkerwijs zijn er bepaalde beveiligingsproblemen waardoor het toch onmogelijk blijkt om alle pagina’s te bezoeken. Tenslotte is het de vraag in hoeverre deze benadering een generieke oplossing biedt voor het ontsluiten van andere RIAs of HTML5 gebaseerde websites.
3.2.3
Aangepast SWF player Door een SWF player aan te passen is het mogelijk om de player te laten vertellen waar de klikbare gedeeltes zitten en om in het SWF object zelf kliks te emuleren. Deze oplossingsrichting is sterk verbonden aan de GUI test automation tools, die geautomatiseerd testen uitvoeren op SWF objecten om te achterhalen of het object goed functioneert. De eerder gepresenteerde oplossing van Adobe en Google voor het indexeren van SWF objecten maakt ook gebruik van deze aanpak. Nadeel van het aanpassen van de SWF player, is dat dit best een complexe operatie is en een stap die niet goed bestand is tegen toekomstige updates. Om dit te realiseren zal gebruik gemaakt moeten worden van een open source player, terwijl Adobe gesloten is, welke veelal een aantal versies achterlopen. Bovendien is de oplossing specifiek voor Flash en kan hij niet zondermeer worden ingezet voor andere technologieën.
3.2.4
Aanpassing van het SWF object door decompileren De vierde benadering om een virtuele gebruiker te simuleren, transformeert het SWF object door het object te decompileren, deze vervolgens aan te passen of anders aangepast te compileren. Decompileren is het omgekeerde van compileren. Bij decompileren wordt het door de Flash Player uitvoerbare SWF object omgezet in (een benadering van) de originele broncode en elementen. Door de broncode aan te passen kan het gedrag van de Flash applicatie worden veranderd. Het gedrag is bijvoorbeeld zo aan te passen dat de applicatie elk klikbaar object (zoals knoppen, menu’s en linkjes) automatisch in een bepaalde volgorde “aanklikt”. Een vraag die nog niet beantwoord is, is hoe een toestand of state van de applicatie wordt gedefinieerd. Dit is noodzakelijk om na te kunnen gaan of de hele applicatie is doorlopen en niet te veel dubbele pagina’s worden bezocht. Een nadeel van deze benadering is dat deze afhankelijk is van de wijze waarop een object in elkaar zit en daarmee is deze benadering ook minder toekomstbestendig. Een tweede nadeel van deze benadering is dat SWF objecten die gemaakt zijn met Adobe Flash, niet met een aangepaste compiler kunnen worden gecompileerd, omdat er alleen closed-source compilers bestaan van Adobe. Het is wel mogelijk deze objecten te decompileren. In dat geval kan alleen de code (ActionScript)
TNO-rapport |
15 / 34
worden aangepast en vervolgens moet de Flash tot SWF object gecompileerd worden met behulp van Adobe Flash. Dit vereist automatische code interpretatie, wat een tamelijk complexe operatie is. Er zijn verschillende Flash decompilers beschikbaar, zowel open-source als commercieel. Sommige decompilers kunnen alleen overweg met Flash animaties, terwijl andere ook Flex reproduceren. Daarnaast moet opgemerkt worden dat ook de versies die Flex ondersteunen verschillen vertoond. Dit onderzoek is uitgevoerd met de Flash Decompiler Trillix, versie 4.2 van Eltima Software. Deze decompiler kan overweg met zowel Flash als Flex en ondersteunt Flash CS5 en Flex 3.
3.2.5
Conclusies Tabel 3 presenteert de evaluatie van de voorgestelde oplossingsrichtingen op basis van het geïntroduceerde programma van eisen.
Tabel 3. Verschillende oplossingsrichtingen om een website te verkennen ten opzichte van de eisen. Pixel-klikken
Browser-
SWF player
technologie
SWF decompileren
Toekomstbestendig
++
++
--
--
Automatisering
+
++
++
++
Volledigheid
--
+
++
++
Schaalbaarheid
+
+
+
+
Toepasbaarheid
++
++
+
+
Complexiteit
++
+
--
-
Op basis van deze analyse komt de ontwikkeling van een virtuele gebruiker op basis van browsertechnologie eruit als de meeste interessante benadering, omdat deze benadering nauwelijks nadelen kent. Wel is er een aantal openstaande onderzoeksvragen met betrekking tot deze oplossing.
3.3
Virtual user – tekst extractie Tijdens het volledig verkennen van een website is het belangrijk om de (tekstuele) informatie die aan de gebruiker wordt gepresenteerd te extraheren en indexeren. Een crawler, zoals HTTrack, gebruikt de verkregen HTML om te tekst te extraheren. Dit werkt niet voor SWF objecten, omdat de SWF pagina’s geen tekstuele pagina’s zijn. Deze sectie presenteert vijf oplossingsrichtingen om de statische en dynamische teksten uit SWF objecten te extraheren. Vervolgens worden de verschillende richtingen geëvalueerd op basis van de volgende eisen: Toekomstbestendig – dit betreft het aspect of de oplossing aangepast moet worden als er een update van Flash of nieuwe technologie wordt geïntroduceerd. Kwaliteit van verkregen tekst – dit betreft het aantal potentiele taal- of tikfouten die voorkomen in de verkregen tekst. Mate van automatisering – dit betreft de mate waarin de oplossing opgenomen kan worden in een automatisch verwerking straat.
TNO-rapport |
3.3.1
16 / 34
Robuust tegen encryptie – dit betreft de mate waarin de oplossing in staat is tekst te extraheren, die geencrypt wordt aangeleverd. Schaalbaarheid – dit betreft de mate waarin de oplossing op grote schaal kan worden toegepast, een oplossing die erg rekenintensief is, is bijvoorbeeld minder schaalbaar. Toepasbaarheid – dit betreft het relatieve aantal cases dat de oplossing van toepassing is. Complexiteit van de oplossing – dit betreft de benodigde inzet die nodig is om de oplossing te realiseren.
OCR van screenshots van de website De meest basale aanpak maakt van ieder scherm dat verkregen wordt een screenshot en herkend automatisch de tekst op deze pagina. Automatische conversie van de tekst in beeld naar platte indexeerbare tekst wordt gedaan met 12 behulp van optical character recognition (OCR). Omdat veel informatie op websites ook in beeld wordt gevat is deze technologie verder onderzocht en worden de resultaten gepresenteerd in de hoofdstukken 4 tot en met 6. Het belangrijkste nadeel van OCR is dat de tekst niet altijd perfect wordt herkend, of zoals onze bevindingen laten zien soms zelfs heel slecht wordt herkend. Het belangrijkste voordeel van OCR is dat het altijd toegepast kan worden, op ieder beeld zonder problemen met betrekking tot de interoperabiliteit tussen bijvoorbeeld een webbrowser en een SWF player. Daarnaast is deze oplossing ook robuust tegen teksten die geëncodeerd of versleuteld worden verstuurd.
3.3.2
Wireshark op het OS Zodra de virtual user een website bezoekt dan veroorzaakt dit netwerkverkeer. Er worden bijvoorbeeld afbeeldingen, filmpjes en dynamische teksten geladen. Dit 13 netwerkverkeer is af te vangen met behulp van een tool als Wireshark . Deze netwerk analyse tool kan weergeven welke data er vanaf het internet worden opgehaald, ook als het SWF object niet in een browser wordt afgespeeld. Indien meerder processen tegelijkertijd draaien op de server, dan is het mogelijk lastig om de verschillende datastromen uit elkaar te houden. Het is van belang alleen de aanroepen van de webbrowser af te vangen.
3.3.3
Firebug vanuit de webbrowser De informatie die door een SWF object wordt weergegeven is niet altijd in het object zelf opgeslagen. Veelal wordt dynamische informatie door het SWF object opgevraagd vanaf een server. Hiervoor doet de SWF player een aanroep naar de server, welke de gevraagde data terugstuurt. Deze aanroepen zijn op verschillende manieren af te vangen. Wanneer het Flash object door een Flash plugin in een 14 15 browser wordt uitgevoerd kunnen tools als Firebug en ServiceCapture de aanroepen die worden gedaan weergeven.
12
http://nl.wikipedia.org/wiki/Optical_character_recognition http://www.wireshark.org/ 14 https://addons.mozilla.org/nl/firefox/addon/firebug/ 15 http://www.kevinlangdon.com/serviceCapture/ 13
TNO-rapport |
17 / 34
Zodra duidelijk is welke content gedownload wordt, wil nog niet zeggen dat alle tekst beschikbaar is. Er is vooral bekend welke content gedownload wordt. Als er een nieuw SWF object wordt gedownload, dan zal deze gedecompileerd moeten worden om de statische teksten te extraheren. Een tweede aspect dat relevant is, is dat verschillende data formaten gebruikt worden zoals: XML, JSON, stringencoding, etc. Deze formaten moeten ook verwerkt worden, voordat content geïndexeerd kan worden.
3.3.4 Aanpassing SWF player Een vierde oplossingsrichting om tekst te extraheren is het aanpassen van de SWF player. Het slimst is om de tekst af te vangen vlak voor het moment dat de tekst gerenderd wordt. Het grote voordeel van deze benadering is dat hij robuust is tegen websites die de data versleuteld versturen, omdat de tekst geëxtraheerd wordt nadat deze is gedecrypt. Deze oplossingsrichting is tamelijk complex omdat het aanpassingen op een SWF player betreft, hiertoe is een open source player nodig 16 zoals Gnash . Nadeel is dat deze open source player elke keer aangepast moet worden als er een update van het SWF format plaatsvindt. Daarnaast lopen open source players regelmatig achter op de meest recente versie van Adobe.
3.3.5
Decompileren voor tekstextractie Het is ook mogelijk om een SWF object te decompileren in zijn originele bouwblokken om vervolgens uit de verkregen broncode de tekst te filteren. Het verkregen resultaat bevat naast de tekst, broncode ook al het beeldmateriaal. Daarnaast is het ook mogelijk om URLs die volledig zijn uit het SWF object te extraheren. Het verkrijgen van dynamische content ligt gecompliceerder. Deze teksten worden eenvoudiger geëxtraheerd op basis van Firebug-achtige oplossingen, omdat deze calls veelal op run-time samengesteld worden en dus niet als zodanig beschikbaar zijn in de broncode van het SWF object.
3.3.6
Conclusies Tabel 4 presenteert de verschillende oplossingen om tekst te extraheren ten opzichte van de geïntroduceerde eisen.
Tabel 4. Verschillende oplossingsrichtingen om tekst te extraheren uit SWF objecten ten opzichte van de eisen. OCR
Wireshark
Firebug
SWF player
Decompileren
++
++
++
-
-
Tekstkwaliteit
--
++
++
++
++
Automatisering
++
+
++
++
++
Encryptie
++
--
--
++
+
Schaalbaarheid
-
++
++
+
+
Toepasbaarheid
-
+
+
++
+
Complexiteit
+
++
++
--
+
screenshots Toekomstbestendig
16
http://www.gnu.org/s/gnash
TNO-rapport |
18 / 34
Een hybride oplossing om op basis van het decompileren van SWF objecten om statische teksten te extraheren in combinatie met het afvangen van dynamische content via de Firebug oplossing, lijkt een zeer interessante oplossingsrichting. Nadeel is dat deze oplossingsrichting niet robuust is tegen encryptie. Een interessant bijproduct van het decompileren is dat ook alle losse grafische elementen verkregen worden die mogelijk ook informatief zijn.
3.4
Conclusies met betrekking tot de oplossingsrichtingen De Google-Flash oplossing werkt alleen onder beperkte voorwaarden en is niet beschikbaar voor andere gebruikers als Google en Yahoo. Deze benadering biedt daarom geen totaal oplossing die algemeen bruikbaar is. Daarentegen is de benadering die gebruik maakt van een virtuele gebruiker wel erg interessant. Om SWF objecten goed te indexeren is geconcludeerd dat een virtuele gebruiker onderzocht moet worden die bestaat uit de volgende twee componenten: Verkennen van de Flash website door browsertechnologie te (her)gebruiken, en op die wijze een website volledig geautomatiseerd te doorlopen. Tekstextractie uit de verkregen content lijkt het best te realiseren alle content af te vangen met een tool als Firebug en vervolgens XML en HTML te verwerken volgens de traditionele benadering en de tekst uit de statische teksten uit SWF objecten te halen door deze te decompileren. Een belangrijke onderzoeksvraag is: in hoeverre is dit een generieke oplossing ook voor andere RIAs die niet zijn gebaseerd op SWF objecten, maar bijvoorbeeld op HTML5 of Ajax.
TNO-rapport |
4
19 / 34
Tekst in afbeeldingen op het internet Een groot aantal afbeeldingen op het internet bevatten tekst. Deze afbeeldingen kunnen verschillende doelen dienen, zoals het presenteren van een reclame banner, tekst in een button of tekst die toevallig aanwezig is in de achtergrond. Om enig gevoel te krijgen bij de relevantie van tekst in afbeeldingen op het internet presenteert dit hoofdstuk twee analyses. Een inventarisatie van tekst in een groot aantal afbeeldingen afkomstig van het internet en vervolgens worden twee relevante cases geïntroduceerd.
4.1
Inventarisatie van tekst in afbeeldingen op het internet Om inzicht te krijgen in het gebruik van tekst in afbeeldingen op het internet is een analyse gemaakt van alle afbeeldingen die bekeken zijn in een periode van een half jaar door middel van een webbrowser. Er wordt aangenomen dat dit een enigszins representatief beeld oplevert van het gebruik van afbeeldingen op het internet. Deze afbeeldingen zijn afkomstig uit de cache van de webbrowser. De verschillende afbeeldingen zijn ingedeeld in zeven categorieën: info tekst, button tekst, logo tekst, banner tekst, map tekst, achtergrond tekst en afbeeldingen met geen tekst. Figuur 7 presenteert voor iedere categorie een voorbeeld. Achtergrond teksten zijn afbeeldingen waarin de tekst zich in de achtergrond bevindt, zoals “zuiderheide” in Figuur 7.
Button tekst
Logo tekst
Banner tekst
Info tekst
Achtergrond tekst
Map tekst
Figuur 7. De 6 voorbeeld categorieën van tekst in afbeeldingen op het internet.
Deze inventarisatie heeft bijna 10 duizend afbeeldingen gecategoriseerd zoals Tabel 5 presenteert. De afbeeldingen zijn tevens gecategoriseerd naar afbeeldingsformaten: gif, jpg en png. Op basis van deze inventarisatie kunnen de volgende conclusies worden getrokken: Ongeveer 25% van de afbeeldingen op het internet bevat tekst. Tekst zit voornamelijk in afbeeldingen met logo’s, banners en plattegronden. Als tekst in de achtergrond zit, dan betreft het altijd foto’s die zijn opgeslagen als een jpg geëncodeerde afbeelding.
TNO-rapport |
20 / 34
Tabel 5. Statistieken van de verschillende categorieën met tekst in afbeeldingen op het internet. GIF
JPG
PNG
ALL
Info tekst
81
0,8%
25
0,3%
6
0,1%
112
1,1%
Button tekst
29
0,3%
7
0,1%
11
0,1%
47
0,5%
Logo tekst
116
1,2%
272
2,7%
154
1,5%
542
5,4%
Banner tekst
182
1,8%
259
2,6%
59
0,6%
500
5,0%
Map tekst
0
0,0%
0
0,0%
855
8,6%
855
8,6%
Background tekst
3
0,0%
300
3,0%
4
0,0%
307
3,1%
1520
15,3%
5426
54,4%
658
6,6%
7604
76,3%
1931
19,4%
6289
63,1%
1747
17,5%
9967
100,0%
No tekst
Veel tekst in de afbeeldingen op het internet is erg klein. Dit maakt herkenning van deze teksten met OCR complex. De randvoorwaarden voor het herkennen van tekst in beeld worden in kaart gebracht in hoofdstuk 7.
4.2
Contactinformatie in beeldmateriaal De website marktplaats.nl presenteert de telefoonnummers van verkopers als afbeeldingen. Dit voorkomt dat zoekmachines en robots deze informatie kunnen zien, indexeren en koppelen aan andere informatie. Voor de internetgebruiker maakt dat niet uit, want je ziet pas dat de tekst is opgenomen in een afbeelding als je de tekst wilt selecteren. Voor zoekmachines maakt dit wel degelijk uit. Op het moment kunnen zoekrobots dergelijke afbeeldingen (nog) niet lezen, terwijl optical character recognition (OCR) beschikbaar is. In de toekomst zullen zoekmachines zoals Google deze technologie gaan gebruiken om afbeeldingen te ‘indexeren’.
Figuur 8. screenshot van Marktplaats17, het telefoonnummer is een plaatje en geen tekst.
In voorbeeld B wordt contactinformatie als afbeelding gepresenteerd. Op deze site wordt alle contactinformatie: naam, adres, telefoonnummer als afbeelding gepresenteerd. 17
In deze en andere screenshots in dit rapport is privacy gevoelige informatie onherkenbaar gemaakt.
TNO-rapport |
21 / 34
Figuur 9. screenshot van case B met de contactinformatie als afbeelding.
Beide voorbeelden worden in het vervolg van dit hoofdstuk gebruikt als ‘use-cases’. Voor marktplaats wordt gericht op het (automatisch) herkennen van het telefoonnummer en voor B wordt gericht op het herkennen van adresgegevens.
4.3
Conclusies De inventarisatie heeft laten zien dat een significant aantal afbeeldingen op het internet tekst bevat. Deze teksten worden tot op heden niet geïndexeerd. Onder andere omdat dit erg lastig is, zal dit niet direct op grote schaal gebeuren. De twee use-cases laten zien dat relevante informatie in de vorm van tekst in afbeeldingen wordt opgenomen. Deze teksten moeten uiteindelijk ook automatisch verwerkt kunnen worden, zodat bijvoorbeeld de contact gegevens van dezelfde personen gekoppeld kunnen worden. Deze use-cases zullen verder onderzocht worden om de tekst automatisch te herkennen. Wat opvalt in de inventarisatie is dat meer dan 10% van de afbeeldingen logo’s bevatten. Dit zijn de afbeeldingen die alleen een logo bevatten, maar ook afbeeldingen met een banner waarin ook een logo voorkomt. Naast het automatisch herkennen van tekst is het ook interessant om logo’s te herkennen. Deze technologie is evenals tekstherkenning erg robuust aan het worden.
TNO-rapport |
5
22 / 34
Tekstextractie met OCR technologie Dit hoofdstuk presenteert de bevindingen met betrekking tot het herkennen van tekst met OCR technologie in de twee geïntroduceerde use cases. Deze inzichten bieden handvatten om OCR technologie in de praktijk toe te passen. Eerst wordt OCR technologie geïntroduceerd, vervolgens wordt deze technologie toegepast op de use cases. Om een betere herkenningskwaliteit te behalen wordt een overzicht gegeven van de verschillende parameters die ingesteld kunnen worden om de kwaliteit te verbeteren. Tenslotte wordt een door TNO ontwikkelde user interface voor een open-source OCR pakket geïntroduceerd, waarmee eenvoudig experimenten kunnen worden uitgevoerd.
5.1
Introductie OCR technologie Technologie om automatische tekst te herkennen wordt OCR (Optical Character Recognition) of ICR (Intelligent Character Recognition) genoemd. OCR is oorspronkelijk ontwikkeld voor geprinte documenten die vervolgens gescand zijn. Er moet bij OCR een onderscheid worden gemaakt tussen handgeschreven en geprinte tekst. OCR software is voornamelijk bedoeld voor geprinte tekst, ICR richt zich meer op de herkenning van geschreven tekst. De huidige generatie OCR software kan naast tekst ook de complete opmaak (gebruikte lettertypes, figuren) achterhalen. Ondanks dat OCR software veel belovend is, blijkt het gebruik ervan in de praktijk niet altijd even triviaal. OCR technologie heeft een rijke historie, waardoor een groot aantal verschillende OCR pakketten is ontwikkeld. Er zijn drie categorieën aan te merken: open source, commerciële en maatwerk software. Tabel 6 presenteert voor iedere categorie drie belangrijke pakketten of spelers. Dit zijn veel gebruikte OCR pakketten. Voor dit project zijn voornamelijk de open source en commerciële software pakketten relevant. Maatwerkoplossingen zijn prijzig en richten zich veelal op specifieke problemen. Hierbij kan bijvoorbeeld gedacht worden aan het real-time herkennen van ingebrande ondertitels in TV programma’s. Het belangrijkste open source OCR pakket is op dit moment Tesseract. Google heeft in 2006 de ontwikkeling van Hewlet-Packard overgenomen en gebruikt deze technologie in haar streven om veel oud leesmateriaal doorzoekbaar en toegankelijk te maken. Veel andere open source initiatieven zijn gestopt met verdere doorontwikkeling. Dat Tesseract de meest krachtige open source oplossing is, blijkt uit het feit dat andere open source initiatieven (zoals bijvoorbeeld Ocropus) ook deze engine zijn gaan gebruiken, omdat die veelal een betere performance laat zien dan de eigen ontwikkelde engine.
TNO-rapport |
23 / 34
Tabel 6. Per OCR software categorie drie belangrijke pakketten of spelers.
Open source 18 Tesseract 21 Ocropus 24 gOCR
Commercieel 19 FineReader 22 Parascript 25 Nuance OmniPage
Maatwerk 20 PrimeVision 23 Autonomy 26 SRI
De meest bekende en best aangeschreven commerciële OCR software is FineReader van Abbyy. Een OCR pakket dat al geruime tijd bestaat en een betrouwbare en robuuste performance biedt. Abbyy biedt finereader aan als een consumentenproduct en als een bibliotheek die andere programmabouwers kunnen gebruiken. Voor het verdere onderzoek naar automatische tekst herkenning zullen deze twee pakketten gebruikt worden. Het is belangrijk te beseffen dat de OCR software is geoptimaliseerd voor: geprinte tekst, scan resoluties: 150, 300 en 600 dpi (dots per inch), papierformaat: A4 in Europa, US letter in VS, Microsoft Word document opmaak, Microsoft Word standaard lettertypen (Times Roman 10.5 punt). Doordat beeldmateriaal van het internet deze karakteristieken niet altijd heeft, wordt de tekst in deze afbeeldingen niet altijd even goed herkend. De volgende sectie presenteert de oplossing om de use-cases goed te herkennen. In feite komt het er op neer dat het beeldmateriaal zodanig aangepast moet worden, dat het de karakteristieken heeft waarvoor OCR software is geoptimaliseerd.
5.2
OCR technologie toegepast op de use-cases Voor het praktische gebruik van OCR software is de belangrijkste les dat het beeldmateriaal goed moet aansluiten op de kenmerken waarvoor de OCR software is geoptimaliseerd: gescande, papieren, geprinte documenten. Als voorbeeld B door Tesseract geanalyseerd wordt, dan wordt er nauwelijks een karakter correct herkend, zoals Figuur 10 laat zien. FineReader geeft in dit geval in zijn geheel geen resultaat terug.
18
http://code.google.com/p/tesseract-ocr/ http://finereader.abbyy.com/ 20 http://www.primevision.nl/ 21 http://code.google.com/p/ocropus/ 22 http://www.parascript.com/ 23 http://www.autonomy.com/ 24 http://jocr.sourceforge.net/ 25 http://www.nuance.com/for-business/by-product/omnipage/index.htm 26 http://www.sri.com/esd/automation/doc_ocr.html 19
TNO-rapport |
24 / 34
Figuur 10. Herkenningsresultaat van Tesseract zonder enige beeldverbetering; alleen “mr R D” en “arnhem” zijn correct herkend.
Om use case B goed te herkennen moet het beeldmateriaal naar het formaat van een gescand document gebracht worden. Dit betekent voor deze use-case dat de afbeelding moet worden opgeschaald (in beeldresolutie verhoogd). Ondanks dat deze operatie geen informatie toevoegt, brengt de operatie de tekst wel in het geoptimaliseerde domein van de OCR software. Figuur 11 presenteert een voorbeeld waarin de contactinformatie wel correct is herkend. Met Tesseract wordt voor deze case dezelfde herkenningskwaliteit behaald.
Figuur 11. Correct herkende contactinformatie met FineReader, nadat het originele beeld een factor twee was opgeschaald en een kleine witte rand was toegevoegd.
Figuur 12 presenteert de grafische gebruikersinterface van FineReader. Deze is gemakkelijk te bedienen en laat eenvoudig zien of bepaalde digitale beelden correct worden herkend. Indien dit het geval is, dan is het mogelijk de FineReader engine te gebruiken als bibliotheek, zodat de OCR technologie opgenomen kan worden in een geautomatiseerde content analyse straat.
TNO-rapport |
25 / 34
Figuur 12: Screenshot van FineReader: na vergroten van de afbeelding kan Finereader de tekst wel lezen. Legenda: links boven en onder de originele afbeelding, rechtsboven het OCR resultaat van FineReader, het groene blok identificeert de door FineReader gevonden tekstblokken.
Tesseract heeft geen grafische gebruikersinterface en kan slechts worden gebruikt in command-line modus. Voor de werking van OCR maakt dat uiteraard niet uit. De syntax voor het gebruik van Tesseract op de command-line wordt gepresenteerd in Tabel 7. Tabel 7. Command-line aanroep van Tesseract
> tesseract plaatje.ext resultaat –l nld
Waarbij “plaatje.ext” het input plaatje is, met “.ext” het extensietype. Bijvoorbeeld “plaatje.png” of “plaatje.gif”. Tesseract stopt het resultaat in de file “resultaat.txt” (als “resultaat” als output parameter wordt gekozen). De laatste optie “-l nld” selecteert de Nederlandse taal in OCR. Dit is een van de instellingen die gekozen kan worden om de herkenningskwaliteit te verbeteren. Na beeldverbetering herkent ook Tesseract de tekst zonder fouten, zoals Figuur 13 laat zien.
TNO-rapport |
26 / 34
Figuur 13. Screenshot Tesseract in command-line mode, met het OCR resultaat van Tesseract na beeldverbetering. De gebruikte command line is MinGW, een Unix shell voor Windows; het Unix ‘cat’ commando laat de inhoud van een tekstfile zien.
5.3
Beeldverbetering voor optimaal OCR resultaat Om tekst goed te herkennen moet de tekst in de afbeelding getransformeerd worden naar de randvoorwaarden waarvoor de OCR software is geoptimaliseerd. Deze transformaties bestaan uit de volgende vier stappen: 1 Selectie van de tekst 2 Oriënteren van de tekst 3 Kleurcorrectie 4 Schalen van de tekst (vergroten van de beeldresolutie) De volgende secties gaan dieper op deze stappen in.
5.3.1
Selectie van de tekst in de afbeelding Voor de automatische extractie van tekst is het belangrijk dat het plaatje alleen tekst bevat en zo min mogelijk verstoringen in de achtergrond. OCR software is wel in staat om onderscheid te maken tussen tekst en niet-tekst (zoals figuren, grafieken, plaatjes, foto’s), maar de beeldelementen die geen tekst zijn, kunnen het OCR resultaat verstoren als het OCR pakket bepaalde delen als tekst aanmerkt. Vaak bevatten internet afbeeldingen alleen tekst, zoals de use-cases marktplaats en case B laten zien. Maar het komt ook geregeld voor dat een plaatje naast tekst andere zaken bevat. Verder is het belangrijk dat tekst die uit meerdere kolommen bestaat apart te verwerken als het belangrijk is de opmaak/structuur te behouden. Niet elke OCR engine kan bij een beperkte hoeveelheid tekst goed zien, waar de kolom begint en eindigt, zodat OCR resultaten incorrect over de kolommen worden gespreid.
5.3.2
Horizontaal georiënteerde tekstregels OCR software is ook gevoelig voor de oriëntatie van de tekstregels, deze moeten zoveel mogelijk echt horizontaal zijn. Een rotatie groter dan 5 graden linksom of 10 graden rechtsom zorgt ervoor dat de herkenning ineens snel minder wordt. Als de tekst nog verder afwijkt, zal de OCR software de tekst steeds slechter gaan herkennen. Het is dan ook van belang om de tekst te transformeren, zodat deze wordt gepositioneerd als horizontale tekstregels.
TNO-rapport |
27 / 34
5.3.3
Donkere karakters op een witte achtergrond Geprinte documenten bestaan meestal uit zwarte letters op een egaal witte achtergrond. De meeste OCR softwarepakketten werken dan ook alleen met dit negatieve contrast (zwart op wit). Als de tekst in de afbeeldingen andere kenmerken heeft, is het belangrijk om deze te transformeren naar donkere tekst op een lichte achtergrond, voordat het beeld wordt aangeboden aan de OCR software.
5.3.4
Resolutie van de tekst Zoals hierboven beschreven heeft use-case B laten zien dat de pixel-resolutie van de afbeelding van groot belang is voor een goed OCR resultaat. Dit komt omdat scanners vaak met een bepaalde resolutie (DPI of dots-per-inch/puntjes per 2,54cm) documenten scannen. Vaak voorkomende resoluties zijn veelvouden van 300DPI: 600DPI en 900DPI. Als het internetplaatje met tekst die resolutie niet haalt, wordt er simpelweg geen tekst gelezen. De oplossing is om het beeld op te schalen 27 of te vergroten zodat de tekst in het juiste bereik komt. Het programma IrfanView heeft bijvoorbeeld een (geavanceerde) batch mode, waarmee een hele verzameling plaatjes kan worden geconverteerd naar een bepaalde resolutie.
5.4
Relevante instellingen in de OCR software Om de tekst zo goed mogelijk te herkennen zijn een aantal instellingen in de OCR software die gekozen kunnen worden. Hiervoor is bepaalde voorkennis nodig over de te herkennen teksten.
5.4.1
Gebruikte taal Het is niet heel duidelijk zichtbaar, maar de taalkeuze in het OCR pakket is ook van belang bij een goede herkenning van de tekst in het beeld. De taalkeuze bepaalt de statistische waarschijnlijkheden van bepaalde letters, opeenvolging van letters en voorkomens van woorden. Zoals Tabel 7 al liet zien voor de aanroep van Tesseract kan aangegeven worden dat het Nederlandse taal betreft met behulp van het argument: -l nld.
5.4.2
Alleen cijfers of letters Indien zeker is dat een afbeelding alleen cijfers of alleen letters bevat dan kan deze informatie bij sommige OCR pakketten worden meegegeven. Dit is bijvoorbeeld relevant bij de herkenning van telefoonnummers. Zeker als het beeld alleen cijfers bevat is het verstandig dit aan te geven, want een OCR pakket heeft over het algemeen namelijk een voorkeur voor een ‘l’ in plaats van een ‘1’ en een ‘o’ in plaats van een ‘0’, omdat in normale tekst de letters ‘l’ en ‘o’ vaker voorkomen dan de cijfers ‘1’ en ‘0’.
5.4.3
Lettertype Soms is bekend welk lettertype is gebruikt voor de tekst in beeld. Bij een enkel OCR pakket kan je dit instellen voor een iets betere herkenning van de tekst. Het volgende hoofdstuk presenteert een korte vergelijking tussen Tesseract en FineReader en daarin wordt ook de afhankelijkheid van de verschillende lettertypes meegenomen.
27
http://www.irfanview.com/ (IrfanView – voor beeldverwerking)
TNO-rapport |
5.5
28 / 34
TNO research tooling 28
TNO heeft een tool ontwikkeld op basis van python en OpenCV , waarmee eenvoudig verschillende experimenten kunnen worden uitgevoerd met OCR software. De tool kan een verzameling beelden verwerken aan de hand van een recept dat is gedefinieerd op basis van een voorbeeldafbeelding. Figuur 14 tot en met 17 presenteren voorbeelden van deze tool om een recept te ontwikkelen.
Figuur 14. Gebruikersinterface van de TNO tool om een afbeelding in te lezen.
Figuur 15. Resultaat van het vergroten van de afbeelding met een bepaalde factor.
28
http://opencv.willowgarage.com/documentation/python/cookbook.html
TNO-rapport |
29 / 34
Figuur 16. Resultaat nadat de afbeelding door de OCR software is geanalyseerd.
5.6
Conclusies De Marktplaats en B case hebben aangetoond dat OCR technologie niet vanzelf tot het gewenste resultaat leidt. Aan de hand van case B hebben we echter laten zien dat het goed mogelijk om na enige tuning met hoge kwaliteit deze tekst te herkennen. Deze tuning betreft een aantal keuzes voor beeldverbeteringen of instellingen van de OCR software. De samenhang van deze keuzes kan gezien worden als een recept dat moet worden uitgevoerd. Het recept dat nodig is voor de marktplaats en use-case B is beperkt tot het opschalen van het beeld. In het geval van de Marktplaats case kan het resultaat nog verder verbeterd worden door aan te geven dat slechts cijfers hoeven worden herkend. Figuur 17 presenteert alle potentiële onderdelen van het “recept” om tekst in een afbeelding te herkennen.
Figuur 17: Alle potentiële onderdelen van het OCR recept om tekst in afbeeldingen te herkennen.
Een recept wordt veelal ontwikkeld om afbeeldingen te verwerken met bekende kenmerken. Daarom is OCR zeer geschikt om in vergelijkbare cases als marktplaats en case B tekst in afbeeldingen te herkennen. Als onbekend materiaal verwerkt moet worden, zou automatisch het recept moeten worden afgeleid op basis van de afbeelding. Dit is een complex proces die buiten de scope van dit project valt.
TNO-rapport |
6
30 / 34
Tesseract of FineReader Dit hoofdstuk vergelijkt door middel van enkele experimenten de prestaties van het open source OCR pakket Tesseract en het commerciële FineReader. Beide software pakketten staan bekend als state-of-the-art. Dit hoofdstuk onderzoekt alleen de herkenningskwaliteit, aspecten als integreerbaarheid en snelheid worden buiten beschouwing gelaten.
6.1
Kwalitatieve vergelijking op basis van de use-case marktplaats Voor een uitgebreide test is een verzameling met telefoonnummers gedownload van marktplaats. Iedere afbeelding is geannoteerd met het correcte telefoonnummer, zodat deze vergeleken kon worden met het herkende nummer om vast te stellen of het correct herkend is. De telefoonnummers in deze afbeeldingen zijn herkend met behulp van drie recepten die Tabel 8 presenteert. Tabel 8. Drie geteste recepten voor marktplaats
Recept A Recept B Recept C
Geen beeldverbetering Opschalen factor twee Opschalen factor vier
Vervolgens hebben Tesseract en FineReader deze afbeeldingen geanalyseerd en de telefoonnummers zo goed mogelijk herkend. Tabel 9 presenteert de herkenningskwaliteit voor de drie recepten en de twee OCR pakketten.
Tabel 9. Herkenningskwaliteit voor de use-case marktplaats.
OCR pakket
Recept
Tesseract Tesseract Tesseract FineReader FineReader FineReader
A B C A B C
Correct herkend 0% 27% 100% 0% 60% 100%
Aantal fouten (correcties) 11 correcties 0 6 correcties + 4 gemist 0
Uit deze test blijkt dat zowel Tesseract als FineReader zonder beeldverbetering geen goede OCR resultaten worden gehaald. In het geval van recept B waren de pakketten nog niet in staat deze telefoonnummers goed te herkennen. Bijna alle voorkomende vergissingen waren de verwisseling van cijfers 5 en 6. Bij recept C hadden zowel Tesseract als FineReader geen enkel probleem met het correct lezen van deze telefoonnummers. Deze test laat wel zien dat voor recept B FineReader een betere performance laat zien dan Tesseract. Deze observaties onderschrijven
TNO-rapport |
31 / 34
de eerder getrokken conclusie dat beeldverbetering essentieel is voor het bereiken van goed tekstherkenning.
6.2
Vergelijking op basis van lettertype en lettergrootte voor de use-case B Om meer inzicht te krijgen in de kwaliteit van de twee OCR pakketten is een vergelijking gemaakt voor verschillende lettertypes en lettergroottes. Op basis van de tekst van case B is dezelfde tekst geproduceerd in een aantal verschillende lettertypes en lettergroottes. Figuur 18 presenteert de definities voor de lettergrootte en presenteert de onderzochte lettertypes. Vervolgens is het beeld geanalyseerd met de OCR pakketten, waarna de output is geëvalueerd. De herkenningkwaliteit is gedefinieerd als het percentage incorrect herkende karakters.
pakket
grootte lettertype in pixels
verschillende lettertypes
Arial MS Comic Sans Monotype Corsiva Tahoma Times New Roman Verdana
Figuur 18. De definitie van de grootte van een letter en de verschillende onderzochte lettertypes
Figuur 19 en Figuur 20 presenteren de herkenningskwaliteit voor een specifiek lettertype als functie van de lettergrootte voor FineReader en Tesseract, respectievelijk. De kwaliteit is gedefinieerd als het percentage niet of onjuist herkende karakters.
120,0% 100,0% arial
80,0%
comic corsiva
60,0%
tahoma 40,0%
times verdana
20,0% 0,0% 8
10 11 12 14 16 20 24 28 36 48 96 144
TNO-rapport |
32 / 34
Figuur 19. Herkenningskwaliteit van FineReader als een functie van de grootte van verschillende lettertypes, op de verticale as staat het foutpercentage: 100% is alles fout, 0% is alles goed gelezen.
120,0% 100,0% arial
80,0%
comic corsiva
60,0%
tahoma 40,0%
times verdana
20,0% 0,0% 8
10 11 12 14 16 20 24 28 36 48 96 144
Figuur 20. Herkenningskwaliteit van Tesseract als een functie van de grootte van verschillende lettertypes, op de verticale as staat het foutpercentage: 100% is alles fout, 0% is alles goed gelezen.
Deze analyse resulteert in de volgende observaties: FineReader kan tekst herkennen bij een kleinere letter dan Tesseract. De kantelpunten liggen ongeveer bij 11 en 14 pixels, respectievelijk. De OCR pakketten volgen dezelfde trend voor de lettertypes Arial, MS Comic Sans, Tahoma, Times New Roman en Verdana. Monotype Corsiva blijkt een gecompliceerd lettertype om goed te herkennen.
6.3
Conclusies en Uitdagingen De OCR pakketten Tesseract en FineReader laten allebei zonder beeldverbetering geen optimale tekstherkenning zien. Kortom, beeldverbetering is een essentiële stap om tot goede herkenningskwaliteit te komen. Dit hoofdstuk maakt inzichtelijk dat FineReader een betere performance laat zien dan Tesseract. Afhankelijk van het doel waarvoor de technologie gebruikt wordt is het verstandig een keuze te maken voor één van deze pakketten. Is de beste herkenning essentieel, dan ligt FineReader meer voor de hand. Moet de oplossing vooral goedkoop zijn en zijn enkele fouten geaccepteerd, dan is Tesseract een zeer geschikte oplossing. Naast de bevindingen die gedaan zijn in dit hoofdstuk staan er nog enkele relevante vragen open. Hoe gaat de OCR technologie om met talen die zijn gebaseerd op een andere alfabet, zoals het Arabisch of Chinees? Hoe gaat de OCR technologie om met opmaak? Het is bekend dat de lokalisatie van tekst in een afbeelding bijna net zo complex is als de herkenning ervan, dus tot welk niveau kunnen bijvoorbeeld korte teksten worden herkend? In hoeverre kan opmaak behouden blijven en voor welke cases is de opmaak belangrijk? De pakketten zijn geoptimaliseerd voor documenten die bijvoorbeeld
TNO-rapport |
33 / 34
zijn opgemaakt in MS Word, maar hoe gaat de OCR oplossing om met tekst in banners? Op welke manier kan de opmaak behouden blijven voor bijvoorbeeld het koppelen van contactgegevens? In dat geval is de positie van tekst in beeld belangrijk, deze wordt door de OCR module meegegeven, maar hoe kan die informatie eenvoudig en goed worden verwerkt?
TNO-rapport |
7
34 / 34
Conclusies Dit project heeft een aantal methoden onderzocht om meer tekst te extraheren uit websites. Specifiek is gekeken naar websites die Flash componenten of beeldmateriaal met tekst bevatten. Standaard webcrawlers, zoals HTtrack, zijn niet in staat om uit dit type materiaal tekst te extraheren. Dit rapport laat zien dat Flash één van de technologieën is die lastig te indexeren is. Dezelfde problematiek komt aan de orde bij HTML5 gebaseerde pagina’s of Ajax gebaseerd webapplicaties met real-time informatie. Het aantal websites met Flash componenten is beperkt, maar het is duidelijk dat het aantal pagina’s dat gebruik maakt van technologieen als Flash, HTML5, Ajax en Java flink toeneemt. Dit wordt onder andere veroorzaakt, omdat het steeds eenvoudiger wordt om dergelijke toepassingen te ontwikkelen met standaard libraries. Om deze reden is het wenselijk een meer generieke oplossing te ontwikkelen. Deze generieke oplossing bestaat uit twee stappen: 1. Een website wordt zo volledig mogelijk “automatisch” bezocht, waarbij zoveel mogelijk data, objecten en componenten van de site worden gedownload. 2. Alle elementen, die zijn gedownload, worden vervolgens zo goed mogelijk geïnterpreteerd om zoveel mogelijk tekst te extraheren. Het rapport presenteert een inventarisatie van verschillende benaderingen voor stap 1. De meest belovende benadering bestaat uit een virtuele gebruiker die gebruik maakt van browsertechnologie. De webbrowser weet precies waar geklikt kan worden, en op die wijze moet deze benadering een website volledig kunnen bezoeken. Om dit daadwerkelijk aan te tonen wordt geadviseerd een haalbaarheidsonderzoek te doen naar deze aanpak. Met betrekking tot stap 2 presenteert het rapport een benadering voor tekstextractie uit Flashobjecten en uit beeldmateriaal afkomstig van het internet. Om tekst uit een Flashobject te halen is het belangrijk onderscheid te maken tussen twee typen tekst: statische en dynamische tekst. Dynamische teksten worden tijdens stap 1 gedownload en kunnen als XML of JSON objecten verwerkt worden. De statische teksten kunnen uit de Flashobjecten gehaald worden door deze te decompileren. Met betrekking tot de extractie van tekst uit beeldmateriaal is OCR een geschikte technologie die in de vorm van verschillende software pakketten beschikbaar is. De belangrijkste pakketten zijn het commerciële pakket FineReader en het opensource pakket Tesseract. Het inzetten van deze technologie is niet triviaal, maar met enige beeldverbetering is het mogelijk om zeer goede resultaten te behalen. OCR technologie is geoptimaliseerd om tekst te herkennen in gescande documenten met karakters vanaf een bepaalde lettergrootte. Als de tekst in een afbeelding wordt getransformeerd naar donkere tekst op een lichte achtergrond met een letterhoogte van meer dan 15 pixels, dan kan tekst in afbeeldingen vrij goed extraheert worden. De kwalitatieve analyse heeft laten zien dat FineReader een betere performance vertoond dan Tesseract, maar afhankelijk van het doel en het beschikbare budget wordt geconcludeerd dat Tesseract een geschikt alternatief biedt voor FineReader.
