IRONSOFTWAREHOME
VIDÉOS

Migration de Windows.Media.Ocr vers IronOCR

Kannaopat Udonpant
Kannapat Udonpant
Updated: 1 août 2026

Ce guide fournit une procédure de migration étape par étape pour les développeurs .NET passant de Windows.Media.OCR à IronOCR. Elle couvre la suppression des espaces de noms, les modifications des fichiers de projet, des exemples de migration de code pour les schémas les plus fréquents lors de la migration, ainsi qu'une liste de contrôle pratique pour valider la transition une fois terminée.

Pourquoi migrer depuis Windows.Media.OCR (UWP/WinRT OCR)

Windows.Media.OCR fonctionne bien dans son domaine d'application. Ces limites sont étroites, et les projets les dépassent régulièrement. Les raisons pour lesquelles les équipes migrent relèvent de catégories prévisibles.

Le TFM Windows bloque chaque cible non Windows. Le fichier de projet doit déclarer un net*-windows* Target Framework Moniker avant que le Windows.Media.Ocr namespace ne se résolve même au moment de la compilation. Cette déclaration n'est pas un indicateur d'exécution — c'est une contrainte de build qui se propage à chaque projet référencé par le vôtre. Une bibliothèque de services OCR partagée, une API Web, un worker en arrière-plan déployé sur Linux — tous sont soumis à cette contrainte. Le supprimer revient à supprimer Windows.Media.OCR.

La disponibilité linguistique est déterminée à l'exécution par le système d'exploitation, et non au moment de la compilation par le développeur. OcrEngine.TryCreateFromLanguage renvoie null lorsque le pack de langue demandé est absent de la machine hôte. Le développeur ne peut pas installer un pack de langue à partir du code, en intégrer un avec le binaire de l'application, ou fournir un modèle de secours. Dans les environnements automatisés (agents de build, exécuteurs CI, machines virtuelles cloud minimales, conteneurs), les packs linguistiques sont rarement installés. Les défaillances de production causées par l'absence d'un pack de langues ne sont pas reproductibles en examinant le code ; Ils nécessitent de vérifier la configuration du système d'exploitation de la machine cible.

Pas de prétraitement signifie pas de chemin de récupération pour une entrée sous-optimale. L'API accepte un SoftwareBitmap et produit du texte. L'amélioration de la qualité de l'image entre ces deux points relève entièrement de la responsabilité du développeur, qui doit utiliser des API Windows Imaging Component distinctes, elles-mêmes réservées à Windows. Les photos prises avec un téléphone portable, les numérisations à plat mal alignées et les documents photocopiés nuisent silencieusement à la précision, sans qu'il n'existe de mécanisme intégré pour diagnostiquer ou améliorer le résultat.

Le PDF est le format de document le plus courant dans les flux de travail d'Enterprise. Windows.Media.OCR ne prend pas en charge les fichiers PDF en entrée. Le traitement d'un PDF numérisé nécessite un moteur de rendu externe, une rastérisation page par page et un assemblage manuel des résultats. Ce moteur de rendu ajoute une dépendance, des considérations relatives aux licences et une surface de défaillance distincte — exactement la complexité qu'une bibliothèque " gratuite et intégrée " était censée éviter.

Le déploiement côté serveur n'est pas pris en charge. Windows.Media.OCR est destiné aux applications clientes. Son exécution sur Windows Server nécessite le pack de fonctionnalités Desktop Experience, ce qui augmente le coût des machines virtuelles et la complexité de l'infrastructure. Le déploiement via Docker est impossible. Azure Functions sur Linux, AWS Lambda et toute charge de travail de conteneurs basée sur Linux ne peuvent tout simplement pas faire référence à l'API.

La pile asynchrone WinRT est incompatible avec les modèles standard .NET. Six appels await ou plus en chaîne — StorageFile, stream, BitmapDecoder, SoftwareBitmap, vérification de null, RecognizeAsync — sont nécessaires avant qu'un seul caractère soit lu. L'intégration de cette chaîne dans un service d'arrière-plan, une boucle Parallel.ForEach ou un contrôleur ASP.NET standard est peu pratique. La machinerie IAsyncOperation WinRT se trouve en dessous, et l'interaction avec le modèle Task de .NET crée des cas limites subtils dans des contextes non-UI.

Le problème fondamental

La disponibilité de la langue dans Windows.Media.OCR est une erreur d'exécution inconnue qui ne peut être résolue au moment du déploiement :

// Windows.Media.Ocr: language availability decided by OS admin, not the developer
// Returns null on any machine without the language pack installed
var engine = OcrEngine.TryCreateFromLanguage(
    new Windows.Globalization.Language("ja-JP"));

if (engine == null)
    throw new InvalidOperationException(
        "Japanese OCR unavailable — install the Japanese language pack in Windows Settings.");
// Non recovery path. Non bundled model. Non fallback.
C#
// IronOCR: language availability is a NuGet package, not an OS configuration
// dotnet add package IronOcr.Languages.Japanese
var ocr = new IronTesseract();
ocr.Language = OcrLanguage.Japanese;
var result = ocr.Read("invoice.jpg"); // Works on any OS, any machine
Console.WriteLine(result.Text);
C#

IronOCR vs Windows.Media.Ocr (OCR UWP/WinRT) : comparaison des fonctionnalités

Le tableau ci-dessous présente l'ensemble des fonctionnalités pertinentes pour les décisions de migration.

FonctionWindows.Media.OcrIronOCR
Plateforme : Windows 10/11OuiOui
Plateforme : Windows ServerLimité (expérience en informatique de bureau requise)Oui
Plateforme : LinuxNonOui
Plateforme : macOSNonOui
Plateforme : conteneurs DockerNonOui
Plateforme : Azure Functions (Linux)NonOui
Plateforme : AWS LambdaNonOui
Exigences du projet TFMnet*-windows* requisAucun (TFM standard)
InstallationIntégré à Windows (sans NuGet)Package NuGet unique (IronOcr)
Fichiers image (JPG, PNG, BMP)Oui (via le pipeline WinRT)Oui
Entrée PDFNonOui (natif)
Fichier TIFF multipages en entréeNonOui
Entrée de flux et de tableaux d'octetsNon (StorageFile uniquement)Oui
Langue sourcemodules linguistiques installés par le système d'exploitationPlus de 125 paquets NuGet inclus
Portabilité linguistiqueNon (dépendant de la machine)Oui (déployer avec l'application)
Multilingue simultanéNonOui
Prétraitement : redressementNonOui (input.Deskew())
Prétraitement : débruitageNonOui (input.DeNoise())
Prétraitement : contrasteNonOui (input.Contrast())
Prétraitement : binarisationNonOui (input.Binarize())
Sortie PDF consultableNonOui (result.SaveAsSearchablePdf())
Scores de confiance par motNonOui (word.Confidence)
Structure de sortie (paragraphes, lignes, WORDs)Lignes uniquementPages, paragraphes, lignes, mots, caractères
Lecture de BarCodes pendant l'OCRNonOui
OCR basé sur la régionNonOui (CropRectangle)
Chemin OCR synchroneNonOui
Traitement parallèle thread-safeLimitéComplet
soutien commercialNon (équipe de la plateforme Windows)Oui
Modèle de licenceGratuit (intégré à Windows)Perpetual ($999 Lite, $1,499 Pro, $2,999 Enterprise)

Guide de démarrage rapide : migration de Windows.Media.Ocr (OCR UWP/WinRT) vers IronOCR

Étape 1 : Remplacer le package NuGet

Windows.Media.OCR ne dispose pas de package NuGet — il fait partie du Windows Runtime et est résolu via le Windows TFM. Le supprimer signifie supprimer les références à l'espace de noms spécifique à Windows et, dans la mesure du possible, le TFM Windows du fichier de projet.

Supprimez les espaces de noms Windows.Media.OCR de tous les fichiers source :

# Audit all files referencing Windows OCR namespaces
grep -r "Windows.Media.Ocr\|Windows.Graphics.Imaging\|Windows.Storage" --include="*.cs" .
SHELL

Installer IronOCR :

dotnet add package IronOcr

Le package NuGet IronOCR cible net6.0, net7.0, net8.0, et net9.0 sans TFMs spécifiques à la plateforme. Après avoir supprimé les namespaces OCR Windows, mettez à jour le <TargetFramework> dans le fichier de projet de net8.0-windows10.0.19041.0 à net8.0 (ou la version appropriée), à condition qu'aucune autre API WinRT ne reste dans le projet.

Étape 2 : Mise à jour des espaces de noms

Remplacer les trois espaces de noms Windows OCR par un seul espace de noms IronOCR :

// Before (Windows.Media.Ocr)
using Windows.Media.Ocr;
using Windows.Graphics.Imaging;
using Windows.Storage;
using Windows.Globalization;

// After (IronOCR)
using IronOcr;
C#

Étape 3 : initialisation de la licence

Ajoutez l'appel d'initialisation de la licence une fois au démarrage de l'application — dans Program.cs, Startup.cs, ou le constructeur de l'hôte de l'application :

IronOcr.License.LicenseKey = "YOUR-LICENSE-KEY";

Une clé d'essai gratuite est disponible sur la page de licence d'IronOCR et permet de supprimer le filigrane d'essai à des fins d'évaluation.

Exemples de migration de code

Remplacer la chaîne asynchrone WinRT dans un service d'arrière-plan

Windows.Media.OCR nécessite au moins six opérations asynchrones en chaîne avant que la reconnaissance ne commence. Dans un service en arrière-plan qui traite une file d'attente de documents, cette chaîne fonctionne dans une boucle — et la destruction SoftwareBitmap, la vérification de null, et l'interopérabilité IAsyncOperation WinRT ajoutent des frictions à chaque itération.

Approche Windows.Media.OCR :

// Windows.Media.Ocr: full async chain required per document
// Requires net8.0-windows10.0.19041.0 TFM — cannot deploy to Linux workers
public async Task<List<string>> ProcessQueueAsync(IEnumerable<string> imagePaths)
{
    var engine = OcrEngine.TryCreateFromUserProfileLanguages();
    if (engine == null)
        throw new InvalidOperationException("No OCR language pack installed on this machine.");

    var results = new List<string>();

    foreach (var path in imagePaths)
    {
        // Each document: 4 async steps before RecognizeAsync
        var file = await StorageFile.GetFileFromPathAsync(path);
        using var stream = await file.OpenAsync(FileAccessMode.Read);
        var decoder = await BitmapDecoder.CreateAsync(stream);
        var bitmap = await decoder.GetSoftwareBitmapAsync();

        var ocrResult = await engine.RecognizeAsync(bitmap);
        results.Add(ocrResult.Text);

        bitmap.Dispose();
    }

    return results;
}
C#

Approche IronOCR :

// IronOCR: one call per document, no WinRT, no SoftwareBitmap, no null checks
// Runs on Windows, Linux, macOS, Docker — same binary, no TFM change
public List<string> ProcessQueue(IEnumerable<string> imagePaths)
{
    var results = new List<string>();

    foreach (var path in imagePaths)
    {
        var result = new IronTesseract().Read(path);
        results.Add(result.Text);
    }

    return results;
}
C#

La version IronOCR élimine le StorageFile aller-retour, le cycle de vie BitmapDecoder, le SoftwareBitmap, et la protection de la vérification de null. Pour les services natifs asynchrones, IronOCR fournit un chemin asynchrone qui s'intègre harmonieusement dans les pipelines à base de Task sans surcharges d'interopérabilité WinRT. Le guide d'installation d'IronTesseract couvre les recommandations relatives au cycle de vie des instances pour les scénarios de files d'attente à haut débit.

Élimination de la conversion SoftwareBitmap pour les données d'image en mémoire

Les applications qui ont déjà des données d'image en mémoire — provenant d'un téléchargement réseau, d'un blob de base de données, ou d'un rappel de capture de caméra — doivent convertir ces données en un SoftwareBitmap avant que Windows.Media.Ocr puisse les traiter. Ce chemin de conversion passe par BitmapDecoder, qui nécessite un flux, ce qui signifie copier le tableau d'octets dans un MemoryStream. IronOCR accepte directement les tableaux d'octets et les flux.

Approche Windows.Media.OCR :

// Windows.Media.Ocr: byte array must travel through WinRT stream → BitmapDecoder → SoftwareBitmap
public async Task<string> RecognizeFromBytesAsync(byte[] imageBytes)
{
    var engine = OcrEngine.TryCreateFromUserProfileLanguages();
    if (engine == null)
        throw new InvalidOperationException("No OCR language available.");

    // Copy byte array into InMemoryRandomAccessStream (WinRT type)
    using var ras = new Windows.Storage.Streams.InMemoryRandomAccessStream();
    using var writer = new Windows.Storage.Streams.DataWriter(ras);
    writer.WriteBytes(imageBytes);
    await writer.StoreAsync();
    ras.Seek(0);

    var decoder = await BitmapDecoder.CreateAsync(ras);
    var bitmap = await decoder.GetSoftwareBitmapAsync();

    var result = await engine.RecognizeAsync(bitmap);
    bitmap.Dispose();
    return result.Text;
}
C#

Approche IronOCR :

// IronOCR: byte array loads directly into OcrInput — no conversion, no WinRT types
public string RecognizeFromBytes(byte[] imageBytes)
{
    using var input = new OcrInput();
    input.LoadImage(imageBytes); // direct byte array load

    var result = new IronTesseract().Read(input);
    return result.Text;
}
C#

Le chemin Windows.Media.Ocr nécessite InMemoryRandomAccessStream — un type WinRT qui ne peut pas être instancié en dehors de Windows — plus DataWriter, BitmapDecoder, et SoftwareBitmap. Le chemin IronOCR utilise OcrInput.LoadImage(byte[]) et produit le résultat en deux lignes. Consultez le guide d'entrée du flux pour des modèles de chargement basés sur Stream, qui suivent la même simplicité que l'entrée du tableau d'octets.

Traitement de documents multilingues sans coordination avec le système d'exploitation

Un pipeline de facturation multilingue devant reconnaître du texte en anglais, en français et en allemand en un seul passage se heurte à une impasse architecturale avec Windows.Media.OCR. L'API n'autorise qu'une seule langue par instance de moteur. Le traitement d'un document multilingue nécessite soit un moteur monolingue utilisant la meilleure estimation possible, soit trois cycles de reconnaissance suivis d'une fusion des résultats — aucune de ces deux méthodes ne produisant un résultat fiable.

Approche Windows.Media.OCR :

// Windows.Media.Ocr: one language per engine, no simultaneous multi-language support
// Each language requires a separate language pack installed on the machine
public async Task<string> RecognizeMultiLanguageAsync(SoftwareBitmap bitmap)
{
    // Must pick ONE language — no simultaneous recognition
    var engine = OcrEngine.TryCreateFromLanguage(
        new Windows.Globalization.Language("en-US"));
    if (engine == null)
        throw new InvalidOperationException("English language pack not installed.");

    // French and German text on the same document will be misrecognized
    var result = await engine.RecognizeAsync(bitmap);
    return result.Text;
}
C#

Approche IronOCR :

// IronOCR: simultaneous multi-language recognition in a single pass
// Language packs are NuGet packages — no OS coordination required
// dotnet add package IronOcr.Languages.French
// dotnet add package IronOcr.Languages.German
public string RecognizeMultiLanguage(string documentPath)
{
    var ocr = new IronTesseract();
    ocr.Language = OcrLanguage.English + OcrLanguage.French + OcrLanguage.German;

    var result = ocr.Read(documentPath);

    // Structured output: walk paragraphs with location data
    foreach (var page in result.Pages)
    {
        foreach (var paragraph in page.Paragraphs)
        {
            Console.WriteLine($"[{paragraph.X},{paragraph.Y}] {paragraph.Text}");
        }
    }

    return result.Text;
}
C#

IronOCR combine plusieurs modèles linguistiques en un seul passage de reconnaissance, éliminant ainsi le besoin de deviner quelle langue est utilisée dans une région donnée. Le guide OCR multilingue couvre l'installation des packs de langues et des valeurs d'énumération OcrLanguage pour les 125+ langues prises en charge. L'index des langues répertorie le catalogue complet, y compris les scripts CJK, l'arabe, l'hébreu, le devanagari et les familles cyrilliques.

Activation de l'OCR côté serveur avec traitement parallèle

Windows.Media.OCR ne peut pas s'exécuter dans un contexte serveur sous Linux, ne peut pas être appelé à partir d'un contrôleur .NET Core standard sur un hôte multiplateforme et présente un comportement indéfini lorsqu'il est appelé à partir de threads non-UI dans des scénarios serveur. Une équipe qui fait passer un point de terminaison OCR d'une application de bureau réservée à Windows à une API Web évolutive est confrontée simultanément à ces trois contraintes.

Approche Windows.Media.OCR :

// Windows.Media.Ocr: cannot run on Linux, Docker, or Azure Functions on Linux
// UWP/WinRT assumptions about thread context cause failures in ASP.NET pipelines
// The entire approach below is non-deployable outside Windows with Desktop Experience

[HttpPost("ocr")]
public async Task<IActionResult> RecognizeDocument(IFormFile file)
{
    // WinRT requires STA thread context in some scenarios — not guaranteed in ASP.NET
    // Cannot deploy this controller to a Linux App Service plan
    using var stream = file.OpenReadStream();
    // InMemoryRandomAccessStream is a WinRT type — does not exist on Linux
    // var ras = new InMemoryRandomAccessStream(); // compile error on net8.0 TFM
    return StatusCode(503, "Windows-only — cannot deploy cross-platform.");
}
C#

Approche IronOCR :

// IronOCR: ASP.NET Core controller running on Linux, Docker, or Windows — same code
[HttpPost("ocr")]
public async Task<IActionResult> RecognizeDocument(IFormFile file)
{
    if (file == null || file.Length == 0)
        return BadRequest("No file provided.");

    using var memoryStream = new MemoryStream();
    await file.CopyToAsync(memoryStream);
    var imageBytes = memoryStream.ToArray();

    using var input = new OcrInput();
    input.LoadImage(imageBytes);
    input.Deskew();   // straighten uploaded scans automatically
    input.DeNoise();  // remove mobile camera noise

    var result = new IronTesseract().Read(input);

    return Ok(new
    {
        Text = result.Text,
        Confidence = result.Confidence,
        Pages = result.Pages.Count
    });
}
C#

Ce contrôleur se déploie sur Linux App Service, Docker et AWS Lambda sans modification. Le guide de déploiement Docker couvre la dépendance apt-get unique requise sur l'image de base Linux. Le guide de déploiement Azure et le guide AWS présentent la configuration spécifique au cloud.

Génération de PDF consultables à partir d'archives numérisées

Windows.Media.OCR génère des chaînes de texte brut. Il n'a pas de format de sortie au-delà de OcrResult.Text et de la géométrie linéaire en OcrResult.Lines. La conversion d'une archive numérisée en fichiers PDF consultables — une exigence courante pour les systèmes de gestion de documents et les workflows de conformité — nécessite une troisième bibliothèque pour construire la couche de sortie PDF. IronOCR produit des PDF consultables en mode natif.

Approche Windows.Media.OCR :

// Windows.Media.Ocr: plain text output only
// Searchable PDF requires external PDF library + manual text layer construction
public async Task<string> GetTextOnlyAsync(SoftwareBitmap bitmap)
{
    var engine = OcrEngine.TryCreateFromUserProfileLanguages();
    if (engine == null)
        throw new InvalidOperationException("No OCR language available.");

    var result = await engine.RecognizeAsync(bitmap);

    // result.Text is all you get
    // Producing a searchable PDF requires an entirely separate library
    return result.Text;
}
C#

Approche IronOCR :

// IronOCR: searchable PDF output is one method call on OcrResult
public void ProcessScannedArchive(IEnumerable<string> pdfPaths, string outputDirectory)
{
    foreach (var sourcePdf in pdfPaths)
    {
        var ocr = new IronTesseract();

        using var input = new OcrInput();
        input.LoadPdf(sourcePdf);   // native PDF input — no external renderer
        input.Deskew();             // correct scan misalignment per page
        input.DeNoise();            // remove scanner speckle

        var result = ocr.Read(input);

        var outputFileName = Path.Combine(
            outputDirectory,
            Path.GetFileNameWithoutExtension(sourcePdf) + "-searchable.pdf");

        result.SaveAsSearchablePdf(outputFileName);

        Console.WriteLine($"Processed: {sourcePdf}{outputFileName} " +
                          $"({result.Pages.Count} pages, {result.Confidence:F1}% confidence)");
    }
}
C#

L'appel SaveAsSearchablePdf intègre une couche de texte sur l'image numérisée originale, préservant la fidélité visuelle tout en permettant une recherche textuelle complète et un Ctrl+F dans n'importe quel visionneur PDF. Le guide pratique au format PDF consultable couvre les options d'intégration des polices, de positionnement des calques de texte et de sortie multipages. Le guide d'entrée PDF traite des fichiers PDF protégés par mot de passe et de la sélection de plages de pages pour les archives volumineuses.

Extraction de données structurées à l'aide de coordonnées au niveau des mots

Windows.Media.Ocr expose OcrResult.Lines avec un texte au niveau des lignes et des rectangles englobants. La géométrie par mot existe en OcrLine.Words avec OcrWord.BoundingRect, mais il n'y a pas de paragraphes, pas de scores de confiance, et pas de données au niveau des caractères. Pour l'extraction de champs de formulaire ou l'analyse des lignes de facture, la géométrie des lignes est insuffisante : les limites de paragraphe et les scores de confiance des mots sont nécessaires pour distinguer les champs structurés du texte environnant.

Approche Windows.Media.OCR :

// Windows.Media.Ocr: line-level geometry, no paragraph grouping, no confidence scores
public async Task<List<string>> ExtractLineTextAsync(SoftwareBitmap bitmap)
{
    var engine = OcrEngine.TryCreateFromUserProfileLanguages();
    if (engine == null)
        throw new InvalidOperationException("No OCR language available.");

    var result = await engine.RecognizeAsync(bitmap);

    var lineTexts = new List<string>();
    foreach (var line in result.Lines)
    {
        // Line text + word bounding rects — no paragraph grouping, no confidence
        lineTexts.Add(line.Text);
    }
    return lineTexts;
}
C#

Approche IronOCR :

// IronOCR: full hierarchy — pages, paragraphs, lines, words, characters
// Each element carries coordinates and confidence for downstream validation
public void ExtractStructuredData(string documentPath)
{
    var result = new IronTesseract().Read(documentPath);

    Console.WriteLine($"Overall confidence: {result.Confidence:F1}%");

    foreach (var page in result.Pages)
    {
        Console.WriteLine($"\n--- Page {page.PageNumber} ---");

        foreach (var paragraph in page.Paragraphs)
        {
            Console.WriteLine($"Paragraph at ({paragraph.X},{paragraph.Y}): {paragraph.Text}");

            // Filter words below confidence threshold for validation workflows
            var lowConfidence = paragraph.Words
                .Where(w => w.Confidence < 70)
                .ToList();

            if (lowConfidence.Any())
            {
                Console.WriteLine($"  Low-confidence words: " +
                    string.Join(", ", lowConfidence.Select(w => $"'{w.Text}' ({w.Confidence:F0}%)")));
            }
        }
    }
}
C#

Le modèle de résultat structuré — Pages, Paragraphs, Lines, Words, Characters — fournit les coordonnées et les données de confiance nécessaires pour l'extraction des champs de formulaire, le traitement des factures, et l'analyse de mise en page des documents. Le guide de lecture des résultats documente la totalité de l'arborescence des objets OcrResult. Le guide des scores de confiance explique comment utiliser les valeurs de confiance par WORD pour signaler les extractions incertaines en vue d'une révision humaine.

Référence de mappage de l'API Windows.Media.OCR vers IronOCR

Windows.Media.OcrIronOCR
OcrEngine.TryCreateFromLanguage(lang)new IronTesseract() + ocr.Language = OcrLanguage.X
OcrEngine.TryCreateFromUserProfileLanguages()new IronTesseract() (anglais par défaut; (pas de retour null)
engine.RecognizeAsync(softwareBitmap)ocr.Read("image.jpg") ou ocr.Read(ocrInput)
StorageFile.GetFileFromPathAsync(path)ocr.Read("path") directement (aucun gestionnaire de fichiers nécessaire)
file.OpenAsync(FileAccessMode.Read)Éliminé — OcrInput se charge directement
BitmapDecoder.CreateAsync(stream)input.LoadImage(stream) via OcrInput
decoder.GetSoftwareBitmapAsync()Éliminé — pas de SoftwareBitmap dans IronOCR
SoftwareBitmap (type WinRT)Éliminé — OcrInput accepte des octets, des flux, des chemins de fichiers
InMemoryRandomAccessStream (type WinRT)new MemoryStream() + input.LoadImage(stream)
OcrResult.TextOcrResult.Text
OcrResult.LinesOcrResult.Lines (aussi Pages, Paragraphs, Words, Characters)
OcrLine.TextOcrResult.Lines[i].Text
OcrLine.WordsOcrResult.Words ou page.Paragraphs[i].Words
OcrWord.BoundingRectword.X, word.Y, word.Width, word.Height
Aucun équivalentresult.Confidence (global) / word.Confidence (par mot)
Aucun équivalentresult.SaveAsSearchablePdf("output.pdf")
Aucun équivalentinput.LoadPdf("document.pdf")
Aucun équivalentinput.Deskew(), input.DeNoise(), input.Contrast()
Aucun équivalentocr.Language = OcrLanguage.A + OcrLanguage.B (simultané)
Aucun équivalentocr.Configuration.ReadBarCodes = true
Aucun équivalentinput.LoadImage(byteArray)

Problèmes de migration courants et solutions

Problème n° 1 : le fichier de projet nécessite toujours Windows TFM après la migration

Windows.Media.Ocr : La déclaration <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework> est requise pour que les types WinRT soient résolus. La suppression des références à Windows.Media.OCR sans vérifier les autres dépendances WinRT dans le même projet peut laisser le TFM en place, empêchant ainsi les builds multiplateformes.

Solution : après avoir supprimé les références à l'espace de noms OCR, recherchez dans le projet toute utilisation restante de l'API WinRT avant de modifier le fichier TFM :

# Find remaining WinRT API usage before removing the Windows TFM
grep -r "Windows\." --include="*.cs" .
grep -r "WinRT\|IAsyncOperation\|StorageFile\|SoftwareBitmap" --include="*.cs" .
SHELL

S'il ne reste aucune référence WinRT, mettez à jour le fichier de projet :

<!-- Before -->
<TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>

<!-- After -->
<TargetFramework>net8.0</TargetFramework>
XML

Si d'autres fonctionnalités WinRT (notifications Windows, intégration au shell, XAML) restent utilisées, abstrayez l'appel OCR derrière une interface et fournissez des implémentations spécifiques à la plateforme plutôt que de supprimer le TFM à l'échelle du projet.

Problème n° 2 : les vérifications de moteur nul n'ont pas d'équivalent dans IronOCR

Windows.Media.Ocr : Chaque appel à TryCreateFromLanguage et TryCreateFromUserProfileLanguages peut renvoyer null. Tout le code existant contient des clauses de protection contre les valeurs nulles qui génèrent une exception ou effectuent une branche en cas de moteur nul.

Solution : IronOCR lève des exceptions structurées en cas d'échec de l'initialisation plutôt que de renvoyer null. Supprimez les clauses de protection contre les valeurs nulles. Enveloppez le code dans une structure try/catch standard si vous devez signaler des erreurs d'initialisation à l'appelant :

// Before: null-check pattern
var engine = OcrEngine.TryCreateFromUserProfileLanguages();
if (engine == null)
    throw new InvalidOperationException("OCR unavailable.");

// After: no null — IronTesseract throws if misconfigured
try
{
    var result = new IronTesseract().Read("document.jpg");
}
catch (IronOcr.Exceptions.OcrException ex)
{
    // structured exception with diagnostic message
    logger.LogError("OCR failed: {Message}", ex.Message);
}
C#

Problème n° 3 : Paramètres SoftwareBitmap dans les signatures de méthodes existantes

Windows.Media.Ocr : Les méthodes utilitaires, les services et les classes de référentiels peuvent accepter SoftwareBitmap comme type de paramètre. Ces signatures de méthode ne peuvent pas être compilées lorsque le TFM Windows est supprimé.

Solution : Remplacez les paramètres SoftwareBitmap par byte[] ou Stream. L'OcrInput d'IronOCR accepte les deux directement. Les sites d'appel qui en construisaient auparavant un SoftwareBitmap peuvent plutôt transmettre leurs données sous-jacentes :

// Before: SoftwareBitmap parameter — cannot compile cross-platform
public async Task<string> RecognizeAsync(SoftwareBitmap bitmap) { ... }

// After: byte array parameter — compiles on all platforms
public string Recognize(byte[] imageBytes)
{
    using var input = new OcrInput();
    input.LoadImage(imageBytes);
    return new IronTesseract().Read(input).Text;
}
C#

Problème n° 4 : les appelants asynchrones ne peuvent pas utiliser directement IronOCR synchrone

Windows.Media.Ocr : Chaque appel de reconnaissance est async. Les appelants dans l'ensemble du code utilisent await et renvoient Task<string>. Utiliser la méthode synchrone Read d'IronOCR à l'intérieur d'une méthode async fonctionne mais peut introduire des appels bloquants dans des contextes où async était architectural.

Solution : IronOCR fournit un chemin asynchrone pour les appelants qui en ont besoin. Utilisez Task.Run pour le cadrage lié au CPU dans les méthodes asynchrones existantes, ou utilisez l'API asynchrone native :

// Option A: wrap synchronous call in Task.Run for async callers
public async Task<string> RecognizeAsync(string imagePath)
{
    return await Task.Run(() => new IronTesseract().Read(imagePath).Text);
}

// Option B: IronOCR async path
// See: https://ironsoftware.com/csharp/ocr/how-to/async/
C#

Le guide de l'OCR asynchrone documente l'API asynchrone intégrée pour les contextes où des modèles de type " fire-and-forget " (lancer et oublier) ou de rapport de progression sont nécessaires.

Problème n° 5 : le format des balises de langue Windows ne correspond pas directement

Windows.Media.Ocr : Les langues sont spécifiées en utilisant des tags BCP-47 passés à Windows.Globalization.Language("fr-FR"). Ces balises de chaîne n'ont pas d'équivalent direct dans IronOCR.

Solution : Mappage des tags de langue BCP-47 à l'énum OcrLanguage. La correspondance est simple pour les langages courants :

// Before: BCP-47 string tags
var engine = OcrEngine.TryCreateFromLanguage(
    new Windows.Globalization.Language("fr-FR"));

// After: OcrLanguage enum
var ocr = new IronTesseract();
ocr.Language = OcrLanguage.French;
// Also: OcrLanguage.German, OcrLanguage.Japanese, OcrLanguage.Arabic, etc.
C#

Le mappage complet est disponible dans le catalogue de langues IronOCR. Pour les langues non listées dans l'énum principal, le support des packs de langues personnalisés couvre le chargement direct des fichiers .traineddata.

Problème n° 6 : FileAccessMode.Read n'a pas d'équivalent

Windows.Media.Ocr : file.OpenAsync(FileAccessMode.Read) est un modèle d'ouverture de fichier spécifique à WinRT. L'énum FileAccessMode n'existe pas dans le standard .NET.

Solution: Replace with standard System.IO.File.ReadAllBytes or FileStream. OcrInput accepte les deux :

// Before: WinRT file access
using var stream = await file.OpenAsync(FileAccessMode.Read);

// After: standard .NET
var imageBytes = File.ReadAllBytes(imagePath);
using var input = new OcrInput();
input.LoadImage(imageBytes);
C#

Liste de contrôle pour la migration de Windows.Media.OCR (OCR UWP/WinRT)

Pré-migration

Vérifiez le code avant d'apporter des modifications :

# Find all Windows OCR namespace usages
grep -rn "using Windows.Media.Ocr" --include="*.cs" .
grep -rn "using Windows.Graphics.Imaging" --include="*.cs" .
grep -rn "using Windows.Storage" --include="*.cs" .
grep -rn "using Windows.Globalization" --include="*.cs" .

# Find WinRT type usages
grep -rn "OcrEngine\|SoftwareBitmap\|BitmapDecoder\|StorageFile" --include="*.cs" .
grep -rn "TryCreateFromLanguage\|TryCreateFromUserProfileLanguages\|RecognizeAsync" --include="*.cs" .
grep -rn "InMemoryRandomAccessStream\|DataWriter\|FileAccessMode" --include="*.cs" .

# Find project files with Windows TFM
grep -rn "net.*-windows" --include="*.csproj" .

# Count files requiring changes
grep -rl "Windows.Media.Ocr\|Windows.Graphics.Imaging\|SoftwareBitmap" --include="*.cs" . | wc -l
SHELL

Enregistrez le nombre de fichiers affectés, les tags de langue utilisés ("en-US", "fr-FR", etc.), et si des types WinRT apparaissent dans les signatures de méthode publique (ceux-ci nécessitent des modifications de surface d'API en plus des réécritures internes).

Migration de code

  1. Installez le package NuGet IronOcr : dotnet add package IronOcr
  2. Ajoutez l'appel d'initialisation de la licence dans Program.cs ou Startup.cs : IronOcr.License.LicenseKey = "YOUR-LICENSE-KEY";
  3. Supprimez using Windows.Media.Ocr; de tous les fichiers sources
  4. Supprimez using Windows.Graphics.Imaging; de tous les fichiers sources
  5. Supprimez using Windows.Storage; de tous les fichiers sources
  6. Supprimez using Windows.Globalization; de tous les fichiers sources
  7. Ajoutez using IronOcr; à tous les fichiers qui réalisent l'OCR
  8. Remplacez chaque appel OcrEngine.TryCreateFromLanguage(new Language("xx-XX")) par new IronTesseract() et définissez ocr.Language = OcrLanguage.X
  9. Remplacez chaque appel OcrEngine.TryCreateFromUserProfileLanguages() par new IronTesseract()
  10. Supprimer toutes les clauses de protection contre les valeurs nulles sur les résultats de la création du moteur
  11. Remplacez les paramètres SoftwareBitmap dans les signatures de méthode par byte[] ou Stream
  12. Remplacez les chaînes de construction StorageFile + BitmapDecoder + SoftwareBitmap par OcrInput.LoadImage(path), OcrInput.LoadImage(bytes), ou OcrInput.LoadImage(stream)
  13. Remplacez engine.RecognizeAsync(bitmap) par ocr.Read(path) ou ocr.Read(input)
  14. Remplacez l'utilisation de InMemoryRandomAccessStream et DataWriter par MemoryStream
  15. Remplacez les chaînes de tags de langue BCP-47 Windows par des valeurs d'énumération OcrLanguage ; Installer les packages NuGet de langage requis
  16. Mettez à jour <TargetFramework> dans les fichiers .csproj pour supprimer le suffixe -windowsX.Y.Z là où aucune autre API WinRT ne reste

Après la migration

  • Confirmez que le projet compile en ciblant net8.0 (ou votre version cible) sans le suffixe TFM Windows
  • Confirmez que le projet compile et fonctionne dans un environnement Linux ou un container Docker en utilisant mcr.microsoft.com/dotnet/aspnet:8.0
  • Vérifier que le texte issu de l'OCR correspond aux résultats attendus pour chaque type de document dans la suite de tests
  • Vérifiez que toutes les langues précédemment prises en charge produisent un résultat correct à l'aide des packages NuGet IronOCR.
  • Vérifier que les documents multilingues produisent des résultats corrects en un seul passage de reconnaissance
  • Confirmez qu'aucun NullReferenceException ou InvalidOperationException n'apparaît à l'initialisation du moteur sur des machines sans packs de langues Windows installés
  • Vérifiez que les valeurs result.Confidence sont dans les plages attendues pour des documents d'entrée de qualité pure et basse
  • Si l'application génère des documents, vérifiez que la sortie SaveAsSearchablePdf s'ouvre correctement dans un visionneur PDF et prend en charge la recherche de texte
  • Exécutez tous les chemins de traitement parallèles ou multithread existants et vérifiez la sécurité des threads sous charge
  • Déployez dans l'environnement cible (Docker, Azure App Service, AWS, serveur Linux) et exécutez au moins une opération OCR complète de bout en bout

Principaux avantages de la migration vers IronOCR

Le déploiement multiplateforme devient une question de configuration, et non plus une réécriture du code. Après la migration, le composant OCR fonctionne de manière identique sous Windows, Linux, macOS, Docker et chez tous les principaux fournisseurs de cloud. Le transfert d'une charge de travail OCR d'une machine virtuelle Windows vers un conteneur Linux afin de réduire les coûts d'hébergement est une opération de déploiement. Le guide de déploiement sous Linux et le guide de déploiement Docker couvrent l'ajout d'une ligne de dépendance requis sur les images de base Linux.

La prise en charge linguistique est fournie avec le binaire de l'application. Les packs de langues s'installent sous forme de paquets NuGet et sont liés à la version du paquet IronOCR. L'ensemble des langues que votre application peut reconnaître est défini dans le fichier de projet et est identique sur chaque machine — poste de travail du développeur, exécuteur CI, serveur de préproduction et hôte de production. Aucune coordination avec l'administrateur du système d'exploitation, aucune exception de stratégie de groupe, aucun contrôle de nullité au moment de l'exécution.

La précision OCR s'améliore sans outillage externe. Le pipeline de prétraitement — Deskew, DeNoise, Contrast, Binarize, Sharpen, Scale — fonctionne à l'intérieur d'IronOCR avant que le moteur de reconnaissance ne voie l'image. Les documents qui produisaient des résultats de qualité médiocre avec Windows.Media.OCR en raison d'un mauvais alignement lors de la numérisation ou de bruit s'améliorent sans ajouter de dépendances externes de traitement d'image. Le guide de correction de la qualité d'image et l'assistant de filtrage aident à identifier la bonne combinaison de filtres pour chaque type de document.

Les workflows PDF sont regroupés dans une seule bibliothèque. Le moteur de rendu PDF externe qui était nécessaire pour faire le lien entre Windows.Media.OCR et les entrées PDF n'est plus nécessaire. Les archives PDF numérisées sont traitées par le même appel IronTesseract.Read que les images. La sortie PDF consultable est une méthode de l'objet résultat. L'architecture à deux bibliothèques disparaît, tout comme la gestion des versions, les frais de licence et la surface de déploiement.

La sortie structurée permet des pipelines d'intelligence documentaire. La hiérarchie OcrResultPages, Paragraphs, Lines, Words, Characters — avec coordonnées par élément et scores de confiance fournit les données nécessaires pour l'extraction de champs de facture, l'analyse de formulaire, et la classification de documents. La sortie au niveau de la ligne de Windows.Media.OCR est insuffisante pour ces workflows. Avec IronOCR, l'extraction de mots filtrée par niveau de confiance, la détection des limites de paragraphes et le mappage de champs basé sur les coordonnées sont des fonctionnalités de premier ordre qui ne nécessitent aucune bibliothèque IronOCR supplémentaire.

La licence perpétuelle remplace une dépendance illimitée à l'infrastructure. Le coût de la maintenance de l'installation des packs linguistiques Windows sur un parc informatique hétérogène, des licences Windows Server Desktop Experience et d'une infrastructure CI exclusivement Windows est réel mais diffus : il apparaît dans les tickets informatiques et les budgets d'infrastructure, et non comme une ligne budgétaire distincte dans le budget OCR. Une licence IronOCR Lite $999 élimine cette surcharge pour un projet de développeur unique. The Professional License costs 1 499 $ and covers ten developers. Ces deux produits sont des achats uniques incluant un an de mises à jour.

Veuillez noter: Tesseract et Windows Media OCR sont des marques déposées de leurs propriétaires respectifs. Ce site n'est pas affilié, approuvé, ou sponsorisé par Google ou Microsoft. Tous les noms de produits, logos et marques sont la propriété de leurs propriétaires respectifs. Les comparaisons sont à titre informatif uniquement et reflètent les informations publiquement disponibles au moment de l'écriture.

Articles connexes

Key in blue circle

Obtenez votre clé d'essai de 30 jours instantanément.

Your trial license will be sent to your email address

Aucune restriction. 100 % débloqué. Pas de carte bancaire.

bullet_checkedAucune carte de crédit ou création de compte requiseAucune restriction. 100 % débloqué. Pas de carte bancaire.
  • Logo Aetna
  • Logo NASA
  • Logo GE
  • Logo Porsche
  • Logo USDA
  • Logo Qatar
Join Millions of Engineers who’ve tried IronPDF
Obtenez Votre Consultation sans Engagement
Remplissez le formulaire ci-dessous ou envoyez un email à sales@ironsoftware.com
Vos informations seront toujours gardées confidentielles.
De confiance par des millions d'ingénieurs dans le monde entier
Logos des clients d'Iron Software
Obtenez votre clé d'essai 30 jours gratuitement.
Aucune carte de crédit ou création de compte requise