EasyOCR-beoordeling: sterke resultaten op schone tekst, een duidelijke groottegrens en een CPU-proces van 1 GB

EasyOCR is JaidedAI’s kant-en-klare OCR-bibliotheek voor Python: pip install easyocr, twee regels code, en de tekst in een afbeelding komt terug als strings. De tool heeft een Apache-2.0-licentie, ondersteunt meer dan 80 talen en draait als een pipeline van twee PyTorch-modellen: eerst een CRAFT-detector die vakken tekent rond alles wat als tekst wordt herkend, daarna een recognizer die de karakters in elk vak leest. De vooraf getrainde gewichten worden automatisch gedownload zodra je de tool voor het eerst aanroept. In de praktijk is dit een self-hosted alternatief voor Tesseract en PaddleOCR, niet een cloud-OCR-API per pagina.

De basis-API is kort: Reader(['en']), daarna readtext(). De deployment is echter zwaarder: ongeveer 2 GB aan PyTorch in deze omgeving en grofweg een gigabyte piekgeheugen in een verse CPU-processessie. Ik renderde 36 Engelse PNG-testbestanden, draaide easyocr 1.7.2 op CPU en vergeleek de output teken voor teken met gegenereerde ground truth. Grootte en oriëntatie veroorzaakten de grootste CER-terugvallen; het dashboard bracht ook fouten aan het licht in de detectie van korte tokens en in het herkennen van dollartekens.

De scherpste van die fouten draait om de parameter die iedereen aanbeveelt. rotation_info staat op de issue tracker bekend als dé oplossing voor gedraaide afbeeldingen, dus ik testte drie orthogonaal gedraaide versies van dezelfde zin. Bij 270° deed het precies wat het belooft: de character error rate zakte van 0,83 naar 0,10. Bij 180° werkte het half: 0,85 naar 0,67, met een stuk zin dat wegviel. Bij 90° ging het juist achteruit: 0,81 naar 0,92, en de recognizer begon spiegeltekst terug te geven. Zelfde parameter, zelfde lijst met hoeken, drie verschillende uitkomsten — dus hem inschakelen betekent niet automatisch dat “rotatie is opgelost”. Uit dezelfde 36 fixtures kwamen ook een harde grens voor lettergrootte, een systematische mislezing van $, en één voorspelling van mij die gewoon fout bleek.

Twee modellen in één jas

EasyOCR is niet één model. Het is een pipeline van twee modellen, en weten welk onderdeel faalde, bepaalt hoe je debugt.

Stap één is CRAFT, de detector. Die heeft maar één taak: lokaliseren waar in de afbeelding tekst staat en daar boxen voor teruggeven. Hij leest nooit een karakter. Stap twee is een CRNN recognizer — ResNet-feature-extractie, daarna een BiLSTM, daarna CTC greedy decoding — die de karakters binnen elke box leest. Beide draaien op PyTorch. Op CPU draait de recognizer standaard dynamisch gequantiseerd naar int8, en daarom is hij sneller en lichter dan de ruwe parametercount doet vermoeden.

De praktische consequentie: EasyOCR heeft twee totaal verschillende faalmodi, en daar horen ook verschillende oplossingen bij. Als de detector nooit een box tekent, helpt het niet om aan de recognizer te sleutelen — de karakters kwamen simpelweg nooit in de pipeline. Als de box er wel is maar de string fout is, dan zit het probleem in herkenning en kan voorbewerking helpen. Bijna elk “EasyOCR mist mijn tekst”-topic dat ik heb gelezen, haalt die twee door elkaar.

Huidige projectstatus, gecontroleerd op 27 juli 2026: 29.825 sterren, 528 open issues, Apache-2.0, en v1.7.2 uit september 2024, met de laatste push naar master in december 2025. Die data bewijzen geen architecturale stabiliteit of onderhoudsgezondheid. Controleer vóór adoptie de compatibiliteit met je Python/PyTorch-stack, de recente respons van maintainers en issues die relevant zijn voor jouw input.

OCR wordt vaak in verband gebracht met CAPTCHA’s, maar dat is hier niet de use case. Er is niets getest tegen bot-detectie-uitdagingen, en niets hier is een goedkeuring van het omzeilen daarvan. De scope is het lezen van tekst uit afbeeldingen en screenshots die je rechtmatig mag lezen.

Wat ik heb gemeten, en wat deze cijfers níét dekken

De testset bestaat uit 36 door mij gerenderde PNG’s: 35 single-line afbeeldingen over zeven fonts, acht groottes, zeven contrastniveaus, zeven skew-hoeken, drie orthogonale rotaties en drie achtergronden — plus één synthetische dashboard-screenshot met 19 afzonderlijk gelabelde elementen. Elke afbeelding werd gegenereerd vanuit dezelfde vaste string (Sphinx of black quartz, judge my vow. 1234567890 — 48 tekens, gemengde hoofdletters/kleine letters, cijfers, interpunctie) in dezelfde stap waarin ook het ground-truth-label werd weggeschreven, dus afbeelding en label kunnen fysiek niet uit elkaar lopen.

De nauwkeurigheid meet ik met character error rate (CER): Levenshtein-afstand in tekens gedeeld door de lengte van de ground truth. CER 0 betekent perfect gelezen. CER 0,10 betekent ongeveer één fout op tien tekens. Ik rapporteer case-sensitive CER als hoofdwaarde en daarnaast case-insensitive, omdat juist daar de meeste “fouten” blijken te zitten.

De grenzen zijn belangrijker dan de cijfers:

• Alleen Engels. De english_g2 recognizer. EasyOCR noemt meer dan 80 talen; ik testte er één. Hieruit kun je niets afleiden over niet-Latijnse scripts, en juist daar zitten de gepubliceerde academische OCR-vergelijkingen.
• Alleen synthetisch. Gerenderde tekst, geen foto’s. Geen cameraruïs, geen JPEG-artefacten, geen lichtproblemen, geen perspectief.
• Geen handschrift. Het project zelf vermeldt handschrift als nog niet ondersteund.
• Alleen CPU. macOS arm64, gpu=False. MPS was beschikbaar op de machine, maar EasyOCR gebruikt CPU op alles wat geen CUDA is. GPU-prestaties zijn nooit gemeten, dus hier staat geen GPU-cijfer.
• Eén machine, één versie. easyocr 1.7.2, torch 2.13.0, Python 3.12.

Dus: dit zijn gecontroleerde curves met één variabele tegelijk, die precies laten zien waar de kwaliteit breekt op schone, gerenderde Latijnse tekst. Het is geen score op een echte dataset, en vervangt zo’n score ook niet.

De onderliggende bewijsstukken zitten niet verstopt in een notebook, maar zijn inspecteerbaar. De fixture-generator en exacte strings staan in tests/build_fixtures.py en tests/fixtures/ground_truth.json; herkenning, timing en resource-capturing staan in tests/run_easyocr.py; en tests/metrics.py berekent de gerapporteerde foutpercentages op basis van de ruwe output. De resulterende herkenningsrecords en geaggregeerde metrics zijn bewaard onder artifacts/raw/. Die keten opnieuw draaien is nuttig om deze machine en versie te controleren. Het zegt nog steeds niets over hoe EasyOCR zich gedraagt op jouw telefoonfoto’s, talen, lay-outs of pre-processing pipeline, dus productieacceptatie moet representatieve inputs meenemen in plaats van deze fixtures als certificeringssuite te zien.

Eén valkuil in de testopzet is het vermelden waard, omdat die bijna tot een fout hoofdcijfer leidde. Mijn eerste metrics-pass rapporteerde CER 0,375 op schone zwarte Arial, wat verschrikkelijk is voor de simpelste input die je maar kunt bedenken. Het lag niet aan EasyOCR. De detector had één visuele regel opgesplitst in een woorden-box en een cijfers-box, en mijn naïeve sorteer-op-y-dan-x-join zette de cijfers eerst. Dat is opgelost met line-aware grouping (boxen groeperen op verticale overlap en daarna van links naar rechts lezen), waarna schone fonts uitkwamen rond 0,04–0,10. Als je zelf een OCR-evaluatie bouwt, ligt die valkuil ook op je te wachten.

Setup: de installatie is klein, de dependency niet

pip install easyocr

Dat is alles, en dat is eerlijk over maar weinig zaken. Het pakket zelf is simpel; wat het meeneemt is PyTorch, ongeveer 2 GB. De eerste keer dat je readtext() aanroept, downloadt EasyOCR stilletjes zijn gewichten naar ~/.EasyOCR/model/ — in totaal 93,7 MiB, opgesplitst in 79,30 MiB voor de CRAFT-detector (craft_mlt_25k.pth) en 14,44 MiB voor de Engelse recognizer (english_g2.pth).

Dat staat nergens duidelijk in tutorials, dus: je eerste run heeft netwerktoegang nodig en pauzeert voor de download, en elke containerdeployment moet die gewichten óf in de image bakken óf bij een cold start de download accepteren. Eenmaal gecachet draait alles offline.

Een koude Reader()-initialisatie — modellen van disk naar RAM, plus de int8-quantisatiepass — kostte 1,3–1,7 seconden over meerdere runs. Daarna:

import easyocr
reader = easyocr.Reader(['en'], gpu=False)
result = reader.readtext('screenshot.png')

En het werkt. Twee regels, niets te configureren, geen checkpoint om te gaan zoeken. De “easy” in de naam is op dit niveau verdiend — de frictie zit volledig in de zwaarte van de dependency, niet in de API.

De ondergrens voor schone tekst: bijna perfecte karakters, maar geen perfecte kapitalisatie

Zeven systeemfonts, zwart op wit, 32 px, telkens dezelfde string:

Gemiddelde CER van 0,071, teruglopend naar 0,024 zodra je hoofdletters/kleine letters negeert. Dáár zit de kern. EasyOCR verliest op schone Latijnse tekst nauwelijks karakters — het krijgt de vorm goed en de case fout.

Concreet: het zet het kleine woord vow in zes van de zeven fonts om naar VOW (Comic Sans maakt er Vow van). Impact maakt er bovendien nog of → Of van. De andere terugkerende fout is interpunctie: de punt aan het einde van de zin komt in meerdere fonts terug als : of _. Georgia is een perfecte leesresultaat zodra je kapitalisatie buiten beschouwing laat.

Dat is echt nuttige informatie. Als je downstream-stap fuzzy matching, keyword search of input voor een taalmodel is, kost een case-swap je bijna niets. Als je downstream-stap een exacte stringvergelijking met een databasekey is, kost het je alles. Normaliseer case vóór je vergelijkt, en de helft van de schijnbare fout van EasyOCR verdwijnt.

Dat Courier de slechtste is (0,1042) klopt ook logisch: monospace fonts zetten spaties onnatuurlijk breed, en dat is lastiger voor een CTC-decoder die normale letterafstand heeft geleerd.

De groottegrens ligt precies waar de docs zeggen dat die ligt

readtext() heeft een gedocumenteerde parameter, min_size=10, die gedetecteerde boxen onder 10 pixels weggooit. De meeste mensen scrollen daar langs. Voor iedereen die screenshots of PDF’s extraheert is dit het meest invloedrijke getal in de API, en dit is wat er gebeurt als je de gerenderde glyphhoogte doorloopt:

De sprong van 0,04 naar 0,77 tussen 12 px en 8 px is geen geleidelijke achteruitgang. Het is een filter dat precies doet wat is gedocumenteerd, met als gevolg dat tekst onder ongeveer 10 px voor de standaardinstellingen van EasyOCR praktisch onzichtbaar is.

De sweet spot ligt tussen 12–28 px, met een volledige CER van 0 op 16 px. Boven 40 px loopt de CER weer iets op — niet omdat de karakters verdwijnen, maar omdat de vow → VOW-omzetting terugkomt. Grote tekst is niet moeilijker te lezen; hij profiteert alleen niet meer van de letterafstand waardoor 16 px precies goed uitkwam.

Voor iedereen die tekst uit screenshots haalt: controleer je glyphhoogte voordat je het model de schuld geeft. Een dashboard dat op een HiDPI-scherm op 1× wordt vastgelegd, of een PDF-pagina die op 72 DPI wordt gerasterd, zet bodytekst vaak onder 10 px. Capture op 2× of upscale vóór OCR, en je slaat een hele categorie “EasyOCR negeerde de helft van mijn pagina”-bugs over. Als dat niet kan, verlaag dan min_size — maar reken op meer ruis, want die filter bestaat juist om rommel-detecties tegen te houden.

Rotatie: tolerantie tot 10° en een fix die niet symmetrisch is

Eerst skew. Kleine hoeken, Arial 32 px, standaardinstellingen versus rotation_info=[90,180,270]:

Standaard EasyOCR verwerkt skew tot ongeveer 10° zonder problemen (CER ≤ 0,083), begint te wankelen bij 15° en is bij 20° praktisch verloren. rotation_info doet niets voor skew, en dat is logisch zodra je weet wat het doet: het probeert alleen opnieuw op de hoeken die jij opgeeft, en een skew van 15° is geen 90, 180 of 270. Bij 10° maakte het juist iets slechter (0,021 → 0,083), omdat een herstart op de verkeerde hoek de confidence vote kan winnen.

De orthogonale rotaties worden pas echt vreemd:

Zelfde parameter. Zelfde lijst met hoeken. Drie verschillende uitkomsten.

Bij 270° doet rotation_info precies wat de issue-thread belooft: CER daalt van 0,83 naar 0,10, dus echt bruikbaar. Bij 180° werkt het half — CER verbetert naar 0,67, maar de frase my vow. valt helemaal weg. Bij 90° gaat het achteruit, van 0,81 naar 0,92, en de ruwe output laat zien waarom: de recognizer geeft gespiegelde strings terug. VOW komt terug als MOA. quartz komt terug als zuuenb. Lees je dat in een spiegel, dan klopt het, wat een leuk kunstje is maar een nutteloze datapipe.

Ik heb dit gecheckt aan de hand van de ruwe predictions in plaats van op de geaggregeerde metrics, omdat “de join-volgorde heeft het gemixt” mijn eerste vermoeden was. Het is geen join-artefact — dit is wat EasyOCR werkelijk teruggaf.

Het mechanisme is een hypothese, geen meting; er is geen experiment gedaan naar rotatieconventies. Pillow rendert positieve hoeken tegen de klok in, dus alleen de op 270° gerenderde afbeelding sluit toevallig aan op een retry-orientatie die de recognizer goed verwerkt, en het 90°-geval eindigt met de best scorende retry op een omgekeerde oriëntatie. Wat het mechanisme ook precies is, de operationele les verandert niet:

Deze fixture laat zien dat je er niet van uit kunt gaan dat rotation_info symmetrisch werkt over oriëntaties. Valideer de rotaties die je in je input verwacht; normalisatie van de oriëntatie upstream is een mogelijke mitigatie, geen eis die door drie gerenderde voorbeelden is bewezen.

De voorspelling die ik fout had

Ik verwachtte vooraf dat laag contrast EasyOCR’s zwakke plek zou zijn. Flets grijs op wit is hét klassieke OCR-probleem, en er is ook een documenteerde reddingsroute voor: contrast_ths=0.1 met adjust_contrast=0.5, waarmee low-contrast boxen opnieuw worden verwerkt met een versterkte kopie en het meest zekere resultaat wordt gekozen.

Die route kwam nooit in actie, omdat hij niet nodig was.

CER verlaat de schone band niet, zelfs niet tot Weber 0,14 — grijs-220 op wit, zo vaag dat ik op de fixture moest turen om te zien of de tekst er echt stond. En de contrast-boost-kolom is op elk punt identiek aan de standaardkolom, omdat de standaardinstelling al goed genoeg was.

De achtergronden vertelden hetzelfde verhaal. Zwarte tekst overal:

Een perfecte read op de ruisigste fixture van de set.

De scope is smal: dit is laag contrast in egale, ruisvrije vorm, niet een gefotografeerd kassabonnetje met sensorruis en JPEG-compressie. In deze fixture-set zorgden geometrie en korte tokens voor de grootste fouten; de geteste kleur- en synthetische-ruisvarianten deden dat niet.

Een realistische situatie: cijfers uit een dashboard-screenshot halen

Dit is in de praktijk waar Python-OCR vaak op neerkomt. Iemand stuurt een screenshot van een intern dashboard, of je draait een Python scraping pipeline tegen een analytics-pagina vol grafieken waarvan de cijfers alleen als gerenderde pixels bestaan, en je wilt die waarden als data.

Ik renderde een venster “Sales Dashboard” — donkere header met titel en een ronde avatar-badge, drie KPI-panelen, drie knoppen, een 2×3 tabel — en labelde alle 19 tekstelementen met hun exacte strings en pixelboxen, waarna ik de output van EasyOCR op basis van box-overlap koppelde.

Detection recall: 16 van 19. De drie misses:

• de enkele letter in de badge, “A”
• de tabelcel “Q1”
• de tabelcel “Q2”

En “Q3” werd wél gedetecteerd. Zelfde font, zelfde grootte, zelfde kolom — de detector hield één token van twee tekens vast en liet twee andere vallen. Detectie was inconsistent over visueel vergelijkbare cellen. Omdat de output in deze runs deterministisch was, is dit geen bewijs van willekeurig “kop-of-munt”-gedrag. Een verwant screenshot-kwaliteitsprobleem staat in #460.

Van de 16 elementen die hij wel vond, was de tekst bijna perfect: gemiddelde CER 0,027, met 13 van de 16 exact goed. Titels, labels, knoppen (“Save”, “Cancel”, “Export CSV”), kolomkoppen en getallen met komma’s kwamen allemaal terug met CER 0. 1,284 werd correct gelezen, komma inbegrepen.

De drie imperfecte reads zijn allemaal dezelfde fout. Dollarbedragen:

Drie van de vier dollartekens werden een hoofdletter S. Visueel is dat nog verdedigbaar, maar het betekent wel dat elk valuta-veld in je extractie één teken verwijderd is van rommel, en een naïeve float() crasht op allemaal.

Als je screenshot-pipeline korte labels of valuta bevat, test dan mogelijke mitigaties zoals upscaling, gepadde crops, beperkte veldverwachtingen of symboolbewuste post-processing. Niets daarvan is hier gebenchmarkt, en een regex die een vooraanstaande S vervangt kan geldige waarden beschadigen. Pas correcties alleen toe waar schema en validatieregels ze veilig maken.

Wat het kost om te draaien

Cijfers op dezelfde machine (macOS arm64, CPU, één host, gemeten onder mogelijk gelijktijdige belasting — zie dit als een vormindicatie, niet als universele benchmark):

De grootste kostenpost zijn niet de 94 MB aan gewichten — het is ongeveer een gigabyte resident memory per workerproces, bovenop een ~2 GB torch-installatie. Dat is het getal dat bepaalt of dit in je container past, en dat is ook het getal dat vrijwel niemand noemt.

Snelheid is prima voor het makkelijke geval. Onder de 0,1 seconde warm voor één schone regel op CPU is heel bruikbaar. Maar dat is het makkelijke geval: één korte, hoog-contrast regel. De terugkerende “EasyOCR duurt tientallen seconden op CPU”-klachten gaan over grote documenten met meerdere regio’s op volledige canvasgrootte, en dat heb ik niet gereproduceerd — ander werkprofiel, en ik noem het hier, ik claim het niet.

Eén kleine mythe om te ontkrachten: detail=0 maakt EasyOCR niet sneller. Het haalt alleen boxen en confidence-scores uit de returnwaarde. Het rekenwerk is dan al gedaan. Medians verschillen met een milliseconde, en dat is ruis.

Voor- en nadelen

Voordelen

• Character recall op schone, gerenderde Latijnse tekst is vrijwel perfect — gemiddelde CER 0,071 case-sensitive, 0,024 case-insensitive, met een volledige CER van 0 op 16 px.
• Echt een API van twee regels. Reader(['en']) en daarna readtext(), zonder configuratie en zonder modelkeuze.
• Veel robuuster tegen contrast dan de folklore doet vermoeden: geen instorting tot Weber 0,14 op schone tekst, en noisy/gradient/gekleurde achtergronden maakten geen verschil (de gaussian-noise-fixture was zelfs perfect).
• Bijna perfect op screenshot-elementen die wel worden gedetecteerd: gemiddelde CER 0,027, 13 van de 16 exact goed, inclusief getallen met komma’s.
• Deterministisch. Elk nauwkeurigheidsgetal hier was byte-identiek over twee volledig onafhankelijke process-runs; alleen timing bewoog.
• Apache-2.0 en self-hosted, zonder gebruiksfee voor een vendor; compute, memory, storage en queueing blijven operationele kosten.

Nadelen

• Harde instorting onder de gedocumenteerde min_size=10-grens — CER 0,77 bij 8 px. Kleine UI-tekst is standaard onzichtbaar.
• Skew-tolerantie stopt rond 10° en stort in bij 20°.
• rotation_info is geen symmetrische fix: 270° herstelt, 180° herstelt deels, 90° wordt slechter en geeft spiegeltekst terug.
• De detector laat geïsoleerde korte tokens vallen — een badge van één letter en twee cellen van 2 tekens, terwijl een derde cel met hetzelfde formaat wel blijft staan.
• Systematische $ → S-mislezing op valutawaarden (3 van 4).
• Ongeveer 1 GB resident memory per proces, plus een ~2 GB torch-dependency.
• De nieuwste release is van september 2024; het project is stabieler dan actief in beweging.

Wie het wel moet gebruiken, en wie beter afhaakt

Evalueer EasyOCR wanneer je inputs schoon, rechtop en op redelijke grootte gerenderde tekst zijn — screenshots, UI-captures, gerasterde PDF’s of gegenereerde rapporten — en je een self-hosted Python-pipeline wilt zonder vendor usage fee. De synthetische Engelse CPU-resultaten gelden voor precies dat scenario; foto’s, handschrift en andere scripts vragen om aparte tests.

Loop weg als je inputs één van deze dingen zijn. Foto’s — mijn cijfers gaan over synthetisch gerenderde tekst en zeggen niets over cameraruïs, perspectief of licht. Handschrift — het project claimt dat zelf ook niet. Niet-Latijnse scripts — EasyOCR ondersteunt meer dan 80 talen, maar ik testte er één, en de gepubliceerde academische vergelijkingen zijn daar de referentie, niet een synthetische Engelse sweep. Arbitrair gedraaide inputs — tenzij je zelf eerst oriëntatiecorrectie doet. Memory-beperkte deployments — een gigabyte per worker loopt snel op.

Controleer vóór je OCR kiest de DOM en de netwerkresponses. Als de gewenste waarden al als gestructureerde tekst bestaan, vermijd je met extractie vanaf die bron de detectie- en herkenningsfouten van OCR. OCR hoort thuis waar pixels de enige beschikbare representatie zijn.

Alternatieven, en waar onze stack past

EasyOCR is Apache-2.0 en self-hosted, zonder gebruiksfee voor een vendor maar met reële compute- en operationele kosten. PaddleOCR, Tesseract en vision-language-modellen zijn niet door deze benchmark gehaald, dus er wordt hier geen head-to-head conclusie getrokken.

De interessantere vergelijking is niet OCR versus OCR. Het is: moet je überhaupt OCR doen?

Het meeste screenshot-extractiewerk dat ik zie is een workaround voor een webpagina die lastig te scrapen was — een JavaScript-gerenderde tabel, een dashboard achter login, een site die tegenwerkt. Screenshotten en OCR’en voelt als de weg van de minste weerstand, maar je gooit prima gestructureerde tekst weg en betaalt daarna een dollartekenbelasting om een slechtere versie terug te krijgen.

Auteursnoot: Thunderbit is onze managed optie voor extractie van webpagina’s. Deze is niet door deze image-fixtures gehaald. De relevante grens is de representatie van de bron: gebruik DOM-/netwerkextractie wanneer gestructureerde webdata bestaat, en evalueer OCR wanneer pixels de enige bron zijn.

Verder lezen uit dezelfde testbench: de volledige vergelijking van open-source scrapers, de Crawl4AI-beoordeling, en een bredere blik op AI-gedreven extractie voor pagina’s die selectors tegenwerken.

Probeer Thunderbit voor webdata-extractie

Oordeel

Moet je EasyOCR gebruiken? Ja, als je afbeeldingen rechtop staan, je glyphs minstens 12 pixels hoog zijn en je Latijns schrift leest. Binnen die grenzen is het erg goed — gemiddelde CER 0,071 op schone tekst, 0,024 zodra je case normaliseert, perfect op 16 px, en met meer contrastrobustheid dan zijn reputatie suggereert. De API bestaat echt uit twee regels en de output is deterministisch, wat belangrijker is dan veel mensen toegeven wanneer je een pipeline debugt.

Buiten die grenzen faalt het op specifieke, leerbare manieren. Tekst onder 10 px verdwijnt in de min_size-filter. Skew boven 20° maakt de read kapot. rotation_info lost één orthogonale oriëntatie op, half een tweede, en maakt de derde erger met spiegeltekst. Enkele letters en tokens van twee tekens vallen uit de detector terwijl hun buren blijven staan. Dollartekens worden de letter S.

De fixture-fouten kwamen uit beide stappen: gemiste of verkeerd georiënteerde boxen aan de geometriekant, en dollar-tekenverwarring aan de herkenningskant. Zie upscaling, oriëntatienormalisatie, gepadde crops en schema-bewuste symboolreparatie als kandidaten om te valideren, niet als universeel veilige fixes.

Test het alleen niet zoals ik bijna deed, met een kapotte evaluatieharnas en een getal dat je niet begrijpt. Render je eigen fixtures, ken je ground truth exact en vind je eigen cliff.

Probeer Thunderbit voor webdata-extractie Get Started Free

FAQs

Is EasyOCR nauwkeurig genoeg voor productie-extractie van screenshottekst? Op het synthetische dashboard hadden de gematchte elementen een gemiddelde CER van 0,027, met 13 van de 16 exact goed. Drie van de 19 elementen werden niet gedetecteerd, en drie van de vier dollartekens werden S. Of dat acceptabel is — en of upscaling of schema-bewuste reparatie helpt — moet je testen op de doelindelingen.

Wat is de minimale lettergrootte die EasyOCR kan lezen? Praktisch gezien ongeveer 12 pixels aan gerenderde glyphhoogte. De parameter min_size=10 in readtext() gooit boxen onder 10 px weg, en het effect is een klif in plaats van een helling: CER was 0,77 bij 8 px, 0,15 bij 10 px, 0,04 bij 12 px en 0 bij 16 px. De schone band in mijn sweep lag tussen 12–28 px. Als je bron een HiDPI-screenshot op 1× is of een PDF die op 72 DPI is gerasterd, upscale dan vóór OCR in plaats van min_size te verlagen, want die filter bestaat juist om rommel-detecties weg te houden.

Lost rotation_info gedraaide afbeeldingen op in EasyOCR? Niet betrouwbaar, en niet symmetrisch. Met rotation_info=[90,180,270] op drie orthogonaal gedraaide kopieën van dezelfde zin herstelde de 270°-afbeelding netjes (CER 0,83 → 0,10), de 180°-afbeelding slechts gedeeltelijk (0,85 → 0,67, met een frase die wegviel), en de 90°-afbeelding werd slechter (0,81 → 0,92) terwijl spiegeltekst terugkwam zoals VOW → MOA. Het doet ook niets voor kleine skew-hoeken, omdat het alleen opnieuw probeert op de hoeken die je opgeeft. Corrigeer de oriëntatie vóór je EasyOCR aanroept in plaats van op deze parameter te vertrouwen.

Hoeveel geheugen en disk heeft EasyOCR nodig? De gewichten zijn 93,7 MiB en worden bij eerste gebruik gedownload naar ~/.EasyOCR/model/ — 79,30 MiB voor de detector plus 14,44 MiB voor de Engelse recognizer. De piek-resident memory in de gemeten verse CPU-processessie was 984,5 MiB, bovenop een torch-installatie van ongeveer 2 GB. Een koude reader-initialisatie duurde 1,3–1,7 seconde; een schone enkele regel liep daarna op deze machine met een p50 rond 0,062 seconde. detail=0 veranderde de vorm van de returnwaarde, niet de gemeten runtime.

Is EasyOCR gratis voor commercieel gebruik, en wordt het nog onderhouden? Ja, het heeft een Apache-2.0-licentie, dus het is permissief en commercieel vriendelijk. Op 27 juli 2026 staat de repository op 29.825 sterren met 528 open issues, de nieuwste release is v1.7.2 uit september 2024, en de laatste push naar master was in december 2025. Lees dat als stabiel in plaats van verlaten — de architectuur is al een tijd onveranderd en de activiteit zit vooral in de issue tracker. Controleer zelf de actuele licentie en release-status voordat je erop bouwt.