Cela vous est sans doute déjà arrivé au travail : vous capturez des conversations et des pages web sous forme de captures d’écran pour pouvoir y revenir plus tard, puis vous découvrez, au moment où vous en avez besoin, que le texte contenu dans ces images n’est pas recherchable. Ou bien un contrat important, signé et tamponné, doit être scanné en PDF pour conserver l’original, mais quand vous devez retrouver une information ou citer un passage, impossible de chercher dedans, impossible de copier le texte ; il faut faire défiler les pages et retaper à la main.
C’est précisément le problème que l’OCR intégré de Gety est conçu pour résoudre.
Pour le mesurer, nous avons comparé l’OCR intégré de Gety aux options locales que les utilisateurs sont le plus susceptibles d’utiliser : PaddleOCR (PP-OCRv6), le concurrent open source le plus solide ; Tesseract, la référence historique ; et l’OCR intégré à macOS et Windows. Le test utilise des images de documents issues de deux jeux de données publics, MDPBench et OmniDocBench.
Les services OCR en ligne et les modèles cloud comme Gemini ne sont pas inclus ici. Ils exigent un envoi de fichier, un appel d’API, une connexion internet et souvent une facturation à l’usage. Ils relèvent donc d’une autre catégorie que l’OCR qui s’exécute localement sur votre propre machine.
Les résultats font ressortir deux avantages nets pour l’OCR intégré de Gety :
- Parmi les moteurs OCR locaux exécutés sur l’appareil, Gety arrive en tête en précision multilingue, avec le meilleur résultat global sur 17 langues.
- Il utilise environ un cinquième de la mémoire des modèles comparables exécutés sur l’appareil, ce qui rend possible un OCR en arrière-plan et une indexation en temps réel.
1. Multilingue : là où Gety prend le plus d’avance
Bien des moteurs OCR gèrent correctement les langues à écriture latine comme l’anglais et le français. Les ennuis commencent quand l’écriture change. En coréen, en russe, en thaï ou en hindi, beaucoup de scores passent de plus de 0.9 à 0.2, voire 0.1, un niveau trop faible pour être utile. Voici comment le peloton se comporte sur les 17 langues, à partir des images de documents de MDPBench :
| Langue / Indicateur | Gety OCR (built-in) | Apple Vision (built-in) | PP-OCRv6(small) | PP-OCRv6(tiny) | Windows OCR | Tesseract |
|---|---|---|---|---|---|---|
| Global (F1) | 0.903 | 0.881 | 0.724 | 0.686 | 0.609 | 0.541 |
| Écritures latines (moy.) | 0.966 | 0.940 | 0.967 | 0.957 | 0.847 | 0.901 |
| Anglais | 0.978 | 0.962 | 0.972 | 0.972 | 0.882 | 0.919 |
| Allemand | 0.959 | 0.967 | 0.992 | 0.991 | 0.923 | 0.962 |
| Français | 0.947 | 0.799 | 0.982 | 0.977 | 0.795 | 0.940 |
| Espagnol | 0.920 | 0.923 | 0.927 | 0.923 | 0.819 | 0.872 |
| Italien | 0.980 | 0.976 | 0.985 | 0.979 | 0.887 | 0.932 |
| Portugais | 0.978 | 0.983 | 0.980 | 0.972 | 0.797 | 0.840 |
| Néerlandais | 0.994 | 0.924 | 0.995 | 0.995 | 0.967 | 0.974 |
| Indonésien | 0.974 | 0.966 | 0.987 | 0.987 | 0.892 | 0.959 |
| Vietnamien | 0.967 | 0.958 | 0.884 | 0.814 | 0.661 | 0.716 |
| Écritures non latines (moy.) | 0.832 | 0.814 | 0.452 | 0.382 | 0.343 | 0.136 |
| Chinois (simplifié) | 0.946 | 0.912 | 0.965 | 0.957 | 0.800 | 0.180 |
| Chinois (traditionnel) | 0.924 | 0.805 | 0.939 | 0.862 | 0.853 | 0.142 |
| Japonais | 0.916 | 0.804 | 0.924 | 0.525 | 0.454 | 0.173 |
| Coréen | 0.970 | 0.961 | 0.276 | 0.248 | 0.211 | 0.190 |
| Russe | 0.954 | 0.960 | 0.155 | 0.106 | 0.096 | 0.102 |
| Thaï | 0.951 | 0.974 | 0.155 | 0.137 | 0.150 | 0.125 |
| Hindi | 0.958 | 0.136 | 0.191 | 0.178 | 0.140 | 0.147 |
| Arabe | 0.039 | 0.962 | 0.011 | 0.046 | 0.037 | 0.031 |
La ligne à surveiller est la moyenne des écritures non latines. Là où beaucoup de moteurs locaux tombent dans la plage de 0.1 à 0.4, Gety se maintient à 0.832. En pratique, cela signifie que les documents contenant du chinois, du japonais, du coréen ou du russe risquent beaucoup moins de devenir invisibles à la recherche simplement parce que l’écriture change.
Les documents photographiés posent un problème plus difficile. Quand l’entrée est une photo d’un document plutôt qu’un fichier numérique propre, avec du flou, une inclinaison ou des reflets, tous les modèles peinent :
| Modèle | Natif numérique (F1) | Photographié (F1) |
|---|---|---|
| Gety OCR (built-in) | 0.903 | 0.322 |
| Apple Vision (built-in) | 0.881 | 0.421 |
| PP-OCRv6(small) | 0.724 | 0.301 |
| PP-OCRv6(tiny) | 0.686 | 0.289 |
| PP-OCRv5 mobile | 0.707 | 0.278 |
| PaddleOCR (PP-OCRv4) | 0.630 | 0.172 |
| Windows OCR | 0.609 | 0.185 |
| Tesseract | 0.541 | 0.192 |
Aucun modèle n’est encore solide dans ce cas. Les scores chutent de la plage des 0.9 vers la bande des 0.2 à 0.4 pour tout le monde. Apple Vision mène sur ce scénario avec 0.421, tandis que Gety devance légèrement les modèles open source. Pour la recherche au quotidien, toutefois, la colonne de gauche compte davantage : la plupart des fichiers que l’on s’attend à rechercher sont des captures d’écran et des scans nets, pas des photos de documents prises de travers.
2. Mises en page complexes : dans le même peloton de tête que le meilleur modèle open source
La langue est un axe. La mise en page en est un autre. Pages multicolonnes, tableaux, en-têtes, pieds de page et structures mixtes : c’est là que les modèles plus faibles commencent à perdre des lignes ou à en brouiller l’ordre. OmniDocBench est conçu pour mettre exactement cela à l’épreuve :
| Modèle | Précision de mise en page (F1) |
|---|---|
| Gety OCR (built-in) | 0.963 |
| PP-OCRv6(small) | 0.968 |
| PP-OCRv6(tiny) | 0.963 |
| Apple Vision (built-in) | 0.948 |
| Windows OCR | 0.855 |
| Tesseract | 0.538 |
Le 0.963 de Gety n’est qu’un demi-point de pourcentage derrière PP-OCRv6 small, à 0.968, un écart que les utilisateurs auront peu de chances de ressentir en pratique. Les deux se situent dans le peloton de tête, nettement devant les options OCR intégrées aux systèmes.
3. La même précision, une fraction de l’empreinte
Bien lire est une chose. Bien lire à un coût assez faible pour tourner toute la journée en est une autre. Sur la même machine, avec les mêmes entrées, sur CPU :
| Modèle | Précision multilingue (F1) | Temps médian par page | Pic de mémoire par page |
|---|---|---|---|
| Gety OCR (built-in) | 0.903 | 862 ms | 908 MB |
| PP-OCRv6(tiny) | 0.686 | 607 ms | 4736 MB |
| PP-OCRv6(small) | 0.724 | 2594 ms | 6304 MB |
Gety a besoin d’environ 908 MB par page. Les versions tiny et small de PP-OCRv6 en réclament 4.7 GB et 6.3 GB, soit cinq à sept fois plus. C’est la différence entre un modèle qui peut rester résident et un autre mieux adapté aux traitements ponctuels. Parce que Gety est léger, il peut continuer à tourner en arrière-plan, détecter les nouveaux fichiers dès leur arrivée et les indexer sans que vous ne leviez le petit doigt.
(Apple Vision et Windows OCR s’exécutent au sein de leurs propres piles de plateforme, si bien qu’une comparaison de mémoire ou de vitesse ne serait pas équitable. Ils n’apparaissent que dans les tableaux de précision.)
4. Ce que nous avons testé, et contre quoi
Les jeux de données
Nous avons utilisé des images de documents issues de deux jeux de données publics, chacun répondant à une question différente :
| Jeu de données | La question à laquelle il répond |
|---|---|
| MDPBench | La précision tient-elle sur 17 langues, à la fois sur des pages nettes et photographiées ? |
| OmniDocBench | Reste-t-elle précise quand la mise en page se complique ? |
Les deux jeux de données mesurent des choses différentes ; nous les présentons donc séparément au lieu de les fondre en un seul score. Pour être clair sur ce dont il s’agit : nous avons utilisé ces jeux de données comme source d’images de documents. La méthode d’évaluation, les indicateurs et l’ensemble des modèles sont les nôtres, et diffèrent des évaluations officielles publiées par les auteurs des jeux de données.
Comment nous notons
Nous notons la sortie OCR avec un F1 au niveau du caractère, indépendant de la mise en page. Il mesure uniquement si le texte a été reconnu correctement, pas la mise en page, les sauts de ligne, la structure des paragraphes ni l’endroit où le texte se trouve sur la page.
Nous le gardons indépendant de la mise en page parce que, pour les usages qui comptent (recherche, copie, indexation), ce qui importe est de savoir si chaque caractère a été lu correctement, non si la mise en page a été reconstituée. Un texte entièrement correct mais dans un ordre différent ou avec des sauts de ligne différents ne devrait pas être pénalisé. C’est un test d’OCR, pas un test de mise en page.
Pour chaque page, nous comparons la sortie OCR au texte annoté à la main et calculons :
Avant la notation, la référence et la sortie OCR passent toutes deux par la même normalisation : normalisation Unicode, suppression des caractères invisibles, unification des espaces et retrait des éléments de page tels que les en-têtes, les pieds de page et les numéros de page.
La correspondance des caractères repose sur un comptage en multiensemble : un caractère qui apparaît plusieurs fois est compté à chaque fois. Cela empêche les différences d’ordre de lecture, de sauts de ligne et de découpage en paragraphes d’affecter le score, de sorte que l’indicateur reste centré sur la question de savoir si l’OCR a lu correctement les caractères de la page.
Les chiffres finaux sont des F1 par page, moyennés en macro sur les langues et les groupes de données ; le rapport complet fournit également un intervalle de confiance bootstrap à 95%.
Contre quoi nous avons comparé
Pour l’ensemble de comparaison, nous avons cherché à couvrir les principales options que les utilisateurs sont susceptibles de rencontrer dans des flux de travail réels :
- PaddleOCR (PP-OCRv6), l’option OCR open source la plus solide aujourd’hui. Il existe en versions tiny, small et medium ; nous avons testé les deux versions embarquées, tiny et small. Medium est un modèle de 34.5M de paramètres destiné aux GPU de serveur, et le glisser dans un test sur CPU embarqué reviendrait à comparer les mauvaises choses.
- Tesseract, un moteur open source de longue date, très répandu et familier comme point de référence.
- Apple Vision et Windows OCR, l’OCR que vous avez déjà si vous n’installez rien du tout.
5. La précision est la base. L’usage est l’objectif.
Les chiffres montrent que Gety lit avec précision. Mais la précision n’est pas une fin en soi ; c’est la base d’une expérience OCR utile.
Le flux de travail habituel d’un outil OCR ressemble plutôt à ceci :
Trouver l'image -> L'ouvrir ou la glisser dans un outil OCR -> Lancer la reconnaissance manuellement -> Attendre le résultat -> Obtenir du texte exploitableLa plupart du temps, cette chaîne ne démarre même pas. Les captures d’écran et les scans deviennent des angles morts dès qu’ils arrivent sur votre ordinateur, et restent invisibles à la recherche jusqu’au jour où vous pensez à les traiter.
C’est ce fossé que Gety cherche à combler. L’OCR s’exécute en arrière-plan, de sorte qu’au moment où une image arrive, Gety peut la reconnaître et l’indexer automatiquement. Rien à convertir, rien à cliquer. Quand vous en avez besoin, vous tapez dans la recherche globale et le texte contenu dans l’image est là.
La précision décide de la qualité de la reconnaissance. La consommation de ressources décide si cette reconnaissance peut rester active en permanence. Nous ne cherchions pas à livrer un moteur OCR de plus ; nous cherchions à faire en sorte que « les mots de cette image ne sont pas recherchables » cesse de se produire sur votre ordinateur.
Ce sont nos propres résultats internes. Nous avons utilisé les images de documents des jeux de données publics MDPBench et OmniDocBench comme matériel de test, mais la méthode d’évaluation et les indicateurs sont les nôtres et diffèrent des évaluations officielles publiées par les auteurs des jeux de données. Chaque jeu de données est assorti de sa propre licence et de ses propres conditions d’utilisation, certaines réservées à la recherche ; nous rapportons ici des résultats, sans redistribuer le moindre échantillon.