Saltar al pie de página
COMPARAR CON OTROS COMPONENTES

OCR en Azure vs. IronOCR: ¿Qué solución de reconocimiento óptico de caracteres se adapta mejor a los proyectos .NET?

Windows.Media.OCR viene incluido gratis con cada instalación de Windows 10 y Windows 11, lo que lo hace atractivo hasta que intentas implementar la misma aplicación en un servidor Linux, un contenedor Dockero una función AWS Lambda, momento en el que la API simplemente no existe. La dependencia de la plataforma no es un caso excepcional con esta biblioteca; Es la restricción definitoria. Cada decisión arquitectónica posterior a la elección de Windows.Media.OCR está condicionada por el requisito de que el sistema operativo anfitrión debe ser un ordenador de sobremesa con Windows 10 o Windows 11, o un servidor de gama de consumo. Ni Linux, ni macOS, ni Docker, ni Azure Functions en Linux, ni AWS Lambda. Para los desarrolladores que crean herramientas internas de Windows sin planes de cruzar ese límite, el precio de 0 dólares es difícil de rechazar. Para todos los demás, el coste oculto reside en reescribir el OCR e integrarlo en un sistema completamente diferente cuando evolucionan los requisitos de implementación.

Comprensión de Windows.Media.OCR

Windows.Media.Ocr es parte de la superficie API de Windows Runtime (WinRT) introducida en Windows 8.1 y refinada para Windows 10 y 11. Expone una clase OcrEngine en el espacio de nombres Windows.Media.Ocr que acepta un SoftwareBitmap — en sí mismo un tipo WinRT de Windows.Graphics.Imaging — y devuelve un OcrResult que contiene texto reconocido y geometría de línea.

La API está construida en torno al contrato async/await de WinRT. Cada operación fluye a través de llamadas async Task respaldadas por la maquinaria WinRT IAsyncOperation: cargar un StorageFile, abrir un flujo, crear un BitmapDecoder, obtener un SoftwareBitmap, y sólo entonces invocar RecognizeAsync. Desde .NET 6 en adelante, consumir APIs WinRT requiere un Identificador de Marco de Trabajo Específico de Windows (TFM) como net8.0-windows10.0.19041.0. Un archivo de proyecto sin ese TFM no puede compilar código que haga referencia a Windows.Media.Ocr en absoluto — los tipos simplemente no existen en el grafo de ensamblados.

Características arquitectónicas clave:

  • Solo Windows 10/11 : la interfaz de la API WinRT no está disponible en Servidor Windowssin Experiencia de escritorio en ninguna configuración, y está completamente ausente en Linuxy macOS.
  • Modelo async de WinRT — todos los reconocimientos fluyen a través de llamadas async respaldadas por IAsyncOperation; no existe ruta sincrónica
  • Paquetes de idioma del sistema operativoOcrEngine.TryCreateFromLanguage y TryCreateFromUserProfileLanguages resuelven los idiomas disponibles de los paquetes de idiomas de Windows instalados por el usuario o el administrador de TI en esa máquina específica; no existe un modelo de idioma agrupado o portátil
  • Entrada solo de imagen — la API acepta SoftwareBitmap directamente; No existe ninguna ruta de entrada de PDF en ninguna capa de la API.
  • Sin canalización de preprocesamiento : el mapa de bits sin procesar se pasa al reconocedor; La corrección de rotación, la eliminación de ruido, la mejora del contraste y el escalado de resolución son responsabilidad del desarrollador, quien deberá utilizar las API de imágenes de Windows por separado.
  • No se genera un archivo PDF con capacidad de búsqueda : el texto reconocido se devuelve como datos de cadena sin formato con geometría de línea; No se ofrece la opción de exportar a PDF.
  • TFM específico de Windows requerido — los archivos de proyecto deben dirigirse a un TFM net*-windows*, lo que impide que el mismo proyecto se compile en múltiples plataformas

La pila asíncrona de WinRT

Cada operación básica de OCR con Windows.Media.Ocr requiere navegar a través de múltiples capas de la superficie de la API de WinRT antes de que pueda comenzar el reconocimiento:

// Windows.Media.Ocr: 6+ async steps before receiving any text
// Requires net8.0-windows10.0.19041.0 TFM — will not compile cross-platform

public async Task<string> ExtractTextAsync(string imagePath)
{
    // Step 1: WinRT file system access
    var file = await StorageFile.GetFileFromPathAsync(imagePath);

    // Step 2: Open WinRT stream
    using var stream = await file.OpenAsync(FileAccessMode.Read);

    // Step 3: Create bitmap decoder
    var decoder = await BitmapDecoder.CreateAsync(stream);

    // Step 4: Decode to SoftwareBitmap
    var bitmap = await decoder.GetSoftwareBitmapAsync();

    // Step 5: Check language availability — null if not installed on this machine
    var engine = OcrEngine.TryCreateFromLanguage(
        new Windows.Globalization.Language("en-US"));
    if (engine == null)
        throw new Exception("OCR engine not available for this language");

    // Step 6: Recognize
    var result = await engine.RecognizeAsync(bitmap);
    return result.Text;
}
// Windows.Media.Ocr: 6+ async steps before receiving any text
// Requires net8.0-windows10.0.19041.0 TFM — will not compile cross-platform

public async Task<string> ExtractTextAsync(string imagePath)
{
    // Step 1: WinRT file system access
    var file = await StorageFile.GetFileFromPathAsync(imagePath);

    // Step 2: Open WinRT stream
    using var stream = await file.OpenAsync(FileAccessMode.Read);

    // Step 3: Create bitmap decoder
    var decoder = await BitmapDecoder.CreateAsync(stream);

    // Step 4: Decode to SoftwareBitmap
    var bitmap = await decoder.GetSoftwareBitmapAsync();

    // Step 5: Check language availability — null if not installed on this machine
    var engine = OcrEngine.TryCreateFromLanguage(
        new Windows.Globalization.Language("en-US"));
    if (engine == null)
        throw new Exception("OCR engine not available for this language");

    // Step 6: Recognize
    var result = await engine.RecognizeAsync(bitmap);
    return result.Text;
}
Imports System.Threading.Tasks
Imports Windows.Media.Ocr
Imports Windows.Storage
Imports Windows.Graphics.Imaging
Imports Windows.Storage.Streams
Imports Windows.Globalization

Public Async Function ExtractTextAsync(imagePath As String) As Task(Of String)
    ' Step 1: WinRT file system access
    Dim file As StorageFile = Await StorageFile.GetFileFromPathAsync(imagePath)

    ' Step 2: Open WinRT stream
    Using stream As IRandomAccessStream = Await file.OpenAsync(FileAccessMode.Read)

        ' Step 3: Create bitmap decoder
        Dim decoder As BitmapDecoder = Await BitmapDecoder.CreateAsync(stream)

        ' Step 4: Decode to SoftwareBitmap
        Dim bitmap As SoftwareBitmap = Await decoder.GetSoftwareBitmapAsync()

        ' Step 5: Check language availability — Nothing if not installed on this machine
        Dim engine As OcrEngine = OcrEngine.TryCreateFromLanguage(New Language("en-US"))
        If engine Is Nothing Then
            Throw New Exception("OCR engine not available for this language")
        End If

        ' Step 6: Recognize
        Dim result As OcrResult = Await engine.RecognizeAsync(bitmap)
        Return result.Text
    End Using
End Function
$vbLabelText   $csharpLabel

La verificación de nulo en engine no es opcional. Si el paquete de idioma de destino no está instalado en la máquina que ejecuta el código, TryCreateFromLanguage devuelve nulo y el reconocimiento es imposible. No hay plan B; La aplicación debe mostrar un error al usuario o fallar silenciosamente.

Comprender IronOCR

IronOCR es una biblioteca OCR comercial .NET, basada en un motor Tesseract 5 optimizado con una capa de API administrada que se encarga del preprocesamiento, la lectura de PDF, la resolución multilingüe y la salida de datos estructurados. Se instala como un único paquete NuGet sin necesidad de desplegar binarios nativos externos por separado, sin carpetas tessdata que gestionar y sin requerir TFM específicos de la plataforma.

Características clave:

  • Multiplataforma por diseño : se ejecuta en Windows, Linux, macOS, Docker, Azure App Service (Windows o Linux), AWS Lambday GCP Cloud Run sin necesidad de modificar el código.
  • Preprocesamiento automático — deskew, denoise, mejora del contraste, binarización, y escalado de resolución se aplican automáticamente en entradas de baja calidad, con control explícito disponible a través de los métodos de filtro OcrInput
  • Entrada nativa de PDFIronTesseract.Read acepta rutas de PDF directamente; Sin pasos de conversión, sin biblioteca externa.
  • Más de 125 idiomas incluidos : los paquetes de idiomas son paquetes NuGet que se implementan con la aplicación; no depende de los datos de idioma instalados en el sistema operativo
  • Salida de PDF con capacidad de búsquedaOcrResult.SaveAsSearchablePdf crea un PDF con capa de texto a partir de cualquier entrada escaneada.
  • Modelo de resultado estructuradoOcrResult expone Pages, Paragraphs, Lines, Words, y puntuaciones de confianza y cuadros delimitadores por palabra.
  • Seguro para hilos — las instancias IronTesseract admiten cargas de trabajo paralelas sin sincronización adicional
  • Licenciamiento perpetuo — $999 Lite a $5,999 Unlimited, compra única, procesa documentos ilimitados

Comparación de características

Característica Windows.Media.Ocr IronOCR
Plataforma Solo para Windows 10/11 Windows, Linux, macOS, Docker, nube
Precio Gratis $5,999 perpetuo
Entrada de PDF No Nativo
Modelo de lenguaje Paquetes instalados por el sistema operativo Más de 125 paquetes incluidos a través de NuGet.
Preprocesamiento None Filtros automáticos + explícitos
Salida en PDF con capacidad de búsqueda No
modelo API WinRT asíncrono .NET Standard

Comparación detallada de características

Característica Windows.Media.Ocr IronOCR
Soporte de Plataforma
Windows 10/11
Servidor Windows Limitado
Linux No
macOS No
Docker No
Azure Functions (Linux) No
AWS Lambda No
Formatos de entrada
JPEG / PNG / BMP Sí (a través de la canalización WinRT)
PDF (escaneado) No
PDF (protegido con contraseña) No
TIFF / varias páginas No
Flujo / matriz de bytes No (solo para archivos de almacenamiento WinRT)
URL No
Idiomas disponibles
Fuente del idioma Paquetes de idioma instalados por el sistema operativo Más de 125 paquetes NuGet incluidos
Instalar sin administrador del sistema operativo No Sí (NuGet)
Multilingüe simultáneo No
Portabilidad del lenguaje entre máquinas No
Preprocesamiento
Inclinación No Sí (input.Deskew())
Reducción de ruido No Sí (input.DeNoise())
Mejora del contraste No Sí (input.Contrast())
Binarización No Sí (input.Binarize())
Escalado de resolución No Sí (input.EnhanceResolution(300))
Producción
Texto sin formato
PDF con función de búsqueda No
hOCR / HTML No
Cuadros delimitadores a nivel de palabra Parcial (geometría lineal)
Puntuaciones de confianza por palabra No
Diseño de API
Restricción de TFM net*-windows* requerido None
Camino síncrono No
Lectura de BarCodes durante el OCR No
OCR basado en la región No

Dependencia de plataforma frente a implementación multiplataforma

La diferencia más importante entre estas dos bibliotecas no radica en la precisión, ni en el preprocesamiento, ni en la compatibilidad con PDF, sino en la topología de implementación. Windows.Media.OCR no existe fuera de Windows 10/11. Esto no es un problema de configuración ni un paquete NuGet faltante; El entorno de ejecución WinRT, que da soporte a la API, está ausente en todos los demás sistemas operativos.

Enfoque de Windows.Media.OCR

La dependencia de WinRT se manifiesta en el archivo del proyecto antes de que se ejecute una sola línea de código. El TargetFramework debe especificar una versión de plataforma de Windows:


<PropertyGroup>
  <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
</PropertyGroup>

<PropertyGroup>
  <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
</PropertyGroup>
XML

Con ese TFM, el proyecto no se puede utilizar desde un contenedor Linux. Una imagen Dockerbasada en mcr.microsoft.com/dotnet/aspnet:8.0 — la imagen base estándar de Linuxpara implementaciones ASP.NET — no tiene tiempo de ejecución WinRT. Intentar hacer referencia a tipos Windows.Media.Ocr en un proyecto dirigido a net8.0 (sin sufijo de Windows) produce errores de compilación, no errores de tiempo de ejecución. El bloqueo se impone en el momento de la compilación.

Cuando surgen requisitos de OCR en una arquitectura de microservicios donde el proceso de OCR se ejecuta en Linux, o en una canalización de CI/CD que produce imágenes Dockermultiplataforma, Windows.Media.Ocr no es una opción a evaluar; se descarta antes del primer pico de demanda.

Enfoque de IronOCR

IronOCR se dirige a net6.0, net7.0, net8.0 y net9.0 sin TFMs específicos de plataforma. El mismo paquete NuGet y el mismo archivo binario de la aplicación funcionan en Windows, Linuxy macOS. Implementar IronOCR en Docker requiere una línea apt-get para libgdiplus en la imagen base de Linux, nada más:

FROM mcr.microsoft.com/dotnet/aspnet:8.0
# Linuxdependency for System.Drawing
RUN apt-get update && apt-get install -y libgdiplus

COPY --from=build /app/publish /app
WORKDIR /app
ENTRYPOINT ["dotnet", "YourApp.dll"]

El código de la aplicación en sí no cambia entre las implementaciones de Windows y Linux:

// Same code — Windows, Linux, macOS, Docker, AWS Lambda
// No platform TFM, no WinRT, no conditional compilation
using IronOcr;

IronOcr.License.LicenseKey = "YOUR-LICENSE-KEY";
var text = new IronTesseract().Read("document.jpg").Text;
// Same code — Windows, Linux, macOS, Docker, AWS Lambda
// No platform TFM, no WinRT, no conditional compilation
using IronOcr;

IronOcr.License.LicenseKey = "YOUR-LICENSE-KEY";
var text = new IronTesseract().Read("document.jpg").Text;
Imports IronOcr

' Same code — Windows, Linux, macOS, Docker, AWS Lambda
' No platform TFM, no WinRT, no conditional compilation

IronOcr.License.LicenseKey = "YOUR-LICENSE-KEY"
Dim text As String = New IronTesseract().Read("document.jpg").Text
$vbLabelText   $csharpLabel

IronOCR se ejecuta en AWS Lambda , Azure Functions en Linux y directamente en servidores Linux sin necesidad de modificar el código. El destino de la implementación es una cuestión de configuración, no una limitación arquitectónica.

Compatibilidad con idiomas: Dependencia del sistema operativo frente a paquetes incluidos

Windows.Media.OCR delega la disponibilidad de idiomas por completo al equipo anfitrión. El conjunto de idiomas que su aplicación puede reconocer viene determinado por los paquetes de idioma que el usuario —o un administrador de TI— haya instalado en esa instalación específica de Windows. Esto crea una clase de fallo de producción que no tiene nada que ver con tu código.

Enfoque de Windows.Media.OCR

OcrEngine.TryCreateFromLanguage devuelve nulo cuando el idioma solicitado no está instalado. TryCreateFromUserProfileLanguages devuelve nulo cuando no existe en absoluto ningún paquete de idioma capaz de OCR. Ambos métodos requieren el manejo de valores nulos, y ninguno proporciona una vía de recuperación elegante; no hay forma de instalar un lenguaje desde el código ni de incluirlo en la aplicación:

// Windows.Media.Ocr: language availability is a runtime unknown
// Returns null if the language pack is not installed on this machine

var engine = OcrEngine.TryCreateFromLanguage(
    new Windows.Globalization.Language("fr-FR"));

if (engine == null)
{
    // French OCR is simply unavailable — no recovery path
    // User must go to Windows Settings > Language to install French
    throw new InvalidOperationException(
        "French OCR unavailable. Install the French language pack in Windows Settings.");
}

var result = await engine.RecognizeAsync(bitmap);
// Windows.Media.Ocr: language availability is a runtime unknown
// Returns null if the language pack is not installed on this machine

var engine = OcrEngine.TryCreateFromLanguage(
    new Windows.Globalization.Language("fr-FR"));

if (engine == null)
{
    // French OCR is simply unavailable — no recovery path
    // User must go to Windows Settings > Language to install French
    throw new InvalidOperationException(
        "French OCR unavailable. Install the French language pack in Windows Settings.");
}

var result = await engine.RecognizeAsync(bitmap);
Imports Windows.Globalization
Imports Windows.Media.Ocr

' Windows.Media.Ocr: language availability is a runtime unknown
' Returns Nothing if the language pack is not installed on this machine

Dim engine = OcrEngine.TryCreateFromLanguage(New Language("fr-FR"))

If engine Is Nothing Then
    ' French OCR is simply unavailable — no recovery path
    ' User must go to Windows Settings > Language to install French
    Throw New InvalidOperationException("French OCR unavailable. Install the French language pack in Windows Settings.")
End If

Dim result = Await engine.RecognizeAsync(bitmap)
$vbLabelText   $csharpLabel

Para implementar una aplicación de procesamiento de documentos multilingüe con Windows.Media.OCR, es necesario coordinar la instalación del paquete de idioma de Windows en todos los equipos del entorno de implementación. En un servidor compartido o en la máquina de un usuario administrada por la Política de grupo, esto no está bajo el control del desarrollador.

Enfoque de IronOCR

IronOCR distribuye los modelos de lenguaje como paquetes NuGet dedicados que se implementan junto con el binario de la aplicación. Los datos de idioma se transmiten con el artefacto de compilación, no con la configuración del sistema operativo. Soportar más de 125 idiomas es una operación dotnet add package:

dotnet add package IronOcr.Languages.French, IronOcr.Languages.German, IronOcr.Languages.Arabic, IronOcr.Languages.ChineseSimplified
// IronOCR: language availability is a deploy-time guarantee, not a runtime unknown
var ocr = new IronTesseract();
ocr.Language = OcrLanguage.French;
ocr.AddSecondaryLanguage(OcrLanguage.German);

// Works on any machine, any OS, zero OS configuration required
var result = ocr.Read("multilingual-document.jpg");
Console.WriteLine(result.Text);
// IronOCR: language availability is a deploy-time guarantee, not a runtime unknown
var ocr = new IronTesseract();
ocr.Language = OcrLanguage.French;
ocr.AddSecondaryLanguage(OcrLanguage.German);

// Works on any machine, any OS, zero OS configuration required
var result = ocr.Read("multilingual-document.jpg");
Console.WriteLine(result.Text);
Imports IronOcr

' IronOCR: language availability is a deploy-time guarantee, not a runtime unknown
Dim ocr As New IronTesseract()
ocr.Language = OcrLanguage.French
ocr.AddSecondaryLanguage(OcrLanguage.German)

' Works on any machine, any OS, zero OS configuration required
Dim result = ocr.Read("multilingual-document.jpg")
Console.WriteLine(result.Text)
$vbLabelText   $csharpLabel

El catálogo completo de idiomas abarca latín, CJK, árabe, hebreo, devanagari, cirílico y conjuntos especializados que incluyen notación matemática. Cada paquete de idioma está vinculado a la versión del paquete IronOCR, por lo que el modelo de idioma en producción coincide con el que se prueba localmente.

Ausencia de preprocesamiento

Los escaneos de baja calidad (páginas ligeramente giradas, texto fotocopiado con ruido granulado, tinta descolorida sobre papel blanquecino) producen una precisión de OCR deficiente en cualquier motor que los reciba tal cual. El preprocesamiento corrige esos defectos antes de que se ejecute el reconocimiento. Windows.Media.OCR no proporciona ninguna capa de preprocesamiento de ningún tipo.

Enfoque de Windows.Media.OCR

La API acepta un SoftwareBitmap y devuelve texto. Lo que sucede con la calidad de la imagen entre esos dos puntos no es configurable. Los desarrolladores que necesiten mejorar la precisión en entradas subóptimas deben implementar el preprocesamiento manualmente utilizando las APIs de Windows Imaging Component antes de construir el SoftwareBitmap. Se trata de un código fuente independiente con su propia carga de mantenimiento, y sigue siendo específico de Windows por la misma razón que la propia API de OCR:

// Windows.Media.Ocr: no preprocessing — what you pass is what gets recognized
// Skewed, noisy, or low-resolution images degrade accuracy with no remedy
// Manual preprocessing via separate Windows Imaging APIs is the only option

var bitmap = await decoder.GetSoftwareBitmapAsync();
// bitmap goes directly to recognition with no quality improvement
var result = await engine.RecognizeAsync(bitmap);
// Windows.Media.Ocr: no preprocessing — what you pass is what gets recognized
// Skewed, noisy, or low-resolution images degrade accuracy with no remedy
// Manual preprocessing via separate Windows Imaging APIs is the only option

var bitmap = await decoder.GetSoftwareBitmapAsync();
// bitmap goes directly to recognition with no quality improvement
var result = await engine.RecognizeAsync(bitmap);
Imports System.Threading.Tasks

' Windows.Media.Ocr: no preprocessing — what you pass is what gets recognized
' Skewed, noisy, or low-resolution images degrade accuracy with no remedy
' Manual preprocessing via separate Windows Imaging APIs is the only option

Dim bitmap = Await decoder.GetSoftwareBitmapAsync()
' bitmap goes directly to recognition with no quality improvement
Dim result = Await engine.RecognizeAsync(bitmap)
$vbLabelText   $csharpLabel

Para escaneos de documentos estándar y limpios (entorno de escaneo controlado, iluminación uniforme, mínimo de 300 ppp, orientación correcta), esta limitación es manejable. Para los sistemas de procesamiento de documentos que reciben imágenes de cámaras de teléfonos móviles, escáneres planos con desalineación de alimentación automática, documentos enviados por fax o materiales fotocopiados, esto significa crear una capa de preprocesamiento desde cero o aceptar una degradación de la precisión.

Enfoque de IronOCR

La clase OcrInput de IronOCR proporciona una cadena de preprocesamiento con métodos de filtro individuales que se aplican en secuencia. Los filtros de corrección de calidad de imagen abordan los problemas más comunes que afectan la precisión en el procesamiento de documentos de producción:

// IronOCR: explicit preprocessing pipeline
// Each filter targets a specific quality defect
using var input = new OcrInput();
input.LoadImage("low-quality-scan.jpg");

input.Deskew();              // Correct page rotation up to ~40 degrees
input.DeNoise();             // Remove scanner speckle and compression artifacts
input.Contrast();            // Boost contrast on faded or washed-out text
input.Binarize();            // Convert to black/white with optimal threshold
input.EnhanceResolution(300); // Scale image to 300 DPI for recognition

var result = new IronTesseract().Read(input);
Console.WriteLine($"Confidence: {result.Confidence}%");
// IronOCR: explicit preprocessing pipeline
// Each filter targets a specific quality defect
using var input = new OcrInput();
input.LoadImage("low-quality-scan.jpg");

input.Deskew();              // Correct page rotation up to ~40 degrees
input.DeNoise();             // Remove scanner speckle and compression artifacts
input.Contrast();            // Boost contrast on faded or washed-out text
input.Binarize();            // Convert to black/white with optimal threshold
input.EnhanceResolution(300); // Scale image to 300 DPI for recognition

var result = new IronTesseract().Read(input);
Console.WriteLine($"Confidence: {result.Confidence}%");
Imports IronOcr

' IronOCR: explicit preprocessing pipeline
' Each filter targets a specific quality defect
Using input As New OcrInput()
    input.LoadImage("low-quality-scan.jpg")

    input.Deskew()              ' Correct page rotation up to ~40 degrees
    input.DeNoise()             ' Remove scanner speckle and compression artifacts
    input.Contrast()            ' Boost contrast on faded or washed-out text
    input.Binarize()            ' Convert to black/white with optimal threshold
    input.EnhanceResolution(300) ' Scale image to 300 DPI for recognition

    Dim result = New IronTesseract().Read(input)
    Console.WriteLine($"Confidence: {result.Confidence}%")
End Using
$vbLabelText   $csharpLabel

Para el caso común,IronOCR aplica preprocesamiento automático al llamar Read directamente en una ruta de archivo — el motor detecta problemas de calidad y los corrige sin configuración explícita de filtro. El tutorial de filtros de imagen cubre todo el conjunto de filtros, incluyendo Sharpen, Dilate, Erode, Invert y ToGrayScale para escenarios especializados. Los filtros de corrección de color y la corrección de orientación amplían aún más el proceso para documentos con perfiles de color no estándar o rotación multiángulo.

Ausencia de soporte PDF

El formato PDF es el formato de documento predominante en los entornos Enterprise . Los contratos, las facturas, los archivos escaneados y los formularios gubernamentales llegan en formato PDF. Windows.Media.OCR no tiene en cuenta el formato PDF; solo acepta datos de imagen. El reconocimiento óptico de caracteres (OCR) de un documento PDF requiere una biblioteca de renderizado de PDF independiente, la rasterización página por página y el ensamblaje manual de los resultados.

Enfoque de Windows.Media.OCR

La API no incluye ninguna ruta para archivos PDF. Para hacer OCR a un PDF escaneado con Windows.Media.Ocr, el desarrollador debe: renderizar cada página en un SoftwareBitmap usando una biblioteca de renderizado de PDF separada (ninguna de las cuales está integrada en Windows), iterar páginas, llamar RecognizeAsync por página, y concatenar los resultados manualmente. Dicha biblioteca de renderizado conlleva consideraciones adicionales en cuanto a licencias e implementación. El código Windows.Media.OCR es la parte más pequeña de la implementación total:

// Windows.Media.Ocr: no PDF support
// Requires external PDF renderer to rasterize pages before OCR
// Conceptual pattern — a PDF rendering library is not provided by Windows APIs

// Step 1: Use external PDF library to render page to bitmap (not shown)
// Step 2: Pass rendered bitmap to Windows OCR
// var bitmap = RenderPdfPageToBitmap(pdfPath, pageIndex); // external library required

var engine = OcrEngine.TryCreateFromUserProfileLanguages();
if (engine == null)
    throw new Exception("No OCR language available");

// Step 3: Recognize the rasterized page
// var result = await engine.RecognizeAsync(bitmap);
// Step 4: Collect and concatenate results across all pages manually
// Windows.Media.Ocr: no PDF support
// Requires external PDF renderer to rasterize pages before OCR
// Conceptual pattern — a PDF rendering library is not provided by Windows APIs

// Step 1: Use external PDF library to render page to bitmap (not shown)
// Step 2: Pass rendered bitmap to Windows OCR
// var bitmap = RenderPdfPageToBitmap(pdfPath, pageIndex); // external library required

var engine = OcrEngine.TryCreateFromUserProfileLanguages();
if (engine == null)
    throw new Exception("No OCR language available");

// Step 3: Recognize the rasterized page
// var result = await engine.RecognizeAsync(bitmap);
// Step 4: Collect and concatenate results across all pages manually
' Windows.Media.Ocr: no PDF support
' Requires external PDF renderer to rasterize pages before OCR
' Conceptual pattern — a PDF rendering library is not provided by Windows APIs

' Step 1: Use external PDF library to render page to bitmap (not shown)
' Step 2: Pass rendered bitmap to Windows OCR
' Dim bitmap = RenderPdfPageToBitmap(pdfPath, pageIndex) ' external library required

Dim engine = OcrEngine.TryCreateFromUserProfileLanguages()
If engine Is Nothing Then
    Throw New Exception("No OCR language available")
End If

' Step 3: Recognize the rasterized page
' Dim result = Await engine.RecognizeAsync(bitmap)
' Step 4: Collect and concatenate results across all pages manually
$vbLabelText   $csharpLabel

El paso de generación de PDF externo por sí solo añade una dependencia, una curva de aprendizaje independiente y una superficie de fallo adicional a lo que comenzó como una solución "gratuita e integrada".

Enfoque de IronOCR

IronOCR lee archivos PDF de forma nativa. Sin renderizador externo, sin paso de rasterización, sin ensamblaje manual de páginas. El mismo método IronTesseract.Read que acepta rutas de imagen acepta rutas de PDF. El OCR de PDF en .NET es una sola línea:

// IronOCR: native PDF support — no external renderer needed
var text = new IronTesseract().Read("scanned-document.pdf").Text;

// Password-protected PDFs
using var input = new OcrInput();
input.LoadPdf("encrypted.pdf", Password: "secret");
var result = new IronTesseract().Read(input);
Console.WriteLine(result.Text);

// PDF con función de búsqueda output: make a scanned PDF text-searchable
var ocrResult = new IronTesseract().Read("scanned-archive.pdf");
ocrResult.SaveAsSearchablePdf("searchable-output.pdf");
// IronOCR: native PDF support — no external renderer needed
var text = new IronTesseract().Read("scanned-document.pdf").Text;

// Password-protected PDFs
using var input = new OcrInput();
input.LoadPdf("encrypted.pdf", Password: "secret");
var result = new IronTesseract().Read(input);
Console.WriteLine(result.Text);

// PDF con función de búsqueda output: make a scanned PDF text-searchable
var ocrResult = new IronTesseract().Read("scanned-archive.pdf");
ocrResult.SaveAsSearchablePdf("searchable-output.pdf");
Imports IronOcr

' IronOCR: native PDF support — no external renderer needed
Dim text As String = New IronTesseract().Read("scanned-document.pdf").Text

' Password-protected PDFs
Using input As New OcrInput()
    input.LoadPdf("encrypted.pdf", Password:="secret")
    Dim result = New IronTesseract().Read(input)
    Console.WriteLine(result.Text)
End Using

' PDF con función de búsqueda output: make a scanned PDF text-searchable
Dim ocrResult = New IronTesseract().Read("scanned-archive.pdf")
ocrResult.SaveAsSearchablePdf("searchable-output.pdf")
$vbLabelText   $csharpLabel

La función de PDF con capacidad de búsqueda inserta una capa de texto sobre la imagen escaneada original, lo que produce un PDF que conserva la fidelidad visual a la vez que permite la búsqueda de texto completo y la función de copiar y pegar. Este es un requisito común para los sistemas de gestión documental y los archivos de cumplimiento normativo. Windows.Media.OCR no puede producir esta salida en ninguna capa de su API.

Referencia de mapeo de API

Windows.Media.Ocr Equivalente a IronOCR
OcrEngine.TryCreateFromLanguage(lang) new IronTesseract() con ocr.Language = OcrLanguage.X
OcrEngine.TryCreateFromUserProfileLanguages() new IronTesseract() (idioma predeterminado resuelto automáticamente)
engine.RecognizeAsync(softwareBitmap) ocr.Read("image.jpg") o ocr.Read(ocrInput)
OcrResult.Text OcrResult.Text
OcrResult.Lines OcrResult.Lines (con metadatos extendidos)
OcrLine.Text OcrResult.Lines[i].Text
OcrLine.Words OcrResult.Words (con cuadros delimitadores + confianza)
OcrWord.BoundingRect OcrResult.Words[i].X, .Y, .Width, .Height
BitmapDecoder.CreateAsync(stream) input.LoadImage(stream) a través de OcrInput
StorageFile.GetFileFromPathAsync(path) ocr.Read("path") directamente
No existe un equivalente (PDF no compatible) ocr.Read("document.pdf")
No existe un equivalente (PDF no compatible) input.LoadPdf("file.pdf", Password: "x")
No existe un equivalente (no hay un PDF con función de búsqueda). result.SaveAsSearchablePdf("output.pdf")
Sin equivalente (sin preprocesamiento) input.Deskew(), input.DeNoise(), input.Contrast()
No existe un equivalente (no es multilingüe). ocr.AddSecondaryLanguage(OcrLanguage.X)
No hay equivalente (sin confianza) result.Confidence, word.Confidence

Cuando los equipos consideran migrar de Windows.Media.OCR a IronOCR

La aplicación supera las capacidades del escritorio de Windows.

El desencadenante más común es un cambio en los requisitos que introduce un destino de implementación distinto a Windows. Una utilidad de escritorio que comienza como una herramienta interna de Windows se convierte en un servicio web, un microservicio basado en Dockero una función en la nube. En el momento en que eso sucede, Windows.Media.OCR se convierte en un obstáculo. El componente OCR requiere una reescritura completa porque la API no existe en la plataforma de destino; no hay ningún puerto, ningún adaptador de compatibilidad ni ninguna bandera de compilación condicional que solucione el problema. Los equipos que planificaron con antelación utilizando IronOCR no se enfrentan a esta reescritura.

Los requisitos de idioma superan los paquetes instalados.

Los procesos de gestión de documentos suelen ampliar su alcance. Un sistema diseñado para procesar facturas en inglés recibe ahora el requisito de gestionar documentos en francés, alemán, árabe o japonés. Con Windows.Media.OCR, la compatibilidad con esos idiomas requiere coordinar la instalación del paquete de idioma del sistema operativo en todos los destinos de implementación: máquinas de desarrolladores, máquinas virtuales de prueba, servidores de producción y cualquier contenedor incluido. En entornos gestionados mediante directivas de grupo o en máquinas virtuales en la nube con una mínima huella del sistema operativo, esa coordinación resulta poco práctica. Los paquetes de idioma de IronOCR, basados ​​en NuGet, se implementan con la aplicación y no requieren coordinación con el sistema operativo.

Se añade el procesamiento de PDF al alcance.

Cuando el requisito original era "imágenes OCR de un escáner plano", Windows.Media.Ocr funciona. Cuando el requisito se amplía a "procesar también el cúmulo de archivos PDF escaneados en nuestro archivo", se añade una segunda biblioteca al proceso. Esa biblioteca supone una dependencia adicional, una consideración adicional en materia de licencias y una superficie de fallo adicional. Los equipos que necesitan reconocimiento óptico de caracteres (OCR) tanto para imágenes como para PDF en una API unificada descubren que IronOCR elimina la arquitectura de dos bibliotecas desde el principio.

La precisión se degrada con la entrada de datos del mundo real.

Los entornos de escaneo controlados producen imágenes nítidas. Los datos de entrada del mundo real (fotografías tomadas con teléfonos móviles, escaneos planos ligeramente sesgados, documentos antiguos recibidos por fax, materiales fotocopiados) producen una degradación de la precisión que no tiene solución en Windows.Media.OCR. Cuando empiezan a llegar las quejas de los clientes sobre textos que faltan, los equipos descubren que el paso de preprocesamiento que omitieron se ha vuelto necesario. Adaptar el preprocesamiento mediante las API de imágenes de Windows supone un esfuerzo de desarrollo considerable que limita la solución exclusivamente a Windows. El proceso de preprocesamiento de IronOCR ya está implementado.

Surge la pregunta sobre la implementación del servidor.

La documentación de Windows.Media.OCR especifica claramente la ubicación de la API para las aplicaciones cliente. Ejecutarlo en un contexto de servidor (una aplicación ASP.NET que procesa documentos subidos por el usuario, un servicio de Windows que consume una cola de documentos) requiere un entorno de Servidor Windowscon Desktop Experience instalado, que es un perfil de máquina virtual más pesado y costoso que un contenedor Linux. Cuando el equipo de infraestructura pregunta si el proceso de OCR puede ejecutarse en una instancia de Linuxpara reducir los costos de alojamiento, la respuesta con Windows.Media.Ocr es no.

Consideraciones comunes sobre la migración

Cambio en el archivo TFM del proyecto

Windows.Media.Ocr requiere un TFM específico de Windows en el archivo de proyecto (net8.0-windows10.0.19041.0 o similar). Eliminar esa dependencia para admitir objetivos multiplataforma implica eliminar el sufijo TFM.IronOCR se dirige a net6.0, net8.0, y net9.0 sin sufijos específicos de Windows. Al migrar, confirme que ninguna otra dependencia de la API WinRT en el proyecto requiera el TFM de Windows; es posible que otras características de la plataforma Windows (integración con el shell, notificaciones de Windows, etc.) deban abstraerse mediante comprobaciones de la plataforma.

Migración de asíncrona a síncrona

Windows.Media.Ocr es completamente async — RecognizeAsync devuelve IAsyncOperation<OcrResult> que se mapea a Task<OcrResult> a través de la interoperabilidad WinRT.IronOCR proporciona rutas tanto sincrónicas como asincrónicas. El ocr.Read("file.jpg") sincrónico reemplaza directamente la cadena de espera de múltiples pasos. Para aplicaciones de servidor en las que la llamada OCR se encuentra dentro de un servicio en segundo plano o una canalización basada en tareas, también está disponible la ruta asíncrona. En cualquier caso, la transición de más de 6 pasos asíncronos a una sola llamada es sencilla:

// Before: Windows.Media.Ocr — 6+ await operations
var file = await StorageFile.GetFileFromPathAsync(imagePath);
using var stream = await file.OpenAsync(FileAccessMode.Read);
var decoder = await BitmapDecoder.CreateAsync(stream);
var bitmap = await decoder.GetSoftwareBitmapAsync();
var engine = OcrEngine.TryCreateFromUserProfileLanguages();
var winResult = await engine.RecognizeAsync(bitmap);
string text = winResult.Text;

// After:IronOCR— 1 call, same result, any platform
string text = new IronTesseract().Read(imagePath).Text;
// Before: Windows.Media.Ocr — 6+ await operations
var file = await StorageFile.GetFileFromPathAsync(imagePath);
using var stream = await file.OpenAsync(FileAccessMode.Read);
var decoder = await BitmapDecoder.CreateAsync(stream);
var bitmap = await decoder.GetSoftwareBitmapAsync();
var engine = OcrEngine.TryCreateFromUserProfileLanguages();
var winResult = await engine.RecognizeAsync(bitmap);
string text = winResult.Text;

// After:IronOCR— 1 call, same result, any platform
string text = new IronTesseract().Read(imagePath).Text;
Imports Windows.Storage
Imports Windows.Graphics.Imaging
Imports Windows.Media.Ocr

' Before: Windows.Media.Ocr — 6+ await operations
Dim file As StorageFile = Await StorageFile.GetFileFromPathAsync(imagePath)
Using stream = Await file.OpenAsync(FileAccessMode.Read)
    Dim decoder As BitmapDecoder = Await BitmapDecoder.CreateAsync(stream)
    Dim bitmap = Await decoder.GetSoftwareBitmapAsync()
    Dim engine = OcrEngine.TryCreateFromUserProfileLanguages()
    Dim winResult = Await engine.RecognizeAsync(bitmap)
    Dim text As String = winResult.Text
End Using

' After: IronOCR— 1 call, same result, any platform
Dim text As String = New IronTesseract().Read(imagePath).Text
$vbLabelText   $csharpLabel

Sustitución del paquete de idiomas

Para cada idioma previamente resuelto a través de OcrEngine.TryCreateFromLanguage(new Windows.Globalization.Language("fr-FR")), instale el paquete de idiomas de IronOCR correspondiente y establezca ocr.Language = OcrLanguage.French. El catálogo de idiomas de IronOCR incluye los más de 125 paquetes disponibles. Los códigos de idioma se asignan directamente de etiquetas BCP-47 al enum OcrLanguage.

Eliminación del manejo del motor nulo

Windows.Media.OCR requiere una comprobación de nulidad en cada llamada de creación del motor.IronOCR genera excepciones estructuradas en lugar de devolver null en caso de fallos de configuración o inicialización. Elimine las cláusulas de protección contra valores nulos y sustitúyalas por el manejo de excepciones estándar donde sea necesario. El resultado es un sitio de llamadas más limpio y sin el modo de fallo de "idioma no disponible silenciosamente".

Funcionalidades adicionales de IronOCR

Más allá de las funciones que reemplazan directamente la funcionalidad de Windows.Media.OCR,IronOCR abarca capacidades para las que Windows.Media.OCR no tiene equivalente:

  • Procesamiento de documentos escaneados : manejo específico para archivos escaneados de varias páginas, incluyendo entradas TIFF y PDF de varias páginas.
  • Extracción de tablas : detección estructurada de datos tabulares dentro de documentos para partidas de facturas, cuadrículas de informes y matrices de formularios.
  • Tipos de documentos especializados : las zonas MRZ de pasaportes, las líneas de cheques MICR, las placas de matrícula y el texto manuscrito tienen cada uno rutas de procesamiento dedicadas.
  • Seguimiento del progreso : las operaciones por lotes informan del progreso mediante eventos, lo que permite el uso de barras de progreso y la monitorización de la tasa de procesamiento en las interfaces de usuario de la aplicación.

Compatibilidad con .NET y preparación para el futuro

IronOCR es compatible con .NET 6, .NET 7, .NET 8 y .NET 9 en TFM estándar sin sufijos específicos de la plataforma, además de .NET Framework versiones 4.6.2 a 4.8 para la compatibilidad con aplicaciones heredadas. La biblioteca recibe actualizaciones periódicas que siguen el ritmo de lanzamiento de .NET , y la compatibilidad con .NET 10 está prevista para 2026. Windows.Media.OCR está disponible en cualquier versión de .NET que admita la interoperabilidad con WinRT a partir de .NET 5, pero el requisito de Windows TFM limita permanentemente su aplicabilidad a proyectos destinados a Windows. A medida que la historia de .NET sobre la compatibilidad multiplataforma madura, con más equipos que se centran en los contenedores Linuxy las funciones en la nube como objetivos de implementación de primera clase, la limitación de TFM de Windows.Media.Ocr se convierte en una desventaja arquitectónica más pronunciada en lugar de una advertencia menor.

Conclusión

Windows.Media.OCR ocupa un nicho específico y legítimo: una aplicación de escritorio para Windows 10/11sin ambiciones multiplataforma, con necesidades básicas de OCR de imágenes y un presupuesto limitado de 0 dólares. Dentro de ese nicho, funciona. Fuera de ese nicho —en el momento en que la implementación se dirige a un contenedor Linux, una función en la nube, un servidor con requisitos de varios idiomas o una canalización de documentos que procesa archivos PDF— la API no existe en la plataforma de destino y el código debe reemplazarse.

El problema de fondo es que las limitaciones de Windows.Media.OCR son de índole arquitectónica, no circunstanciales. El bloqueo de plataforma no es una opción de configuración que se pueda desactivar; Está integrado en el entorno de ejecución WinRT del que depende la API. La disponibilidad del idioma no es un paquete que deba incluirse en el momento de la compilación; se delega a los administradores del sistema operativo. La compatibilidad con PDF no es una característica que falte para añadir a un paquete NuGet ; Está completamente ausente de la interfaz de programación de aplicaciones (API). Cada limitación requiere un sistema independiente para compensarla, y cada sistema compensatorio reintroduce dependencias de la plataforma.

IronOCR resuelve las cuatro limitaciones (plataforma, idioma, preprocesamiento y PDF) en un único paquete. El precio de entrada de $999 no es $0, y para una utilidad de escritorio solo para Windows con entrada controlada y documentos solo en inglés, Windows.Media.Ocr sigue siendo una opción válida. Para cualquier proyecto con requisitos más amplios, el costo de construir en torno a las limitaciones de Windows.Media.Ocr puede exceder el costo de la licencia de IronOCR en horas de desarrollador antes de que el proyecto alcance su primera implementación en producción.

La prueba práctica es sencilla: si el destino de la implementación pudiera ser Linux, Dockero una función en la nube, y si los documentos de entrada pudieran ser archivos PDF o estar en idiomas distintos a los del paquete predeterminado del sistema operativo, Windows.Media.OCR no es la base adecuada. Descubrirlo a mitad de un proyecto es considerablemente más caro que elegir la herramienta adecuada desde el principio. Evaluar las funcionalidades de IronOCR en función de sus requisitos específicos antes de decidirse por una u otra opción es la forma más eficiente de tomar esa decisión.

Por favor notaTesseract y Windows Media OCR son marcas registradas de sus respectivos dueños. Este sitio no está afiliado con, respaldado por, o patrocinado por Google o Microsoft. Todos los nombres de producto, logotipos y marcas son propiedad de sus respectivos dueños. Las comparaciones son solo para fines informativos y reflejan información públicamente disponible en el momento de la redacción.

Preguntas Frecuentes

¿Qué es Windows.Media.Ocr?

Windows.Media.Ocr es una solución de OCR utilizada por desarrolladores y empresas para extraer texto de imágenes y documentos. Es una de las diversas opciones de OCR evaluadas junto con IronOCR for .NET para el desarrollo de aplicaciones.

¿Cómo se compara IronOCR con Windows.Media.Ocr para desarrolladores .NET?

IronOCR es una biblioteca de OCR .NET nativa de NuGet que utiliza IronTesseract como motor principal. En comparación con Windows.Media.Ocr, ofrece un despliegue más sencillo (sin instaladores SDK), precios de tarifa plana y una API de C# limpia sin interoperabilidad COM ni dependencias de la nube.

¿Es IronOCR más fácil de configurar que Windows.Media.Ocr?

IronOCR se instala mediante un único paquete NuGet. No hay instaladores de SDK, archivos de licencia que copiar, componentes COM que registrar ni binarios de ejecución independientes que gestionar. Todo el motor de OCR está incluido en el paquete.

¿Qué diferencias de precisión existen entre Windows.Media.Ocr e IronOCR?

IronOCR logra una alta precisión de reconocimiento para documentos comerciales estándar, facturas, recibos y formularios escaneados. Para documentos muy degradados o escrituras poco comunes, la precisión varía en función de la calidad de la fuente. IronOCR incluye filtros de preprocesamiento de imágenes para mejorar el reconocimiento en entradas de baja calidad.

¿Es IronOCR compatible con la extracción de texto en PDF?

Sí. IronOCR extrae texto tanto de PDF nativos como de imágenes PDF escaneadas en una sola llamada. También admite archivos TIFF de varias páginas, imágenes y secuencias. En el caso de los PDF escaneados, el OCR se aplica página a página con objetos de resultado por página.

¿Qué diferencia hay entre las licencias de Windows.Media.Ocr y las de IronOCR?

IronOCR utiliza una licencia perpetua de tarifa plana sin cargos por página o por escaneo. Las organizaciones que procesan grandes volúmenes de documentos pagan el mismo coste de licencia independientemente del volumen. Encontrará más información y precios por volumen en la página de licencias de IronOCR.

¿Qué idiomas admite IronOCR?

IronOCR es compatible con 127 idiomas a través de paquetes de idiomas NuGet independientes. Para añadir un idioma, basta con ejecutar el comando 'dotnet add package IronOcr.Languages.{Language}'. No es necesaria la colocación manual de archivos ni la configuración de rutas.

¿Cómo instalo IronOCR en un proyecto .NET ?

Instalación a través de NuGet: install-Package IronOcr' en la consola del gestor de paquetes o 'dotnet add package IronOcr' en la CLI. Los paquetes de idiomas adicionales se instalan del mismo modo. No se requiere ningún instalador nativo del SDK.

¿Es IronOCR adecuado para Docker y las implementaciones en contenedores, a diferencia de Windows.Media.Ocr?

Sí. IronOCR funciona en contenedores Docker a través de su paquete NuGet. La clave de licencia se establece mediante una variable de entorno. No se requieren archivos de licencia, rutas de SDK ni montajes de volumen para el propio motor de OCR.

¿Puedo probar IronOCR antes de comprarlo, en comparación con Windows.Media.Ocr?

Sí. El modo de prueba de IronOCR procesa documentos y devuelve resultados de OCR con una marca de agua superpuesta en la salida. Puede verificar la precisión en sus propios documentos antes de adquirir una licencia.

¿Admite IronOCR la lectura de códigos de barras junto con la extracción de texto?

IronOCR se centra en la extracción de texto y el reconocimiento óptico de caracteres. Para la lectura de códigos de barras, Iron Software ofrece IronBarcode como biblioteca complementaria. Ambas están disponibles por separado o como parte del paquete Iron Suite.

¿Es fácil migrar de Windows.Media.Ocr a IronOCR?

La migración de Windows.Media.Ocr a IronOCR suele implicar la sustitución de las secuencias de inicialización por la instanciación de IronTesseract, la eliminación de la gestión del ciclo de vida COM y la actualización de las llamadas a la API. La mayoría de las migraciones reducen significativamente la complejidad del código.

Kannaopat Udonpant
Ingeniero de Software
Antes de convertirse en Ingeniero de Software, Kannapat completó un doctorado en Recursos Ambientales de la Universidad de Hokkaido en Japón. Mientras perseguía su grado, Kannapat también se convirtió en miembro del Laboratorio de Robótica de Vehículos, que es parte del Departamento de Ingeniería ...
Leer más

Equipo de soporte de Iron

Estamos disponibles online las 24 horas, 5 días a la semana.
Chat
Email
Llámame