OCR in Azure vs. IronOCR : Quelle solution de reconnaissance optique de caractères convient le mieux aux projets .NET ?
Windows.Media.Ocr est fourni gratuitement avec chaque installation de Windows 10 et Windows 11, ce qui le rend attractif jusqu'à ce que vous tentiez de déployer la même application sur un serveur Linux, un conteneur Dockerou une fonction AWS Lambda : dans ce cas, l'API est tout simplement inexistante. La dépendance à une plateforme spécifique n'est pas un cas isolé avec cette bibliothèque ; C'est la contrainte déterminante. Chaque décision architecturale en aval du choix de Windows.Media.Ocr est façonnée par l'exigence que le système d'exploitation hôte soit un ordinateur de bureau ou un serveur grand public Windows 10 ou Windows 11. Ni Linux, ni macOS, ni Docker, ni Azure Functions sur Linux, ni AWS Lambda. Pour les développeurs qui créent des outils internes Windows sans aucune intention de franchir cette limite, le prix de 0 $ est difficilement contestable. Pour tous les autres, le coût caché réside dans la réécriture complète du système OCR en un système différent lorsque les exigences de déploiement évoluent.
Comprendre Windows.Media.Ocr
Windows.Media.Ocr fait partie de l'API Windows Runtime (WinRT) introduite avec Windows 8.1 et améliorée pour Windows 10 et 11. Elle expose une classe OcrEngine dans l'espace de noms Windows.Media.Ocr qui accepte un SoftwareBitmap — lui-même un type WinRT de Windows.Graphics.Imaging — et renvoie un OcrResult contenant du texte reconnu et la géométrie des lignes.
L'API est construite autour du contrat async/await de WinRT. Chaque opération passe par des appels async Task soutenus par la machinerie WinRT IAsyncOperation : charger un StorageFile, ouvrir un flux, créer un BitmapDecoder, obtenir un SoftwareBitmap, et seulement alors invoquer RecognizeAsync. À partir de .NET 6, l'utilisation des API WinRT nécessite un Target Framework Moniker (TFM) spécifique à Windows tel que net8.0-windows10.0.19041.0. Un fichier projet sans ce TFM ne peut pas compiler le code qui réfère à Windows.Media.Ocr du tout — les types n'existent tout simplement pas dans le graphe d'assemblage.
Principales caractéristiques architecturales :
- Windows 10/11 uniquement — l'interface de l'API WinRT n'est pas disponible sur Serveur Windowssans Expérience utilisateur (dans toutes les configurations) et est totalement absente sur Linuxet macOS.
- Modèle asynchrone de WinRT — tous les reconnaissances passent par des appels asynchrones soutenus par
IAsyncOperation; il n'existe pas de voie synchrone - Packs de langues du système d'exploitation —
OcrEngine.TryCreateFromLanguageetTryCreateFromUserProfileLanguagesrésolvent les langues disponibles à partir des packs de langues Windows installés par l'utilisateur ou l'administrateur informatique sur cette machine spécifique ; il n'y a pas de modèle de langue intégré ou portable - Entrée uniquement image — l'API accepte
SoftwareBitmapdirectement ; Aucun chemin d'entrée PDF n'existe à aucun niveau de l'API - Aucun pipeline de prétraitement — l'image bitmap brute est transmise au système de reconnaissance ; La correction de la rotation, la suppression du bruit, l'amélioration du contraste et la mise à l'échelle de la résolution sont de la responsabilité du développeur, qui utilise des API d'imagerie Windows distinctes.
- Aucune sortie PDF consultable — le texte reconnu est renvoyé sous forme de données de chaîne brute avec une géométrie de ligne ; Aucune exportation au format PDF n'est disponible.
- TFM spécifique à Windows requis — les fichiers de projet doivent cibler un TFM
net*-windows*, ce qui empêche le même projet de se compiler sur plusieurs plateformes
La pile asynchrone WinRT
Chaque opération OCR de base avec Windows.Media.Ocr nécessite de naviguer à travers plusieurs couches de l'interface de l'API WinRT avant que la reconnaissance puisse commencer :
// 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
La vérification nulle sur engine n'est pas facultative. Si le pack de langue cible n'est pas installé sur la machine exécutant le code, TryCreateFromLanguage renvoie null et la reconnaissance est impossible. Il n'y a pas de solution de repli ; L'application doit signaler toute erreur à l'utilisateur ou échouer silencieusement.
Comprendre IronOCR
IronOCR est une bibliothèque OCR .NET commerciale construite sur un moteur Tesseract 5 optimisé avec une couche API gérée qui prend en charge le prétraitement, la lecture de PDF, la résolution multilingue et la sortie de données structurées. Il s'installe sous la forme d'un seul package NuGet , sans binaires natifs externes à déployer séparément, sans dossiers tessdata à gérer et sans TFM spécifiques à la plateforme requis.
Caractéristiques principales :
- Conçu pour une utilisation multiplateforme : fonctionne sous Windows, Linux, macOS, Docker, Azure App Service (Windows ou Linux), AWS Lambdaet GCP Cloud Run sans modification du code.
- Prétraitement automatique — redressement, débruitage, amélioration du contraste, binarisation et mise à l'échelle de la résolution sont appliqués automatiquement sur les entrées de mauvaise qualité, avec un contrôle explicite disponible via les méthodes de filtre
OcrInput - Entrée PDF native —
IronTesseract.Readaccepte directement les chemins des PDF ; aucune étape de conversion, aucune bibliothèque externe - Plus de 125 langues intégrées — les packs de langue sont des packages NuGet qui sont déployés avec l'application ; aucune dépendance aux données de langue installées par le système d'exploitation
- Sortie PDF consultable —
OcrResult.SaveAsSearchablePdfcrée un PDF avec une couche de texte à partir de n'importe quelle entrée numérisée - Modèle de résultat structuré —
OcrResultexposePages,Paragraphs,Lines,Words, et des scores de confiance par mot et des boîtes englobantes - Compatible multi-thread — les instances de
IronTesseractsupportent les charges de travail parallèles sans synchronisation supplémentaire - Licence perpétuelle — $999 Lite à $5,999 Unlimited, purchase unique, traitement illimité de documents
Comparaison des fonctionnalités
| Fonction | Windows.Media.Ocr | IronOCR |
|---|---|---|
| Plateforme | Windows 10/11uniquement | Windows, Linux, macOS, Docker, cloud |
| Prix | Gratuit | $5,999 perpétuel |
| Entrée PDF | Non | Natif |
| Modèle de langage | Packs installés par le système d'exploitation | Plus de 125 modules intégrés via NuGet |
| Prétraitement | None | Filtres automatiques et explicites |
| Sortie PDF consultable | Non | Oui |
| Modèle d'API | WinRT asynchrone | .NET Standard |
Comparaison détaillée des fonctionnalités
| Fonction | Windows.Media.Ocr | IronOCR |
|---|---|---|
| Support de la plateforme | ||
| Windows 10/11 | Oui | Oui |
| Serveur Windows | Limité | Oui |
| Linux | Non | Oui |
| macOS | Non | Oui |
| Docker | Non | Oui |
| Azure Functions (Linux) | Non | Oui |
| AWS Lambda | Non | Oui |
| Formats d'entrée | ||
| JPEG / PNG / BMP | Oui (via le pipeline WinRT) | Oui |
| PDF (numérisé) | Non | Oui |
| PDF (protégé par mot de passe) | Non | Oui |
| TIFF / plusieurs pages | Non | Oui |
| Flux / tableau d'octets | Non (fichier de stockage WinRT uniquement) | Oui |
| URL | Non | Oui |
| Assistance linguistique | ||
| Source de langue | modules linguistiques installés par le système d'exploitation | Plus de 125 packs NuGet intégrés |
| Installation sans administration système | Non | Oui (NuGet) |
| Multilingue simultané | Non | Oui |
| Portabilité du langage entre les machines | Non | Oui |
| Prétraitement | ||
| Déclin | Non | Oui (input.Deskew()) |
| Denoise | Non | Oui (input.DeNoise()) |
| Amélioration du contraste | Non | Oui (input.Contrast()) |
| Binarisation | Non | Oui (input.Binarize()) |
| Mise à l'échelle de la résolution | Non | Oui (input.EnhanceResolution(300)) |
| Sortir | ||
| Texte brut | Oui | Oui |
| PDF consultable | Non | Oui |
| hOCR / HTML | Non | Oui |
| Cadres de délimitation au niveau des mots | Partiel (géométrie linéaire) | Oui |
| Scores de confiance par mot | Non | Oui |
| Conception d'API | ||
| Restriction TFM | net*-windows* requis |
None |
| Chemin synchrone | Non | Oui |
| Lecture de codes-barres lors de la reconnaissance optique de caractères (OCR) | Non | Oui |
| OCR basé sur la région | Non | Oui |
Dépendance à une plateforme unique vs déploiement multiplateforme
La différence la plus importante entre ces deux bibliothèques ne réside ni dans la précision, ni dans le prétraitement, ni même dans la prise en charge du format PDF ; elle réside dans la topologie de déploiement. Windows.Media.Ocr n'existe pas en dehors de Windows 10/11. Il ne s'agit pas d'un problème de configuration ni d'un package NuGet manquant ; L'environnement d'exécution WinRT qui prend en charge l'API est absent sur tous les autres systèmes d'exploitation.
Approche Windows.Media.OCR
La dépendance à WinRT se manifeste dans le fichier projet avant même l'exécution d'une seule ligne de code. Le TargetFramework doit spécifier une version de plateforme Windows :
<PropertyGroup>
<TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
</PropertyGroup>
<PropertyGroup>
<TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
</PropertyGroup>
Avec ce TFM, le projet ne peut pas être utilisé depuis un conteneur Linux. Une image Dockerbasée sur mcr.microsoft.com/dotnet/aspnet:8.0 — l'image de base Linuxstandard pour les déploiements ASP.NET — n'a pas de runtime WinRT. Tenter de référencer les types Windows.Media.Ocr dans un projet ciblant net8.0 (sans suffixe Windows) produit des erreurs de compilation, pas des erreurs d'exécution. Le verrouillage est imposé au moment de la compilation.
Lorsque des besoins en reconnaissance optique de caractères (OCR) apparaissent dans une architecture de microservices où le processus OCR s'exécute sous Linux, ou dans un pipeline CI/CD qui produit des images Dockermultiplateformes, Windows.Media.Ocr n'est pas une option à évaluer — il est éliminé avant même le premier pic d'utilisation.
Approche d'IronOCR
IronOCR cible net6.0, net7.0, net8.0, et net9.0 sans TFMs spécifiques à la plateforme. Le même package NuGet et le même fichier binaire d'application fonctionnent sous Windows, Linuxet macOS. Déployer IronOCR sur Docker nécessite une ligne apt-get pour libgdiplus sur l'image de base Linux, rien d'autre :
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"]
Le code de l'application lui-même reste inchangé entre les déploiements sous Windows et Linux :
// Same code — Windows, Linux, macOS, Docker, AWS Lambda
// Non 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
// Non 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
IronOcr.License.LicenseKey = "YOUR-LICENSE-KEY"
Dim text As String = New IronTesseract().Read("document.jpg").Text
IronOCR fonctionne sur AWS Lambda , Azure Functions sur Linux et directement sur les serveurs Linux sans modification de code. La cible de déploiement relève de la configuration, et non d'une contrainte architecturale.
Prise en charge des langues : dépendance au système d'exploitation ou modules linguistiques intégrés
Windows.Media.Ocr délègue entièrement la gestion des langues à la machine hôte. L'ensemble des langues que votre application peut reconnaître dépend des modules linguistiques installés par l'utilisateur (ou un administrateur informatique) sur cette installation Windows. Cela crée une catégorie de défaillances en production qui n'a rien à voir avec votre code.
Approche Windows.Media.OCR
OcrEngine.TryCreateFromLanguage renvoie null lorsque la langue demandée n'est pas installée. TryCreateFromUserProfileLanguages renvoie null lorsqu'il n'existe aucun pack de langue OCR. Les deux méthodes nécessitent une gestion des valeurs nulles, et aucune ne propose de solution de récupération élégante : il est impossible d'installer un langage à partir du code ou de l'intégrer à l'application :
// 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)
Le déploiement d'une application de traitement de documents multilingue avec Windows.Media.Ocr nécessite la coordination de l'installation du module linguistique Windows sur chaque machine de la cible de déploiement. Sur un serveur partagé ou sur la machine d'un utilisateur gérée par une stratégie de groupe, cela ne dépend pas du développeur.
Approche d'IronOCR
IronOCR distribue les modèles de langage sous forme de packages NuGet dédiés qui se déploient en même temps que le binaire de l'application. Les données linguistiques sont incluses dans le fichier de compilation, et non dans la configuration du système d'exploitation. Supporting 125+ languages is a dotnet add package operation:
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)
Le catalogue complet des langues couvre le latin, le CJK, l'arabe, l'hébreu, le devanagari, le cyrillique et des ensembles spécialisés incluant la notation mathématique. Chaque version de pack de langue est liée à la version du package IronOCR , de sorte que le modèle de langue en production corresponde à celui testé localement.
Absence de prétraitement
Les numérisations de mauvaise qualité (pages légèrement pivotées, texte photocopié avec du bruit de pointillé, encre délavée sur papier blanc cassé) produisent une précision OCR médiocre de la part de tout moteur qui les reçoit telles quelles. Le prétraitement corrige ces défauts avant l'exécution de la reconnaissance. Windows.Media.Ocr ne fournit aucune couche de prétraitement.
Approche Windows.Media.OCR
L'API accepte un SoftwareBitmap et renvoie du texte. La qualité d'image qui évolue entre ces deux points n'est pas configurable. Les développeurs qui doivent améliorer la précision sur des entrées sub-optimales doivent implémenter le prétraitement manuellement en utilisant les APIs de composant d'imagerie Windows avant de construire le SoftwareBitmap. Il s'agit d'un code source distinct, avec ses propres contraintes de maintenance, et il reste spécifique à Windows pour la même raison que l'API OCR elle-même :
// 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)
Pour les numérisations de documents standard et propres (environnement de numérisation contrôlé, éclairage constant, 300 DPI minimum, orientation correcte), cette limitation est gérable. Pour les chaînes de traitement de documents qui reçoivent des images provenant d'appareils photo de téléphones portables, de scanners à plat avec un mauvais alignement de l'alimentation automatique, de documents faxés ou de photocopies, cela signifie soit construire une couche de prétraitement à partir de zéro, soit accepter une dégradation de la précision.
Approche d'IronOCR
La classe OcrInput d'IronOCR offre un pipeline de prétraitement avec des méthodes de filtre individuelles qui s'appliquent en séquence. Les filtres de correction de la qualité d'image permettent de corriger les principaux facteurs de perte de précision dans le traitement des documents de production :
// 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
Pour le cas général, IronOCR applique un prétraitement automatique lors de l'appel à Read directement sur un chemin de fichier — le moteur détecte les problèmes de qualité et les corrige sans configuration explicite du filtre. Le tutoriel des filtres d'images couvre l'ensemble complet de filtres, y compris Sharpen, Dilate, Erode, Invert, et ToGrayScale pour des scénarios spécialisés. Les filtres de correction des couleurs et la correction de l'orientation étendent encore davantage le processus pour les documents présentant des profils de couleur non standard ou une rotation multi-angle.
Absence de support PDF
Le format PDF est le format de document dominant dans les environnements Enterprise . Les contrats, factures, archives numérisées et formulaires gouvernementaux arrivent au format PDF. Windows.Media.Ocr ne prend pas en charge le format PDF ; il n'accepte que les données d'image. La reconnaissance optique de caractères (OCR) d'un document PDF nécessite une bibliothèque de rendu PDF distincte, une rastérisation page par page et un assemblage manuel des résultats.
Approche Windows.Media.OCR
L'API ne contient pas de chemin d'accès aux fichiers PDF. Pour OCRiser un PDF scanné avec Windows.Media.Ocr, le développeur doit : rendre chaque page vers un SoftwareBitmap en utilisant une bibliothèque de rendu PDF séparée (aucune d'entre elles n'étant intégrée dans Windows), itérer les pages, appeler RecognizeAsync par page, et concaténer les résultats manuellement. Cette bibliothèque de rendu elle-même implique des considérations supplémentaires en matière de licences et de déploiement. Le code Windows.Media.Ocr représente la plus petite partie de l'implémentation totale :
// 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
L'étape de rendu PDF externe ajoute à elle seule une dépendance, une courbe d'apprentissage supplémentaire et une surface d'échec supplémentaire à ce qui était initialement une solution " gratuite et intégrée ".
Approche d'IronOCR
IronOCR lit les fichiers PDF nativement. Aucun moteur de rendu externe, aucune étape de rastérisation, aucun assemblage manuel de pages. La même méthode IronTesseract.Read qui accepte les chemins d'images accepte aussi les chemins de PDF. La reconnaissance optique de caractères (OCR) des fichiers PDF en .NET se fait sur une seule ligne :
// 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 consultable 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 consultable 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 consultable output: make a scanned PDF text-searchable
Dim ocrResult = New IronTesseract().Read("scanned-archive.pdf")
ocrResult.SaveAsSearchablePdf("searchable-output.pdf")
La fonction PDF consultable intègre une couche de texte par-dessus l'image numérisée originale, produisant un PDF qui préserve la fidélité visuelle tout en permettant la recherche en texte intégral et le copier-coller. Il s'agit d'une exigence courante pour les systèmes de gestion documentaire et les archives de conformité. Windows.Media.Ocr ne peut pas produire ce résultat à aucun niveau de son API.
Référence de mappage d'API
| Windows.Media.Ocr | Équivalent d'IronOCR |
|---|---|
OcrEngine.TryCreateFromLanguage(lang) |
new IronTesseract() avec ocr.Language = OcrLanguage.X |
OcrEngine.TryCreateFromUserProfileLanguages() |
new IronTesseract() (langue par défaut résolue automatiquement) |
engine.RecognizeAsync(softwareBitmap) |
ocr.Read("image.jpg") ou ocr.Read(ocrInput) |
OcrResult.Text |
OcrResult.Text |
OcrResult.Lines |
OcrResult.Lines (avec métadonnées étendues) |
OcrLine.Text |
OcrResult.Lines[i].Text |
OcrLine.Words |
OcrResult.Words (avec les boîtes englobantes + confiance) |
OcrWord.BoundingRect |
OcrResult.Words[i].X, .Y, .Width, .Height |
BitmapDecoder.CreateAsync(stream) |
input.LoadImage(stream) via OcrInput |
StorageFile.GetFileFromPathAsync(path) |
ocr.Read("path") directement |
| Aucun équivalent (PDF non pris en charge) | ocr.Read("document.pdf") |
| Aucun équivalent (PDF non pris en charge) | input.LoadPdf("file.pdf", Password: "x") |
| Aucun équivalent (pas de PDF consultable) | result.SaveAsSearchablePdf("output.pdf") |
| Aucun équivalent (aucun prétraitement) | input.Deskew(), input.DeNoise(), input.Contrast() |
| Aucun équivalent (pas de version multilingue) | ocr.AddSecondaryLanguage(OcrLanguage.X) |
| Aucun équivalent (absence de confiance) | result.Confidence, word.Confidence |
Quand les équipes envisagent de passer de Windows.Media.Ocr à IronOCR
L'application dépasse les capacités d'un bureau Windows.
Le déclencheur le plus courant est une modification des exigences qui introduit une cible de déploiement non-Windows. Un utilitaire de bureau, initialement conçu comme un outil interne à Windows, est promu en service web, en microservice basé sur Dockerou en fonction cloud. Dès que cela se produit, Windows.Media.Ocr devient un bloqueur. Le composant OCR nécessite une réécriture complète car l'API n'existe pas sur la plateforme cible : il n'y a ni portage, ni adaptateur de compatibilité, ni option de compilation conditionnelle pour résoudre le problème. Les équipes qui avaient anticipé cette réécriture avec IronOCR ne sont pas concernées.
Les exigences linguistiques dépassent le nombre de packs installés.
Les chaînes de traitement de documents étendent souvent leur portée. Un système conçu pour traiter les factures en anglais doit désormais également gérer les documents en français, en allemand, en arabe ou en japonais. Avec Windows.Media.Ocr, la prise en charge de ces langues nécessite la coordination de l'installation du module linguistique du système d'exploitation sur chaque cible de déploiement : machines de développement, machines virtuelles de test, serveurs de production et tous les conteneurs impliqués. Dans les environnements gérés par stratégie de groupe ou dans les machines virtuelles cloud avec une empreinte système minimale, cette coordination est impraticable. Les packs de langue d'IronOCR basés sur NuGet sont déployés avec l'application et ne nécessitent aucune coordination avec le système d'exploitation.
Le traitement des fichiers PDF est ajouté au périmètre.
Lorsque la demande initiale était " des images OCR provenant d'un scanner à plat ", Windows.Media.Ocr fonctionne. Lorsque l'exigence s'étend au " traitement également du retard accumulé dans les fichiers PDF numérisés de nos archives ", une deuxième bibliothèque entre en jeu. Cette bibliothèque représente une dépendance supplémentaire, une considération supplémentaire en matière de licences et une surface de défaillance supplémentaire. Les équipes qui ont besoin à la fois de la reconnaissance optique de caractères (OCR) d'images et de PDF sur une API unifiée constatent IronOCR élimine d'emblée l'architecture à deux bibliothèques.
La précision se dégrade avec les entrées du monde réel
Les environnements de numérisation contrôlés produisent des images nettes. Les données d'entrée réelles (photos prises avec des téléphones portables, numérisations à plat légèrement déformées, documents reçus par fax plus anciens, photocopies) entraînent une dégradation de la précision qui ne peut être corrigée dans Windows.Media.Ocr. Lorsque les plaintes des clients concernant les SMS non reçus commencent à arriver, les équipes découvrent que l'étape de prétraitement qu'elles avaient négligée est devenue nécessaire. L'adaptation du prétraitement à l'aide des API d'imagerie Windows représente un effort de développement considérable qui limite la solution à Windows uniquement. Le pipeline de prétraitement d'IronOCR est déjà en place.
La question du déploiement du serveur se pose
La documentation de Windows.Media.Ocr positionne explicitement l'API pour les applications clientes. Son exécution dans un contexte serveur (une application ASP.NET traitant des documents téléchargés par l'utilisateur, un service Windows consommant une file d'attente de documents) nécessite un environnement Serveur Windowsavec l'expérience utilisateur de bureau installée, ce qui représente un profil de machine virtuelle plus lourd et plus coûteux qu'un conteneur Linux. Lorsque l'équipe d'infrastructure demande si le processus OCR peut s'exécuter sur une instance Linuxpour réduire les coûts d'hébergement, la réponse concernant Windows.Media.Ocr est non.
Considérations courantes en matière de migration
Modification du fichier projet TFM
Windows.Media.Ocr nécessite un TFM spécifique à Windows dans le fichier de projet (net8.0-windows10.0.19041.0 ou similaire). Supprimer cette dépendance pour prendre en charge les cibles multiplateformes implique de supprimer le suffixe TFM. IronOCR cible net6.0, net8.0, et net9.0 sans suffixe spécifique à Windows. Lors de la migration, vérifiez qu'aucune autre dépendance de l'API WinRT du projet ne nécessite le TFM Windows ; d'autres fonctionnalités de la plateforme Windows (intégration à l'interface, notifications Windows, etc.) peuvent devoir être abstraites derrière des vérifications de la plateforme.
Migration asynchrone vers synchrone
Windows.Media.Ocr est entièrement asynchrone — RecognizeAsync renvoie IAsyncOperation<OcrResult> qui se mappe à Task<OcrResult> via interop WinRT. IronOCR propose des chemins synchrones et asynchrones. Le ocr.Read("file.jpg") synchrone remplace directement la chaîne d'attente à plusieurs étapes. Pour les applications serveur où l'appel OCR se trouve dans un service en arrière-plan ou un pipeline basé sur des tâches, le chemin asynchrone est également disponible. Dans les deux cas, la transition de plus de 6 étapes asynchrones à un seul appel est simple :
// 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
Remplacement du pack de langue
Pour chaque langue précédemment résolue via OcrEngine.TryCreateFromLanguage(new Windows.Globalization.Language("fr-FR")), installez le pack de langues correspondant d'IronOCR et définissez ocr.Language = OcrLanguage.French. Le catalogue de langues IronOCR répertorie l'ensemble des plus de 125 packs disponibles. Les codes de langue se mappent directement depuis les balises BCP-47 à l'énum OcrLanguage.
Suppression de la gestion du moteur nul
Windows.Media.Ocr exige une vérification de valeur nulle à chaque appel de création de moteur. IronOCR génère des exceptions structurées plutôt que de renvoyer null en cas d'échec de configuration ou d'initialisation. Supprimez les clauses de protection contre les valeurs nulles et remplacez-les par une gestion standard des exceptions lorsque cela est nécessaire. Le résultat est un site d'appel plus propre, sans mode de défaillance lié à une " langue silencieusement indisponible ".
Fonctionnalités supplémentaires d'IronOCR
Outre les fonctionnalités qui remplacent directement celles de Windows.Media.Ocr, IronOCR offre des capacités pour lesquelles Windows.Media.Ocr n'a pas d'équivalent :
- Traitement des documents numérisés — gestion dédiée des archives numérisées multipages, y compris les fichiers TIFF et PDF multipages
- Extraction de tableaux — détection structurée des données tabulaires dans les documents pour les lignes de factures, les grilles de rapports et les matrices de formulaires
- Les types de documents spécialisés — zones MRZ des passeports, lignes de chèques MICR, plaques d'immatriculation et textes manuscrits — disposent chacun de voies de traitement dédiées.
- Suivi de la progression — les opérations par lots rendent compte de leur progression via des événements, ce qui permet d'afficher des barres de progression et de surveiller le taux de traitement dans les interfaces utilisateur des applications.
Compatibilité .NET et préparation à l'avenir
IronOCR prend en charge .NET 6, .NET 7, .NET 8 et .NET 9 sur les TFM standard sans suffixes spécifiques à la plateforme, ainsi que .NET Framework 4.6.2 à 4.8 pour la prise en charge des applications héritées. La bibliothèque reçoit des mises à jour régulières suivant le rythme des versions de .NET , avec la prise en charge de .NET 10 prévue pour 2026. Windows.Media.Ocr est disponible sur toute version de .NET prenant en charge l'interopérabilité WinRT à partir de .NET 5, mais l'exigence Windows TFM limite définitivement son applicabilité aux projets destinés à Windows. À mesure que l'histoire multiplateforme de .NET mûrit — avec de plus en plus d'équipes ciblant les conteneurs Linuxet les fonctions cloud comme cibles de déploiement de premier ordre — la contrainte TFM de Windows.Media.Ocr devient un handicap architectural plus prononcé plutôt qu'une simple mise en garde.
Conclusion
Windows.Media.Ocr occupe un créneau spécifique et légitime : une application de bureau Windows 10/11sans aucune ambition multiplateforme, répondant à des besoins de base en matière de reconnaissance optique de caractères d'images et ne disposant d'aucun budget. Dans ce créneau, elle fonctionne. En dehors de ce créneau — dès que le déploiement cible un conteneur Linux, une fonction cloud, un serveur avec des exigences multilingues ou un pipeline de documents traitant des PDF — l'API n'existe pas sur la plateforme cible et le code doit être remplacé.
Le problème de fond est que les limitations de Windows.Media.Ocr sont architecturales, et non accidentelles. Le verrouillage de la plateforme n'est pas un paramètre de configuration à désactiver ; Elle est intégrée au runtime WinRT dont dépend l'API. La disponibilité des langues n'est pas un élément à inclure lors de la compilation ; elle est déléguée aux administrateurs du système d'exploitation. La prise en charge des fichiers PDF n'est pas une fonctionnalité manquante à ajouter avec un package NuGet ; Elle est totalement absente de l'interface de l'API. Chaque limitation nécessite un système distinct pour la compenser, et chaque système de compensation réintroduit des dépendances à la plateforme.
IronOCR répond aux quatre contraintes (plateforme, langue, prétraitement et PDF) dans un seul et même package. Le prix d'entrée $999 n'est pas de 0 $, et pour un utilitaire de bureau exclusivement Windows avec une entrée contrôlée et des documents uniquement en anglais, Windows.Media.Ocr reste un choix valide. Pour tout projet avec des exigences plus larges, le coût de construction autour des contraintes de Windows.Media.Ocr peut dépasser le coût de la licence IronOCR en heures de développeur avant que le projet n'atteigne son premier déploiement en production.
Le test pratique est simple : si la cible de déploiement peut être Linux, Dockerou une fonction cloud, et si les documents d'entrée peuvent être des PDF ou arriver dans des langues autres que celles du système d'exploitation par défaut, Windows.Media.Ocr n'est pas la bonne base. Découvrir cela en cours de projet coûte beaucoup plus cher que de choisir le bon outil dès le départ. Évaluer les fonctionnalités IronOCR en fonction de vos besoins spécifiques avant de prendre une décision est la méthode la plus efficace pour y parvenir.
Questions Fréquemment Posées
Qu'est-ce que Windows.Media.Ocr ?
Windows.Media.Ocr est une solution OCR utilisée par les développeurs et les entreprises pour extraire du texte à partir d'images et de documents. Il s'agit de l'une des nombreuses options d'OCR évaluées aux côtés d'IronOCR pour le développement d'applications .NET.
Comment IronOCR se compare-t-il à Windows.Media.Ocr pour les développeurs .NET ?
IronOCR est une bibliothèque OCR .NET native de NuGet qui utilise IronTesseract comme moteur principal. Par rapport à Windows.Media.Ocr, elle offre un déploiement plus simple (pas d'installateurs SDK), un prix forfaitaire et une API C# propre sans interopérabilité COM ou dépendances cloud.
IronOcr est-il plus facile à installer que Windows.Media.Ocr ?
IronOCR s'installe via un seul package NuGet. Il n'y a pas d'installateur SDK, de fichiers de licence à copier, de composants COM à enregistrer ou de binaires d'exécution séparés à gérer. L'ensemble du moteur d'OCR est inclus dans le package.
Quelles sont les différences de précision entre Windows.Media.Ocr et IronOcr ?
IronOcr atteint une grande précision de reconnaissance pour les documents commerciaux standard, les factures, les reçus et les formulaires numérisés. Pour les documents très dégradés ou les scripts peu courants, la précision varie en fonction de la qualité de la source. IronOCR comprend des filtres de prétraitement d'image pour améliorer la reconnaissance sur des entrées de faible qualité.
IronOCR prend-il en charge l'extraction de texte au format PDF ?
Oui. IronOCR extrait le texte des PDF natifs et des images PDF numérisées en un seul appel. Il prend également en charge les fichiers TIFF multipages, les images et les flux. Pour les PDF numérisés, l'OCR est appliquée page par page avec des objets de résultat par page.
Comment les licences de Windows.Media.Ocr se comparent-elles à celles d'IronOcr ?
IronOCR utilise une licence perpétuelle forfaitaire sans frais par page ou par scan. Les organisations qui traitent de gros volumes de documents paient le même coût de licence, quel que soit le volume. Les détails et la tarification au volume se trouvent sur la page de licence d'IronOCR.
Quelles langues IronOCR prend-il en charge ?
IronOcr prend en charge 127 langues via des packs linguistiques NuGet distincts. L'ajout d'une langue nécessite une seule commande "dotnet add package IronOcr.Languages.{Language}". Il n'est pas nécessaire de placer manuellement des fichiers ou de configurer des chemins d'accès.
Comment installer IronOCR dans un projet .NET ?
Installation via NuGet : 'Install-Package IronOcr' dans la console du Package Manager ou 'dotnet add package IronOcr' dans le CLI. Les packs de langues supplémentaires sont installés de la même manière. Aucun programme d'installation du SDK n'est nécessaire.
IronOcr est-il adapté à Docker et aux déploiements conteneurisés, contrairement à Windows.Media.Ocr ?
Oui. IronOCR fonctionne dans les conteneurs Docker via son package NuGet. La clé de licence est définie via une variable d'environnement. Aucun fichier de licence, chemin d'accès au SDK ou montage de volume n'est nécessaire pour le moteur OCR lui-même.
Puis-je essayer IronOCR avant de l'acheter, par rapport à Windows.Media.Ocr ?
Oui. Le mode d'essai d'IronOcr traite les documents et renvoie les résultats de l'OCR avec un filigrane en surimpression sur la sortie. Vous pouvez vérifier la précision sur vos propres documents avant d'acheter une licence.
IronOCR prend-il en charge la lecture de codes-barres parallèlement à l'extraction de texte ?
IronOCR se concentre sur l'extraction de texte et l'OCR. Pour la lecture de codes-barres, Iron Software propose IronBarcode comme bibliothèque d'accompagnement. Les deux sont disponibles individuellement ou dans le cadre de l'offre groupée Iron Suite.
Est-il facile de migrer de Windows.Media.Ocr vers IronOCR ?
La migration de Windows.Media.Ocr vers IronOCR implique généralement le remplacement des séquences d'initialisation par l'instanciation d'IronTesseract, la suppression de la gestion du cycle de vie de COM et la mise à jour des appels d'API. La plupart des migrations réduisent considérablement la complexité du code.

