Abre cualquier imagen en un editor hexadecimal. Una foto de una señal de tráfico, un recibo, una captura de pantalla de un PDF. En el desplazamiento cero tienes la cabecera del formato. Unos kilobytes más adelante llegas a los datos de píxeles: tres bytes por píxel en RGB, una cuadrícula de números donde (128, 52, 19) podría ser una pared de ladrillos y (240, 238, 220) papel. En algún lugar de esa cuadrícula hay una señal de stop con la palabra "STOP" en blanco sobre rojo en fuente Highway Gothic. Un humano ve cuatro letras. La computadora ve un parche de 47 × 19 de valores de píxeles cercanos al rojo donde el canal R ronda los 200 y G y B caen por debajo de 40. Asignar ese parche a la cadena "STOP" es reconocimiento óptico de caracteres (Optical Character Recognition), y ha sido un problema de investigación abierto desde que Gustav Tauschek patentó la primera máquina lectora en 1929.
El OCR es engañosamente difícil porque leer es engañosamente fácil. Un niño de seis años puede reconocer la letra A en una docena de fuentes, a varios tamaños, bajo iluminación desigual, ligeramente girada, parcialmente ocluida y escrita a lápiz. Una computadora necesita un pipeline: limpiar la imagen, encontrar las regiones de texto, segmentar los caracteres o secuencias de glifos y clasificar cada uno. Cada una de esas etapas tiene un modo de fallo, y los fallos se acumulan.
Qué hace difícil el OCR
El problema central no es la clasificación. Clasificar una imagen de carácter pre-segmentada de 28 × 28 en una de 62 clases (A–Z, a–z, 0–9) es una tarea que un LeNet de los años 90 puede resolver con un 99 % de precisión. La parte difícil es todo lo que viene antes del clasificador.
Variación de fuentes. La letra "g" tiene al menos cuatro variantes estructurales comunes: de un piso (manuscrita), de dos pisos (la mayoría de las fuentes con serifa), la cola en bucle de Helvetica y la cola abierta de Futura. Un modelo entrenado en Tahoma leerá mal Univers a una tasa medible. El OCR en el mundo real abarca cientos de tipografías además de la escritura a mano, que no tiene ninguna topología de trazo consistente.
Distorsión geométrica. Las fotos de documentos rara vez son escaneos planos. Una foto de un recibo con el teléfono introduce sesgo de perspectiva, curvatura y escala no uniforme. El texto cerca del lomo de un libro se curva. Las fotos de pizarra capturan la sombra del fotógrafo. Un sesgo de 10 grados reduce la precisión de Tesseract de ~97 % a menos del 85 % en los benchmarks estándar. Los algoritmos de enderezamiento (detección de líneas de Hough, transformada de Radon, análisis de perfil de proyección) recuperan parte de esa pérdida, pero ninguno la recupera toda.
Iluminación y ruido. La iluminación desigual convierte un fondo uniforme en un degradado, rompiendo el umbralizado global. Los artefactos de compresión JPEG crean ringing alrededor de los bordes nítidos. En términos de OCR, eso significa ringing alrededor de los trazos de las letras. El ruido de sal y pimienta de los sensores con poca luz llena el espacio blanco con píxeles oscuros que parecen signos de puntuación. Una fotocopia de una fotocopia emborrona los trazos finos, fusionando "rn" en "m" y "cl" en "d".
Complejidad del diseño. Los documentos tienen columnas, leyendas, tablas, encabezados, notas al pie y barras laterales. El texto fluye alrededor de las imágenes. Algunos idiomas se escriben de derecha a izquierda. Otros mezclan direcciones en el mismo párrafo. Identificar el orden de lectura (qué bloque de texto va después de cuál) es un problema de análisis de diseño separado del reconocimiento, y equivocarse desordena la salida incluso cuando cada carácter se clasifica correctamente.
Ambigüedad contextual. Dado solo el patrón de píxeles, "0" (cero), "O" (letra O mayúscula) y "o" (letra o minúscula) son idénticos en muchas fuentes sans-serif. "1", "l", "I" y "|" comparten un trazo vertical. La resolución añade otra dimensión: a 12 píxeles de altura, "e" y "c" difieren en un solo trazo horizontal de tres píxeles de ancho. Los lectores humanos resuelven esto por el contexto. Las máquinas necesitan modelos de lenguaje, estadísticos o aprendidos, para tomar la misma decisión.
El pipeline tradicional de OCR
Antes del Deep Learning, el OCR era una secuencia de etapas diseñadas a mano. Cada etapa se desarrollaba de forma independiente, a menudo por diferentes grupos de investigación, y se ajustaba para una degradación específica. El pipeline se veía así:
Imagen cruda → Preprocesamiento → Binarización → Enderezamiento → Análisis de diseño
→ Segmentación de caracteres → Extracción de características → Clasificación
→ Postprocesamiento (modelo de lenguaje) → Salida de texto
Preprocesamiento y binarización
Las imágenes a color se convierten a escala de grises. La reducción de ruido suaviza la señal antes del umbralizado. El filtrado de mediana maneja el ruido de sal y pimienta. El desenfoque gaussiano maneja el ruido del sensor. El filtrado bilateral se usa cuando la preservación de bordes importa.
La binarización convierte la imagen en escala de grises en texto negro sobre fondo blanco. El algoritmo estándar es el método de Otsu (1979): busca exhaustivamente el umbral que minimiza la varianza intra-clase entre las distribuciones de píxeles de primer plano y fondo. Otsu asume un histograma bimodal (los píxeles de texto se agrupan en una intensidad, los píxeles de fondo en otra), lo que funciona para escaneos planos bajo iluminación controlada y falla en fotos de teléfono con sombras. Los métodos adaptativos locales (Sauvola, Niblack) calculan un umbral diferente por píxel basado en estadísticas de vecindad, manejando la iluminación desigual a costa de artefactos cerca de los bordes.
Enderezamiento y análisis de diseño
El sesgo del documento se detecta encontrando líneas: ya sea mediante la transformada de Hough sobre los píxeles de borde, o mediante análisis de perfil de proyección donde el documento se rota a través de un rango de ángulos y se elige el ángulo con los picos de proyección horizontal más nítidos. Una vez conocido el ángulo de sesgo, una transformación afín gira la imagen de vuelta.
El análisis de diseño segmenta la página en bloques de texto. El enfoque clásico ejecuta análisis de componentes conectados (Connected-Component Analysis, CCA) para encontrar manchas de píxeles de primer plano, las agrupa en palabras por proximidad y luego agrupa palabras en líneas y líneas en bloques. El algoritmo XY-cut divide recursivamente la página encontrando huecos de espacio en blanco a lo largo de proyecciones horizontales y verticales, construyendo un árbol de regiones. Las implementaciones modernas usan un híbrido: CCA para las manchas iniciales, luego un modelo aprendido para clasificar cada mancha como texto, imagen, tabla o separador.
Segmentación de caracteres
Para texto impreso, la segmentación significa cortar imágenes de palabras en caracteres individuales. El perfil de proyección vertical (un histograma de conteos de píxeles de primer plano por columna) produce picos en los centros de los caracteres y valles en los límites de los caracteres. Esto funciona hasta que dos caracteres se tocan, o un carácter contiene partes desconectadas ("i", "j", ":", "%"). La sobre-segmentación (cortar demasiado agresivamente) seguida de fusión basada en la confianza del clasificador es una solución. Otra es saltarse la segmentación por completo y reconocer palabras enteras, que es lo que hacen los métodos modernos basados en secuencias.
Extracción de características y clasificación
Una vez que tienes una imagen de carácter, necesitas describirla numéricamente para un clasificador. Las características pre-Deep Learning incluían:
- Valores de píxeles crudos como vector aplanado (simple, frágil ante la traslación y la escala)
- Zoning: dividir la caja delimitadora del carácter en una cuadrícula N × N, contar píxeles de primer plano por celda, usar los conteos como características
- Características basadas en gradiente (HOG): el Histograma de Gradientes Orientados captura las direcciones de los bordes, robusto ante pequeñas traslaciones
- Transformada de características invariante a la escala (SIFT): detecta y describe puntos clave invariantes a la escala, rotación e iluminación
El clasificador era típicamente una Máquina de Vectores de Soporte (SVM) con kernel RBF, entrenada en decenas de miles de imágenes de caracteres etiquetadas por fuente. Un pipeline SVM + HOG bien ajustado podía alcanzar ~98 % de precisión por carácter en texto impreso limpio. Mete una entrada ruidosa, sesgada o manuscrita en el mismo pipeline, y la precisión caía al 70–80 %.
Tesseract: de HP Labs a LSTM
Tesseract es el motor OCR de código abierto de referencia. Comenzó como un proyecto de doctorado en HP Labs Bristol en los años 80, fue liberado como código abierto en 2005 y ha sido mantenido por Google desde 2006. Su arquitectura se divide claramente en dos eras.
Versión 3: el pipeline clásico
Tesseract 3 implementó el pipeline tradicional con algunas innovaciones. Su análisis de diseño usaba un algoritmo de detección de tabulaciones que encontraba los límites de columna alineando las cajas delimitadoras de palabras — una heurística pragmática ajustada para el tipo de documentos que HP escaneaba en los años 90. La segmentación de caracteres usaba una lógica de troceador/asociador: el troceador sobre-segmentaba la imagen de la palabra en cortes candidatos, y el asociador usaba la confianza del clasificador y un diccionario para decidir qué cortes fusionar.
El clasificador era un sistema de dos pasadas. La primera pasada (clasificador estático) emparejaba las manchas segmentadas con prototipos (muestras de entrenamiento agrupadas) usando una búsqueda por vecino más cercano. La segunda pasada (clasificador adaptativo) se afinaba sobre el propio documento, aprendiendo la fuente específica usada en esa imagen. El clasificador adaptativo necesitaba aproximadamente una página de texto para volverse efectivo, razón por la cual Tesseract 3 funcionaba mal en imágenes de una sola palabra como señales de tráfico y leyendas.
Tesseract 3 distribuía archivos .traineddata: archivos que contenían los clústeres prototipo, definiciones del conjunto de caracteres, un diccionario de frecuencia de palabras y una tabla de ambigüedad unichar que mapeaba pares de caracteres confundibles. Entrenar un nuevo idioma requería alimentar a Tesseract con imágenes de texto emparejadas con transcripciones de verdad terreno, encuadrar cada carácter y ejecutar las herramientas de entrenamiento. Un proceso de varias horas por idioma.
Versión 4/5: LSTM reemplaza el pipeline
Tesseract 4 (2018) reemplazó toda la ruta de reconocimiento con una única red neuronal LSTM. El LSTM opera sobre una secuencia de cortes verticales de la imagen de la línea de texto, cada corte de un píxel de ancho y la altura completa de la línea de texto. Cada corte se introduce en una pila de capas LSTM bidireccionales. La salida es una secuencia de probabilidades de caracteres con una pérdida CTC (Connectionist Temporal Classification) que alinea la secuencia de salida de longitud variable con el texto de verdad terreno sin requerir posiciones de caracteres pre-segmentadas.
El modelo LSTM maneja caracteres de ancho variable, caracteres que se tocan y variación de fuentes sin la maquinaria troceador/asociador. Todavía depende del análisis de diseño heredado de Tesseract para encontrar líneas de texto, pero el reconocimiento de líneas es neuronal de extremo a extremo. En el benchmark ICDAR 2017, Tesseract 4 logró una tasa de error de caracteres (CER) del 4,4 % en inglés impreso, comparado con el 7,2 % de Tesseract 3. El proceso de entrenamiento pasó de la herramienta de encuadre heredada a combinar líneas de texto con transcripciones. Seguía siendo supervisado, pero con una etiqueta por línea en lugar de por carácter.
El formato .traineddata se amplió para contener los pesos del modelo LSTM (varios megabytes) junto con los datos heredados (diccionario, tablas unichar) en un solo archivo. Entrenar un modelo LSTM rápido desde cero toma aproximadamente 24 horas en una GPU moderna para un idioma de escritura latina con ~100 clases de caracteres; los idiomas CJK tardan más debido a conjuntos de caracteres más grandes.
Características de precisión
Tesseract 5 mejoró la versión 4 con un corpus de entrenamiento más grande y mejores parámetros por defecto, pero la arquitectura no cambió. La precisión depende fuertemente de la entrada:
| Condición de entrada | Tesseract 4 CER | Tesseract 5 CER |
|---|---|---|
| Escaneo limpio 300 DPI, inglés, una columna | 2,1 % | 1,8 % |
| Foto móvil 150 DPI, inglés | 5,8 % | 4,9 % |
| Escaneo limpio con fuentes mixtas | 7,3 % | 6,1 % |
| Documento histórico (tipografía irregular) | 18,4 % | 16,2 % |
| Escritura a mano (conjunto de datos IAM) | 28,7 % | 26,3 % |
El modelo LSTM elimina la mayoría de los problemas de sensibilidad a las fuentes de la versión 3, pero el motor todavía se degrada en baja resolución (por debajo de 200 DPI, la entrada de cortes de píxeles del LSTM pierde detalle de trazo), texto manuscrito (el modelo fue entrenado en fuentes impresas; la escritura a mano tiene estadísticas de trazo fundamentalmente diferentes) y diseños complejos (el análisis de diseño sigue siendo la ruta de código heredada, no la neuronal).
Enfoques modernos de Deep Learning
Académicamente, el OCR superó el paradigma CTC + LSTM alrededor de 2019. Tres arquitecturas dominan ahora la literatura.
CRNN + CTC
La Red Neuronal Convolucional Recurrente (CRNN), publicada por Shi et al. en 2015, empareja un extractor de características CNN con un modelo de secuencia RNN y decodificación CTC. La CNN extrae características espaciales de la imagen, aprendiendo esencialmente lo que al LSTM en Tesseract se le daba a mano (representaciones de cortes verticales). La RNN modela dependencias secuenciales a través de las características extraídas. El CTC maneja la alineación. CRNN-CTC se convirtió en la línea base estándar: entrenable de extremo a extremo, buena generalización, inferencia rápida (~20 ms por línea en GPU).
Codificador-decodificador basado en atención
Los modelos basados en atención adaptaron el paradigma seq2seq de la traducción automática. Un codificador CNN o de visión produce un mapa de características de la imagen. Un decodificador RNN genera el texto de salida un carácter a la vez, prestando atención a las regiones espaciales relevantes del mapa de características en cada paso. El mecanismo de atención elimina la restricción de monotonía del CTC: el decodificador puede saltar a partes anteriores de la imagen cuando el modelo de lenguaje espera un patrón repetido, aunque esta flexibilidad también introduce riesgo de alucinación para entradas ilegibles. Los decodificadores basados en atención alcanzan ~1,5–3 % de CER en inglés impreso limpio, superando a los modelos solo CTC en secuencias largas y diseños irregulares.
Vision Transformers (TrOCR, Donut)
TrOCR (Microsoft, 2021) aplicó la arquitectura Transformer al OCR. La imagen se divide en parches, codificada por un codificador ViT (Vision Transformer), y el texto se decodifica autorregresivamente por un decodificador de texto Transformer. Es la arquitectura de un modelo multimodal estándar, entrenado específicamente para OCR. TrOCR logra resultados de vanguardia en texto impreso (menos del 1 % de CER en escaneos limpios) sin ningún preprocesamiento CNN, modelo de lenguaje explícito o segmentación a nivel de carácter.
Donut (NAVER, 2022) extendió el enfoque a la comprensión de documentos: la entrada es una imagen de documento completa, y la salida es JSON estructurado extraído directamente de las características visuales, saltándose completamente el pipeline OCR → NLP. Esto difumina la línea entre OCR y análisis de documentos de una manera que importa para aplicaciones reales: extraer el total de una factura, un número de pasaporte o una tabla de un artículo de investigación se convierte en una sola llamada al modelo en lugar de OCR + regex + heurísticas.
Comparación de rendimiento (inglés impreso, 300 DPI limpio)
| Método | CER | Velocidad de inferencia (líneas/s) | Datos de entrenamiento necesarios |
|---|---|---|---|
| Tesseract 3 (clásico) | 7,2 % | ~2 (CPU) | ~100K imágenes de caracteres |
| Tesseract 5 (LSTM) | 1,8 % | ~15 (CPU) | ~500K líneas de texto |
| CRNN + CTC | 2,5 % | ~120 (GPU) | ~2M líneas de texto |
| Attention seq2seq | 1,8 % | ~60 (GPU) | ~2M líneas de texto |
| TrOCR (ViT + decodificador) | 0,8 % | ~20 (GPU) | ~10M líneas de texto |
| Donut (ViT + decodificador) | 1,2 % | ~15 (GPU) | ~12M imágenes de documentos |
La brecha entre Tesseract y los mejores modelos Transformer es real en los benchmarks. En la práctica, la brecha se estrecha porque la mayoría de los sistemas desplegados alimentan a Tesseract con entrada limpia, bien iluminada, a 300 DPI, y en esa entrada, un 1,8 % de CER significa un carácter incorrecto de cada 55. Aceptable para indexación de búsqueda, menos para una transcripción de documento legal.
OCR no inglés: por qué es más difícil
El OCR en inglés es un problema resuelto. Un conjunto de caracteres de 26 mayúsculas, 26 minúsculas, 10 dígitos y un puñado de signos de puntuación da aproximadamente 70 clases. Un problema de clasificación multi-clase cómodamente dentro de la capacidad de un LeNet de los años 90. El resto de los sistemas de escritura del mundo son menos indulgentes.
CJK: explosión del conjunto de caracteres
El chino, japonés y coreano (CJK) representan el desafío de OCR más difícil solo por el tamaño del conjunto de caracteres. El chino simplificado usa aproximadamente 3.500 caracteres comunes y más de 6.000 en texto general. El chino tradicional añade otro millar de formas variantes. El japonés mezcla dos silabarios (hiragana, katakana: 46 caracteres cada uno) con ~2.000 kanji comunes más caracteres alfanuméricos latinos en la misma oración. El hangul coreano es fonéticamente regular (24 letras básicas que se combinan en bloques silábicos), pero visualmente denso: un solo bloque puede contener hasta seis componentes jamo individuales empaquetados en un espacio aproximadamente del tamaño de dos caracteres latinos lado a lado.
Un sistema OCR CJK no puede tratar el reconocimiento como una clasificación de 70 vías. Es una clasificación de 4.000 vías para japonés, 6.000 para chino simplificado y más de 10.000 para chino tradicional, como mínimo. Solo la capa de salida softmax tiene más parámetros que un modelo OCR completo para escritura latina. Las necesidades de datos de entrenamiento escalan con el conjunto de caracteres: ~100 muestras etiquetadas por clase para una precisión aceptable, por lo que los conjuntos de entrenamiento chinos comienzan en 600.000 imágenes de líneas de texto.
Tesseract proporciona archivos traineddata CJK (chi_sim, chi_tra, jpn, kor), pero son significativamente más grandes que los modelos latinos. chi_sim.traineddata ocupa ~50 MB frente a ~15 MB para eng.traineddata, y el reconocimiento es más lento porque el espacio de salida es mayor. La precisión en texto CJK impreso limpio es del 2–5 % de CER para Tesseract 5, aproximadamente 2–3 veces la tasa de error del inglés en condiciones equivalentes.
Árabe y escrituras de derecha a izquierda
El árabe añade dos problemas más allá del conjunto de caracteres (28 letras con formas contextuales que cambian según la posición dentro de la palabra). Primero, se escribe de derecha a izquierda, por lo que el motor OCR debe detectar la dirección del texto e invertir el orden de salida. Segundo, el árabe es cursivo. Las letras dentro de una palabra se conectan mediante un trazo de línea base, haciendo la segmentación inherentemente más difícil que con las formas de letras mayormente desconectadas de las escrituras latina y cirílica. Una imagen de palabra árabe es una mancha continua; la segmentación basada en caracteres es efectivamente imposible, razón por la cual el enfoque LSTM/CTC (que opera en imágenes de palabras sin segmentación de caracteres) fue un avance mayor para el OCR árabe que para el OCR inglés.
El hebreo, urdu, farsi y pastún comparten alguna combinación de estos desafíos. Tesseract proporciona traineddata árabe, pero la precisión es de aproximadamente 5–8 % de CER en texto impreso limpio, unas 4 veces peor que el inglés en las mismas condiciones.
Escrituras índicas: el problema del conjunto
El devanagari (hindi, marati, nepalí) y otras escrituras bráhmicas representan un desafío distinto: la unidad de escritura no es el carácter sino el conjunto (conjunct), un grupo visualmente fusionado de una consonante, un modificador vocálico y a veces una consonante adicional. El bloque Unicode devanagari tiene 128 puntos de código, pero el número de conjuntos posibles supera los 1.000. La "shirorekha" (la línea de cabeza horizontal que conecta los caracteres en una palabra) hace la segmentación más difícil porque la línea de cabeza fusiona caracteres adyacentes en una sola unidad visual.
El traineddata hindi de Tesseract (hin) cubre los conjuntos comunes, pero la precisión va 3–4 veces por detrás del inglés en texto impreso. El tamil, telugu, bengalí y otras escrituras indias están peor soportadas, algunas sin archivos traineddata oficiales. La causa raíz es el volumen de datos de entrenamiento: existen millones de imágenes de líneas de texto anotadas de alta calidad para el hindi, mientras que para el kannada los conjuntos de datos disponibles se cuentan en decenas de miles.
Texto vertical y diseños de dirección mixta
El japonés y el chino tradicional a veces se componen verticalmente, con líneas de arriba a abajo y columnas de derecha a izquierda. El análisis de diseño de Tesseract asume texto horizontal; el texto vertical requiere pre-rotación o un motor separado. El texto horizontal y vertical mezclado en la misma página, común en periódicos japoneses y manga, rompe completamente la suposición de dirección única y requiere detección de dirección por región antes del reconocimiento.
Idiomas pequeños y datos de entrenamiento
Para idiomas con menos de 10 millones de hablantes, rara vez existen datos de entrenamiento OCR de alta calidad. El consorcio Unicode ha codificado más de 150 escrituras, pero Tesseract distribuye traineddata para aproximadamente 120 idiomas, muchos de ellos generados a partir de texto sintético renderizado con fuentes estándar sobre fondos limpios. Los datos sintéticos funcionan para texto impreso en fuentes comunes y fallan para las fuentes, papeles y calidades de impresión encontrados en documentos reales de esos idiomas. Un modelo entrenado en Arial sintético a 300 DPI no leerá un documento amárico mecanografiado de los años 70.
OCR en el lado del navegador con Tesseract.js
Ejecutar OCR en el navegador era impracticable hasta que WebAssembly llegó. Tesseract.js compila Tesseract 5 (LSTM) a WebAssembly mediante Emscripten, envolviendo el motor C++ en una API JavaScript que ejecuta un Web Worker por tarea de reconocimiento. El motor, los datos de idioma y el worker se cargan desde activos estáticos. Sin ida y vuelta al servidor para los datos de imagen.
La superficie de la API es sencilla: crea un worker con uno o más códigos de idioma, dale una imagen y recibe el texto reconocido con puntuaciones de confianza por carácter. Se pueden ejecutar varios workers en paralelo, limitados por los núcleos de CPU disponibles. Típicamente cuatro trabajos de reconocimiento en paralelo en un portátil de consumo, seis a ocho en teléfonos recientes.
El rendimiento está limitado por tres factores. Primero, WebAssembly se ejecuta aproximadamente al 50–70 % de la velocidad nativa; una línea de texto que tarda 100 ms en Tesseract nativo tarda unos 160 ms en el navegador. Segundo, los archivos traineddata se cargan a través de la red. eng.traineddata ocupa ~15 MB, chi_sim.traineddata ~50 MB, y ambos deben descargarse completamente antes de que comience el reconocimiento. Tercero, la decodificación de imágenes (JPEG/PNG/WebP/HEIC a datos de píxeles crudos) usa los decodificadores integrados del navegador, que son rápidos pero varían según el formato y el dispositivo.
La ventaja de privacidad es estructural. El OCR del lado del cliente significa que la imagen nunca sale del dispositivo. Una foto de un pasaporte, un extracto bancario, un historial médico. Los píxeles se decodifican en el navegador, el equivalente a Textract se ejecuta en un Web Worker, y el resultado es una cadena de texto que el usuario puede copiar o guardar. Ningún centro de datos procesa la imagen. Eso no es una característica; es la ausencia de un servidor, lo que es categóricamente diferente de una política de privacidad que promete no mirar.
Nuestra herramienta Imagen a Texto ejecuta exactamente esta pila: Tesseract.js con reconocimiento LSTM, Web Workers para procesamiento paralelo, y traineddata para 12 idiomas (inglés, español, francés, alemán, portugués, italiano, chino simplificado y tradicional, japonés, coreano, hindi y ruso). Suelta una foto, selecciona idiomas, obtén texto. La herramienta lee entradas JPEG, PNG, WebP, BMP y GIF, aplica pre-escalado consciente de la resolución (las imágenes de más de 3.000 píxeles en el lado más largo se reducen para mantener la latencia de reconocimiento razonable) y produce texto plano por imagen con confianza por carácter disponible.
La elección del formato de imagen afecta la calidad del OCR en la práctica. Las fotos HEIC de iPhones, convertidas a JPEG antes del OCR, adquieren artefactos de compresión alrededor de los bordes del texto que reducen la precisión del reconocimiento. Convertir HEIC a PNG primero (sin pérdida, sin artefactos de cuantificación) preserva los bordes nítidos de los que depende el LSTM. Nuestros convertidores HEIC a JPG y HEIC a PNG manejan este paso de preprocesamiento directamente en el navegador. Del mismo modo, las fotos tomadas con poca luz se benefician de convertir a un formato que preserve el rango tonal completo antes del umbralizado: JPG a PNG evita los artefactos JPEG de segunda generación que se acumulan cuando se recodifica una fuente JPEG.
La pila OCR del navegador no es competitiva con los modelos del lado del servidor acelerados por GPU en rendimiento. Un servidor ejecutando Tesseract en 32 núcleos CPU con C++ nativo siempre superará a una pestaña del navegador. Gana en privacidad, cero infraestructura y cero costo por solicitud. Para escanear unas pocas páginas, un recibo o un puñado de letreros, la diferencia de latencia entre 200 ms y 50 ms es imperceptible.
Hacia dónde va el OCR
El OCR dejó de ser un campo de investigación independiente alrededor de 2022 y se fusionó en el espacio más amplio de IA documental y modelos multimodales. Tres cambios están en marcha.
LLMs multimodales como OCR zero-shot. GPT-4V, Claude y Gemini pueden leer texto de imágenes sin entrenamiento OCR explícito. Introduce una foto de un documento y pide el texto, y el modelo lo devuelve. No porque tenga una cabeza OCR dedicada, sino porque el reconocimiento de texto emerge del entrenamiento en miles de millones de pares imagen-texto. La calidad es desigual. En inglés impreso limpio, GPT-4V alcanza ~1 % de CER, comparable a un TrOCR afinado. En fotos de baja resolución de recibos chinos, puede superar a Tesseract porque el modelo aprovecha el contexto (sabe cómo es un recibo y qué números esperar) en lugar de depender solo de la evidencia a nivel de píxel. En escritura a mano, es peor que un reconocedor afinado porque la distribución de entrenamiento no incluía suficientes imágenes manuscritas.
El compromiso es costo y latencia. Una llamada API a GPT-4V para OCR cuesta 1–3 centavos por página dependiendo del número de tokens y tarda 1–3 segundos. Tesseract se ejecuta localmente en 100–500 ms y no cuesta nada por página. Para escanear un documento de 200 páginas, la diferencia es de $2–6 y varios minutos de tiempo real frente a cero y menos de un minuto. Para uso puntual (un solo recibo, una foto de pizarra), el modelo multimodal es más simple y a menudo más preciso.
Inferencia en el dispositivo. Los modelos detrás del OCR de servidor se están reduciendo. ONNX Runtime Web ejecuta modelos CRNN cuantificados y pequeños ViT en el navegador a 50–100 ms por línea de texto en WebGPU. El framework Vision de Apple incluye un modelo OCR compacto en el dispositivo para iOS y macOS, accesible mediante VNRecognizeTextRequest sin llamada de red. La brecha entre "modelo GPU de servidor" y "modelo de navegador" se está cerrando porque ambos convergen en el mismo punto óptimo arquitectónico: un pequeño codificador ViT (~20–50M de parámetros) con un decodificador ligero, cuantificado a INT8 o FP16.
Comprensión de documentos, no solo transcripción. La salida del OCR es una cadena. La mayoría de las tareas del mundo real implican extraer información estructurada de esa cadena: números de factura, fechas, totales, nombres, direcciones. El enfoque tradicional encadena OCR con regex, reconocimiento de entidades nombradas y mapeo de esquemas. Cada etapa es un modelo separado con sus propios modos de fallo. Los modelos de comprensión de documentos de extremo a extremo (Donut, LayoutLMv3, Pix2Struct) se saltan el OCR y mapean imágenes de documentos directamente a salidas estructuradas. Un modelo Donut afinado en recibos no produce una transcripción de texto y luego la analiza. Produce {"total": "42.50", "date": "2026-07-27", "vendor": "..."} directamente desde la entrada de píxeles. El paso OCR, la parte de la que trata este artículo, se convierte en un detalle de implementación invisible.
Eso no hace obsoleto el OCR. Lo convierte en un bloque de construcción. El pipeline todavía necesita manejar los casos límite: el recibo fotografiado en ángulo en un restaurante oscuro, el documento de 50 años mecanografiado en papel amarillento, el letrero en un idioma para el que ningún modelo multimodal grande fue entrenado. Los motores OCR especializados, entrenados en esas distribuciones específicas, superarán a un modelo de propósito general durante años, porque un modelo de propósito general entrenado en todo Internet asigna una fracción ínfima de su capacidad a leer la salida de una máquina de escribir amárica de los años 70.
El OCR no es un problema resuelto para la mayoría de los idiomas del mundo y la mayoría de las condiciones de imagen del mundo real. Es un problema resuelto para texto limpio, 300 DPI, inglés, una columna, impreso a máquina — la porción más estrecha y mejor financiada del espacio del problema. El resto sigue abierto.
