Par hasard, nous sommes tombés sur une information qui a affecté la vie de millions de gens, et était pourtant passée presque inaperçue.
Il y a quelques jours, une importante source de Spam a été localisée, et ses accès ont été coupés.
Cela n'aurait pas mérité la une des journaux si, à la suite de cette action, la quantité de spam émise dans le monde n'avait chuté de 30 à 50% !
En résumé, entre le tiers et la moitié du spam envoyé chaque jour dans le monde aurait été originaire de ce point précis de Californie.
Circonspects, nous avons alors regardé nos statistiques, et avons effectivement remarqué une baisse sensible (environ 35%) du nombre de spams que nous recevons, à partir du 12 novembre:
Ceci correspond bien à la date à laquelle le serveur Californien a été mis hors service.
La machine à pourriel n'est donc pas si multicéphale que ça. Bien sûr, les ordinateurs qui envoient physiquement les messages sont probablement des millions, la plupart le faisant à l'insu même de leur propriétaire. Mais il pourrait bien n'y avoir que quelques poignées de personnes à les contrôler.
Le répis ne sera que de courte durée, il ne faudra certainement pas beaucoup de temps pour que les malfaisants (probablement liés à la mafia russe) montent un nouveau serveur pour reprendre le contrôle de leur armée de PCs. En attendant, tous les serveurs de courrier du monde profitent d'un peu de répis...
Pour plus de renseignements sur cette affaire, voir ici, et, beaucoup plus détaillé mais assez technique et en anglais, là. |
|
|
| by Olivier Guillion |  |
| |
|
Nous avons commencé à coder le projet GroundHog. Lié par une clause de non divulgation, nous ne pouvons détailler ce que nous faisons. C'est dommage, mais tout à fait compréhensible. Disons que ce projet sera basé sur du recyclage de certaines de nos librairies, mais sur un support matériel original.
Pourquoi ce nom d'abord ?
Ben...
Comme c'est un projet qui devra rester caché jusqu'au Printemps, cela nous a semblé approprié ! |
|
|
| by Didier Guillion |  |
|
| |
|
Nous avons reçu hier un e-mail de notre hébergeur Web, qui nous avertissait que le serveur de myriad-online.com avait été surchargé à la mi-journée, sans que le volume de données téléchargées ne montre rien de particulier.
Pensant qu'il pouvait s'agir d'un bug dans un de nos script, il nous a donc prévenu, en nous conseillant de vérifier le journal des erreurs de notre serveur.
Nous nous sommes donc empressés de le faire, et rien de spécial n'a pu être mis en évidence. Intrigués (et un peu inquiétés) par ceci, nous nous sommes alors résolus à examiner le fichier-journal quotidien, qui garde trace de tous les accès ayant été faits sur le serveur depuis minuit une.
Nous étions en début d'après-midi et ce fichier faisait déjà un bon poids (43 Mo).
En examinant les données enregistrées aux alentours de 13 heures, nous avons alors remarqué un nombre anormalement élevé d'accès aux pages du forum.
Pendant à peu près 10 mn, entre 12h55 et 13h05, plusieurs personnes (avec différentes adresses IP) faisaient plusieurs dizaines d'accès au forum chaque seconde.
Etant donné qu'à chaque accès, le script du forum doit recréér dynamiquement la page devant apparaître sur le navigateur de l'utilisateur, cela expliquait la saturation du serveur au bout de quelques minutes.
Mais qui étaient ces personnes? Plusieurs internautes équipés d'un aspitateur de site? A moins qu'ils ne soient de mêche, leur arrivée était trop simultanée pour être un simple hasard. Les pages consultées également : ils alternaient tous une lecture de fil de discussion, la consultation d'un profil, et une tentative de réponse à un fil ou une création d'un nouveau fil. N'ayant pas passé le stade de l'enregistrement de leur pseudo et de l'image "captcha", ils n'avaient pas le droit de poster, donc le forum n'avait pas souffert.
Nous avons donc commencé à rechercher les adresses IP de ces internautes sur Google. Dès les trois premières, nous nous sommes rendus compte que, depuis ces adresses, du spam était couramment envoyé.
Nous supposons donc qu'il s'agit de PC "zombies" (dont un pirate peut prendre le contrôle à l'insu de son propriétaire) ou des relais proxy ouverts (serveur mal configuré dont les pirates se servent pour masquer leur adresse IP) utilisés simultanément pour mener une attaque au spam sur le forum.
L'attaque, un peu trop violente, a donc conduit à la saturation temporaire du serveur.
Dans ce genre de cas, nous avons malheureusement peu de solutions, mis à part désactiver momentanément le forum. Si ce genre de mésaventure se produit trop souvent, nous devrons mettre en place un système automatique qui, lors d'accès répétés trop rapides au forum, couoera purement et simplement le script du forum pendant quelques minutes afin de tout laisser refroidir en attendant que ça passe. 
|
|
|
| by Olivier Guillion | |
|
| |
|
Cela faisait un certain temps que je papillonnais sur le Forum de Discussion sans aller au plus profond des sujets. Il faut dire qu'il commence à y avoir des Lucky Luke de la réponse juste qui me donnent de plus en plus l'impression de mieux connaître nos logiciels que moi... J'ai donc pris quelques heures pour lire les fils en cours et essayer de donner quelques éclaircissements.
Sinon :
- Ajout d'une commande de configuration du plug-in permettant de ne plus afficher la barre verticale montrant la position dans la musique.
- Correction d'un problème de reconnaissance d'accroche dans PDFtoMusic
Et on travaille toujours sur la reconnaissance des caractères !
|
|
|
| by Didier Guillion | |
| |
|
Les extractions de formes élémentaires (lignes, arcs) du caractère scanné s'étant avérées suffisamment stables, nous avons commencé à implémenter un module de reconnaissance proprement dit.
Une série de caractères connus (16000 caractères issus de diverses fontes) est envoyée à l'extracteur, et les formes élémentaires ainsi obtenues sont stockées.
Une fois cet apprentissage terminé, une autre série de caractères, issus d'une page scannée cette fois, est envoyée au programme, qui, en les comparant à ce qu'il a stocké lors de l'apprentissage, essaie de déterminer de quels caractères il s'agit.
Premiers essais. Le programme n'est pas aveugle, mais un peu myope. Il commet des erreurs, mais donne généralement comme résultat un caractère assez proche (Q au lieu de O, c au lieu de e, etc.)
Il faut maintenant essayer d'améliorer tout cela. |
|
|
| by Olivier Guillion | |
| |
|
Rien de très palpitant aujourd'hui. Nous continuons à explorer les différents algorithmes de reconnaissance de caractère sans rien de concret à présenter ici.
Nous avons commencé à collecter des glyphes de caractères scannés afin de créer une base qui nous servira soit à l'apprentissage, soit à la validation du module.
Ah ! Si ! Le contrat pour le projet GroundHog est en passe d'être signé, il devrait aboutir mi 2009 et là nous pourrons enfin en parler.
Vous connaissez le tilt shift ? Quelques photos bluffantes sur ce site :
http://www.smashingmagazine.com/2008/11/16/beautiful-examples-of-tilt-sh ift-photography/ |
|
|
| by Didier Guillion | |
| |
|
L'extraction des caractères à bien progressé. Nous l'avons ajusté sur différents scans, plus ou moins "propres". Le module peut pécher par excès : découper un caractère unique en deux parce qu'il est parasité ou par défaut : ne pas reconnaître deux caractères comme séparés dans un même blob.
Mais, comme tous ceci est paramétrable le module sera vraisemblablement invoqué avec différents jeux de paramètres jusqu'à ce que tous les éléments du blob soient reconnus.
Nous espérons pouvoir connecter très bientôt l'extraction à la reconnaissance et voir comment cela réagit...
|
|
|
| by Didier Guillion | |
| |
|
Pendant qu'Olivier planche toujours sur la reconnaissance de caractères, j'ai attaqué l'autre bout de la chaîne : l'extraction des caractères.
Une première étape à permis de localiser les lignes de caractères puis d'isoler des ensembles de caractères dans ces lignes.
En effet, et en particulier lorsque les caractères sont en italiques, ils se chevauchent verticalement et on obtient ce que l'on appelle un "blob" : un ensemble de caractères comme celui-ci par exemple :
Nous avions en tête depuis le début un algo spécial qui pouvait éventuellement ce sortir de ce genre de cas. Et on obtient :
Mince! Ca marche !
On voit que l'accent du "e" à été extrait comme un caractère à part entière. C'est normal et nous nous y attendions. Il va falloir maintenant trouver un moyen logique de le rattacher au "e". Nous avons quelques idées, que nous essaierons demain... |
|
|
| by Didier Guillion | |
| |
|
Enfin ! Notre première application pour iPhone est disponible sur l'AppleStore. Démarrée et terminée en Août de cette année, il a fallu presque trois mois pour franchir toutes les barrières imposées par Apple. A l'ère où l'information circule à la vitesse de la lumière (voire même plus vite pour certaines rumeurs sur la santé de notre iPapy), c'est assez paradoxal...
Comme elle est maintenant publiée, nous pouvons donc en parler.
C'est un logiciel gratuit pour iPhone et iPod, qui assure une interface avec des dictionnaires de traduction sur le web. Plus précisément avec le site :
http://www.wordreference.com
L'application s'appelle également WordReference. Sur l' Apple Store elle est référencée sous le nom "WordReference.com Spanish-English Dictionary" mais en fait c'est uniquement parce que les dictionnaires accessibles au départ sont Anglais et Espagnol. Une simple configuration des boutons permet d'accéder aux dictionnaires Français.
Cela a été une expérience très intéressante.
Nous nous devons de le reconnaitre, les kits de développement d'Apple sont plutôt bien fait. Très en avance sur Android par exemple.
Elle ressemble à cela :
|
|
|
| by Didier Guillion | |
|
| |
|
Pour faire suite au dernier billet, nous avons amélioré la recherche de formes élémentaires dans les images scannées.
En plus des segments de droites, nous avons ajouté des arcs de cercle. Voici ce que cela donne avec les caractères pris en exemple la dernière fois.
A gauche, l'image originale du caractère scanné, au centre, les primitives graphiques qui en ont été extraites, dessinées en lignes fines, et à droite, les mêmes, dessinées en lignes épaisses:
Certaines lignes dépassent, car les calculs prennent en compte les bords extérieurs de la forme d'origine. Les formes extraites sont donc généralement trop longues d'une demi-épaisseur du tracé du caractère scanné. Ce sera ajusté, si besoin est.
Il nous reste maintenant à trouver une manière efficace de comparer ces données à un jeu de référence. Nous planchons toujours là-dessus.
|
|
|
| by Olivier Guillion | |
|
| |
|
Pour reconnaître un caractère, il faut pouvoir le comparer à un ou plusieurs caractères de référence, afin d'en déduire un niveau de similarité.
Mais quelles données comparer? La présence de pixels allumés ou éteints à tel ou tel endroit ? Cela est trop sensible à la fonte utilisé, la taille, le "bruit" dû aux imperfections du papier ou du scan...
Il faut donc fournir à l'algorithme de classification des données sur le caractère scanné à reconnaître, qui soient à la fois peu nombreuses, pour faciliter et accélérer les comparaisons, mais également qui décrivent bien la forme du caractère, pour que l'algorithme ait suffisamment de matériel pour discriminer.
Si l'extraction des caractéristiques de l'image du caractère scanné fournit des données qui, quelle que soit la manière dont on les représente, ne permettent pas à un observateur humain de savoir de quel caractère il s'agissait, il y a fort à parier qu'un algorithme ne le pourra pas non plus (ou mal).
Dans cette optique, nous avons essayé de "vectoriser" l'image, c'est-à-dire, à partir du dessin du caractère, trouver le nombre minimal de formes graphiques (droites, arcs de cercle, etc) qui permettent de redessiner ce caractère, et suffisantes pour qu'un observateur humain puisse déterminer de quel caractère il s'agissait.
Le travail est complexe, mais nous sommes arrivés à d'assez bon résultats. En voici quelques exemples, en utilisant seulement des lignes droites :
A gauche un petit "a" extrait d'un texte scanné.
A droite, l'image décomposée (vectorisée) par l'algorithme en seulement 5 lignes droites
Avec un peu d'imagination, on peut aisément reconnaitre le "a" dans le dessin de droite. Cela ressemble à un petit "a" tracé à la main par un allergique aux courbes 
Même chose avec un petit "d" (4 lignes) :
Un "M" donne ceci (5 lignes, dont une pour le serif à gauche):
et enfin un grand A, décomposé en seulement trois lignes:
Les premiers résultats sont donc encourageants, car il réduisent grandement la quantité d'information fournie à l'algorithme. Il faut maintenant vérifier la stabilité de l'extraction des vecteurs, puis trouver comment comparer deux jeux de vecteurs afin de reconnaître la lettre.
Il n'est cependant pas encore certain que ce type de traitement sera retenu dans la version finale. Nous avons jusqu'ici développé une vingtaine d'algorithmes différents, avec plus ou moins de succès. Nous en conserverons, au final, un maximum de 3 ou 4. Tous les autres finiront à la poubelle |
|
|
| by Olivier Guillion | |
| |
|
Aujourd'hui Daniel est venu nous faire une démo de la vielle à roue qu'il a lui même construite. Du grand Art !
Je ne résiste pas au plaisir de vous en montrer une petite photo :
Superbe non ? Et elle sonne vraiment bien. |
|
|
| by Didier Guillion | |
|
| |
|
Aujourd'hui :
- Amélioration de l'import Finale
- PDFtoMusic : amélioration de la gestion des appogiatures, correction de l'interprétation de certains types de portées batteries. Les appogiatures barrées sont localisées et exportées. Certaines partitions pour cornemuse, bourrées de ce type de symbole, sont maintenant traitées sans erreur.
- Correction de l'ajout de note sur la portée standard en mode tablature prioritaire
- Correction de l'ajout de note sur la tablature en mode tablature non prioritaire
|
|
|
| by Didier Guillion | |
| |
|
Toujours à la recherche de l'algorithme parfait de reconnaissance de caractère, l'intuition rejoint les conclusions de la documentation disponible à ce sujet : un tel algorithme n'existe pas.
Certains sont efficaces, d'autres un peu moins, mais les meilleurs résultats finaux sont produits par des programmes qui utilisent plusieurs algorithmes à la fois.
Chacun analyse le dessin du caractère avec ses propres méthodes, s'attache plus précisément à tels ou tels aspects, le compare avec des caractères de référence qui lui sont propres.
A la fin, les résultats de tous les algorithmes sont comparés, et l'issue finale de la reconnaissance de ce caractère est soumise au vote. Le gagnant est celui qui a été reconnu par le maximum d'algorithmes. Les taux globaux de reconnaissance sont, par ce principe, grandement améliorés.
De là à généraliser, et avancer que l'union et la démocratie sont préférables à l'individualisme et la dictature... |
|
|
| by Olivier Guillion | |
| |
|
- Les fichiers BMP tracés de haut en bas n'étaient pas gérés par Harmony. C'est corrigé.
- PDFtoMusic et Harmony : meilleur export des appogiatures en MusicXML.
Sinon, nous sommes en plein dans deux projets : l'application pour l'iPhone et le projet GroundHog, mais il nous est interdit d'en parler. Bientôt peut être... |
|
|
| by Didier Guillion | |
|
| |
|
Nous sommes maintenant capables de faire à peu près ce que nous voulons sur l'aspect du caractère : en extraire un squelette, détecter les trous et les bosses, les parties indépendantes au sein d'un même caractère (par exemple les point et la virgule d'un point-virgule, ou le "e" et son accent dans "é") et diverses données statistiques.
Il nous reste maintenant à choisir l'algorithme qui va déterminer la nature de ce caractère, par comparaison avec un jeu de référence (algorithme de discrimination).
Nous avons déjà exploré plusieurs possibilités, allant de la simple comparaison de matrice à un filtre bayesien, un réseau de neurones, la construction d'un arbre de décision, ou les modèles de Markov cachés (HMM)
Plusieurs de ces techniques s'avèrent efficaces, mais le résultat de l'apprentissage est difficile à vérifier à posteriori. On obtient une série de chiffres dont la signification n'est pas évidente pour l'observateur humain. En résumé, ça marche, mais c'est une boîte noire.
Or la pertinence des données que nous extrayons de la forme du caractère et qui servent à alimenter l'algorithme de discrimination est cruciale. Il faut fournir à cet algorithme les données permettant de différencier le mieux possible chacun des caractères. Si nous envoyons ces données vers une boîte noire, nous ne pouvons pas savoir quel paramètre mériterait d'être affiné ou remplacé par un autre pour de meilleurs résultats. On peut simplement essayer, et voir si le résultat s'améliore. Cela revient un peu à tirer des flèches les yeux bandés en essayant de s'approcher du centre de la cible.
Nous travaillons donc dans ce sens, en expérimentant et en recherchant de la documentation. Cela risque de prendre un peu de temps... |
|
|
| by Olivier Guillion | |
| |
|
Juste une petite histoire qui m'est arrivé et qui me confirme qu' Internet est une chose formidable.
En Juin dernier, nous avons observé un comportement assez étrange d'une bande de martinets qui égaie notre quartier.
Après quelques heures de recherche sur l'Internet, je n'ai pas trouvé de publications à ce sujet. Mais, je vois régulièrement apparaître sur Google le nom d'un chercheur travaillant au Muséum de Nîmes.
J'envoie donc l'email suivant au muséum en leur demandant d'avoir la gentillesse de faire suivre, sans trop y croire :
<<Bonjour,
Je me permet de vous contacter car je suis curieux de nature et je sais que vous avez travaillé sur le comportement des martinets.
En Juin dernier, j'ai été le témoin à plusieurs reprises de quelque chose que je n'avait jamais vu et peut être pourrez vous me l'expliquer.
Tous les jours ensoleillés entre 12h et 12h30, une bande d'une vingtaine de martinets s'amusaient à tourner autour de ma maison en criant. Rien que de très habituel.
Au bout de quelques minutes, il se sont mis a voler de plus en plus près d'une poutre (un corbeau) tout en hauteur et ont essayé de s'y poser alors qu'il n'y a que quelques centimetres entre la poutre et la toiture. Certains touchaient le toit, d'autres le mur, mais quand l'un d'entre eux y arrivait, il attendait qu'un de ces collègues viennent le déloger.
Apprenaient-ils aux jeunes de l'année comment réussir un atterrissage en hauteur ?
Merci de votre attention.
Cordialement>>
Le lendemain, le chercheur m'appelle au téléphone !
Et me donne un véritable cours sur le comportement du martinet noir (apparemment il est passionné ce Monsieur).
En fait, la deuxième année de leur vie, les martinets qui n'ont pas encore formé de couple, cherchent à s'introduire sur le territoire de leurs confrères pour y trouver un endroit pour nidifier et également se dégotter un conjoint. Ils garderons les deux toute leur vie.
Ces petits nouveaux participent aux sarabandes de leur aînés et tentent de poser les jalons d'un futur nid en s'appropriant un endroit élevé, plan et protégé de la pluie. Mais ceux qui occupent déjà le territoire les délogent manu militari !
C'est cela que nous avons eut la chance d' observer.
Si un couple arrive à s'établir, il restera une saison à défendre l'endroit, sans pondre. C'est l'année suivante qu'ils nidifierons réellement. Peut être aurons nous la chance d'avoir un nid de martinet sur notre façade...
A l'an prochain donc ! |
|
|
| by Didier Guillion | |
|
| |
|
La version 1.1.1 de PDFtoMusic est entrée doucement en chantier, alimentée par les remarques de nos utilisateurs.
Une bonne demi-journée à été passée sur un PDF récalcitrant : les textes y étaient tout mélangés. "Lord" s'écrivait "%(!G" par exemple.
Nous avons repris pas à pas le décodage des polices TrueType sans trouver d' irrégularité. En plus, la police était la bien connue "Times New Roman". Enfin, nous est venu l'idée de copier les textes depuis le visualiseur de PDF vers un éditeur de texte quelconque : même problème ! C'était donc la police embarquée qui était abîmée.
Pour pallier à ceci, toutes les polices texte peuvent maintenant être traitées par reconnaissance optique de caractère.
Un fichier PDF fourni présentait des appogiatures tracées avec un caractère par note (et non pas avec une tête, une ligne pour la tige et la hampe). PDFtoMusic a été modifié pour en autoriser le traitement. |
|
|
| by Didier Guillion | |
|
| |
|
Afin de simplifier les comparaisons de caractères , nous avons travaillé sur la squelettisation.
Ce procédé permet de transformer des formes pleines en "fil de fer". Grâce à cela, on pourrait s'affranchir des épaisseurs de caractères, pour ne conserver que les données constituant effectivement la forme.
A partir de notre texte d'exemple:
nous avons appliqué l'algorithme de Zang-Suen, assorti d'un amincissement maximal. Sur un squelette, on pourrait appeler ça une décalcification :
Un autre algorithme de squelettisation, morphologique, celui-là, suivi de la "décalcification", donne des résultats légèrement différents :
Certains détails sont mieux conservés, mais de petites barres matérialisent l'épaisseur d'origine du caractère à certains endroits.
Peut-être qu'avec un bon élagage de ces petites branches, nous pourrons nous en servir, en conjonction avec le squelette précédent.
Nous nous attaquons maintenant aux méthodes de discrimination, c'est-à-dire le coeur de la reconnaissance proprement dite. Cela risque d'être plus difficile de montrer les résultats ici, de manière graphique. |
|
|
| by Olivier Guillion | |
| |
|
|
