Myriad Blog 1.3.0 Saturday, Dec 20th, 2014 at 09:55pm 

Wednesday, May 24th, 2006 at 04:55pm
Du glyphe à l'Unicode (2)
Le cerveau humain, à partir des informations visuelles qui lui sont transmises, distingue assez facilement (après un petit apprentissage), une clé de sol d'une clé de fa, un "M" d'un "T", etc.
L'idée de simuler le fonctionnement des neurones dans un programme coulait donc de source.  
 
Concrètement, un réseau de neurones "informatique" se présente en couches, comme un plat de lasagnes:
 
- Une série de neurones dits "d'entrée", chacun d'entre eux recevant une valeur quantifiable dépendant de l'objet à analyser. Ce peut être la luminosité d'un point, mais aussi un rapport largeur/hauteur du caractère,  l'épaisseur moyenne de ses traits, en fait tout paramètre pouvant avoir une utilité dans la discrimination.  
 
- Une série de neurones dits "de sortie", chaque neurone correspondant à une valeur possible à déterminer. Par exemple, si on veut que le réseau de neurones soit capable de trouver à quelle lettre (A-Z) correspond le caractère analysé, il faudra 26 neurones de sortie, un par lettre possible
 
- Entre l'entrée et la sortie, une ou plusieurs couches de neurones dits "cachés".
 
Chaque neurone de chaque couche est relié à chaque neurone de la couche suivante, par une liaison plus ou moins "forte". Au départ, la force de chacune des liaisons est choisie au hasard, et le réseau est incapable de reconnaître quoi que ce soit.
 
Ensuite, on présente au réseau des exemples de caractères à déterminer. Il essaie (et échoue). Il faut alors lui enseigner de quoi il s'agissait. Cet apprentissage affaiblit les liaisons qui ont conduit à l'erreur et renforce celles qui favorisent un résultat correct.
 
Si les valeurs alimentant la couche d'entrée sont bien choisies, si le réseau est correctement dimensionné, et si l'apprentissage est bien réglé, le réseau, petit à petit, apprend, et au bout de quelques milliers d'expérimentations et d'apprentissages, devient capable de distinguer quelque chose. Après 50 à 100000 apprentissages, il se débrouille pas mal.
 
Nous avons écrit un prototype d'un tel réseau en MyrScript, et l'avons fait travailler sur des exemples de caractères (comme les lettres de A à Z écrites en différentes tailles et différentes fontes). Une dizaine de milliers d'apprentissages plus tard, le réseau obtient un taux de fiabilité de 99% sur les exemples qui lui ont déjà été fournis, et plus de 90% sur des exemples issus d'autres fontes proches mais pas identiques.
 
Globalement, les résultats sont donc encourageants. Seul petit bémol : la masse de calculs devient assez conséquente. Pour un tout petit réseau de neurones de 3 couches de 26 neurones, il faut effectuer 1352 opérations pour obtenir un résultat. Si on passe le nombre  de neurones par couche à 120, il en faut 28800.
 
MyrScript commence à peiner un peu, et nous nous apercevons que le réglage du "taux d'apprentissage" s'avère crucial. Il détermine si le réseau apprend vite ou lentement de ses erreurs.
Trop vite, et une correction d'une de ses erreurs lui fait "oublier" ses apprentissages précédents, et trop lentement, il commet inlassablement la même faute, sans apprendre à se corriger.
 
Enfin, si on désire réduire le nombre de paramètres d'entrée pour simplifier le réseau, il faut choisir des critères quantifiables facilement extractibles du dessin du caractère. Quels qu'ils soient, leur choix sera dicté seulement par notre propre intuition, et risque de s'avérer moins performant qu'attendu.  
 
Cette méthode fonctionne donc, mais avant de passer à l'étape suivante de l'analyse, nous préférons explorer d'autres voies similaires, basées sur les statistiques de répartition des pixels dans chaque forme de caractère. Cela permettrait d'alléger les calculs et d'obtenir un apprentissage plus rapide qu'avec un réseau neuronal classique...
by Olivier Guillion
Comments

Comment from Jean-Armand Thursday, May 25th, 2006 at 00:03am
(No subject)
Si vous constituez une base de données de "caractères" musicaux, vous pouvez aussi calculer la distance d'un caractère à chacun des caractères de la base, et choisir celui qui est le plus proche (distance = somme des valeurs absolues des différences de pixels). Cela devrait fonctionner pas trop mal compte tenu du faible nombre (?) de polices de caractères musicales, et de l'absence de bruit. L'intérêt, c'est que l'apprentissage est immédiat ; par contre, cela demande beaucoup trop de calculs pour la reconnaissance d'un seul caractère... Bon, c'était juste une idée comme ça.
 
A propos de la vitesse de convergence de l'apprentissage des réseaux de neurones : à côté de la classique "rétropragation du gradient" (vous ne dites pas quelle méthode vous employez, mais on peut supposer que c'est celle-là), il existe des méthodes pour augmenter drastiquement la vitesse de convergence. Méthodes d'ailleurs dérivées des méthodes d'analyse numérique utilisées pour résoudre plus rapidement les problèmes d'optimisation en général. Je n'ai pas de pointeur vers un article à vous proposer, mais cela devrait se trouver sur le Web.

Comment from Olivier Guillion Thursday, May 25th, 2006 at 10:04am
Rétropropagation, convergence et statistiques
Merci, Jean-Armand
 
Je vois que tu es bien au fait de ce genre de problème, et je n'exclus pas de te demander quelques conseils par e-mail au cours de l'avancement de ce projet.
 
En effet, nous avons, au cours de nos tests, utilisé une simple rétropropagation pour l'entrainement du réseau de neurone, et nous expérimenterons d'autres techniques plus poussées si nous nous engageons dans cette voie.
 
Un simple calcul de différence devrait effectivement pouvoir fonctionner sur la plupart des caractères musicaux, mais je te rappelle que nous aurions également à traiter des polices non musicales, dans lesquelles un C sera plus proche d'un G de la même police que d'un C italique gras dans une autre police.
 
Nous sommes pour l'instant en train d'évaluer d'autres procédés (dont le calcul statistique Bayésien) afin de savoir lequel serait le mieux adapté à notre cas précis, et présenterait le meilleur rapport efficacité/difficulté d'implémentation et de maintenance.
 
J'aime bien, lorsque je démarre un projet de ce type, commencer par essayer différentes solutions par moi-même, sans trop m'appuyer sur ce qui a déjà été fait par d'autres. Même si cela prend un peu plus de temps au départ, cela me permet d'acquérir une meilleure compréhension du sujet, et donc par la suite de saisir l'intérêt des solutions qui ont pu être découvertes pour résoudre tel ou tel problème d'implémentation ou de calcul.
 
Mais, bien sûr, les conseils restent toujours bienvenus, surtout si cela peut me permettre d'éviter de m'égarer...

Comment from fx Saturday, May 27th, 2006 at 03:47pm
pourquoi une sortie sur 26 neurones
utiliser uns sortie sur 5 neurones permet de coder 2**5 caracteres, ce qui reduit considerablement la taille du reseau (logarithmiquement)
 
fx

Comment from Jean-Armand Saturday, May 27th, 2006 at 11:54pm
Re : Rétropropagation, convergence et statistiques
Bonjour Olivier,
 
"Je vois que tu es bien au fait de ce genre de problème"
Euh, disons que je l'étais il y a 18 ans, mais maintenant il ne me reste plus que quelques souvenirs de la question.
 
"je te rappelle que nous aurions également à traiter des polices non musicales, dans lesquelles un C sera plus proche d'un G de la même police que d'un C italique gras dans une autre police"
Effectivement, j'avais oublié que les musiques peuvent aussi comporter du texte... Ca complique singulièrement !
 
Fx : "utiliser une sortie sur 5 neurones permet de coder 2**5 caracteres, ce qui reduit considerablement la taille du reseau (logarithmiquement) "
C'est vrai, mais d'un autre côté cela empêche de savoir quel est le "second choix" du réseau. Lorsqu'il y une case de sortie par caractère à reconnaître, le réseau peut par exemple indiquer que c'est un C, mais donner aussi un poids, moins fort, au G. Si l'on utilise un dictionnaire en complément, on peut alors tester le G si le C ne convient pas. (Mais on pourrait aussi se servir d'une table prédéfinie, disant par exemple qu'un C et un G sont facilement confondus).

Comment from Olivier Guillion Sunday, May 28th, 2006 at 10:08am
5 ou 26 neurones?
A mon avis (je n'ai pas fait de test) obtenir le résultat en binaire comporte trois inconvénients:
 
1- Le réseau de neurone donne des résultats qui ne sont pas nécessairement 1 ou 0. Avec 26 neurones, il suffit de choisir celui qui a la plus grande valeur en sortie. Avec du binaire, cela obligerait à définir un "seuil", d'où plus d'erreurs à proximité de ce seuil.
 
2- Comme l'a dit Jean-Armand, en binaire impossible de savoir quelle valeur était classée deuxième. De plus, si le réseau hésite entre un C et un G, on va obtenir un "mix" de leurs deux valeurs binaire, donc probablement n'importe quoi.
 
3- Enfin la corellation entre l'image d'origine et la présence ou non du bit n°1, 2, 3 ou 4 dans le résultat étant moins évidente qu'avec l'un des 26 neurones de sortie, il faudra probablement augmenter la taille du réseau, et certainement ajouter une couche cachée d'à peu près 26 neurones.
 
On obtiendra alors quelque chose qui ressemblera à notre réseau à 26 sorties, auquel a été ajouté un convertisseur neuronal de décimal en binaire, ce qui n'est pas avantageux du point de vue des calculs.

Comment from Gilbert Rouquié Wednesday, Jun 7th, 2006 at 11:48am
Réseaux Neuronaux
C'est probablement une méconnaissance, je garde un certain scepticisme envers la reconnaissance de partitions par Réseaux Neuronaux. De grâce, ne m'en veuillez pas !
 
Je souhaite vous faire part de mon expérience acquise en digitalisant un centaine de partitions. Papier, scanné, reconnu sous SharpEye2. CPDL, PDF, converti en TIFF, reconnu sous SharpEye2. Pour les plus récentes, CPDF, Encore ou Finale, converties directement.
 
SharpEye2 est dans la même lignée qu'Omer. OCR à partir d'une bitmap. Avec des soucis, toujours les mêmes, qu'un traitement direct des PDF devrait mieux résoudre, tels que bien différencier une tête de note, d'un dièze ou d'un bémol. C'est pour cela que je crois à votre projet PDF -> Musique.
 
Au dela de cela, je crois que ce sont des architectures de blackboard qui devraient le mieux reconnaitre des partitions. Un exemple sous SharpEye2 qui m'avait frappé : une altération en tête de portée. Fait elle partie de l'armature ou bien est elle accidentelle ?  
 
Pour répondre, une bonne heuristique : regarder l'armature de la même portée sur les autres systèmes, regarder les armatures des autres portées du même système.  
 
Un OCR de type traditionnel - à reconnaissance de motifs élémentaires - ne peut pas coder ce genre d'heuristiques. Un blackboard, où des faits qui ont des taux de plausibilité, et qui peuvent être remis en cause, permet de coder des agents qui encodent des heuristiques, observent des faits et en ajoutent, retranchent ou altèrent les plausibilités, le peut.
 
Un autre point. L'IRISA a travaillé sur l'OCR de partitions. Je regrette que cette recherche n'aie pas débouché sur un produit logiciel, ce serait à mon avis un OCR imbattable. Voici en tous cas une référence :
 
B. Coüasnon, Segmentation et reconnaissance de documents guidées par la connaissance a priori : application aux partitions musicales, Thèse de l'université de Rennes 1, Janvier 1996.  
 
Pardonnez ces quelques divagations...

Comment from Olivier Guillion Wednesday, Jun 7th, 2006 at 01:56pm
Confusion?
Merci pour vos conseils et vos références.
Je pense cependant que vous faites une confusion entre la reconnaissance des caractères, et la reconnaissance d'une partition.
 
Personne ici n'a sous-entendu qu'un réseau neuronal pourrait être utilisé pour la reconnaissance de la structure de la partition (à qui est ce dièse, comment se raccordent les portées des divers systèmes, etc).
 
Nous parlons des réseaux neuronaux pour différencier les caractères entre eux (ce caractère est-il un dièse ou un bécarre?). Je ne pense pas que, pour cela, un blackboard soit ni nécessaire, ni utile.
 
Par contre, pour les résolutions de problèmes de structure, c'est effectivement à explorer. Merci pour les références!


Most recent first
Oldest first

Top of page
Last update:  (c) Myriad