Ce monsieur, professeur dans le département de psychologie à l'université Ritsumeikan, à Kyoto, se consacre depuis quelques années aux illusions d'optique, et notamment les illusions de mouvement.
Il poste régulièrement ses dernières création sur son site. Je vous invite à les regarder. Non, il ne s'agit pas de GIFs animés mais bien d'images statiques. Toutes les sensations de mouvement ne sont que des illusions !
Dans la section " the latest works", vous pourrez voir ses réalisations de ces 5 dernières années.
Bluffant... A tel point que nous allons essayer d'en imprimer quelques-unes pour voir si ça fonctionne aussi sur papier. Apparemment oui, puisque Akiyoshi Kitaoka a publié des livres (en japonais) sur ses illusions.
Sur ce, toute l'équipe vous souhaite de passer un bon réveillon.
Rendez-vous en 2009 !
|
|
|
| by Olivier Guillion |  |
|
| |
|
Maintenant que le module de reconnaissance de caractères est suffisamment avancé, nous allons poursuivre deux tâches en parallèle :
- L'amélioration de la reconnaissance de textes, notamment par un meilleur découpage des zones de texte en caractères individuels
- L'application des connaissances que nous avons pu acquérir à la reconnaissance des symboles musicaux proprement dite. Le problème principal réside dans les lignes des portées, qui "brouillent" la reconnaissance.
Deux solutions sont possibles:
Soit nous essayons d'enlever physiquement ces lignes de l'image, en tentant de reconstituer les parties des symboles qui sont dessinées dessous
Soit nous adaptons nos algorithmes de reconnaissance, en leur faisant ignorer partiellement ou totalement ces parties-là.
Entre les deux, notre coeur balance...
|
|
|
| by Olivier Guillion | |
| |
|
- En mode ruban, les effets associés à la note et marqués "invisibles" s'afficherons en gris clair (comme cela se fait actuellement en mode page)
- Un certain type de police TrueType n'était pas reconnu par PDFtoMusic (problème d'encodage de cmap) c'est maintenant corrigé.
- ScanToMusic:La reconnaissance de caractères a été simplifiée au maximum, et les combinaisons d'algorithmes les plus rapides (ou plutôt les moins lents) ont été privilégiés.
Les temps de calcul sont toujours très longs, mais maintenant supportables pour les premiers tests en vraie grandeur. Prochaine étape, améliorer l'extraction des caractères individuels dans les lignes de textes. |
|
|
| by Didier Guillion |  |
|
| |
|
Le sapin s'est habillé pour faire la fête,
les petits enfants vont ouvrir leur cadeaux,
la dinde mitonne dans le four,
revoici le jour tant attendu.
Toute l'équipe vous souhaite un merveilleux Noël !
|
|
|
| by Didier Guillion | |
| |
|
- Correction d'interaction de palettes (problème minime, seulement graphique)
- On nous a soumis un fichier Finale qui ne se chargeait pas sous Harmony, après quelques heures d'investigations, nous nous sommes rendu compte que Finale ne le chargeait pas non plus. Certainement un mauvais transfert à un moment donné...
Sinon, demain c'est la trêve de Noël, on devrait reprendre le collier Lundi prochain.
|
|
|
| by Didier Guillion | |
|
| |
|
Sur suggestion d'un utilisateur :
Le défilement des pages en mode Lutrin (Player et Plug-In) a été amélioré. Lorsque la musique se joue, la page suivante affichée est calculée en fonction des ruptures afin que l'interprète ait toutes les informations nécessaires. Mais, en conséquence, les pages affichées en vis à vis seront différentes lorsque l'on navigue dans le document via les icônes "page suivante" et "page précédente" |
|
|
| by Didier Guillion | |
| |
|
Le module d'extraction de zones de caractères dans une image et le module de reconnaissance ont été fusionnés.
On peut donc maintenant charger une page scannée, lancer une analyse, et obtenir graphiquement le texte reconnu affiché en surimpression sur le scan.
Cela va nous permettre de poursuivre plus avant l'amélioration de la reconnaissance, mais nous devrons rapidement résoudre le problème de lenteur de calcul, qui va nous gêner dans nos mises au point.
Avant d'optimiser les routines de reconnaissances elles-mêmes, nous essayons de trouver un algorithme simple et rapide, fiable à 100%, permettant d'éliminer des comparaisons les caractères trop différents du caractère scanné. En effet, plutôt que de rendre plus rapide la fonction complexe de comparaison, il vaudrait mieux qu'elle soit exécutée le moins souvent possible.
Et rien ne nous empêchera, une fois cela fait, de l'optimiser quand même... |
|
|
| by Olivier Guillion | |
| |
|
Attention.
Là, on touche le grandiose, on plonge dans le délire onirique d'un Grand de ce millénaire, il y aura l'avant et puis l' après. Est ce un ingénieur ? Un artiste ? Un sculpteur ?
En tout cas, ce qu'il fait laisse sans voix.
Theo Jansen est Néerlandais. Il crée des sculptures ambulantes, mues uniquement par le vent. C'est si délicat, si étrange, que l'on à l'impression de contempler des insectes de la planète Mars.
On dit qu'une oeuvre n'existe que par le regard de celui qui l'admire, alors admirons :
http://www.strandbeest.com/film.html |
|
|
| by Didier Guillion | |
|
| |
|
Ca y est, un module de reconnaissance optique des caractères alphanumériques est maintenant opérationnel.
Lorsque les caractères individuels ont été correctement extraits du texte, et que le programme d'extraction peut fournir quelques informations sur l'échelle des caractères et leur position par rapport à la ligne de base, ce module a un taux de succès qui avoisine les 100%.
Les erreurs qu'il commet encore surviennent sur des scans de mauvaise qualité, ou lorsque plusieurs lettres collées sont considérées comme une seule.
Il nous faut maintenant interconnecter nos différents modules, pour réaliser une chaine complète allant de l'image scannée au texte complet extrait.
Seul bémol pour l'instant, la reconnaissance, si elle fonctionne assez bien, reste abominablement lente. Du travail d'optimisation devra être effectué pour rendre le procédé utilisable, mais ce n'est pas notre souci pour l'instant. D'abord quelque chose qui fonctionne tout court, et ensuite seulement quelque chose qui fonctionne vite.
|
|
|
| by Olivier Guillion | |
|
| |
|
Sur certains systèmes il est possible de formater son disque dur sensible à la casse (ne me demandez pas pourquoi...), ce qui veut dire qu'un fichier nommé "AAAA" sera considéré comme différent d'un fichier nommé "aaaa". Il y a quelques mois, nous avions ajusté nos différents programmes pour les faire fonctionner dans ce cas précis.
Mais nous avions oublié les scripts...
Ceci est réparé, il a fallut tout de même rectifier une bonne quarantaine d'entre eux. |
|
|
| by Didier Guillion | |
|
| |
|
Depuis notre déménagement, l'an dernier, nous ne nous étions pas préoccupés de vider le grenier de nos anciens locaux.
Nous rangions là le stock de matières premières (CDs, archives, papier, ...), ainsi que les appareils mis au rebut, la documentation technique devenue plus ou moins inutile depuis l'avènement d'Internet, et toutes ces choses qu'on ne peut pas jeter mais dont on ne se sert quasiment plus.
Nous nous sommes, donc, depuis quelques jours, attelés à la lourde tâche de trier et de transporter tout ce fourbi, dont nous évaluons le poids à une bonne tonne (le papier, ça pèse !)
Quelques centaines de kilos de documentations et jaquettes de logiciels comme "La vie du Lac" (1989) , encore en liasses non déballées, sont partis directement au recyclage. Nous avons gardé seulement quelques exemplaires de chaque, par nostalgie.
Nos vieux ordinateurs ont été testés directement dans le grenier. Quelques vieux Macintosh ont démarré sans problème, tout juste un peu surpris de se réveiller en 2008 alors qu'ils avaient été éteints la dernière fois en 1998. Nous n'avons pas pu nous résoudre à jeter les machines qui fonctionnaient. Peut-être feront-elles un jour le bonheur d'un collectionneur?
Certains cartons sont en sursis. Donc, si vous habitez près de Toulouse, et que vous êtes intéressés par:
- La collection complète de la documentation officielle "Inside Macintosh" (une dizaine de volumes en anglais)
- Des boitiers de CD vides, neufs (boitiers CD cristal simple épaisseur, pas slim)
- Des disquettes 3"1/2 et 5"1/4 bulk, qualité dupliqueur, sans pochette ni boîte
- un scanner Agfa SCSI
- Des notices d'utilisation de "La Vie du Lac" 
contactez-nous, nous conviendrons alors d'un rendez-vous pour que vous puissiez passer le prendre. C'est gratuit, mais s'il vous plaît ne répondez que si vous êtes vraiment intéressé. Si c'est pour le jeter après, nous pouvons aussi bien le faire nous-même... 
|
|
|
| by Olivier Guillion | |
| |
|
Aujourd'hui, c'est Lundi, et comme tous les Lundi une bonne partie de la journée à été passée à traiter les mails en souffrance du week-end.
Mais sinon :
Ces derniers jours nous avons commencé à interconnecter le module d'extraction de caractères depuis l'image au module de reconnaissance. Comme ce sont pour l'instant deux projets séparés, les blobs sont sauvegardés comme des images BMP puis relus par le module d'OCR et le résultat est affiché.
Bon, il faut le dire, c'est en l'état plutôt moyen avec une reconnaissance à 80%, ce qui fait tout de même deux caractères erronés sur dix.
Mais on ne désespère pas, nous savions dès le départ que ce serait un projet de longue haleine.
|
|
|
| by Didier Guillion | |
|
| |
|
Dans la série "Le vendredi c'est presque le week-end alors plutôt que de poster des trucs sérieux parlons de choses qui nous plaisent", voici Chris Jordan un Américain de Seattle.
Ce photographe réalise ce que l'on peut appeler des "collages numériques" (ou alors ce sont de vrais collages et je n'ai pas tout compris)
En tout cas, c'est engagé, souvent drôle et c'est ici. |
|
|
| by Didier Guillion | |
|
| |
|
- Harmony : Correction d'un problème de défilement de la musique lorsque l'on demandait de jouer la sélection depuis le curseur.
- Melody Player : correction d'un problème d'affichage du curseur de position dans la musique sur les mesures multi-silences
- Harmony : Correction de la commande clavier de remise à zéro des palettes.
- Ajout de la commande Application.Palette.ResetAll() à MyrScript |
|
|
| by Didier Guillion | |
| |
|
Souvent, les scans des pages sont effectués avec une faible précision, ce qui peut poser problème au module de reconnaissance.
Avec peu de pixels, les caractères sont crénelés, présentant des arêtes aiguës, et certaines opérations graphiques (extraction de squelette ou de contour par exemple) peuvent être perturbées.
Aussi désirons-nous, lorsque le nombre de pixels est insuffisant, "zoomer" le caractère afin de reconstituer les courbes et les formes qui les composent. Evidemment, il ne s'agit pas simplement d'agrandir les pixels, cela ne supprimerait pas le crénelage.
Deux solutions sont utilisables.
La première, la plus simple, consiste à agrandir les pixels du caractère puis d'appliquer un effet de flou assez puissant. Les contours du caractère deviennent alors indéfinis. En jouant alors sur l'histogramme des valeurs de gris, on peut lui redonner une certaine netteté. Les courbes sont ainsi arrondies.
La seconde est d'utiliser un redimensionnement "bicubique". Il s'agit de considérer que chaque position intermédiaire entre les pixels suit une fonction mathématique (polynôme d'ordre 3) dépendante des pixels adjacents. La valeur des pixels intermédiaires passe donc d'une valeur de pixel à l'autre en suivant une courbe douce (spline).
Les deux méthodes donnent des résultats assez proches.
Par exemple, ici, à gauche le caractère brut, dont les pixels ont été simplement agrandis,. au milieu, le résultat de l'agrandissement par flou/histogramme, et à droite le résultat de l'agrandissement bicubique :
La méthode du milieu donne des formes plus rondes, mais au détriment des détails (base et jonction de la barre verticale du "P", haut de la barre du "d", etc) et a tendance à éroder les lignes fines, comme le haut du "e".
Nous avons donc conservé l'agrandissement bicubique (à droite). Il sera appliqué dès que le caractère à reconnaître est d'une taille inférieure à un seuil à déterminer. |
|
|
| by Olivier Guillion | |
| |
|
Aujourd'hui ;
- Amélioration de l'import NoteWorthy
- Correction d'un problème de copier/ajouter sur les pistes numériques
- Nouvelles valeurs MyrScript :Score.ChordGridFontName,Score.ChordGridFontFace,Score.ChordGridFontSize ,Score.ChordGridFontColor
- Robert à mis le doigt sur un problème très,très bas niveau d'affichage de texte qui a été corrigé. Il apparaissait, entre autre, lors de l'affichage des tempi avec des commandes. Merci à lui ! |
|
|
| by Didier Guillion | |
|
| |
|
Il nous est venu une astuce qui permettrait peut être d'améliorer la reconnaissance.
Maintenant, nous savons localiser les lignes sur la page et extraire des blobs sur celles ci. Il est très difficile de différencier par exemple un 'i' d'un 'l' surtout quand le point du 'i' est considéré comme un blob indépendant. Le seul critère dont nous disposons est la hauteur de la forme par rapport à la hauteur de la ligne de caractère. Par rapport à la ligne de base, il y a la partie au dessus appelée "ascent" et la partie en dessous appelée "descent". Par exemple, un 'p' ou un 'g' ont un descent, un 't' ou un 'l' un ascent plus prononcé. Un '(' a à la fois un ascent et un descent.
Nous avons commencé à implémenter des algorithmes de discrimination des caractères permettant de déterminer si le blob à un ascent, un descent, si c'est un accent associé à une lettre ou même un symbole de ponctuation, simplement en comparant l'aire de la forme à l'aire de la ligne.
A terme, nous espérons que cela permettra de mieux séparer les caractères en restreignant la recherche à un groupe de caractères possibles. |
|
|
| by Didier Guillion | |
|
| |
|
Ferry Halim est un vrai artiste. Un poète visuel. Mais aussi un informaticien talentueux. Alors, ce californien s'exprime en Flash depuis 8 ans.
Son graphisme est rondouillard, tendre, et délavé. Cela rappelle l'aquarelle.
Résultat : Plein de mignons petits jeux gratuits, que vous trouverez sur son site :
http://ferryhalim.com/orisinal/
Un de mes préféré, la petite fille qui attrape le reflet des étoiles sur la glace...
Incontournable. |
|
|
| by Didier Guillion | |
|
| |
|
Nous avons maintenant passé en revue la plupart des algorithmes de reconnaissance de caractères. Nous commençons à avoir une vision claire de ce qui peut fonctionner et des problèmes inhérents à chaque méthode.
Un bon taux de reconnaissance pourrait être effectué en écrivant un sous-programme spécifique pour chaque caractère, du genre : "s'il y a un demi-cercle en bas à gauche, et une grande ligne verticale à droite, c'est un 'd' ". Mais nous préférerions éviter ce genre de chose, car cela empêche une amélioration de l'algorithme par apprentissage. Pour que le résultat change, il faut modifier le programme...
Une autre méthode, l'une des plus anciennes, qui donne étonnamment de bons résultats, est la comparaison graphique des matrices de points. Mais cette méthode reconnaît mal les fontes ou les styles encore jamais rencontrés.
L'extraction de données caractéristiques du caractères (position des trous et des bosses, courbes, lignes, etc) permet d'atteindre d'assez bons taux avec seulement une poignée de données décrivant le caractère.
Nous essayons donc d'implémenter une méthode "mixte", combinant l'extraction de données caractéristiques et une reconnaissance de la matrice de points. Sachant que les deux méthodes, indépendamment, trouvent toujours le bon résultat dans les 5 premiers, la combinaison des deux devrait donc augmenter sensiblement le taux de reconnaissance.
La manière de combiner les deux n'a, d'après la documentation que nous avons pu trouver, jamais été mise en oeuvre jusqu'ici. Est-ce parce que cela ne fonctionne pas, ou parce que personne n'y a pensé avant ? Les tests de ces prochains jours nous permettront de le savoir. |
|
|
| by Olivier Guillion | |
|
| |
|
Un premier prototype, sous forme d'une boîte noire, à été fourni au commanditaire. L'équipe d'en face va l'alimenter avec des données diverses et vérifier les sorties. Si tout est correct nous leur fournirons alors les sources et tous les éléments pour le compiler de leur coté.
Une fois que ce sera fait, ce sera normalement terminé pour nous.
Sinon, le 20 ème concours s'est terminé cette semaine, le 21 ème est en route. Nous préparerons demain les archives pour les membres du jury. |
|
|
| by Didier Guillion | |
| |
|
Des corrections aujourd'hui, rien de bien grave mais tout de même un peu long :
- Correction d'un problème d'affichage des numéros de mesure.
- Correction d'un problème de copier coller de piste numerique
|
|
|
| by Didier Guillion | |
| |
|
Ces derniers jours, nous avons travaillé dur sur ce projet. Un premier prototype est en phase de test. Dès que cela nous semblera bon, nous le proposerons au commanditaire.
Depuis quelques années, c'est en fait assez rare que nous travaillons "sur commande". C'est assez ingrat car dans ce genre de projet, il n'y a pas de retour d'utilisateur.
On conçoit, on code, on livre, on est payé, on oublie.
La semaine dernière une personne nous a contacté car elle avait des problèmes d'installation sous Window Vista d'un logiciel appelé Cassiopée. Il nous a fallu réfléchir un bon moment avant de nous souvenir que c'était un de nos logiciels, développé pour le Cemagref dans les années 1990.
De même, qui se rappelle que nous avons porté le jeu RealmZ et Monkey Shine du Mac vers le PC en 1999 ? Certainement même plus nous...
Mais bon, même si rien ne vaut le contact avec une communauté d'utilisateur enthousiaste (et critique), GroundHog est suffisamment original pour que nous y passions un peu de temps.
Seulement, comme nous n'avons en main qu'un minimum d'informations, espérons que nous ne sommes pas à coté de la plaque...
|
|
|
| by Didier Guillion | |
| |
|
|
