Myriad Blog 1.3.0 Thursday, Nov 27th, 2014 at 11:29am 

Saturday, May 20th, 2006 at 07:51pm
Du glyphe à l'Unicode (1)
Dans le cadre du projet "PDFToMusic" (voir les autres articles), nous avons été amenés à étudier les divers moyens d'effectuer une reconnaissance simple de caractères. Ceci permettrait, lorsqu'on trouve dans un fichier PDF un caractère dessinant par exemple une clé de sol, de savoir qu'il s'agit bien d'une clé de sol et pas d'autre chose.
 
Dans ce projet, contrairement à une véritable reconnaissance de textes scannés, nous avons seulement besoin de différencier les caractères individuels au sein d'une fonte, ce qui supprime d'un coup plusieurs problèmes inhérents aux reconnaissances optiques conventionnelles :  
 
1- Les caractères sont "propres", c'est-à-dire que tous les pixels sont à leur place, qu'il n'y a pas de possibilité de poussière, ou défaut de numérisation qui pourraient perturber la reconnaissance
 
2- Les caractères sont isolés. On connait exactement la taille et la position du caractère à analyser. Impossible d'avoir malencontreusement deux caractères consécutifs confondus avec un seul (notamment avec des paires commes "ff" ou "ft" dont les constituants se touchent graphiquement), ou un caractère coupé en morceaux comme par exemple avec les deux points de la clé de fa.
 
Une première étape, de pré-analyse, consiste à voir s'il n'y aurait pas des valeurs et paramètres quantifiables, indiscutables, permettant de se passer d'intelligence artificielle ou de calculs statistiques complexes pour identifier le caractère.
 
Une première maquette est écrite en MyrScript.
 
Le caractère est affiché, puis le nombre de pixels "noirs" sur chaque ligne et sur chaque colonne est calculé. Un double histogramme est alors tracé, avec des couleurs dépendant du nombre de "trous" détectés lors du balayage de la ligne ou de la colonne.
 
Ensuite, divers traitements sont essayés.
 
Le premier combine les histogrammes horizontaux et verticaux afin d'obtenir une "empreinte" du caractère. Nous la calculons avec le même caractère dans diverses fontes musicales, mais malgré d'assez importantes similitudes, cela ne semble pas être suffisamment "stable" pour permettre une reconnaissance.
 
Deuxième essai. L'aspect du caractère est analysé, et les "directions" des tracés sont extraites. Le graphe obtenu montre en rouge les lignes "plutôt verticales", en vert les lignes "plutôt horizontales" et en bleu les lignes "plutôt diagonales". Une comparaison directe de ces paramètres à un jeu-type semble difficile, mais les résultats sont suffisamment significatifs pour garder ceci dans un coin et ne pas le jeter tout de suite.
 
Troisième essai. Afin de s'abstraire de l'épaisseur des traits constituant le caractère, le script tente de le "fildefériser", de réduire tous les traits à un seul pixel d'épaisseur. Si cela ne permet pas de déterminer ce qu'est le caractère, cela pourrait au moins être utilisé pour simplifier une comparaison ultérieure.
 
Beaucoup des programmes que nous écrivons sont seulement des tests destinés à finir à la corbeille. C'est probablement le cas de ce petit outil d'analyse, qui nous a permis d'expérimenter quelques techniques, et d'essayer d'extraire des paramètres quantifiables du graphisme d'un caractère.
 
La reconnaissance du caractère s'avère cependant complexe (nous nous y attendions), et doit probablement passer par des algorithmes de discrimination un peu plus évolués qu'une simple série de comparaisons.  
 
Nous nous penchons donc sur les réseaux de neurones, qui semblent souvent employés dans les programmes d'OCR (Optical Character Recognition)...
by Olivier Guillion
Comments

Comment from Olivier Guillion Monday, May 22nd, 2006 at 01:01pm
OMeR et OCR
La reconnaissance dans OMeR est basée sur un algorithme "ad hoc", paramétré manuellement (et empiriquement), et destiné à reconnaitre uniquement les formes simples liées à l'écriture musicale (clés, notes, altérations...).
 
Ici, la police de caractère à reconnaître peut être alphanumérique, avec des lettres accentuées. Trouver à la main les paramètres permettant de distinguer la centaine de caractères possibles les un des autres, et qui fonctionne quelle que soit la police et  le style (italique,gras...) me paraît assez délicat.
 
De plus, nos capacités en programmation dans ce domaine, et celles des ordinateurs en matière de puissance ont bien évoluées depuis la première sortie d'OMeR, donc reconcevoir des algorithmes de reconnaissance à la base pourrait bien profiter à une nouvelle version d'OMeR, ou à tout autre nouveau produit basé sur de tels filtres.

Comment from Jean-Armand Sunday, May 21st, 2006 at 00:15am
(No subject)
Bonjour Olivier et Didier,
 
Un détail que je ne comprends pas : en principe le problème que vous voulez résoudre est déjà résolu dans OMeR, qui plus est avec des caractères bruités. Alors pourquoi repartir de zéro ?
 
Sur le fond, le fait que les caractères soient non bruités incite à utiliser des méthodes basées sur des algorithmes "ad hoc" (comme ceux que vous décrivez ci-dessus), plutôt que sur des algorithmes génériques comme les réseaux neuronaux, dont un grand avantage est la résistance au bruit.
 
Dans les algorithmes génériques de reconnaissance, il y a aussi le filtrage bayésien, que vous avez mentionné à propos des spams.
 
Pour la petite histoire, j'ai réalisé le même genre de tests (compter les trous, fildeférisation, réseaux neuronaux, et bien d'autres) sur de l'écriture manuscrite, il y a presque 20 ans. Avec un succès très mitigé... mais les problèmes sont bien différents.


Most recent first
Oldest first

Top of page
Last update:  (c) Myriad 2013