Reseña de EasyOCR: muy buen rendimiento con texto limpio, un techo brusco por tamaño y un proceso CPU de 1 GB

EasyOCR es la librería OCR de JaidedAI para Python: pip install easyocr, dos líneas, y el texto de una imagen vuelve como cadenas. Apache-2.0, más de 80 idiomas anunciados, y por dentro un pipeline de dos modelos PyTorch: un detector CRAFT que dibuja cajas sobre lo que cree que es texto, y un reconocedor que lee los caracteres de cada caja. Los pesos se descargan solos al primer uso. Es una alternativa autoalojada a Tesseract y PaddleOCR, no una API de OCR en la nube que cobra por página.

La API es cortísima: Reader(['en']) y readtext(). El despliegue pesa más: PyTorch ocupa unos 2 GB, y la memoria residente máxima en el proceso recién iniciado ronda el gigabyte. Rendericé 36 fixtures PNG en inglés, corrí easyocr 1.7.2 en CPU y puntué carácter por carácter contra una referencia generada. Tamaño y orientación provocaron las mayores caídas de precisión; el panel también reveló fallos en tokens cortos y errores con el símbolo del dólar.

El fallo más llamativo apareció en el parámetro que todos recomiendan. rotation_info tiene fama de ser la solución para imágenes rotadas, así que le di tres copias de la misma frase giradas en ángulos ortogonales. A 270° cumplió su promesa: de 0,83 a 0,10. A 180° a medias: de 0,85 a 0,67, con una frase perdida. A 90° fue al revés, de 0,81 a 0,92, y el reconocedor devolvió texto en espejo. Mismo parámetro, mismos ángulos, tres resultados: activarlo no significa que "la rotación ya está resuelta". Los mismos fixtures mostraron además un precipicio de tamaño de fuente y una confusión sistemática con el dólar.

Dos modelos disfrazados de uno

EasyOCR no es un solo modelo, sino un pipeline de dos etapas, y saber cuál falló cambia cómo lo depuras.

La primera etapa es CRAFT, el detector: solo localiza, decide dónde hay texto y devuelve cajas. Nunca lee un carácter. La segunda es un reconocedor CRNN: ResNet, luego BiLSTM y decodificación CTC greedy, que lee los caracteres de cada caja. Ambas corren sobre PyTorch. En CPU, el reconocedor usa por defecto cuantización dinámica a int8, por eso es más rápido y ligero de lo que sugiere su número de parámetros.

La consecuencia práctica: EasyOCR tiene dos modos de fallo distintos, y cada uno necesita su propio arreglo. Si el detector nunca dibuja una caja, ajustar el reconocedor no sirve. Si la caja existe pero la cadena está mal, es un problema de reconocimiento y el preprocesado puede ayudar. Casi todos los hilos de "EasyOCR se saltó mi texto" mezclan ambos casos.

Estado del proyecto al 27 de julio de 2026: 29.825 estrellas, 528 issues abiertos, Apache-2.0, y v1.7.2 de septiembre de 2024, último push a master en diciembre de 2025. Estas fechas no demuestran salud del mantenimiento; antes de adoptarlo, comprueba compatibilidad con tu stack y los issues relevantes.

El OCR suele asociarse con resolver CAPTCHAs, y ese no es el caso aquí. No se probó nada contra retos anti-bot, y nada de este análisis avala saltarse ese tipo de detección. El alcance es leer texto de imágenes y capturas que tienes derecho a leer.

Qué medí, y lo que estos números no cubren

El conjunto de prueba son 36 PNG renderizados por mí: 35 imágenes de una línea que recorren siete fuentes, ocho tamaños, siete contrastes, siete inclinaciones, tres rotaciones ortogonales y tres fondos, más una captura sintética de un panel con 19 elementos etiquetados. Cada imagen se generó desde una cadena fija (Sphinx of black quartz, judge my vow. 1234567890, 48 caracteres, mayúsculas, minúsculas, dígitos y puntuación) en el mismo paso que la etiqueta de referencia, así que no pueden desincronizarse.

La precisión se mide como tasa de error de caracteres (CER): distancia de Levenshtein entre caracteres dividida entre la longitud de referencia. CER 0 es lectura perfecta; CER 0,10 significa que uno de cada diez caracteres falla. Reporto la CER sensible a mayúsculas como cifra principal, y la insensible al lado, porque buena parte del error vive ahí.

Los límites importan más que las cifras:

• Solo inglés. Reconocedor english_g2. EasyOCR anuncia más de 80 idiomas; probé uno. Nada habla de escrituras no latinas, donde se concentran las comparaciones académicas de OCR.
• Solo sintético. Texto renderizado, no fotografías: sin ruido de cámara, artefactos JPEG, iluminación ni perspectiva.
• Sin escritura a mano. El proyecto la lista como no soportada aún.
• Solo CPU. macOS arm64, gpu=False. Había MPS disponible, pero EasyOCR usa CPU salvo con CUDA. No hay cifra de GPU aquí.
• Una máquina, una versión. easyocr 1.7.2, torch 2.13.0, Python 3.12.

Son curvas controladas de una sola variable que muestran dónde se rompe la fidelidad sobre texto latino limpio. No son una puntuación de corpus real, ni la sustituyen.

La evidencia es inspeccionable. El generador de fixtures y las cadenas están en tests/build_fixtures.py y tests/fixtures/ground_truth.json; tiempos y recursos en tests/run_easyocr.py; tests/metrics.py calcula las tasas de error desde la salida en bruto, y los registros se conservan en artifacts/raw/. Repetir esa cadena verifica esta máquina y versión, pero no dice cómo se comportará con fotos u otros idiomas: la aceptación en producción debe añadir entradas representativas, no tratar estos fixtures como certificación.

Una trampa del harness casi produce un titular equivocado. Mi primera pasada dio CER 0,375 en Arial negro limpio, pésimo para la entrada más fácil posible. No era EasyOCR: el detector dividió una línea en caja de palabras y caja de dígitos, y mi ordenación por y-luego-x ponía los dígitos primero. Agrupando por solapamiento vertical y leyendo de izquierda a derecha, las fuentes limpias cayeron a 0,04–0,10. Esa trampa espera a cualquiera que construya su propia evaluación de OCR.

Instalación: el paquete es pequeño, la dependencia no

pip install easyocr

Eso es todo, y solo es sincero en parte. El paquete es trivial; lo que arrastra es PyTorch, unos 2 GB. Al primer readtext(), EasyOCR descarga en silencio sus pesos a ~/.EasyOCR/model/: 93,7 MiB en total, 79,30 MiB para el detector (craft_mlt_25k.pth) y 14,44 MiB para el reconocedor en inglés (english_g2.pth).

Casi ningún tutorial lo menciona: la primera ejecución necesita red y se detiene a descargar, y cada contenedor debe incluir esos pesos en la imagen o pagar la descarga en frío. Cacheados, todo funciona sin conexión.

La inicialización en frío de Reader() —cargar modelos a RAM más la cuantización int8— tardó 1,3–1,7 s:

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

Dos líneas, nada que configurar, ningún checkpoint que buscar. El "easy" del nombre se gana aquí; la fricción está en el peso de la dependencia, no en la API.

El suelo del texto limpio: caracteres casi perfectos, mayúsculas imperfectas

Siete fuentes del sistema, negro sobre blanco, 32 px, siempre la misma cadena:

Media de 0,071, que baja a 0,024 al normalizar mayúsculas. Ese salto es el hallazgo: EasyOCR no pierde caracteres en texto latino limpio, acierta la forma y falla en las mayúsculas.

Devuelve vow como VOW en seis de siete fuentes (Comic Sans transige con Vow); Impact además cambia of por Of. El otro error recurrente es puntuación: el punto final vuelve como : o _ en varias fuentes. Georgia logra lectura perfecta en cuanto dejas de contar mayúsculas.

Es un dato útil: si tu siguiente paso es búsqueda difusa, palabras clave o un modelo de lenguaje, un cambio de mayúscula casi no cuesta nada; si es comparación exacta contra una clave de base de datos, cuesta todo. Normaliza mayúsculas antes de comparar y la mitad del error aparente desaparece.

Que Courier sea la peor (0,1042) encaja: las fuentes monoespaciadas separan caracteres de forma poco natural, más difícil para un decodificador CTC entrenado en espaciados típicos.

El precipicio de tamaño está donde dice la documentación

readtext() tiene un parámetro documentado, min_size=10, que descarta cajas de menos de 10 píxeles. Casi todos lo pasan por alto. Es el número más determinante de la API para quien extrae texto de capturas o PDFs, y esto pasa al recorrer la altura de glifo:

El salto de 0,04 a 0,77 entre 12 y 8 px no es degradación gradual: es un filtro haciendo lo que dice su documentación. El texto bajo unos 10 px resulta prácticamente invisible por defecto.

El punto dulce está entre 12 y 28 px, con CER 0 completo a 16 px. Sobre 40 px, la CER sube un poco de nuevo, no porque se pierdan caracteres, sino porque regresa el cambio vow → VOW. El texto grande no es más difícil de leer; deja de beneficiarse del espaciado que hacía perfecto a 16 px.

Para quien extrae texto de capturas: comprueba la altura de glifo antes de culpar al modelo. Un panel capturado a 1× en HiDPI, o un PDF a 72 DPI, suele dejar el texto de cuerpo bajo 10 px. Captura a 2× o reescala antes del OCR y te ahorras la categoría entera de "EasyOCR ignoró media página". Si no es posible, baja min_size, pero espera ruido: ese filtro existe para suprimir detecciones basura.

Rotación: 10° de tolerancia, y una corrección que no es simétrica

Primero la inclinación. Ángulos pequeños, Arial 32 px, configuración por defecto frente a rotation_info=[90,180,270]:

Por defecto, EasyOCR aguanta hasta unos 10° sin problemas (CER ≤ 0,083), tambalea a los 15° y desaparece a los 20°. rotation_info no hace nada frente a la inclinación: solo reintenta en los ángulos listados, y 15° no es 90, 180 ni 270. A 10° incluso empeoró (0,021 → 0,083), porque un reintento en ángulo equivocado puede ganar la votación de confianza.

Las rotaciones ortogonales son donde se pone raro:

Mismo parámetro, mismos ángulos, tres resultados distintos.

A 270°, rotation_info hace lo que promete el hilo del issue: CER de 0,83 a 0,10, lectura utilizable. A 180°, a medias: mejora a 0,67, pero my vow. desaparece por completo. A 90°, retrocede de 0,81 a 0,92, y la salida en bruto explica por qué: el reconocedor devuelve cadenas en espejo. VOW vuelve como MOA, quartz como zuuenb. Correctas en espejo, un truco de fiesta divertido y un pipeline de datos inservible.

Comprobé esto contra las predicciones en bruto, no las métricas agregadas, porque sospeché primero de un error de orden de unión. No lo era: eso es lo que EasyOCR devolvió de verdad.

El mecanismo es una hipótesis, no una medición; no hubo experimento específico sobre la convención de rotación. Pillow renderiza ángulos positivos en sentido antihorario, así que solo la imagen a 270° coincide por casualidad con una orientación que el reconocedor maneja bien, mientras que a 90° el mejor reintento cae en una orientación invertida. Sea cual sea el mecanismo, la lección operativa no cambia:

Este fixture demuestra que no se puede asumir que rotation_info se comporte de forma simétrica entre orientaciones. Valida las rotaciones que esperas en tus entradas; la normalización de orientación aguas arriba es una mitigación candidata, no un requisito que estos tres ejemplos hayan establecido.

La predicción en la que me equivoqué

Esperaba que el bajo contraste fuera el punto débil de EasyOCR. El texto gris tenue sobre blanco es el clásico fallo de OCR, y hay una ruta de rescate documentada: contrast_ths=0.1 con adjust_contrast=0.5, que reprocesa cajas de bajo contraste con una copia realzada y se queda con el resultado más confiado. Nunca se activó, porque nunca hizo falta.

La CER nunca sale de la banda limpia, hasta Weber 0,14 —gris 220 sobre blanco, tan tenue que tuve que entrecerrar los ojos para confirmar que había texto—. La columna con contraste realzado es idéntica a la de por defecto en cada fila, porque el modo por defecto ya acertaba.

Los fondos contaron la misma historia, texto negro en todos los casos:

Lectura perfecta en el fixture más ruidoso del conjunto.

El alcance es estrecho: bajo contraste de color sólido y sin ruido, no un recibo fotografiado con ruido de sensor y compresión JPEG. En este conjunto, geometría y tokens cortos causaron los mayores fallos; color y ruido sintético no.

Un escenario real: sacar cifras de la captura de un panel

Este es el caso en el que acaba realmente casi todo el trabajo de OCR en Python. Alguien manda la captura de un panel interno, o corres un pipeline de scraping en Python contra una página de analítica llena de gráficos donde las cifras solo existen como píxeles, y quieres esos valores como datos.

Rendericé una ventana "Sales Dashboard": cabecera oscura con título e insignia de avatar, tres paneles de KPI, tres botones y una tabla 2×3; etiqueté los 19 elementos de texto con sus cadenas exactas y cajas en píxeles, y crucé la salida de EasyOCR con ellos por solapamiento.

Recall de detección: 16 de 19. Faltan la insignia de una sola letra "A" y las celdas "Q1" y "Q2". Y "Q3" sí se detectó: misma fuente, mismo tamaño, misma columna, pero el detector conservó un token de dos caracteres y descartó otros dos. La detección fue inconsistente entre celdas visualmente similares. Como las salidas fueron deterministas, esto no es azar. Un problema relacionado con la calidad de captura está en el #460.

En los 16 elementos detectados, el texto fue casi perfecto: CER media de 0,027, con 13 de 16 exactos. Títulos, etiquetas, botones ("Save", "Cancel", "Export CSV"), encabezados y números con separador de miles volvieron con CER 0. 1,284 se leyó correctamente, coma incluida.

Las tres lecturas imperfectas son el mismo error, importes en dólares:

Tres de cuatro dólares se convirtieron en una S mayúscula. Visualmente tiene sentido, pero cada campo de moneda queda a un carácter de ser basura, y un float() ingenuo falla en los tres.

Si tu pipeline de capturas contiene etiquetas cortas o moneda, valida mitigaciones como reescalado, recortes con margen, expectativas de campo restringidas o postprocesado consciente de símbolos. Nada de eso se probó aquí, y una regex que reescriba una S inicial puede corromper valores legítimos. Aplica correcciones solo donde el esquema y las reglas de validación las hagan seguras.

Qué cuesta ejecutarlo

Cifras en la misma máquina (macOS arm64, CPU, un solo host; tómalas como forma general, no benchmark universal):

El coste real no son los 94 MB de pesos: es cerca de un gigabyte de memoria residente por proceso, más torch de ~2 GB. Ese número decide si esto cabe en tu contenedor, y nadie suele mencionarlo.

La velocidad es correcta en el caso fácil: menos de 0,1 s en caliente para una línea limpia en CPU. Pero ese es el caso fácil, una sola línea corta y de alto contraste. Las quejas de "EasyOCR tarda decenas de segundos en CPU" hablan de documentos grandes con muchas regiones a tamaño completo, carga distinta que no reproduje; la cito en lugar de reclamarla como propia.

Un mito que conviene desmontar: detail=0 no hace a EasyOCR más rápido. Solo quita cajas y confianza del valor devuelto; el cómputo ya se hizo. Las medianas difieren en un milisegundo, puro ruido.

Ventajas y desventajas

Ventajas

• Recall de caracteres en texto latino limpio prácticamente perfecto: CER media 0,071 sensible a mayúsculas, 0,024 insensible, CER 0 alcanzable a 16 px.
• API realmente de dos líneas: Reader(['en']) y readtext(), sin configuración ni elección de modelo.
• Más robusto ante el contraste de lo que sugiere la fama: sin colapso hasta Weber 0,14, y fondos con ruido, degradado o color no lo degradaron (el gaussiano dio lectura perfecta).
• Casi perfecto en los elementos de captura que detecta: CER media 0,027, 13 de 16 exactos.
• Determinista: cada cifra de este análisis fue idéntica byte a byte entre dos ejecuciones independientes; solo cambió el tiempo.
• Apache-2.0 y autoalojado, sin cuota al proveedor; cómputo, memoria, almacenamiento y colas siguen siendo costes propios.

Desventajas

• Colapso brusco bajo el min_size=10 documentado: CER 0,77 a 8 px. El texto pequeño de interfaz es invisible por defecto.
• La tolerancia a la inclinación acaba en torno a 10° y se derrumba a los 20°.
• rotation_info no es simétrico: 270° se recupera, 180° a medias, y 90° empeora devolviendo texto en espejo.
• El detector descarta tokens cortos aislados: una insignia de una letra y dos celdas de dos caracteres, mientras conserva una tercera celda idéntica en formato.
• Confusión sistemática de $ por S en moneda (3 de 4).
• ~1 GB de memoria residente por proceso, más torch de ~2 GB.
• Última versión de septiembre de 2024; proyecto estable más que en evolución activa.

Quién debería usarlo, y quién debería alejarse

Evalúa EasyOCR cuando tus entradas sean texto limpio, derecho y de tamaño razonable —capturas, interfaces, PDFs rasterizados, informes generados— y quieras un pipeline de Python autoalojado sin cuota al proveedor. Los resultados en inglés sintético sobre CPU aplican a ese carril; fotografías, escritura a mano y otras escrituras necesitan pruebas aparte.

Aléjate si tus entradas son: fotografías (mis cifras son sintéticas, nada sobre ruido de cámara, perspectiva o iluminación); escritura a mano (el proyecto no la reclama); escrituras no latinas (probé solo inglés; ahí la referencia son las comparaciones académicas); entradas rotadas arbitrariamente, salvo corrección de orientación propia; despliegues con memoria limitada, donde un gigabyte por trabajador se acumula rápido.

Antes de elegir OCR, inspecciona el DOM y las respuestas de red. Si los valores ya existen como texto estructurado, extraer esa fuente evita los errores de detección y reconocimiento del OCR. El OCR es para cuando los píxeles son la única representación disponible.

Alternativas, y dónde encaja nuestro stack

EasyOCR es Apache-2.0 y autoalojado, sin cuota al proveedor pero con cómputo y coste operativo reales. PaddleOCR, Tesseract y los modelos de visión y lenguaje no pasaron por este banco de pruebas, así que no hay conclusión cara a cara con ellos.

La comparación más interesante no es OCR contra OCR, sino si deberías hacer OCR siquiera.

Buena parte del trabajo de extracción por captura que veo es en realidad un parche para una página difícil de scrapear: una tabla renderizada en JavaScript, un panel tras un login, un sitio que se resiste. Capturar pantalla y aplicar OCR parece el camino fácil, pero descartas texto ya estructurado y pagas después un impuesto en símbolos de dólar por recuperar una versión peor de lo mismo.

Nota del autor: Thunderbit es nuestra opción gestionada para extraer datos de páginas web; no pasó por estos fixtures. El límite relevante es la representación de origen: DOM/red cuando exista texto estructurado, OCR cuando los píxeles sean la única fuente.

Lecturas relacionadas del mismo banco de pruebas: la comparativa de scrapers de código abierto, la reseña de Crawl4AI, y la extracción impulsada por IA para páginas que resisten a los selectores.

Prueba Thunderbit para extraer datos web

Veredicto

¿Deberías usar EasyOCR? Sí, si tus imágenes están derechas, tus glifos miden al menos 12 px y lees escritura latina. Dentro de esos límites funciona muy bien: CER media 0,071 en texto limpio, 0,024 tras normalizar mayúsculas, lectura perfecta a 16 px, y mejor robustez al contraste de lo que sugiere su fama. La API es de dos líneas y la salida determinista, algo que pesa más de lo que se admite al depurar un pipeline.

Fuera de esos límites, falla de formas concretas y aprendibles. El texto bajo 10 px desaparece en el filtro min_size. Una inclinación mayor de 20° destroza la lectura. rotation_info arregla una orientación ortogonal, arregla a medias otra, y empeora la tercera con texto en espejo. Letras sueltas y tokens de dos caracteres se caen del detector mientras sus vecinos sobreviven. Los símbolos de dólar se vuelven S.

Los fallos vinieron de las dos etapas: cajas perdidas o mal orientadas en la geometría, confusión con el dólar en el reconocimiento. Trata el reescalado, la normalización de orientación, los recortes con margen y la reparación de símbolos consciente del esquema como candidatos a validar, no como arreglos universales.

No lo pongas a prueba como estuve a punto de hacerlo yo, con un harness roto y una cifra que no entiendes. Renderiza tus propios fixtures, conoce tu verdad de referencia con exactitud y encuentra tu propio precipicio.

Prueba Thunderbit para extraer datos web Get Started Free

Preguntas frecuentes

¿Es EasyOCR lo bastante preciso para extraer texto de capturas en producción? En el panel sintético, los elementos emparejados tuvieron CER media 0,027, con 13 de 16 exactos. Tres de 19 elementos no se detectaron, y tres de cuatro dólares se convirtieron en S. Si eso es aceptable —y si el reescalado o la reparación consciente del esquema ayudan— hay que probarlo sobre los layouts reales.

¿Cuál es el tamaño mínimo de fuente que puede leer EasyOCR? Unos 12 px de altura de glifo. min_size=10 descarta cajas de menos de 10 px, y el efecto es un precipicio, no una pendiente: CER 0,77 a 8 px, 0,15 a 10 px, 0,04 a 12 px y 0 a 16 px. La banda limpia fue 12–28 px. Si tu fuente es HiDPI a 1× o un PDF a 72 DPI, reescala antes del OCR en vez de bajar min_size, ya que ese filtro existe para suprimir detecciones basura.

¿rotation_info corrige las imágenes rotadas en EasyOCR? No de forma fiable, ni simétrica. Con rotation_info=[90,180,270], la imagen a 270° se recuperó limpiamente (CER 0,83 → 0,10), la de 180° solo a medias (0,85 → 0,67, con una frase perdida), y la de 90° empeoró (0,81 → 0,92) devolviendo texto en espejo como VOW → MOA. Tampoco hace nada frente a inclinaciones pequeñas, porque solo reintenta en los ángulos indicados. Corrige la orientación antes de llamar a EasyOCR.

¿Cuánta memoria y disco necesita EasyOCR? Los pesos ocupan 93,7 MiB: 79,30 MiB el detector, 14,44 MiB el reconocedor en inglés. La memoria residente máxima medida fue 984,5 MiB, sobre una instalación de torch de unos 2 GB. La inicialización en frío tardó 1,3–1,7 s; una línea limpia corrió después con mediana (p50) cercana a 0,062 s. detail=0 cambió la forma del valor devuelto, no el tiempo medido.

¿Es EasyOCR gratuito para uso comercial, y sigue manteniéndose? Licencia Apache-2.0, permisiva y compatible con uso comercial. A 27 de julio de 2026, el repositorio suma 29.825 estrellas y 528 issues abiertos; la última versión es v1.7.2, de septiembre de 2024, y el último push a master fue en diciembre de 2025. Léelo como estable más que abandonado: la arquitectura no ha cambiado y la actividad se trasladó al issue tracker. Confirma tú mismo la licencia antes de construir sobre ella.