Dans cette section, nous allons estimer les temps de calculs néces-saires à l’acquisition des données, à la recherche d’images selon la mor-phologie (algorithme HD) et à la recherche d’un pattern identique en utilisant la machine parallèle.
Nous discuterons également du temps utilisé pour retourner la liste des images similaires qui, d’une manière générale, va dépendre de trois facteurs principaux: le type de machine utilisée chez le client, l’ordinateur
employé comme serveur et le réseau utilisé pour interconnecter le client avec le serveur.
Comme nous l’avons détaillé dans le chapitre 4, les images pro-viennent soit d’anciens documents, soit d’encyclopédies. Dans le premier cas, les documents doivent être analysés. Une lecture complète du docu-ment, sa traduction éventuelle, la détermination de son origine, etc., sont effectuées par un historien. Le temps de cette analyse dépend du docu-ment et nécessite suivant les cas jusqu’à une heure d’étude. Le temps es-timé de la digitalisation recto, verso et par transparence du document est d’environ deux minutes, auxquelles s’ajoutent deux minutes pour le trai-tement global de l’image acquise par transparence. Dans la seconde situa-tion, l’étape d’analyse des images de filigranes provenant de l’encyclopédie de Briquet est moins importante car celle-ci a déjà été ef-fectuée par son auteur. Dans ce cas, on peut estimer à environ quatre mi-nutes le temps d’acquisition de ces données, depuis le moment où on les digitalise jusqu’à ce que les images soient dans la base de données. Ce temps est décomposé ainsi: une minute pour la digitalisation, une minute pour la récupération de l’image et sa transformation dans le format KB-Vision, cinquante secondes pour effectuer les étapes de traitement d’image et finalement une minute pour introduire l’image dans notre base de données et retranscrire les informations fournies par Briquet.
Lors d’une requête morphologique avec l’algorithme HD, les opéra-tions pour analyser la requête ainsi que pour extraire les caractéristiques principales sont effectuées sur la machine du client. Le temps de calcul va
rang (r)
Figure 6.11 : Test de l’algorithme HD pour la robustesse à la rotation pour 5, 10, 15 et 20 degrés.
dépendre des dimensions x et y de l’image et est de l’ordre de O(xy). Par exemple, pour un tracé contenu dans un carré de 400 par 400 pixels (taille maximale admissible), l’algorithme, écrit en Java, prend environ 10 se-condes sur une station Sun Ultra Sparc 2.
En ce qui concerne les calculs effectués sur le serveur, ils consistent essentiellement à rechercher dans la base de données les images similaires par comparaison des vecteurs caractéristiques ou des histogrammes.
L’utilisation d’une base de données commerciale nous oblige à estimer le temps de calcul effectif. Pour une base contenant environ 4’000 images, le temps total de la recherche et donc de la comparaison entre les histo-grammes n’excède pas cinq secondes.
L’un des points les plus critiques de ce système est le réseau connec-tant le client et le serveur. En effet, si ce réseau possède une bande pas-sante limitée, le temps de transfert des informations devient important.
Dans notre application, le réseau est sollicité deux fois: lors du transfert de la requête vers le serveur (essentiellement transfert de la commande SQL ainsi que de l’histogramme caractéristique) puis lors du transfert du résultat contenant la liste des images vers le client. Dans le premier cas, on transfert au maximum une centaine de bytes de données: huit bytes pour l’histogrammes HD (seize pour l’histogramme HC) plus quelques informations annexes; on peut donc considérer ce temps de transfert comme étant insignifiant. Par contre, lors du retour des images retrouvées par le système, les données à transférer sont de taille beaucoup plus im-portante. Si le système retourne seize images, en considérant une taille moyenne de 5’000 bytes par image, et que l’utilisateur utilise un modem fonctionnant à 28’800 bit/s, alors le temps de transfert prendra un peu moins de 30 secondes. Dans notre cas, en travaillant sur une station Sun Sparc 4 reliée à notre serveur de calcul par l’intermédiaire du réseau de l’Université de Genève, l’algorithme de recherche d’images similaires se-lon la morphologie nécessite environ 30 secondes d’attente. Ce temps est calculé depuis le moment où la requête est acceptée, jusqu’au moment où les seize images sont affichées chez le client.
En ce qui concerne l’algorithme de recherche d’un pattern identique sur la machine parallèle SP2 (paragraphe 5-7), les temps de calcul ont été quantifiés de manière plus approfondie (figure 6.12) [81]. Le premier
gra-taille de 60 par 60 pixels en fonction du nombre de filigranes contenus dans la table de hashing (de 100 à 3000 filigranes), l’algorithme étant exé-cuté sur un seul processeur. Les temps de calcul varient de 7 à 10 minutes environ. La rapidité de la recherche dépend aussi de la taille du pattern.
La figure 6.12.b montre l’évolution du temps de calcul (de 6 à 13 minutes environ) en fonction du nombre de pixels significatifs que contient le pattern (de 10 à 500 pixels). La dernière courbe affiche les temps de calcul en fonction du nombre de processeurs utilisés (de 1 à 9 processeurs). En utilisant neuf processeurs, on arrive à effectuer la recherche en moins d’une minute.
Les algorithmes basés sur les caractéristiques globales des filigranes (paragraphe 5-5) étant relativement simples, ils ne nécessitent pas une étude détaillée de leurs complexités en temps de calcul. Néanmoins, la ra-pidité avec laquelle le moteur de recherche retourne les résultats nous per-met de conclure que, l’application peut être utilisée aisément avec un nombre bien plus élevé de données sans dégrader les performances de ma-nière significative. Dans ce sens, une base de données virtuelle simulant un nombre total de 70’000 filigranes à été construite dans le but d’évaluer les performances de notre système avec un nombre accru d’images. Les résultats ont montrés que les performances du système ne s’étaient pas dé-gradées de manière significative. En extrapolant ces résultats, on peut af-firmer que le but initial de gérer un ensemble de 600’000 images semble raisonnable. Le seul problème que nous avons rencontré est le manque d’espace disque mis actuellement à notre disposition pour gérer l’en-semble de toutes ces données.
Figure 6.12 : (a)Temps de calcul en secondes en fonction du nombre de filigranes dans la table de hashing (temps sur un seul processeur). (b) Temps de calcul en fonction de la taille du pattern de recherche. (c)Temps de calcul en fonction du nombre de processeurs utilisés pour un pattern donné.
6-8 Conclusion
Nous avons commencé ce chapitre par présenter l’approche utilisée pour déterminer un sous-ensemble d’images de test à partir de la base de données originale. Cette nouvelle base de données réduite à été créée de telle manière que chacune des classes possède exactement dix images qui soient visuellement similaires. Lors des tests, chacune des images a alors été prise comme modèle et les valeurs de precision, recall ont été éva-luées. Nous avons également cherché à déterminer si les algorithmes ba-sés sur l’histogramme circulaire et sur les filtres directionnels (HC et HD), utilisant la forme des filigranes étaient effectivement aptes à retrou-ver toutes les images de la même classe. Pour permettre ces comparaisons et pour chaque expérience, le nombre moyen d’images retournées parmi les P premières images à été calculé ainsi que le rang moyen le plus élevé pour les images appartenant à une même classe.
Les résultats obtenus impliquent que l’algorithme principal HD de re-cherche de filigranes est le plus performant, et est compatible avec l’uti-lisation souhaitée par le Musée du Papier à Bâle. La robustesse de l’algorithme aux changements d’échelle, au bruit, ainsi qu’aux variations d’orientation est suffisante pour résister aux distorsions observées en pra-tique dans les cas courants rencontrés par l’utilisateur.
Les différents essais pratiques effectués permettent d’affirmer que la recherche d’un filigrane spécifique est efficace. Comme nous l’avons vu plus précisément, la donnée recherchée est dans pratiquement tous les cas parmi les premières images retournées. Le temps de calculs reste accep-table non seulement pour notre base de données de 4’000 filigranes, mais également pour une base qui contiendrait 70’000 images (ou plus). Fina-lement, nous pouvons conclure que le système SWIC peut être utilisé de manière interactive et ceci grâce à l’utilisation de plusieurs procédés: pro-grammation favorisant la rapidité des calculs, utilisation d’une machine parallèle dans le cas de l’algorithme de recherche de pattern similaire, uti-lisation de structures adaptées aux données manipulées (B, arbres-R, tables de hashing), distribution des calculs (client/serveur) et sélection interactive de multiples algorithmes.