Rapport

Rapport de projet recherche ENSG Ingénieurs 2ième
année
Cédric Menut – Hugo Baltz – Maxime Siret 2015-2016 Page 1 sur 42
Rapport de Projet Recherche :
Etude des approches
d’agrégation multicritère
pour l’appariement de données
géoréférencées et d’images
Elèves : Commanditaires :
Cédric Menut Nathalie Abadie (COGIT)
Hugo Baltz Valérie Gouet-Brunet (MATIS)
Maxime Siret

année
Contexte
Dans le cadre de notre formation de deuxième année d’école d’ingénieur à l’ENSG,
nous avons effectué un projet dans les laboratoires de recherches de l’IGN. Ce projet a été
réalisé chaque mercredi dans les locaux du COGIT, entre le 07/10/2015 et le 03/02/2016.
Le projet auquel nous avons été confrontés se situe dans la continuité de travaux
antérieurs des laboratoires MATIS et COGIT sur l’appariement d’images et l’appariement de
données vecteur. L’objectif de ce projet était de comprendre et poursuivre une démarche
scientifique sur un sujet abordant des notions nouvelles, qui ne sont pas enseignées à
l’ENSG.

année
Introduction
De nos jours il existe plusieurs bases de données pour représenter le même thème.
C’est le cas des monuments historiques de France. Ils sont référencés par la base de données
DBpedia et Mérimée (par exemple).
DBpedia est une base de données issue de Wikipédia. Elle a été formée grâce aux
informations récupérées dans la « box » de Wikipédia (voir VI). Mérimée est quant à elle, la
base de données gouvernementale, contenant des prises de vues datant majoritairement du
début du XXe siècle, époque à laquelle la qualité était bien inférieure à celle que l’on trouve
aujourd’hui sur les appareils modernes.
Un des enjeux essentiel est donc d’apparier ces bases relatant du même thème.
Suivant le contexte, l’appariement permet de mettre à jour une base de données, quantifier
sa qualité ou intégrer des nouvelles données.
Pour ce faire, nous avons à notre disposition plusieurs critères d’appariement,
majoritairement sémantiques. Cependant, même si ces bases représentent le même thème,
leurs données peuvent être très hétérogènes.
De plus, une composante essentielle justifiant de la complexité de l’appariement
vient de la chronologie. En effet, les bâtiments de la base Mérimée ayant été photographiés
il y a une centaine d’années, le temps a posé son empreinte, et dégradé les bâtiments (pas
toujours restaurés). C’est pourquoi cette hétérogénéité induit une difficulté importante lors
de l’appariement de ces deux bases de données.
Comme expliqué précédemment, nous disposons de deux bases de données
contenant des monuments historiques de France, que nous avons réduit à l’agglomération
parisienne (les données sont suffisantes pour cette étude).
L’objectif général est d’apparier ces deux bases de la façon la plus efficace possible,
ce qui signifie qu’il faut prendre en compte les meilleurs critères qui permettront d’apparier
le maximum de monuments historiques communs aux deux bases, et ce, malgré les
disparités sémantiques (et les absences d’informations) présentes.
Initialement, pour effectuer ceci, l’appariement repose sur des critères exclusivement
sémantiques (nom du monument, adresse, nom de l’architecte…). Cette méthode permet
d’obtenir un résultat globalement satisfaisant, mais il reste encore des monuments non
appariés. C’est pourquoi il nous a été demandé de concentrer nos recherches sur l’ajout d’un
critère d’appariement basé sur les similarités entre deux images issues de deux bases
différentes.
Table des matières
I. Introduction ................................................................................Erreur ! Signet non défini.
II. Appariement multicritère ...................................................................................................6
1. Description ...................................................................................................................... 6
2. Résultats..................................................................................Erreur ! Signet non défini.

année
3. Améliorations possibles ..........................................................Erreur ! Signet non défini.
III. Appariement d’images..................................................................................................16
1. Description .................................................................................................................... 16
1.1 Descripteur SIFT.....................................................................................................16
1.2 Fonction de vote ....................................................................................................16
1.3 Automatisation des calculs .................................................................................... 18
2. Appariement avec la base Mérimée .............................................................................19
2.1 Utilisation de la fonction de vote sans prendre en compte le nombre de points
appariés............................................................................................................................ 19
2.2 Prise en compte du nombre de points appariés dans la fonction de vote............20
2.3 Prise en compte du nombre de points appariés dans la fonction de vote et
dégradation de l’image de référence après redimensionnement...................................23
2.4 Difficultés rencontrées avec la base Mérimée ...................................................... 24
3. Appariement avec la base Flickr.................................................................................... 25
3.1 Choix de Flickr ........................................................................................................26
3.2 Méthode de création de la base de données Flickr...............................................26
3.3 Résultats des tests d’appariement ........................................................................28
3.3.1 Résultats d’appariement intra-base avec l’Arc de Triomphe pour référence ...29
3.3.2 Résultats d’appariement intra-base avec l’Eglise Saint-Germain-des-prés pour
référence .......................................................................................................................... 32
IV. Appariements multicritère avec le critère d’image ......................................................... 32
1. Description des tests effectués..................................................................................... 33
V. Perspectives...................................................................................................................... 34
VI. Conclusion ........................................................................................................................ 34
VII. Annexes......................................................................................................................... 34
Table des illustrations
Figure 1 : Coordonnées des couples des points appariés avec l’image de référence et
distance entre les vecteurs de descriptions SIFT de chacun de ces couples. .......................... 17
Figure 2 : A gauche, le fichier .txt lisible, et à droite le fichier .txt destiné aux traitements...18
Figure 4 : Difficultés rencontrées avec Mérimée et choix d'une nouvelle base...................... 25
Figure 5 : Impression écran d'un fichier .xml avec la présence de la balise "<location>".......27

année
Figure 6 : Arc de Triomphe, image de référence pour le test intra-base. ............................... 29
Figure 7 ; Résultats du test intra-base pour différentes valeurs de seuil................................ 30
Figure 8 : Influence du score de critère d'image sur l'appariement multicritère.................... 31
Figure 9 : Eglise de Saint-Germain-des-prés, image de référence pour les tests intra-base...32

année
I. Appariement multicritere
1. Description
La notion d’agrégation multicritère est une notion courante et usuelle en web
sémantique : afin de pouvoir fusionner deux bases de données, il faut faire appel à des
méthodes d’appariement basées sur la sémantique et la géométrie des données mises en
jeu.
Dans un premier temps, nous allons détailler les méthodes utilisées lors d’un
appariement multicritère sans en prendre en compte notre nouveau critère d’appariement
d’images (voir le II.).
Comme évoqué dans le titre de cette partie, l’objectif est de trouver une méthode
permettant de faire correspondre à chaque donnée l’ensemble des données représentant la
même réalité physique. En utilisant les critères communs des données exploitées, on parlera
d’appariement multicritère.
Ainsi, l’appariement multicritère est une méthode permettant de calculer un score de
similarité entre deux données ayant des critères communs pouvant être très différents l’un
par rapport à l’autre.
On parlera d’appariement intra-base lorsque cette méthode s’appliquera sur
l’ensemble des données d’une unique ressource, à la différence de l’appariement multi-
base. Afin d’utiliser une méthode commune suivant les différents cas d’utilisation, il est
essentiel de choisir un format de données unique pour chaque ressource.
Dans notre cas, les trois ressources ont chacune un type de format différent. La base
DBpedia est au format RDF, Mérimée au format CSV et FlickR en XML. La plupart des outils
d’interconnexion de données s’appuie sur des données RDF, nous avons donc retenu ce
modèle de données. Le format RDF (Resource Description Framework) est le langage de base
du Web sémantique développé par le W3C.
Les données RDF sont représentées sous la forme d’un modèle de triplets suivant : (sujet,
prédicat,objet).
Exemples :
La fontaine de Diane est située à Paris
La fontaine de Diane a pour architecte Louis Desprez.

année
Intéressons-nous aux différents critères communs de nos ressources : de leurs
descriptions jusqu’à l’obtention d’un score associé à ce critère. En effet, du fait de leur
hétérogénéité, chaque critère possède des méthodes de similarité qui leurs sont propres. La
spécificité de nos ressources est d’associer des données structurées de type
alphanumériques avec des données images. Dans notre cas, les données de nos ressources
peuvent être visualisées comme ci-dessous :
A chaque description d’un monument historique on associe une image, un titre, une
géolocalisation et le nom de l’architecte. Il est à noter qu’un même monument peut
posséder plusieurs descriptions.
1.1 Données structurées
1.1.1 Critères textuels
Les critères textuels sont les titres et nom des architectes. Deux données de sources
différentes peuvent représenter la même réalité physique tout en étant très hétérogènes
l’une par rapport à l’autre.
Prenons le cas de l’église Saint-Eustache. Son appellation diffère d’une base à une autre :
DBpedia : Église Saint-Eustache de Paris
Flickr : Paris, Saint Eustache
Mérimée : Eglise Saint-Eustache

année
Afin de trouver le meilleur score de similarité, une des méthodes consiste à utiliser
une distance mathématique mesurant la similarité entre deux chaînes de caractères.
En première approche, l’utilisation de la distance de Levenshtein est conceptuellement
simple. Elle est fondée sur un algorithme qui affecte un poids égal à 1 dès que l’on substitue,
supprime ou ajoute un caractère pour passer d’une expression à une autre. Plus le poids est
faible et plus la similarité est grande. Cette distance présente cependant quelques
inconvénients. D’une part elle ne renvoie pas un score normalisé, d’autre part, elle est peu
efficace lorsqu’une expression est composée de plusieurs mots.
Une autre mesure de similarité classique de chaine de caractère est l’utilisation de la
distance et l’indice de Jaccard. Cet algorithme s’appuie sur la comparaison du rapport entre
les mots qui sont communs aux deux expressions et ceux qui l'appartiennent qu'à l'une des
deux. Une extension de cette distance est la distance de Jaro-Winkler utilisée
essentiellement dans la détection de doublons.
Enfin, une des distance de similarité les plus efficaces pour les chaînes de caractère
est la distance Token-Wise. Elle s’appuie sur les mêmes méthodes que les algorithmes
évoqués ci-dessus, à la différence près qu’elle travaille non plus sur un caractère seul mais
sur un ensemble de caractère appelé « jeton ». L’algorithme s’appuie donc sur l’affectation
d’un poids lors d’une substitution, d’une suppression ou d’un ajout de « jeton » dans une
expression.
1.1.2 Géolocalisation
L’ensemble des ressources étudiées possède un critère alphanumérique de type
adresse. Ce critère est relatif à chaque donnée. Les méthodes de distances de similarités
textuelles évoquées ci-dessus ont été utilisées pour géocoder l’ensemble des données. En
effet, ces méthodes ont été appliquées entre l’une des trois ressources et la base de
données BDTopo® propre au géocodage.
Ainsi, chaque donnée possède un critère structuré de géolocalisation de type
longitude, latitude. Pour obtenir un score de similarité relatif à la géolocalisation, nous
avons appliqué une distance euclidienne en prenant soin de respecter le type de projection
utilisée. Cette distance a ensuite été normalisée pour représenter le score de similarité.
1.2 Données images

année
Dans le cas d’images, nous avons généralement recours à des descripteurs de contenu
afin d’évaluer leur ressemblance. Ces descripteurs peuvent soit décrire globalement le
contenu de l’image (descripteurs de couleurs, textures et formes), soit plus localement (avec
des descripteurs de points d’intérêt notamment).
2. Type de fusion et formules d’appariement
Dans le cadre de ce projet, nous avions une certaine liberté concernant nos choix de
méthodes d’appariement. En effet, lorsqu’il s’agit d’appariement multicritère, nous devons
faire un choix : utiliser la méthode de fusion précoce ou la méthode de fusion tardive.
Afin de justifier le choix que nous avons fait, nous allons présenter dans cette partie les
deux méthodes avec leurs avantages et leurs inconvénients dans ce cas d’application précis.
Nous souhaitons aussi préciser que les descriptions exposées ci-après ont été inspirées de
lectures (état de l’art) de plusieurs publications scientifiques sur ce sujet, et mis à notre
disposition en début de projet.
2.1 Fusion précoce
Voici ci-dessous le principe général de fusion précoce expliqué par un schéma1
.
1
Schéma issu du document SnoekICM (2005).

année
Figure 1 : Principe général d'une fusion précoce pour un appariement multicritère.
 Tout d’abord, extraction des éléments unimodaux.
 Ensuite, fusion des données pour avoir une représentation multimodale, puis tri
grâce à l’apprentissage supervisé.
 Ne nécessite qu’une seule phase d’apprentissage contrairement à la fusion
tardive. Il est difficile de combiner les différents éléments de la base dans une
représentation commune.
Dans notre cas d’application, il faudrait donc obtenir un score de précision regroupant
les trois critères en même temps (et donc fusionner les trois critères). Ceci ne nous semblait
très difficilement réalisable, sans aucune garantie d’efficacité de résultat.
De plus, nous allons voir ci-dessous que l’autre méthode de fusion semblait beaucoup
plus adaptée à notre problème.
2.2 Fusion tardive
Voici ci-dessous le principe général de fusion tardive expliqué par un schéma2
.
2
Schéma issu du document SnoekICM (2005).

année
Figure 2 : Principe général d'une fusion tardive pour un appariement multicritère.
 Tout d’abord, extraction des éléments unimodaux.
 Ensuite, à la différence de la fusion précoce, nous ne combinons pas tout de suite les
éléments : nous effectuons des tests et calculs sémantiques directement sur les
éléments unimodaux.
 Puis nous les combinons, et nous effectuons à nouveau des tests et calculs
sémantiques sur les éléments agrégés.
 L’un des inconvénients de cette méthode réside dans son coût : à chaque étape,
un apprentissage est nécessaire. Ce qui peut être couteux. Aussi, il y a un risque
de perte de corrélation au niveau des éléments agrégés.
Comme nous pouvons le voir, cette méthode attribue d’abord un score pour chaque
critère, puis applique une fonction d’agrégation sur ces scores pour pouvoir obtenir un score
final d’appariement.
Puisque les critères que nous utilisons donnent tous individuellement un score
d’appariement, nous avons fait le choix d’utiliser cette méthode pour tous nos tests
d’appariement multicritère effectués lors de notre projet recherche.
Nous allons désormais étudier les formules d’appariement utilisées une fois les scores
des différents critères obtenus.

année
2.3 Formules d’appariement multicritère
A première vue et de façon simple, nous utiliserions la moyenne pour obtenir un score
global d’appariement. En effet, une fois les scores de chaque critère obtenus, il suffit de faire
la moyenne de ces scores. Cette méthode, bien que simple, peut se révéler suffisante et
efficace dans certains cas.
Cependant, nous avons remarqué que nous avions besoin de méthodes plus
sophistiquées pour pouvoir disposer d’une méthode d’appariement efficace.
Ceci s’explique notamment par le fait que certains critères sont plus prépondérants que
d’autres. En ce sens, la moyenne ne peut représenter une solution viable puisqu’elle
n’attribue pas de poids différents à chaque critère.
Ainsi, nous avons par la suite utilisé la moyenne pondérée. Cette moyenne permet de
donner plus d’importance à un critère qu’à un autre, selon un choix purement subjectif et
déterminé à partir des résultats expérimentaux sur plusieurs jeux de données.
Il existe aussi d’autres formules d’appariement multicritère (opérateurs de compromis3
)
que nous n’avons pas utilisés par manque de temps (et donc à poursuivre pour une future
étude de ce cas) :
 Le minimum et maximum pondérés
 La somme pondérée ordonnée (OWA) : le poids n’est pas sur les sources mais sur le
rang des quantités
 Diverses intégrales : d’une façon générale, on peut dire que les intégrales calculent la
valeur moyenne d’une fonction, et dans le cas discret, peuvent donc être vues
comme un opérateur d’agrégation du type moyenne (intégrale de Choquet stable
pour les changements d’échelle).
A COMPLETER
3. Résultats
Par manque de temps nous n’avons obtenu des résultats que sur les monuments du
8éme arrondissement de Paris entre les bases de données DBpedia et Flickr.
3
Les opérateurs présentés sont issus du document Grabish&Perny (2002).

année
3.1 Intra-base
Dans cette section, nous allons vous présenter les résultats d’appariement
multicritère en intra-base Flickr, c’est-à-dire que la base de données référence et la base de
données requête sont les mêmes : Flickr.
La base de données Flickr est composée de 89 photos de 20 monuments du 8éme
arrondissement de Paris dont 7 n’ayant qu’une occurrence (Voir annexe VI pour plus de
détails).
Nous effectuons des appariements 1:n c’est-à-dire qu’un monument référence peut être
apparié à plusieurs monument requêtes. Voici les différentes méthodes utilisées ainsi que
leur seuil qui est propre à la méthode utilisée, les poids des différents critères dans les
méthodes multicritère et le filtre final qui définit le score au-dessus duquel on apparie les
données:
- pour la distance sur la géolocalisation seule : 150 mètres pour la fonction de
confiance et 0 pour sélectionner les résultats finaux.
- pour les noms seuls (méthode TokenWiseDistance) : 0.7 pour la fonction de
confiance et 0.4 pour sélectionner les résultats finaux.
- pour les images seules: 0.8 pour la fonction de confiance et 0.45 pour sélectionner
les résultats finaux.
- pour la moyenne géolocalisation + noms : les mêmes paramètres pour les fonctions
de confiance et 0.3 pour le filtre final.
- pour le produit pondéré géolocalisation + noms (poids 0.5/0.5) : les mêmes
paramètres pour les fonctions de confiance et 0.3 pour le filtre final.
- pour le produit pondéré ordonné géolocalisation + noms (poids 0.5/0.5): les mêmes
paramètres pour les fonctions de confiance.
- pour le produit pondéré géolocalisation + noms + images (poids 0.3/0.3/0.4): les
mêmes paramètres pour les fonctions de confiance et 0.3 pour le filtre final.
- pour le produit pondéré ordonné géolocalisation + noms + images (poids
0.3/0.3/0.4): les mêmes paramètres pour les fonctions de confiance.
Après application de ces méthodes voici les résultats obtenus : (voir annexe pour le
détail)

année
Graphique 1 : Résultats des calculs sur le 8ième en intra-base Flickr
Nous remarquons que le cas où nous obtenons le plus de bons appariements est lorsque
nous ne conservons que le critère de distance géométrique (environ 319 images).
Cependant la méthode du produit entre les critères images, de nom et de distances
géométriques est la seule à posséder un pourcentage de bons appariements de 100% avec
un grand nombre d’images (environ 100). Néanmoins avec cette méthode nous perdons
quand même des bons appariements par rapport à des méthodes qui ont un pourcentage de
bons appariements de 95% et avec un plus grand nombre de bons appariements (environ
230). (voir schéma ci-dessus).
3.2 Inter-base
Dans cette section, nous allons vous présenter les résultats d’appariement
multicritère en inter-base Dbpedia-Flickr, c’est-à-dire que la base de données référence est
Dbpedia et la base de données requête est Flickr.

année
La base de données Dbpedia est composée de 28 monuments du 8éme
arrondissement de Paris dont 9 en commun avec la base de données Flickr (Voir annexe VI
pour plus de détails). Cela réduit déjà le nombre possible d’appariements.
Comme pour la partie les calculs intra-base Flickr nous effectuons des appariements
1:n. Les méthodes, poids et seuils sont les mêmes que pour la partie intra-base.
Graphique 2 : Résultats des calculs du 8ième en inter-base DBpedia - Flickr.
Comme pour le calcul intra-base, nous remarquons que le cas où nous obtenons le
plus de bons appariements est lorsque nous ne conservons que le critère de distance
géométrique (26 images). Les méthodes d’appariement multicritère de produit et de produit
ordonné n’appariet que peu d’images, elles ne sont donc pas satisfaisantes. Pour la méthode
de moyenne arithmétique dans le cas où nous ne conservons que les critères de nom et de
géométrie, nous avons 24 appariements dont 20 bons. Lorsque l’on ajoute à la moyenne le
critère image, on a 23 appariements dont 17 bons.
Ainsi dans notre cas le critère image nous fait perdre des bons appariements, cela
montre la limite de notre fonction de score (détail des résultats des calculs en annexe).

année
II. Appariement d’images
Nous allons à présent exposer les méthodes utilisées pour le calcul d’appariement de
bases de données par le critère d’image. Nous partons du principe que le lecteur connaît
déjà les principes généraux de l’appariement d’images (notion de descripteur
notamment).
1. Description
4. Descripteur SIFT
Dans le cadre de notre projet, il nous a été proposé d’utilisé le descripteur SIFT, car il
possède les avantages d’être bon dans la reconnaissance d’objets et d’être invariant à la
translation, au facteur d’échelle, à la rotation et aux petites distorsions. Cependant, son
inconvénient majeur est qu’il fonctionne mal (donne de mauvais résultats) lorsque que le
fond manque de texture ou qu’il y a du bruit (problème récurrent lors de l’appariement
d’images).
Nous avons donc voulu testé si, avec le descripteur SIFT, nous pouvions obtenir de bons
appariements d’images entre les bases DBpedia et Mérimée, malgré l’écart temporel entre
les différentes prises de vue.
Si temps : voir annexe ligne commande exe Arnaud
5. Fonction de vote
Nous avons donc en premier lieu extrait indépendamment les points d’intérêts à
l’aide de SIFT, puis nous avons effectué l’appariement des points d’intérêt et le calcul de
distance entre ces points à l’aide de l’algorithme utilisé par le logiciel MicMac. En sortie de
cet algorithme nous obtenons un fichier .txt contenant les coordonnées des couples des
points appariés avec l’image de référence, ainsi que la distance entre les vecteurs de
descriptions SIFT de chacun de ces couples.

année
Figure 3 : Coordonnées des couples des points appariés avec l’image de référence et distance entre les vecteurs de
descriptions SIFT de chacun de ces couples.
Pour obtenir un score à intégrer dans notre agrégation multicritère, il nous a donc
fallu calculer un score de ressemblance entre les images à l’aide des distances entre les
différents couples formés à l’étape précédente.
Pour implémenter cette fonction de vote nous nous sommes basés sur une publication de
Valérie Gouet-Brunet4
. Dans ses grandes lignes, la fonction de vote fonctionne ainsi :
1. Pour chaque point de la requête, nous allons calculer la distance entre ce
point et ses plus proches voisins.
2. On ne garde que le « meilleur voisin » pour la suite du calcul
3. La fonction de vote fVote est initialisée à zéro, et elle a pour formule :
𝑓𝑉𝑜𝑡𝑒(𝐼𝑘) = 𝑓𝑉𝑜𝑡𝑒(𝐼𝑘) + (1 −
𝑑𝑖, 𝑗
𝜀
)
Avec Ik l’image sur laquelle on effectue la requête, di,j la distance entre le point pi et
son « meilleur voisin » vj et 𝜀 la valeur de seuil qui indique à partir de quelle valeur deux
images ne sont plus similaires.
Pour normaliser le résultat nous le divisons par le nombre de couple appariés.
4
Calcul d’un vote simple par image pour la recherche par l’exemple par points d’intérêt
(12/08/2008)
X1 Y1
1
X2
1
Y2 D

année
Après plusieurs tests, nous nous sommes rendus compte qu’entre plusieurs couples
d’images, le nombre de couples appariés pouvait varier. Nous avons alors choisi de ne garder
dans notre fonction de vote que le nombre minimum de couples appariés sur l’ensemble des
images.
Par exemple, si nous possédons un jeu de 4 images et que l’image de référence
possède avec la première image 450 couples de points appariés, la secondes 800 et la
troisième 120, alors nous garderons dans le calcul de la fonction de vote entre l’image de
référence et chacun de ces images les 120 couples ayant la distance la plus petite et nous
normalisons en divisant le score par 120.
Notre fonction de vote prend donc en entrez le .txt obtenu en sorti de l’algorithme
d’appariement des points d’intérêt, le seuil sur la distance entre les couples de points
appariés au-delà duquel le couple n’est pas pris en compte dans le calcul, le nombre limite
de points qui correspond au minimum du nombre de couples appariés sur un ensemble
d’images.
Notre fonction affiche le résultat dans la console. De plus, elle stocke le résultat dans
deux fichiers textes, l’un lisible facilement par un être humain et l’autre utilisé dans les
traitements suivants (et donc simplifié, épuré).
Figure 4 : A gauche, le fichier .txt lisible, et à droite le fichier .txt destiné aux traitements
6. Automatisation des calculs
Pour gagner du temps, nous avons décidé d’implémenter des fonctions qui effectueront
nos calculs de façon plus automatique. Nous avons donc implémenté une fonction qui

année
applique à un ensemble d’images la fonction de calcul des points d’intérêt à l’aide du
descripteur SIFT.
Nous avons aussi implémenté une autre fonction qui va changer à chaque itération
d’image de référence, et qui va calculer le score de ressemblance entre l’image de référence
et le reste des autres images.
2. Appariement avec la base Mérimée
Comme évoqué en introduction, nous avons testé les algorithmes d’appariement
d’images sur des images issues de données Mérimée et DBPedia. Ces deux bases de données
étant très hétérogènes, nous avons commencé par utiliser ces algorithmes sur quelques
images sélectionnées manuellement.
Au préalable, nous avions déterminé l’image de référence dans la base DBPedia étant
donné que cette base possède des images de qualité supérieure. Les images requêtes
étaient uniquement issues de la base Mérimée et représentaient soit le même monument,
soit un monument différent. Ces tests ont été effectués dans le but de calibrer au mieux
notre fonction de vote, de connaître les paramètres discriminants et de vérifier la cohérence
des résultats obtenus sur un échantillon d’images.
Dans cette section, nous détaillerons uniquement les tests décrits en annexe. Ils nous ont
permis de conclure sur la qualité de notre fonction de vote ainsi que sur celle des images
utilisées.
Sur ces tests, nous avons utilisé notre fonction de vote de deux manières différentes : en
prenant en compte ou non le nombre de points appariés. Pour chacune de ces méthodes,
nous avons fait varier le seuil de 0,5 à 1,5. Il est à noter qu’à ce stade de notre projet, nous
travaillions plusieurs fois sur quelques images seulement. Ainsi, l’ensemble de ces résultats a
été généré sans aucune automatisation.
De plus, pour ces tests, l’image de référence est le château de Vincennes de la base
DBpedia. (je l’ai rajouté car ce n’était pas dit, et du coup on ne comprend pas les tableaux
exposés ensuite. C’est bien çà ?!!)
2.1 Utilisation de la fonction de vote sans prendre en compte
le nombre de points appariés

année
Voici ici présenté le tableau des résultats obtenus pour le premier test effectué sans
prendre en compte le nombre de points appariés.
TEST 1 Vincennes Mérimée Moret Mérimée
Seuil Nombre de points Score Score
0,5 ## 0,102778 0,124137
0,8 ## 0,147462 0,177913
1 ## 0,167865 0,176252
1,5 ## 0,26676 0,218765
Tableau 1 : Tableau des tests effectués sans prendre en compte le nombre de points appariés.
Graphique 3 : Graphe de visualisation des scores obtenus pour différents seuils sans prendre en compte le nombre de
points appariés
Analyse : Dans ce cas de figure, les résultats ne sont pas discriminants. L’image requête
correspondant à l’image de référence est correctement appariée seulement à partir d’un
seuil de 1.
2.2 Prise en compte du nombre de points appariés dans la
fonction de vote
0,5 19 0,165166 0,124137
0,5 0,8 1 1,5
0
0,1
0,2
0,3
0,4
0,5
Seuil
Score
Vincennes merimee
Moret merimee

année
0,8 153 0,345639 0,177913
1 409 0,396958 0,176252
1,5 2781 0,437692 0,218765
Analyse : On obtient une importante différence de score entre ces deux images. La prise en
compte du nombre de points appariés dans la fonction de vote semble pertinente.
TEST 2 Hôtel de
ville 1
Mérimée
Hôtel de ville
2 Mérimée
Hôtel de ville
3 Mérimée
Hôtel de ville
4 Mérimée
Seuil Nombre de
points
Score Score Score Score
0,5 24 0,203035 0,077813 0,141513 0,14996
0,8 244 0,304783 0,1964 0,252673 0,177689
1 643 0,3056 0,232707 0,237167 0,181989
1,5 1945 0,400194 0,363615 0,299973 0,307347
0,5 0,8 1 1,5
0
0,1
0,2
0,3
0,4
0,5
Seuil
Score
Vincennes
merimee
Moret merimee

année
Analyse : On remarque ici que pour deux images proches le résultat est cohérent.
TEST 3 Hôtel de ville 1
Mérimée
Hôtel de ville 2
Mérimée
Roger Mérimée
Seuil Nombre de
points
Score Score Score
1,5 1945 0,400194 0,363615 0,419777
0
0,05
0,1
0,15
0,2
0,25
0,3
0,35
0,4
0,45
0,5 0,8 1 1,5
Score
Seuil
Hotel de ville 1 merimee
0,33
0,34
0,35
0,36
0,37
0,38
0,39
0,4
0,41
0,42
0,43
Hotel de ville 1
merimee
Hotel de ville 2
merimee
Roger merimee
Score
Série1

année
Analyse : Ce test nous montre que pour deux photos de monuments différents ayant une
architecture proche, le score peut-être plus élevé que pour deux photos du même bâtiment.
Ce résultat est d’autant plus présent que le nombre d’image est grand. L’appariement
d’image semble dans ce cas de figure être limité par la nature des images elles-mêmes.
2.3 Prise en compte du nombre de points appariés dans la
fonction de vote et dégradation de l’image de référence
après redimensionnement.
0,5 9 0,097634 0,0840389
0,8 111 0,168597 0,154497
1 290 0,215615 0,173162
1,5 1848 0,236153 0,233474
Analyse : Ce résultat nous confirme le fait que la nature des images joue un rôle important
dans l’appariement. Les résultats sont d’autant plus satisfaisants que les paramètres des
images requêtes et de l’image de référence sont proches.
Les résultats évoqués ci-dessous nous ont permis de confirmer que notre fonction de
vote est plus satisfaisante lorsque nous prenons en compte le nombre de points appariés.
Cependant, après de nombreux tests, les résultats ne sont pas assez cohérents pour
0,5 0,8 1 1,5
0
0,1
0,2
0,3
0,4
0,5
Seuil
Score
Vincennes
merimee
Moret merimee

année
poursuivre avec les images Mérimée. Les écarts de résolution entre l’image de référence et
les images requêtes ont une influence trop importante sur l’appariement.
2.4 Difficultés rencontrées avec la base Mérimée
Lorsque nous avons commencé nos tests d’appariement d’images, nous nous
sommes portés sur la base de données Mérimée (décrite précédemment).
Cependant, cette base de données date du début du XXe siècle, et la qualité des
images s’en ressent. Afin d’être plus explicite, voici un exemple d’image présente dans la
base de données :
Mettre une photo dégueulasse de Mérimée.
Comme nous pouvons le remarquer, cette photo d’un monument parisien est en
mauvais état, et il est donc évident que l’appariement avec une photo de DBpedia sera très
compliqué, voire impossible.
De plus, ce phénomène n’est pas un cas isolé, nous avons rencontré un grand
nombre de fois ce souci, et nos résultats d’appariement furent donc faibles et insatisfaisants.
Nous pouvons ici observer une impression écran du viewer (fichier .exe permettant
de visualiser l’appariement des points d’intérêt entre les deux images des deux bases) :
Mettre une impression écran du viewer avec 1 photo de DBpedia, et 1 photo de Mérimée
dégueulasse.
Nous voyons donc bien ici les défauts d’appariement : l’image Mérimée de droite, de
par sa qualité, empêche un bon appariement avec l’image DBpedia de gauche.
Aussi, nous avons procédé à des tests intra-bases dans Mérimée, et là aussi, les
résultats n’ont pas été satisfaisants.
Après de nombreux tests, nous en avons déduit que nos résultats médiocres
n’étaient pas dus à une erreur dans le calcul de la fonction de vote ou d’utilisation du
descripteur, mais bien de la qualité de notre jeu de données en entrée.
La base Mérimée représentait donc un obstacle à notre objectif de pouvoir évaluer la
pertinence de l’ajout d’un critère d’appariement d’image dans un dispositif d’agrégation
multicritère.

année
Figure 5 : Difficultés rencontrées avec Mérimée et choix d'une nouvelle base.
Ainsi, nous envisageons pour la suite de créer notre propre jeu d’images en utilisant le
site communautaire Flickr.
3. Appariement avec la base Flickr

année
3.1 Choix de Flickr
Comme vu précédemment, les résultats obtenus avec la base de données Mérimée
ne sont pas satisfaisants. C’est pourquoi nous avons fait le choix de nous intéresser à une
autre base de données, de meilleure qualité afin de pouvoir obtenir de bons résultats
d’appariement.
Notre choix s’est donc porté sur le réseau social de partage de photographies Flickr.
Ce site internet propose à ses utilisateurs de partager leurs photos avec d’autres utilisateurs,
en pouvant y intégrer des descriptions et des tags sur les photos. Etant donné le succès de ce
site internet, un grand nombre d’images sont disponibles notamment pour les monuments
parisiens (notre base d’étude).
Les images que nous avons donc récupérées sont de meilleurs qualités que celles de
la base Mérimée, ceci car les photos Flickr datent de 2005 pour les plus anciennes (et donc
l’appareil photo utilisé est plus performant que ceux utilisés pour les photos Mérimée).
Désormais, nous allons présenter la méthode qui nous a permis de créer cette
nouvelle base de données, composée de 489 photos de monuments parisiens (récupérées
une par une sur Flickr), pris sous des angles et prises de vues différents.
3.2 Méthode de création de la base de données Flickr
Nous avons fait le choix de récupérer des images de monuments parisiens (triés dans
un premier temps par arrondissement) à partir des images dites « Creative Commons »,
c’est-à-dire une licence qui provient d’une organisation à but non lucratif proposant une
alternative au copyright complet. Ceci bien entendu pour des soucis de droits d’images.
Nous avions aussi d’autres impératifs concernant la récupération de ces images
Flickr, qui, provenant d’une source communautaire et libre, ne garantissent en aucun cas
une fiabilité semblable à celles de la base Mérimée.
En effet, les utilisateurs de Flickr disposent d’une grande liberté quant au choix de
description, de tags et de coordonnées géographiques de leurs photos. Ainsi, nous avons fait
le choix de ne récupérer que les images qui disposaient d’une information sur leur
localisation géographique (longitude et latitude).

année
De plus, au moment du téléchargement des images Flickr, nous avions la possibilité
de récupérer différents formats, mais nous avons téléchargé uniquement les formats (tailles)
originaux des photos (ceci afin de disposer de la meilleure qualité d’image possible).
Dans l’idéal, nous aurions souhaité disposer d’un minimum de deux à trois images par
monuments afin de procéder à des tests d’appariement intra-base (on prend une image de
référence sur la base Flickr, et on essaie de l’apparier aux autres images du même
monument de la même base). En réalité, il a parfois été difficile de garantir ce besoin car le
nombre d’images Creative Commons est bien inférieur au nombre total d’images disponibles
sur Flickr.
Balise <location> présente dans
le fichier XML de chaque image
de la base Flickr
Figure 6 : Impression écran d'un fichier .xml avec la présence de la balise "<location>"

année
De ce fait, nous disposons, parmi les 429 images de la base, de 74 monuments représentés
par une seule et unique image.
Une fois la base de données créée, nous avons redimensionné les images afin qu’elles
soient toutes au même format, c’est-à-dire 800 pixels de hauteur (la largeur est calculée à
partir de la hauteur imposée). Ce redimensionnement a été exécuté via la commande Linux
mogrify convert.
Capture d’écran ligne de commande mogrify Linux
Ce choix de redimensionnement s’explique par le fait que, lors des tests effectués
avec les images originales, de trop grands écarts de formats avec les images de la base
DBpedia rendaient les résultats d’appariement faussés et insatisfaisants. En imposant un
même format, nous nous sommes libérés de cette contrainte récurrente en domaine
communautaire.
Une fois ce travail effectué, nous avons pu procéder aux différents tests
d’appariement d’images.
3.3 Résultats des tests d’appariement
Dans un premier temps, afin de contrôler la qualité de nos images récupérées, et la
fiabilité de notre fonction de vote, nous avons effectué une série de tests d’appariements
intra-base.
En effet, nous avons choisi plusieurs monuments qui nous semblaient facilement
détectables et appariables, mais aussi comportant un nombre suffisant d’images comme
l’Arc de Triomphe (6 images présentes dans la base) ou l’église de Saint-Germain-des-prés (7
images présentes dans la base).
Initialement, nous avons commencé par apparier l’Arc de Triomphe avec un lot
d’images réduits de la base (32 images), ceci afin de limiter le temps de calcul des fonctions
d’appariement utilisées (et présentées auparavant). Cependant, la présentation de ces
résultats n’est pas d’un grand intérêt, c’est pourquoi nous allons vous présenter les résultats
d’appariement intra-base avec un grand lot d’images (190 images, car à ce moment précis
des calculs, nous n’avions pas encore récupéré la totalité des images Flickr).

année
Il faut aussi noter que nous avons effectué ces tests en utilisant différentes valeurs de
seuil (0.5, 0.8, 0.9, 1, 1.3, 1.6).
3.3.1 Résultats d’appariement intra-base avec l’Arc de Triomphe
pour référence
Pour ce test, nous avons pris comme image de référence l’image de l’Arc de
Triomphe suivante :
Figure 7 : Arc de Triomphe, image de référence pour le test intra-base.
Nous avons ensuite effectué toutes les manipulations nécessaires (et décrites
auparavant) au test d’appariement, et voici le résultat de l’appariement de cette image avec
les 190 autres images prises en compte, avec un seuil de 0.9 ici :

année
Figure 8 ; Résultats du test intra-base pour différentes valeurs de seuil.
Nous pouvons donc observer qu’il n’y a qu’une seule image (« arc de triomphe 2 »)
qui obtient un score élevé (0.73) et significatif par rapport aux autres images de la base (et
qui ne sont pas l’Arc de Triomphe).
Cependant, ce qui nous importe, ce n’est pas nécessairement d’avoir un score
significatif par rapport aux autres images, mais plutôt d’obtenir un score élevé, et une
présence dans le premier quart du classement d’appariement (critère subjectif).
En effet, les autres images ayant elles aussi obtenu un bon score ne seront pas
appariées à l’image de référence car les autres critères pris en compte lors de l’appariement
(critères sémantiques) auront donné des scores faibles pour ces photos.
Au contraire, les bonnes images de l’Arc de Triomphe qui auront obtenu le même score via
l’appariement d’images, seront finalement appariées car elles auront aussi obtenu un bon
score via les autres critères (du moins, nous l’espérons) !
C’est ce que nous pouvons voir sur le schéma explicatif suivant :

année
Figure 9 : Influence du score de critère d'image sur l'appariement multicritère
Ainsi, pour ce test, nous pouvons retenir que 3 images ont obtenu des bons scores
d’appariement (0.73, 0.54, 0.52).
En revanche, nous pouvons aussi en déduire pour ce test, que le critère d’image ne
peut pas être un critère majeur pour l’appariement, il ne peut intervenir qu’en tant que
complément de critère d’appariement, comme nous venons de l’expliquer.
Le seul cas où ce critère justifierait un appariement direct (sans consulter les résultats
d’appariement via les autres critères) serait d’obtenir un score d’appariement supérieur à
tous les autres scores (un résultat hautement significatif donc). Ceci est le cas pour la photo
« arc de triomphe 2 », qui obtient un score largement supérieur aux autres scores.
Réfléchir à une réponse plus scientifique que « largement supérieur »

année
3.3.2 Résultats d’appariement intra-base avec l’Eglise Saint-
Germain-des-prés pour référence
Pour ce test, nous avons pris comme image de référence l’image de l’Eglise Saint-
Germain-des-prés suivante :
Figure 10 : Eglise de Saint-Germain-des-prés, image de référence pour les tests intra-base.
A FINIR AVEC LES NOUVEAUX RESULTATS EXCEL
III. Appariements multicritere avec le
critere d’image

année
1. Description des tests effectués
Les méthodes d’appariement multicritère basées uniquement sur des critères
sémantiques et géométriques donnent des résultats satisfaisants (voir le II.Erreur ! Source
du renvoi introuvable.), mais par souci de perfectionnement, il nous a été demandé
d’évaluer la pertinence de l’ajout d’un critère d’appariement basé sur les images. Ainsi, nous
avons effectué des séries de tests d’appariement en prenant en compte plusieurs critères,
isolés et réunis.
Afin de mettre en œuvre ces méthodes, nous avons commencé par récupérer les
données de DBpedia en format rdf, format reconnaissable et utilisable par le WorkBench,
ceci afin de créer des « repositories ». Ces derniers comportent toutes les données relatives
aux monuments choisis, mais elles sont structurées de manière à pouvoir analyser et isoler
une caractéristique spéciale telle que le nom du monument, le nom de l’architecte,
l’adresse, etc…
Afin de pouvoir réaliser cet appariement, il a d’abord fallu géocoder les adresses
présentes dans la base DBpedia : grâce au WorkBench, et à la requête en langage SPARQL ci-
dessous, nous avons pu obtenir les coordonnées de localisation de nos monuments. Ces
coordonnées pourront être comparées à celles de Flickr pour l’appariement.
Impression écran d’une requête SPARQL de géocodage
Une fois ceci effectué, nous avons utilisé l’outil d’agrégation SILK qui, via son
interface, nous a permis de choisir les critères d’appariement que nous voulions utiliser pour
les tests, ainsi que les méthodes d’appariement.
Impression écran de SILK
En effet, comme nous pouvons le voir sur l’impression écran ci-dessus, nous pouvions
choisir les critères sur lesquels travailler (label – nom du monument -, location – localisation
-…), puis les méthodes d’appariement. Ces dernières sont très variées, et permettent un
grand nombre de tests différents (voir le II.1).
Nous nous sommes essentiellement concentrés sur les méthodes d’évaluation de
similarité sur les chaînes de caractères et de distance.
Concernant les méthodes de similarité de chaînes de caractères, nous avons
commencé par utiliser la méthode de Levenstein (expliquer la méthode), puis la Tokenwise
distance (expliquer la méthode).
Afin de pouvoir mieux visualiser les résultats d’appariement, nous avons utilisé une
interface créée par Nathalie Abadie avec OpenLayers en JavaScript (utilisation de Virtuoso).

année
Voici les résultats d’appariement en prenant en compte uniquement la levensein puis
la token-wise distance.
Impression écran des tests
IV. Perspectives
La majeure partie de notre projet s’est portée sur l’appariement d’images du fait de sa
complexité et de sa difficulté de mise en œuvre, c’est pourquoi les résultats sur les
appariements multicritère ne sont pas aussi conséquents et diversifiés que nous aurions
aimés qu’ils le soient.
V. Conclusion
VI. Annexes
1. Les protocoles
Protocole :
0. Vérifier que vous possédez l’ensemble de ces exécutables :
 ann_ppv_multiple_export_distances.exe
 fVote.exe
 siftpp_tgi.exe
 fAuto_key.exe
 fAuto_ann_ppv.exe
 fAuto_ann_ppv_seuil.exe
 min_ligne.exe
 fAuto_fct_de_vote.exe
1. Placer dans D:exes les exécutables suivants :

année
 fVote.exe
 siftpp_tgi.exe
2. Créer dans D : les dossiers de résultats :
 results_key
 results_ann_ppv
 results_ann_ppv_seuil
 results_vote
3. Lancer dans le dossier contenant vos images : fAuto_key.exe, il ne prend aucun
paramètre en entrée. Il crée les fichiers de points d’intérêts .key dans D:results_key
4. Lancer dans D:results_key fAuto_ann_ppv.exe qui prend en entrée le .key de
référence, penser à exporter les distances (répondre « o » à la question du calcul de
distance) qui seront utiles dans le calcul des scores par la fonction de vote. Les
résultats d’appariement en .txt seront créés dans D: results_ann_ppv
5. Lancer dans D:results_key fAuto_ann_ppv_seuil.exe qui prend en entrée le .key de
référence ainsi qu’un seuil. Les résultats d’appariement en .txt seront créés dans D:
results_ann_ppv_seuil. Cette étape est utile dans le calcul du plus petit nombre de
couples appariées.
6. Lancer dans D: results_ann_ppv_seuil : min_ligne.exe qui va calculer le nombre de
couples appariés le plus petit, noter le résultat il sera utile dans le calcul de la
fonction de vote.
7. Lancer dans D: results_ann_ppv : fAuto_fct_de_vote.exe qui prend en entrée le
seuil et le nombre de couples appariées le plus faible (résultat de l’étape
précédente). Il créer dans D: un fichier log.txt qui regroupe l’ensemble des calculs,
ainsi qu’ ‘un fichier _log.txt par image contenant le résultat de la fonction de score
entre l’image de référence et cette image. Dans D:results_vote
Protocole tout auto:
8. Vérifier que vous possédez l’ensemble de ces exécutables :
 fVote.exe
 siftpp_tgi.exe
 fAuto_key.exe
 fAuto_ann_ppv.exe
 fAuto_ann_ppv_seuil.exe
 min_ligne.exe

année
 fAuto_fct_de_vote.exe
9. Placer dans D:exes les exécutables suivants :
 fVote.exe
 siftpp_tgi.exe
 fAutoScore.exe
 fAuto_ann_dist.exe
10. Créer dans D : les dossiers de résultats :
 results_key
11. Lancer dans le dossier contenant vos images : fAuto_key.exe, il ne prend aucun
paramètre en entrée. Il crée les fichiers de points d’intérêts .key dans D:results_key
12. Lancer dans D:results_key fToutAuto.exe qui va calculer en prenant une par une les
images pour référence les scores de similarité avec chacune des images.

année
2. Description et visualisation des différents
tests appliqués entre les bases de données
Mérimée et DBPedia.

année
TEST 2
Image de référence
(Hôtel de Ville)
Image requête 3
(Hôtel de Ville 3)
Image requête 1
(Hôtel de Ville 1)
Image requête 2
(Hôtel de Ville 2)
Image requête 4
(Hôtel de Ville 4)

année
TEST 3
Image requête 3
(Hôtel Roger)
Image requête 1
(Hôtel de Ville 1)
Image requête 2
(Hôtel de Ville 2)
Image de référence
(Hôtel de Ville)

année
3. Description des bases Flickr et DBpedia
(8éme arrondissement) :
Flickr :
Nom du monument Nombre d'occurrence
Arc de triomphe 7
La Cathédrale Saint-Alexandre-
Nevsky
4
Hôtel Céramique 4
La Chapelle Expiatoire 1
La Madeleine 7
Eglise de Saint Augustin 6
Galerie de la Madeleine 3
Gare de Saint-Lazare 5
Le Grand Palais 8
Hôtel de Beauharnais 1
L'hôtel de Coislin 1
Hôtel de Crillon 1
Hôtel de Marigny 1
Hôtel de Beauvau 1
Hôtel de Beauvau 1
L'obélisque place de la Concorde 10
Le Palais de L'Élysée 2
Parc Monceau 14
Petit Palais 8
Le théâtre des Champs Elysées 4
Dbpedia :
Nom du monument Nombre d'occurrence
Arc de triomphe 1
La Cathédrale Saint-Alexandre-
Nevsky
1
Hôtel Céramic 1
La Chapelle Expiatoire 1
Gare de Saint-Lazare 1
Le Grand Palais 1
L'hôtel de Coislin 1
Le Palais de L'Élysée 1
Petit Palais 1
Chevaux de Marly 1
Hôtel Potocki 1
Hôtel Salomon de Rothschild 1
Lavatory Madeleine 1

année
Palais de la découverte 1
Église Saint-Philippe-du-Roule 1
Hôtel Landolfo-Carcano 1
Tombe du Soldat inconnu 1
Cathédrale américaine de Paris 1
Chapelle Notre-Dame-de-
Consolation
1
Au roi de la bière 1
Hôtel de Saint-Florentin 1
Hôtel de la Marine 1
Hôtel Cail 1
Hôtel Pillet-Will 1
Hôtel de Pourtalès 1
Hôtel Le Marois 1

année
4. Calculs multicritère
Intra-base Flickr 8eme arrondissement :
Type d'appariement Nombre
d'appariements
Nombre de bons
appariements
Pourcentage de bons
appariements
Distance géométrique 378 319 84%
Nom : Token-wise 163 160 98%
Image 245 52 21%
Moyenne nom-géométrique 245 230 94%
Produit nom-géométrique 145 143 99%
Produit ordonnée nom-
géométrique
3 3 100%
Produit nom-image-
géométrique
98 98 100%
Produit ordonnée nom-img-
géom
3 3 100%
Annexe calcul inter-base DBpedia-Flickr 8eme arrondissement:
Type d'appariement Nombre
d'appariements
Nombre de bons
appariements
Pourcentage
Distance géométrique 36 26 72%
Nom : Token-wise 14 10 71%
Image 81 6 7%
Moyenne nom-géométrique 24 20 83%
Produit nom-géométrique 9 9 100%
Produit ordonnée nom-
géométrique
7 7 100%
Moyenne nom-image-
géométrique
23 17 74%
Produit nom-image-géométrique 8 8 100%
Produit ordonnée nom-image-
géométrique
7 7 100%

Rapport

Recomendados

Recomendados

Más contenido relacionado

Similar a Rapport

Similar a Rapport (20)

Rapport