L'opportunité nous a été donnée de tester (enfin) Windows Vista.
La compatibilité de nos programmes semble assurée, l'installation et l'exécution s'étant déroulée sans problème notable. Simplement, comme prévu, Vista est bourré d'alertes de sécurité. S'apercevant que les systèmes précédents étaient des passoires dans ce domaine, Vista, à l'instar de MacOS X, décharge la responsabilité sur l'utilisateur, qui doit à tout bout de champ confirmer l'installation des programmes, l'usage des plug-ins dans le navigateur, l'utilisation des panneaux de configuration, etc.
Par exemple, lors du lancement de l'installateur, on obtient (sur une version anglaise du système) :
Brr, ça fait peur ! 
Donc, je suppose que nous aurons des tonnes de demandes au support technique, disant "Y'a Windows qui me dit que votre programme veut accéder à mon ordinateur. Qu'est-ce que je dois faire"?
Jusqu'à ce que nous nous soyons décidés à acheter une signature numérique, et la mettre en place sur nos programmes...
Sinon, les programmes fonctionnent bien, la preuve :
Il n'y a plus qu'à faire un thème d'écran "Vista" (sans les icônes qui bougent) pour Harmony/Melody, afin ne pas perturber ceux qui ne connaîtront que cette interface graphique. |
|
|
| by Olivier Guillion |  |
|
| |
|
Alors que nous améliorons la reconnaissance des portées sur la page, des tests doivent être réalisés avec autant que possible de partitions différentes, pour localiser les éventuels problèmes.
Durant nos recherches de partitions scannées pouvant servir d'exemple, ce site a attiré notre attention :
Historic American Sheet music
Il contient de très nombreuses partitions anciennes (1850-1920), scannées avec une bonne précision et un soin particulier.
Les typographies sont parfois assez bizarres (dessinées à la main?) :
Le fait que ces partitions proviennent de sources diverses permettra de fournir à ScanToMusic des jeux de caractères très différents, pour juger de son adaptabilité.
|
|
|
| by Olivier Guillion | |
|
| |
|
La première connexion entre les modules de traitement d'image et les modules de traitement des informations musicales a été effectuée.
Le traitement d'image repère les lignes horizontales, suit leurs petites imprécisions, élimine les "trous", les classe, puis transmet ces données brutes à un module de recherche de portées, similaire à celui utilisé dans PDFtoMusic.
A partir de là, on obtient les premières informations concernant la structure de la partition scannée, c'est-à-dire la position des portées et la valeur de l'espace entre les lignes.
Ceci permettra d'entamer une deuxième phase d'analyse d'image, car la valeur de l'interligne conditionne la taille des objets que l'on peut rencontrer sur la portée (altérations, têtes de notes...). Connaître cette valeur facilite la discrimination entre les objets pouvant avoir à peu près la même forme, mais à des échelles différentes, comme par exemple une tête de noire et un point.
|
|
|
| by Olivier Guillion | |
| |
|
Une des premières opérations généralement effectuées par un logiciel de reconnaissance optique de partition, OMeR inclus, est de "seuiller" l'image, c'est-à-dire de remplacer les nuances de gris par du noir ou du blanc pur.
Ceci permet de simplifier grandement les calculs, chaque point de l'image ne pouvant alors avoir que deux états, allumé ou éteint.
Dans ScanToMusic, nous avons décidé, dès le début, de conserver les niveaux de gris de l'image. "Pourquoi ?" me demanderez-vous,
"C'est simple", vous répondrai-je  :
lorsque l'oeil - ou le cerveau- humain regarde une forme dessinée avec des niveaux de gris, les gris plus ou moins foncés sur le pourtour des objets lui permettent d'affiner ce contour. Cela permet de voir des formes aux contours arrondis même si la précision du scan est faible, alors qu'une image seuillée noir/blanc fait apparaître un crénelage.
Voici un exemple:
Cette note, extraite d'une partition scannée, est présentée en taille réelle sur la ligne du haut et en taille double sur la ligne du bas.
En A, l'image originale en niveaux de gris, telle que la traite ScanToMusic. Même s'il apparaît un peu flou, le symbole est bien visible, et sa forme et ses courbes se voient clairement.
En B, C, D, la même image en noir/blanc, réalisée avec divers niveaux de seuillage. On se rend nettement compte de la perte de qualité et de définition qui résulte de cette opération.
Partant du principe qu'il est préférable de conserver un maximum d'information utile dans l'image avant d'entamer la phase de reconnaissance de symboles, les niveaux de gris seront donc conservés tout au long du traitement par ScanToMusic.
|
|
|
| by Olivier Guillion | |
|
| |
|
Les premiers tests de reconnaissance de symboles musicaux ont été effectués. Il a suffi de sauvegarder tous les symboles qui ont été isolés sur la partition scannée puis de les fournir au module d'OCR musical de PDFtoMusic.
Ces premiers résultats sont prometteurs, le module reconnaissant quasiment 100% des clés de sol, 90% des rondes, noires et blanches. Sachant que, pour l'instant, les symboles sont fournis au module de reconnaissance avec les lignes de portées, c'est-à-dire traversés de part en part par une ou plusieurs lignes horizontales noires, on peut considérer ces résultats comme prometteurs.
Il faut maintenant améliorer les algorithmes de "mise en boîte", afin d'éviter de fournir à ce module soit des morceaux de symboles considérés comme indépendants, alors qu'ils constituent le même signe (clés de fa, certains chiffres indicateurs de mesure, etc), soit plusieurs symboles distincts mais pris pour un seul signe (notes accrochées ou en accord, groupe "note+altération" lorsque cette dernière est proche, etc.).
|
|
|
| by Olivier Guillion | |
| |
|
Le module le plus important de ScanToMusic va être la reconnaissance de caractères musicaux (et alphanumériques). Afin de permettre de tester rapidement ce système, nous avançons rapidement, en laissant de coté le "fignolage" des modules en amont.
Après une élimination rapide des lignes de portées, des algorithmes de "mise en boîte" des divers objets ont été mis en place. Ces algorithmes sont destinés à séparer sur la page scannée les divers éléments qui la composent, et de les extraire un à un pour les soumettre à l'analyse de caractères. Ceci pose des problèmes lorsque deux lettres apparaissent "collées" l'une à l'autre dans un mot, ou lorsque des notes sont reliées par des barres d'accroche par exemple. Mais pour l'instant nous faisons abstraction de ces problèmes, pour savoir rapidement quels résultats nous pourrons obtenir sur les éléments bien séparés.
Afin que ce blog reste lisible par un non-initié, nous simplifions ici le plus possible les concepts qui sont abordés. De même, pour des raisons de confidentialité, nous n'entrons pas dans le détail des algorithmes que nous mettons en place. Certains d'entre vous (et je pense notamment à Jean-Armand) ont posté dans les étapes précédentes des suggestions et même des algorithmes fort bien faits, sur lesquels nous étions déjà en train de travailler. Merci, et chapeau !
Je ne suis jamais contre un petit coup de main, et échanger des idées est le meilleur moyen d'en trouver des nouvelles et des bonnes, mais si possible, pour discuter précisément du programme, je préfèrerais que cela se fasse par e-mail. Il y a déjà des produits dans ce créneau, et probablement d'autres à venir, donc cela m'embêterait un peu de fournir publiquement un mode d'emploi pas à pas sur l'art et la manière de développer un tel projet, avec tous les algorithmes que nous utilisons expliqués en détail  |
|
|
| by Olivier Guillion | |
|
| |
|
Aujourd'hui, nous avons commencé à essayer de gommer les lignes de portées, sans trop abîmer les caractères qui sont imprimés dessus.
Ce n'est pas aussi facile que ça peut en avoir l'air. Il faut parvenir à "deviner" ce qu'il y avait imprimé sur la partie noire de la ligne, sans pour l'instant pouvoir s'appuyer sur une quelconque connaissance des caractères typographiques, puisque c'est justement cette étape qui est destinée à isoler les objets graphiques à reconnaitre.
Si, au bout du compte, nous nous apercevons que cette opération ne peut pas s'effectuer sans dommage, nous pouvons encore changer notre fusil d'épaule, et considérer que les lignes de portées font partie intégrante du caractère à reconnaître.
Mais cela compliquerait alors la partie reconnaissance proprement dite, car pour une tête de note, par exemple, il faudrait pouvoir reconnaître les quatre glyphes:
- tête de note entre deux lignes
- tête de note sur une ligne ou sur une petite ligne supplémenraire (ledger line)
- tête de note avec une ligne dessous (Sol aigu pour une clé de sol)
- tête de note avec une ligne dessus (Ré grave pour une clé de sol).
En somme, multiplier les calculs de reconnaissance par quatre...
|
|
|
| by Olivier Guillion | |
|
| |
|
Le suivi des déformations des lignes horizontales de portées a été mis en place.
L'algorithme corrige donc les rotations de page jusqu'à +/- 4°, avec une précision qui a été augmentée pour atteindre le 30ème de degré.
Les déformations sont également gérées, le programme permet donc de déterminer la courbe que forment les lignes, et de la compenser.
Voici un extrait d'une partition scannée, puis détériorée artificiellement, juste pour rendre les choses plus difficiles :
Voici la même partition, une fois débruitée, recontrastée et redressée :
Maintenant que les lignes horizontales sont bien horizontales, on peut attaquer l'étape suivante, qui consiste à s'intéresser aux symboles qui sont écrits sur les portées... |
|
|
| by Olivier Guillion | |
|
| |
|
Aujourd'hui, premiers tests sur de vrais scans de partition. Les algorithmes de suivi de lignes de portées fonctionnent correctement sur ce type de document, mais ceux destinés à l'amélioration du contraste sont perturbés par les particularités liées au scan :
pages tachées, froissées, ou laissant apercevoir le verso par transparence.
Ces algorithmes ont donc été repris pour tenir compte de ces particularités.
L'angle maximal de rotation de la page scannée a été réduit à un intervalle de -4° à +4°
Faites l'essai avec un logiciel de traitement d'image, en appliquant une rotation à une page parfaitement horizontale:
Vous vous apercevez que pour obtenir un angle de rotation supérieur à 4°, il faut vraiment positionner sa page comme un sagouin sur la vitre du scanner.
ScanToMusic devrait être beaucoup plus tolérant qu'OMeR sur les paramètres de numérisation, mais il ne faut quand même pas exagérer, un minimum de soin sera tout de même nécessaire. |
|
|
| by Olivier Guillion | |
|
| |
|
Le suivi des lignes de portées a été amélioré, afin de permettre de suivre les déformations de la page scannée.
Dans cette image, on voit les courbes détectées (en rouge) dessinées par-dessus la partition débruitée et recontrastée :
Il faut maintenant peaufiner ce résultat. En effet, pour chaque ligne de portée, on obtient un petit faisceau de courbes possibles, quasiment confondues. La prochaine étape est d'y effectuer une sélection, pour ne garder que la courbe la plus probable, et y appliquer un lissage afin qu'elle se confonde au mieux avec la véritable ligne.
|
|
|
| by Olivier Guillion | |
| |
|
Nous avons attaqué les premiers algorithmes de détection proprement dits.
Nous partons d'une image déformée et bruitée, dans laquelle les lignes ne sont pas parfaitement horizontales :
Après avoir appliqué les algorithmes de débruitage et d'optimisation du contraste de l'étape 1, on en extrait les lignes fines et "presque" horizontales. Les tiges, barres de mesures, accroches, têtes de notes et autres symboles sont gommés :
Puis une recherche des pentes des droites est effectuée, avec une précision d'1/10 de degré (cela pourra être ajusté par la suite), le résultat apparaissant ici en rouge :
Les lignes de portées apparaissent donc clairement, avec leur pente et leur écartement. Ces données sont cruciales pour la suite, lorsque nous effectuerons la détection des symboles qui sont imprimés dessus.
On suppose cependant ici que les droites restent des droites, ce qui n'est pas toujours le cas lors d'un scan. Parfois lorsqu'on scanne une page d'un livre relié, il y a une courbure, une déformation sur le bord de la page.
L'algorithme doit donc maintenant être modifié pour s'adapter à ces contraintes, et effectuer le suivi de la pente de chacune des lignes de portée. |
|
|
| by Olivier Guillion | |
|
| |
|
Le projet "Super-OMeR" a enfin démarré, sous le nom provisoire de "ScanToMusic". Le but de ce programme, est, je le rappelle, d'analyser des pages de partition scannées pour en extraire les éléments constitutifs, et recréer une partition éditable (Harmony ou MusicXML). Dans la dernière étape, les algorithmes développés pour PDFtoMusic devraient pouvoir être largement utilisés.
Mais dans un premier temps, il faut préparer la reconnaissance optique de l'image.
Plutôt que d'utiliser de vraies pages scannées, nous partons des images obtenues par l'afficheur de PDF de PDFtoMusic :
Cette image est alors altérée pour la faire ressembler à ce qu'on aurait pu obtenir à la suite d'un -très- mauvais scan. Rotation, déformation, altération des contrastes, "taches" et bruit de fond sont appliqués :
Les premiers algorithmes de ScanToMusic doivent permettre de retrouver une image "propre", débarassée (ou presque) des problèmes de taches, de bruit et de contraste :
La prochaine étape consistera à redresser tout cela, en évaluant, puis en compensant les déformations de la page.
|
|
|
| by Olivier Guillion | |
|
| |
|
|
