Het advies dat iedereen geeft over het scannen van tekst is om de hoogste resolutie te gebruiken die je kunt en de verlichting goed te krijgen. Ik heb de motor die deze site gebruikt tegen een reeks opzettelijk beschadigde afbeeldingen gebruikt om erachter te komen welke van die zaken, en het antwoord was geen van beide. Dezelfde zin kwam perfect terug van een foto een derde van het originele formaat, perfect van grijze tekst op een grijze achtergrond, en perfect van een JPEG die bij kwaliteit 25 is opgeslagen. Wat het sneuvelde, was dat de pagina vijf graden kantelde. Elk nummer hieronder kwam uit die run en ze wijzen op een andere checklist dan het gebruikelijke.
tl;dr: Tesseract leest netjes weergegeven tekst totdat er twee specifieke dingen misgaan. Tilt is de eerste: 0 tot 3 graden scheeftrekking gaf een foutpercentage van 0% karakter, 5 graden gaf 2,9%, 12 graden gaf 16,7% en 20 graden gaf 32,4%. Grootte is de tweede, en het is een klif in plaats van een helling: tekst bleef perfect tot een hoofdhoogte van ongeveer 7 pixels en stortte vervolgens in tot 85,3% fouten bij 5,8 pixels. Laag contrast, onscherpte en zware JPEG-compressie nauwelijks geregistreerd. Maak de foto recht voordat je iets anders doet. de Afbeelding naar tekstconverter Voert de engine in uw browser uit, zodat de foto nooit wordt geüpload.
Hoe werden deze nummers geproduceerd?
Door een bekende zin weer te geven, de afbeelding één voor één te beschadigen, deze terug te lezen en de bewerkingen te tellen die nodig zijn om het resultaat te herstellen.
De metriek is karakterfouten: de Levenshtein-afstand tussen wat het beeld zei en wat de motor terugbracht, gedeeld door de lengte van de waarheid. Een foutenpercentage van 2% op een regel van vijftig tekens is één verkeerd teken. De tekst bestond uit drie regels die proza mengden, een factuurnummer, een datum, een valutabedrag, een e-mailadres en een telefoonnummer, omdat de fouten die er in de praktijk toe doen in de tweede soort inhoud in plaats van de eerste worden gemaakt.
Eén voorbehoud hoort bovenaan in plaats van begraven. Dit zijn gesmolten afbeeldingen, geen foto's. Elk isoleert een enkele variabele, wat de enige manier is om een fout toe te schrijven aan een oorzaak, maar een echte foto van een pagina komt met meerdere tegelijk: een lichte kanteling, ongelijkmatige verlichting over de vouw, bewegingsonscherpte aan één rand en een camera die alles verscherpte voordat ze opslaat. De onderstaande drempels zijn dus de beste gevallen. Een foto die precies op het punt staat op twee assen, zal het slechter doen dan elk nummer doet vermoeden.
De motor is het LSTM-model van Tesseract 4 via Tesseract.js, en dat is precies wat de tool draait, dus dit zijn geen nummers van een ander systeem.
Hoeveel scheef is te veel?
tussen de drie en vijf graden, wat minder tilt is dan je zou merken.
| wenteling | Karakterfoutpercentage | gemeld vertrouwen |
|---|---|---|
| 0 graden | 0,0% | 95 |
| 1 graad | 0,0% | 95 |
| 2 graden | 0,0% | 95 |
| 3 graden | 0,0% | 94 |
| 5 graden | 2,9% | 91 |
| 8 graden | 7,8% | 82 |
| 12 graden | 16,7% | 70 |
| 20 graden | 32,4% | 66 |
Er gebeurt niets gedurende drie graden en dan valt het van een plank. De reden is hoe de engine werkt: hij vindt regels tekst en snijdt vervolgens elke regel in tekens. Een gekantelde lijn kruist verschillende rijen pixels, dus het snijden snijdt door de bovenkant van sommige letters en de onderkant van andere, en het model wordt gevraagd om fragmenten te classificeren.
Bij 5 graden waren de fouten klein en duur. "gedateerd" kwam terug als "dateq" en "totaal" als "totg)". Beide zijn een enkele letter in een woord dat een mens meteen zou lezen, en beide zaten naast een factuurnummer en een valutabedrag dat een persoon zou kopiëren zonder te controleren.
Een telefoon die met de hand wordt vastgehouden, wordt routinematig meer dan vijf graden uitgeleend. Dit is het enige dat de moeite waard is om te repareren voordat je iets uitvoert, en de oplossing is gratis: draai de afbeelding totdat de lijnen waterpas zijn.
Hoe klein kan de tekst zijn voordat OCR faalt?
Kleiner dan je verwacht, tot het punt waarop het helemaal niet meer werkt.
| Afbeeldingsbreedte | Hoogte hoofdletter | error percentage | Vertrouwen |
|---|---|---|---|
| 1600 px | ~29 px | 0,0% | 95 |
| 800 px | ~14 px | 0,0% | 95 |
| 533 px | ~10 px | 0,0% | 92 |
| 400 px | ~7 px | 0,0% | 84 |
| 320 px | ~6 PX | 85,3% | 41 |
| 240 px | ~4 px | 100,0% | 0 |
Dezelfde drie regels lezen perfect op een kwart van hun oorspronkelijke grootte, waarbij elke hoofdletter ongeveer zeven pixels hoog is. Een stap verder naar beneden en de output was onbruikbaar, dan leeg.
Dat is een klif, geen helling, en het verandert het advies. "Gebruik de hoogste resolutie die je hebt" is niet verkeerd, maar het beschrijft een probleem dat de meeste foto's niet hebben. Een screenshot van een webpagina, een foto van een bord, een telefoonfoto van een gedrukte brief: deze hebben allemaal veel meer dan zeven pixels letterhoogte. Wat ze vaker hebben is een tilt.
De plaats die de klif bijt is een gewas van een afstand. Tekst op de achtergrond van een vakantiefoto, een bord over een straat, een lijn van kleine lettertjes in een pagina met volledige pagina's bij schermresolutie. Als de letters moeilijk voor u zijn om te lezen met 100% zoom, is de motor ook in de buurt van de vloer.
Verpest een laag contrast de lezing?
Nee, en dit was het resultaat dat het meest in tegenspraak was met wat ik verwachtte.
Grijze tekst op #8A8A8A op een grijze achtergrond bij #BDBDBD Read terug met een foutenpercentage van 0,0% en een betrouwbaarheid van 95, identiek aan zwart op wit. Een Gaussiaanse onscherpte van drie pixels over het hele beeld gaf 0,6%. Een JPEG opgeslagen op kwaliteit 25 en geschaald naar de halve grootte gaf 0,0%.
De reden is dat de motor uw grijs niet leest. Het binarist het beeld eerst, verandert alles in zwart-wit met een drempel die uit de afbeelding wordt gekozen, en een uniform laag contrast overleeft die stap intact. Wat niet overleeft, is contrast dat over de pagina varieert, wat een schaduw of een telefoonflitser produceert: één drempel kan niet passen bij beide helften van de afbeelding.
Dus de nuttige versie van het verlichtingsadvies is smaller dan de gebruikelijke. Zelfs verlichting is belangrijk. Heldere verlichting niet. Een vage, gelijkmatig verlichte foto van een pagina verslaat een heldere met een schaduw in het midden.
Waarom komt een lay-out met twee kolommen uit de lucht?
Omdat het lezen van volgorde een lay-outoordeel is, en de motor het alleen uit geometrie haalt.
Ik heb twee blokken tekst naast elkaar weergegeven, elk drie lijnen, op gedeelde basislijnen. Het resultaat kwam terug in de ban:
LEFT ONE RIGHT ONE LEFT TWO RIGHT TWO LEFT THREE RIGHT THREE
Elk woord klopt. De bestelling is nutteloos. De motor vond zes regels tekst op drie verticale posities en las elke rij over, wat het juiste gedrag is voor een tabel en de verkeerde voor twee kolommen proza.
Een echte krantenpagina of academische pdf overleeft dit vaak, omdat de goot tussen kolommen breed en consistent genoeg is om de paginasegmentatiestap te detecteren. Een screenshot van een lay-out met twee losse blokken naast elkaar, wat het meest voorkomende geval is voor dit soort tool, doet dat vaak niet.
De betrouwbare oplossing is om bij te snijden. Voer een kolom uit, kopieer het resultaat en voer de andere uit. Het klinkt omslachtig en duurt ongeveer vijftien seconden, wat minder is dan het opnieuw opbouwen van een alinea waarvan de zinnen zijn geschud.
Kan het handschrift lezen?
niet betrouwbaar, en de grens gaat over de vraag of de letters elkaar raken in plaats van of ze er informeel uitzien.
Ik kon het echte handschrift niet testen zonder een foto te leveren, die gemengde variabelen zou hebben, dus ik testte drie lettertypen met afnemende regelmaat als stand-in:
| oliehouder van | error percentage | Vertrouwen |
|---|---|---|
| komisch zonder MS | 0,0% | 95 |
| Borstelscript MT | 5,9% | 67 |
| Snell-rondehand | 20,6% | 55 |
Comic Sans is informeel en perfect leesbaar voor de motor, omdat de letters afzonderlijke vormen zijn van consistente breedte. Snell Roundhand is een verbonden script en een vijfde van de personages kwam verkeerd terug.
Dat is het echte onderscheid. Het model van Tesseract is getraind op het gedrukte type en verwacht een lijn in discrete glyphs te snijden. Verbonden schrijven heeft geen zuivere snijpunten, dus de segmentatie mislukt voordat de herkenning een kans krijgt. Echt handschrift is erger dan Snell Roundhand, niet beter, omdat het ook van letter tot brief varieert.
Als je handschrift moet lezen, is dit het verkeerde hulpmiddel en dat geldt ook voor elke andere Tesseract-front-end. Die baan heeft een model nodig dat is getraind in handschrift.
Welke personages gaat het mis?
Letters die eruitzien als cijfers, en de richting is consistent.
Ik heb een regel van de gebruikelijke verdachten weergegeven en las het terug:
truth: O0 l1I 5S 8B 2Z rn/m
read: 00 111 5S 8B 2Z rn/m
Capital O werd een nul. Kleine letters L en kapitaal I werden beide de cijfer 1. De paren waar mensen zich het meest zorgen over maken, 5 tegen S en 8 tegen B, kwamen correct terug, net als RN tegen M.
Het patroon is dat een geïsoleerde letter met een cijfervormige glyph als het cijfer wordt gelezen. Bij het runnen van proza doet dit zelden ertoe, omdat het taalmodel eromheen het resultaat terugtrekt naar het woord. In een referentiecode, een serienummer of een kentekenplaat is er geen omringend woord om te helpen, en dat is precies waar dit soort gereedschap wordt gebruikt.
Lees elke tekenreeks die letters en cijfers combineert zonder spaties. Het is de enige uitgangsklasse waar de motor vol vertrouwen verkeerd is.
Wat vertelt de betrouwbaarheidsscore je?
Hoe de pagina ging, en niet of het nummer waar je om geeft klopt.
De tool toont het gemiddelde woordvertrouwen van het motorvermogen van het gemiddelde, medium of laag, met een hoogte van 85 en hoger. Tegenover de gemeten foutenpercentages is die mapping in het algemeen verstandig en optimistisch aan de rand:
| geval | Vertrouwen | Label | Echt foutenpercentage |
|---|---|---|---|
| Clean | 95 | geweldig | 0,0% |
| 5 graden scheef | 91 | geweldig | 2,9% |
| 12 graden scheef | 70 | middenweg | 16,7% |
| 320 px breed | 41 | tegen lage prijs | 85,3% |
| Verbonden script | 55 | tegen lage prijs | 20,6% |
Een lage score is een betrouwbare waarschuwing: alles wat scoorde onder de 60 was echt kapot. Een hoge score is zwakker bewijs dan het lijkt. De 5 graden case scoorde 91, die de interface hoog aanroept, terwijl hij stilletjes een woord in een factuurregel vermande.
Gebruik het als een rookmelder in plaats van een garantie. Lage middelen nemen niet de moeite om de output te lezen. Hoog betekent dat de pagina als geheel goed ging, wat niet hetzelfde is als elk personage dat gelijk heeft.
Hoeveel kost elke taal om te downloaden?
Tussen 0,67 en 2,82 megabyte, één keer, en dan wordt het in de cache opgeslagen.
De engine heeft per taal een getraind gegevensbestand nodig. Omdat de tool alleen het LSTM-model uitvoert, trekt het de gehele getal van beste kwaliteit set, die aanzienlijk kleiner is dan de meest OCR-schrijfacties. Gemeten vanaf het CDN De bibliotheek is standaard ingesteld op:
| taal | download | taal | download |
|---|---|---|---|
| Engels | 2,82 MB | Hindi | 1,32 MB |
| Rus | 2,56 MB | Bengalees | 1,31 MB |
| Spaans | 2,00 MB | Koreaans | 1,50 MB |
| Japans | 1,94 MB | Duitser | 1.27 MB |
| Chinees (vereenvoudigd) | 1.64 MB | Portugees | 1,33 MB |
| Arabisch | 1,58 MB | Italiaan | 1,58 MB |
| Frans | 0,67 MB |
Alle dertien samen komen uit op ongeveer 21 MB, wat minder is dan één foto van een moderne telefoon. De algemene veronderstelling dat Chinees of Japans enorm moet zijn, geldt hier niet: Chinees vereenvoudigd is 1,64 MB, kleiner dan Engels, omdat het bestand een model opslaat in plaats van een glyph-bibliotheek.
Waarom is de eerste run langzamer dan de tweede?
Omdat de eerste een engine is die een engine downloadt en start, en de tweede is gewoon aan het lezen.
De eerste versie van een taal haalt de webassembly-build van Tesseract op, haalt dat gegevensbestand van de taal op en initialiseert een werknemer. Daarna blijft de werknemer in leven in de pagina en wordt het gegevensbestand in de cache opgeslagen door de browser, dus een tweede afbeelding in dezelfde taal begint onmiddellijk. Door van talen wisselen, wordt de werknemer opnieuw geïnitialiseerd, maar downloadt niets dat al is opgehaald.
De herkenning zelf is snel. Op deze machine duurde het lezen van de drieregelige testafbeelding 186 milliseconden voor de schone versie en tussen 70 en 125 milliseconden voor de beschadigde, allemaal op een reeds lopende werknemer. Voor een volledige pagina met tekst verwacht u een seconde of twee in plaats van een tiende van één, maar het eerste-run wachten dat u opmerkt, is ingesteld, niet lezen.
Zodra een taal in de cache is opgeslagen, werkt de tool zonder netwerk, wat een echte offline mogelijkheid is in plaats van een marketinglijn.
Wat moet je doen met een afbeelding voordat je OCR uitvoert?
Drie dingen, in deze volgorde, en de eerste is belangrijker dan de andere twee samen.
- Maak het recht. Roteer totdat de tekstregels gelijk zijn. Drie graden is gratis, vijf niet.
- bijsnijden naar de tekst. Dit lost het kolomprobleem op, verwijdert de achtergrond die de segmenter moet afwijzen en maakt de tekst een groter deel van het frame.
- Laat al het andere met rust. Niet slijpen, niet verhogen, het contrast niet verhogen, niet met de hand omzetten in zwart-wit. De motor binareert sowieso en een slijpfilter voegt rinkelen toe rond de letterranden die er voorheen niet waren.
Het ding dat het waard is om toe te voegen in plaats van te verwijderen, is resolutie, maar alleen als je in de buurt van de vloer bent. Van een hoofdhoogte van 7 pixels naar een 14 pixels veranderde niets in de metingen. Van 6 naar 7 gaan veranderde alles.
Wanneer is OCR de verkeerde tool?
Wanneer de afbeelding niet van tekst is, wanneer de tekst met de hand is geschreven en wanneer het ding dat u wilt een doorzoekbaar document is in plaats van een blok tekens.
OCR geeft je de woorden zonder structuur: geen koppen, geen tabelcellen, geen alineagrenzen die je kunt vertrouwen, geen leesvolgorde in een complexe lay-out. Voor een citaat uit een screenshot of een adres van een foto die precies klopt. Voor het converteren van een gescand rapport in iets bewerkbaars, is het de eerste van verschillende stappen.
Als je een beschrijving van een afbeelding wilt in plaats van de woorden die erin zijn afgedrukt, is dat een heel ander model en een ander hulpmiddel. En als de bron een PDF is die is gegenereerd in plaats van gescand, staat de tekst al in het bestand: door hem direct uit te trekken, blijft de lay-out en verliest niets, wat geen enkele hoeveelheid beeldherkenning kan matchen.
Waarom wordt dit uitgevoerd in de browser?
Omdat de foto's die mensen door OCR hebben gemaakt, de foto's zijn die ze het minst willen uploaden.
Ontvangsten, bankbrieven, recepten, paspoorten, ID-kaarten, een foto van een contract, een screenshot van een privégesprek. Het gebruikelijke alternatief is een site die uw afbeelding neemt, verwerkt op een server waar u niets vanaf weet en alles behoudt.
Hier is de engine webassembly die in de pagina draait, in een werknemer. De afbeelding wordt gedecodeerd in het tabgeheugen, lees daar en de tekst verschijnt. Er wordt niets geüpload, er is geen wachtrij en geen opgeslagen kopie, en na de eerste run werkt het hele ding offline. De kosten zijn de eenmalige taaldownload en dat zeer grote afbeeldingen worden beperkt door wat het tabblad kan bevatten.
Twee dingen die deze site nog niet doet, en die thuishoren in dezelfde pijplijn: een gefotografeerde pagina rechttrekken en bijsnijden tot de tekst. Beide moeten gebeuren in welke kijker je al hebt, wat de enige onhandige naad is in de workflow hierboven. Wat erna komt, komt aan bod: als de bron een foto van verschillende pagina's is, De gids over het combineren van afbeeldingen gaat over het terugbrengen van de resultaten.
