Escaneas un contrato, haces una foto a una factura o recibes un PDF, y al buscar una palabra dentro el ordenador no encuentra nada. No es un fallo: para el ordenador esa página es una imagen, una cuadrícula de píxeles sin letras dentro. El OCR, el reconocimiento óptico de caracteres, es lo que convierte esa imagen en texto de verdad, que se puede buscar, copiar y editar, y también la razón de que a veces aparezcan palabras que nadie escribió.
Repasamos cómo trabaja un motor de OCR por dentro, por qué los actuales leen líneas enteras con redes neuronales y qué defectos del original estropean el resultado, con la documentación del motor libre Tesseract y la de los servicios de visión de Google y Microsoft, consultadas el 27 de octubre de 2026.
Qué es el OCR y en qué se diferencia de una imagen con texto
Una foto de una página y la misma página pasada por OCR se ven igual en la pantalla, pero no son lo mismo. La primera solo guarda colores de puntos; la segunda guarda caracteres. La lista de funciones de Cloud Vision, el servicio de visión artificial del buscador, lo define así: reconocimiento óptico de caracteres para una imagen, que reconoce el texto y lo convierte en texto codificado para la máquina. Con ese texto ya puedes buscar una palabra, copiar un párrafo o pegarlo en un editor; con la imagen sola, no.
El motor libre del que sale casi todo lo que contamos aquí se presenta como un motor de reconocimiento de texto de código abierto, con licencia Apache 2.0, que se usa desde la línea de comandos o, si programas, a través de una API para extraer texto impreso de imágenes, y que admite una gran variedad de idiomas. Su versión 5 es la estable y arrancó con la 5.0.0 el 30 de noviembre de 2021.
El servicio de la nube ofrece dos maneras de pedir el OCR. TEXT_DETECTION extrae texto de cualquier imagen, por ejemplo una señal de tráfico en una fotografía, y está pensado para zonas dispersas de texto dentro de una imagen más grande. DOCUMENT_TEXT_DETECTION también extrae texto, pero su respuesta está optimizada para texto denso y documentos, admite archivos PDF y TIFF y se usa también con imágenes que contienen escritura a mano. Si se piden las dos a la vez, manda la segunda.
La competencia tiene su equivalente en Azure Vision, un servicio en la nube que procesa imágenes y devuelve información sobre ellas, y en cuya documentación el reconocimiento óptico de caracteres tiene apartado y API propios.
De la foto al texto: las fases del reconocimiento
Todo empieza con la captura: el escáner, la cámara o el móvil producen la imagen que el motor va a leer. Si dudas en qué formato guardarla, en Formatos de imagen comparados: JPEG, PNG, WebP, AVIF y HEIC repasamos cómo comprime cada uno, y si fotografías documentos con una cámara, en RAW frente a JPEG: qué información contiene cada formato contamos qué guarda cada archivo.
Después llega el preprocesado. El motor libre hace por dentro varias operaciones de tratamiento de imagen, con la biblioteca Leptonica, antes del OCR propiamente dicho. La principal es la binarización, que convierte la imagen a blanco y negro: la hace con el algoritmo de Otsu, y la versión 5.0.0 añadió dos métodos más, Otsu adaptativo y Sauvola. Su guía de calidad avisa de que normalmente lo hace muy bien, pero que habrá casos en los que no baste, y entonces la precisión puede caer de forma importante.
La tercera fase es la segmentación: partir la página en bloques, líneas y palabras. Por defecto el motor espera una página de texto, y el modo de segmentación se cambia con la opción --psm: el 3, automático, es el predeterminado; el 4 supone una sola columna, el 7 una sola línea y el 11 busca todo el texto posible sin orden. El servicio de la nube devuelve el texto ordenado en una jerarquía parecida: página, bloque, párrafo, palabra y símbolo.
Luego viene el reconocimiento, que en los motores actuales hace una red neuronal (lo vemos en la siguiente sección), y por último el posprocesado. Aquí entra el diccionario: el manual explica que el motor está optimizado por defecto para reconocer frases formadas por palabras, y que si lo tuyo son tiques, listas de precios o códigos conviene desactivar los diccionarios con las variables load_system_dawg y load_freq_dawg. También se pueden añadir palabras a su lista, y si solo vas a encontrar dígitos, limitar los caracteres con tessedit_char_whitelist.
Por qué los motores actuales leen líneas enteras con redes neuronales
El gran cambio llegó con la versión 4.0, que añadió un motor de OCR nuevo basado en redes neuronales LSTM. Según su manual, funciona bien en x86 con Linux, con modelos de idioma oficiales para más de 100 idiomas y más de 35 escrituras.
La clave está en qué recibe esa red. La página sobre sus redes neuronales lo dice sin rodeos: el subsistema está configurado como un reconocedor de líneas de texto. No le llegan letras sueltas, le llega la imagen de una línea entera. Se puede usar junto al análisis de la disposición de la página para leer un documento grande, o con un detector de texto externo para leer la imagen de una sola línea.
Desde la versión 4.00 la red es el motor predeterminado, y en la 5 la opción --oem 1 elige la red neuronal y --oem 0 el motor clásico, que el proyecto llama Legacy. Leer así tiene un precio: el subsistema neuronal es muy intensivo en cálculo y usa del orden de diez veces los recursos de procesador del motor base, aunque lo mitiga usando hasta cuatro núcleos en paralelo con OpenMP y las instrucciones SSE y AVX de los procesadores de Intel y AMD. Y como la red lee líneas, todo lo que estropea la división en líneas estropea el resultado, como se ve en el apartado siguiente.
Qué estropea el resultado
La guía para mejorar la calidad del resultado empieza con un aviso útil: hay muchas razones para no obtener un buen resultado, y salvo que uses una fuente muy poco habitual o un idioma nuevo, volver a entrenar el motor difícilmente ayudará. Lo que sí propone es tratar la imagen, y repasa uno a uno los defectos que la estropean.
Resolución. El motor funciona mejor con imágenes de al menos 300 dpi, así que puede compensar redimensionarlas. Inclinación. Una página escaneada torcida reduce de forma notable la calidad de la segmentación en líneas, y eso perjudica gravemente al OCR; la solución es girar la imagen hasta que las líneas queden horizontales.
Contraste y fondo. La binarización puede quedarse corta sobre todo si el fondo de la página tiene un tono irregular. Y con texto claro sobre fondo oscuro, la guía pide para la versión 4.x texto oscuro sobre fondo claro. Ruido. Las variaciones aleatorias de brillo o color dificultan leer el texto, y algunas no desaparecen al binarizar, con lo que la precisión baja.
Grosor de las letras. Los caracteres muy gruesos o muy finos, sobre todo con remates, pueden afectar al reconocimiento de los detalles; la tinta corrida de los documentos antiguos se compensa con una erosión de los trazos. Bordes. Las páginas escaneadas suelen traer bordes oscuros que el motor puede tomar por caracteres de más; al revés, un borde enorme alrededor de una sola palabra puede acabar en una «página vacía». La recomendación es recortar dejando un margen razonable, por ejemplo de 10 píxeles.
Tablas y columnas. La guía reconoce que el motor tiene problemas para sacar texto y datos de tablas sin una segmentación o un análisis de la disposición a medida, y para recortes pequeños pide probar otro modo de segmentación.
El resumen, problema por problema:
| Problema del original | Qué provoca en el OCR | Cómo evitarlo |
|---|---|---|
| Resolución baja | Peor reconocimiento | Al menos 300 dpi |
| Página torcida | Falla la división en líneas | Girarla hasta dejar las líneas rectas |
| Fondo de tono irregular | Mala conversión a blanco y negro | Mejor original u otro método de umbral |
| Texto claro sobre oscuro | La versión 4.x pide lo contrario | Invertir los colores |
| Ruido | Baja la precisión | Limpiar la imagen antes |
| Bordes oscuros del escaneo | Caracteres de más | Recortar con un margen |
| Letras gruesas, finas o corridas | Se pierden detalles | Erosionar o dilatar los trazos |
| Tablas | Datos mal leídos | Segmentarlas aparte |
| Idioma equivocado | Letras propias mal leídas | Elegir bien el idioma |
| Códigos o precios | El diccionario estorba | Desactivarlo o limitar caracteres |
Idiomas mezclados y escritura a mano
El idioma se elige en el motor libre con -l y un código de tres letras, y si no se indica, da por hecho que el texto está en inglés. Su página de uso por línea de comandos lo enseña con una imagen que mezcla varios idiomas: leída solo en inglés, la palabra alemana «über» sale como «iiber»; con -l eng+deu sale bien. En las dos pasadas, eso sí, la frase portuguesa del final sale con palabras que no existen, como «cdo» y «preguigoso». El orden en que se ponen los idiomas también puede cambiar el tiempo que tarda y el resultado.
El servicio del buscador va por otro camino. Su página de detección de texto admite pistas de idioma, pero avisa de que dejar el valor vacío suele dar los mejores resultados, porque así se activa la detección automática del idioma; para los idiomas de alfabeto latino no hace falta ninguna pista. Solo en casos raros, cuando se conoce el idioma del texto, una pista ayuda, y puede ser un estorbo importante si es errónea.
Con la escritura a mano pasa algo parecido. El manual del motor libre lo presenta para extraer texto impreso, y el servicio de la nube dedica a la detección de escritura a mano su modo para documentos: uno de los usos concretos de DOCUMENT_TEXT_DETECTION es detectar texto manuscrito en una imagen. Incluso hay una pista de idioma para ello, en-t-i0-handwrit, que significa inglés transformado desde escritura a mano.
El PDF con capa de texto: qué conserva
Un PDF «con capa de texto» no cambia la página por texto: le añade una capa. Es lo que produce la salida pdf del motor libre, que, como explica su documentación, crea un PDF con la imagen y una capa de texto aparte, en la que se puede buscar, con el texto reconocido.
Eso tiene dos caras. Lo bueno es que el documento se sigue viendo exactamente como el original, porque lo que ves es la imagen. Lo malo es que lo que buscas, copias o pegas sale de la capa de texto, es decir, de lo que el OCR leyó: si leyó «cdo», buscar la palabra bien escrita no encontrará nada aunque la tengas delante.
El servicio de visión del buscador también trabaja con documentos enteros: su modo para documentos está optimizado para archivos PDF y TIFF. Y si vas a compartir el PDF resultante, conviene revisar antes sus metadatos, como explicamos en Qué metadatos contienen tus archivos y cómo consultarlos.
Cómo comprobar y corregir un OCR
Mira la confianza de cada palabra. El motor libre puede sacar el resultado en formato hOCR o TSV, que acompañan cada palabra de un valor de confianza (x_wconf en hOCR, la columna conf en TSV). En el extracto de su documentación, casi todas las palabras marcan entre 92 y 96, y la más baja, 80, es «cdo», una de las mal leídas. Las palabras con la confianza más baja son las primeras que hay que revisar, pero no las únicas: «preguigoso», también mal leída, marca 92. Las muestras de código del servicio de la nube imprimen también una confianza por bloque, párrafo, palabra y símbolo.
Mira lo que vio el motor. Con la variable tessedit_write_images activada, el motor guarda la imagen ya procesada en un archivo tessinput.tif. Si ese archivo tiene mala pinta, la guía recomienda tratar la imagen antes de pasársela.
Busca palabras raras. Repasa el texto buscando palabras que no existen, letras dobladas donde iba una con diéresis, como el «iiber» del ejemplo, o números con letras en medio. Es lo que la confianza no siempre marca.
Corrige el original, no solo el texto. Si una página sale mal, la guía del motor libre apunta primero a la imagen: volver a escanearla recta, a 300 dpi o más, sin bordes oscuros y con el idioma bien elegido ataca la causa. Y si lo que lees son códigos o importes, su manual propone desactivar el diccionario o limitar los caracteres a dígitos.
Te puede interesar
Tech Planet participa en el programa de afiliados de Amazon. Si compras a través de estos enlaces, recibimos una pequeña comisión sin coste extra para ti, lo que nos ayuda a seguir creando contenido como este.
| Imagen | Producto | Características | Comprar |
|---|---|---|---|
![]() |
Xiaomi Redmi Pad 2 | Pantalla 2K de 9,7″ a 120 Hz · Snapdragon 6s Gen 2 de ocho núcleos hasta 2,9 GHz · 4 GB de RAM y 64 GB · batería de 7.600 mAh con carga rápida de 18 W · cuerpo unibody de aluminio · Xiaomi HyperOS 3 | Ver precio en Amazon |
![]() |
Lenovo Idea Tab 11″ | Pantalla 2.5K de 11″ a 90 Hz · MediaTek Dimensity 6300 · 8 GB de RAM y 128 GB UFS · cuatro altavoces · Wi-Fi 5 y Bluetooth 5.2 · Android 15 · Lenovo Tab Pen incluido | Ver precio en Amazon |
![]() |
Apple iPad 11″ (A16) con 5G | Pantalla Liquid Retina de 11″ con True Tone · chip A16 · 128 GB · Wi-Fi 6 y 5G · cámaras frontal y trasera de 12 Mpx con vídeo 4K · Touch ID · compatible con Apple Pencil (USB-C) y Magic Keyboard Folio | Ver precio en Amazon |
![]() |
Samsung Galaxy Tab S10 FE+ | Pantalla de 13,1″, la mayor de la serie FE · procesador Exynos 1580 · 8 GB de RAM y 256 GB ampliables con microSD de hasta 2 TB · protección IP68 · S Pen incluido · tres años de garantía más uno adicional | Ver precio en Amazon |









