Projet Orion

Précédent : Logiciels Remonter : Projet ORION, Environnements de résolution Suivant : Actions industrielles

Résultats nouveaux

Pilotage de programmes

Participants : Monica Crubézy , Frank van Harmelen, Mar Marcos , Sabine Moisan , Jean-Paul Rigault , Monique Thonnat , Régis Vincent

Résumé : Cette année nous avons plus particulièrement porté nos efforts sur la modélisation du pilotage de programmes pour spécifier des moteurs plus riches et pour définir des propriétés permettant des vérifications plus significatives par rapport à l'utilisation des connaissances. De plus nous avons continué le développement de la plate-forme LAMA notamment en réalisant un compilateur YAKL vers C++.

Modélisation du pilotage

Participants : Monica Crubézy , Frank van Harmelen, Mar Marcos , Sabine Moisan

Modélisation des connaissances pour le traitement d'images médicales

Un effort d'abstraction a permis de formaliser l'organisation générale usuelle d'un traitement d'images médicales. Tout d'abord une étape de préparation des données a pour but d'isoler la zone intéressante des données à traiter, grâce à des prétraitements si nécessaire, puis l'étape de traitement principal extrait les informations pertinentes des données. L'étape d'évaluation des résultats détermine leur adéquation vis-à-vis de la résolution du but et décide en conséquence si l'analyse est terminée ou doit être continuée sur le reste des données ou au contraire recommencée de façon modifiée. Enfin, l'étape de visualisation des résultats augmente la facilité des cliniciens à les interpréter. Cette organisation est essentiellement dirigée par les données, dont la richesse et le rôle peuvent être modélisés à leur tour, comme suit (cf. figure ) : les informations du monde réel déterminent les caractéristiques des données et du traitement, les informations d'acquisition et de contenu des données esquissent le plan global du traitement à accomplir. Les informations de présentation des données permettent d'adapter le plan aux conditions d'exécution et enfin les informations d'implantation servent lors de l'accès physique aux données.

Figure: Caractérisation de la richesse des données images. (Avec l'aimable autorisation de l'INSERM-U66.)

$\begin{figure}\centerline{\includegraphics [height=5cm]{Figures/mip-data.eps}}\end{figure}$

Nous avons répercuté cette modélisation sur la manière d'exprimer les connaissances de pilotage de nos deux applications de référence : le pilotage de l'AFSIM et celui de la segmentation du cerveau. Une capture d'écran de l'interface LIVE montre par exemple une sous-partie de la base de connaissances pour l'AFSIM (cf. figure ). Ce travail permet d'exploiter les connaissances d'utilisation des programmes de traitement d'images médicales à des fins de réutilisation logicielle et méthodologique. Notre souci est en effet de guider l'expert dans la construction de sa base de connaissances, en lui fournissant des structures proches des modèles qu'il utilise dans son domaine. De plus, cette modélisation étant indépendante des traitements particuliers utilisés pour l'analyse des images, elle fournit un cadre à la construction d'une base de connaissances de pilotage de programmes en distinguant différents niveaux de connaissances : générales (communes) au domaine (traitement d'images médicales) et spécifiques à la méthode utilisée (AFSIM, segmentation du cerveau). Cette distinction peut s'appliquer quels que soient les concepts de connaissances : buts, squelettes, règles, etc. et correspond éventuellement à différentes sources d'expertise (par exemple, méthodologique et clinique).

Nous travaillons également depuis peu sur une deuxième application de l'AFSIM, pour la caractérisation de la perfusion myocardique sur des séquences dynamiques PET/IRM, avec le CERMEP-CREATIS à l'hôpital neuro-cardiologique de Lyon. Cette expérience devrait nous permettre d'expérimenter l'ajout d'un niveau de connaissances supplémentaire : les connaissances spécifiques à l'utilisation particulière d'une méthode.

Modélisation des connaissances pour la vérification de systèmes de pilotage

Afin de pouvoir identifier les propriétés de la connaissance intéressantes pour la vérification, nous avons travaillé sur la modélisation des systèmes de pilotage de programmes. Ce travail s'est basé sur nos expériences, d'une part, avec OCAPI et PLANETE, et d'autre part, avec les moteurs plus récents PEGASE et PULSAR, ainsi que sur nos travaux en cours sur les besoins spécifiques des systèmes de pilotage dans le domaine du traitement d'images médicales (MedIA). La modélisation que nous avons réalisée couvre des aspects structurels (sur les éléments de connaissance et leur organisation) et fonctionnels (comportement du moteur) des systèmes de pilotage. De cette manière, elle peut être utilisée dans le but d'identifier non seulement les propriétés structurelles de la connaissance, mais aussi celles imposées par le fonctionnement du moteur. Dans la modélisation fonctionnelle, chaque sous-tâche du pilotage précise le rôle de la connaissance impliquée, en plus de sa description détaillée en sous-étapes et de son contrôle. Ces précisions peuvent introduire des prérequis supplémentaires pour son déroulement. Nous avons ainsi modélisé deux moteurs de pilotage (PEGASE et PULSAR) et identifié les sous-tâches dans lesquelles des variations sont possibles. Ces variations peuvent donner lieu à différents moteurs de pilotage. À partir des modèles précédents, nous avons dérivé les propriétés que les bases de connaissances écrites pour ces deux moteurs doivent vérifier. Nous avons classé ces propriétés selon différents critères : celles qui font référence à la structure ou au rôle de la connaissance, celles qui dépendent du moteur ou non, et celles qui sont obligatoires ou facultatives. Ces catégories sont générales, et elles vont nous permettre de concevoir des modules de vérification qui seront intégrés à la plate-forme LAMA. Pour un moteur donné, il sera ainsi possible de fournir un outil de vérification adapté à ce moteur à partir des modules nécessaires.

Moteurs de pilotage

Participants : Monica Crubézy , Mar Marcos , Sabine Moisan , Jean-Christophe Noel , Monique Thonnat , Régis Vincent

Améliorations du moteur PEGASE

Notre objectif est d'améliorer les systèmes à base de connaissances en pilotage pour les rendre plus robustes et plus fiables. Rendre plus fiables les SBC consiste à fournir un moyen d'exprimer la connaissance de réparation des experts. En effet peu de SBC proposent un moyen de réparation lorsqu'une erreur a été détectée. Notre approche consiste à fournir un système complet qui permette de détecter des erreurs, de les corriger et de modifier les bases de connaissances de manière automatique. Nous avons intégré dans le moteur P´EGASE un nouveau modèle de gestion des erreurs [8]. Nous avons aussi développé une application qui valide ce modèle de réparation sur un exemple réel [19]. Le modèle de récupération d'erreurs est basé sur cinq mécanismes :

un mécanisme d'évaluation ;
un mécanisme de transmission d'erreurs, basé sur trois fonctionnalités : send-operator, send-up, send-down ;
un mécanisme d'états, c'est-à-dire la possibilité de générer des états et de pouvoir revenir à un état précis ;
des fonctionnalités de réparation, basées sur deux fonctionnalités re-execute, back-choice ;
un moyen d'exprimer la connaissance de réparation connue de l'expert. Par exemple, cela peut être une base de règles spécifiques à la récupération d'erreurs.

Ces mécanismes pallient les limites du modèle d'OCAPI en matière de récupération d'erreurs.

OCAPI pour la simulation numérique

D'autre part nous avons étudié dans quelle mesure le modèle d'OCAPI était adapté au pilotage de codes de simulation numérique. Une base de connaissances a été développée avec le moteur OCAPI et une analyse critique (voir le rapport de J-C Noel [22]) a permis de juger de la pertinence de la planification basée sur une hiérarchie d'opérateurs et de l'intérêt de mécanismes perfectionnées de réparation. Par contre de nouveaux concepts sont nécessaires pour la description des données de simulation numérique ou la description des opérateurs (par exemple la notion de domaine de validité d'un code ou la notion d'itération sur un code).

Spécifications du moteur MedIA

Les spécificités du domaine du traitement d'images médicales nous ont amenés à spécifier le comportement d'un moteur adapté : MedIA (Medical Image processing Assistant). Étant donné la richesse des données manipulées par le traitement d'images médicales, MedIA doit prendre en compte la structuration de ces données à différentes étapes du raisonnement, selon le rôle de chaque type d'information. Le respect de la démarche complexe des experts en traitement d'images médicales nécessite que MedIA intègre deux types de raisonnement complémentaires pour la sélection et l'organisation des étapes de traitement à exécuter : planification à base de squelettes hiérarchiques et planification réactive. Ce travail se situe de plus dans la lignée des expériences d'Orion sur les moteurs PULSAR (planification basée sur les pré-conditions et effets des opérateurs [vdE96]) et PHENIX (planification non ordonnée). Partant d'une base de connaissances exprimée avec des squelettes d'opérateurs et des opérateurs isolés, MedIA commence par décomposer le traitement à effectuer en une suite d'étapes abstraites, sans précision des opérateurs primitifs à utiliser. Puis le moteur sélectionne et combine judicieusement les opérateurs de la base de connaissances pour chacune des étapes du plan abstrait, en se basant sur la description précise des données, des contraintes d'utilisation des opérateurs réels, etc. MedIA se base sur les fonctionnalités de PEGASE pour résoudre les squelettes de plan, auxquelles sont ajoutés des mécanismes pour la sélection dynamique d'un opérateur et l'adaptation de cette sélection aux conditions réelles d'exécution.

Plate-forme LAMA

Participants : Joël Cavarroc , Monica Crubézy , Patrick Itey , Mar Marcos , Sébastien Mathieu , Sabine Moisan , Jean-Paul Rigault , Régis Vincent

La bibliothèque de frames FRAMELIB

Dans le langage de description des connaissances YAKL utilisé par les experts, le contenu des bases de connaissances est décrit en utilisant des structures de données appelées frames. Une frame est une structure à trois niveaux : frame, slot (ou attribut) et facette, assez proche de la notion de classe utilisée dans les langages à objets. Dans le cas de YAKL, les attributs sont donnés par l'expert et leur nombre est fixé lors de la traduction dans le langage cible. La bibliothèque de frames FRAMELIB, développée pour LAMA dans le projet, définit des classes et des macro-commandes permettant de créer des classes C++ ayant un comportement de frame. Elle est écrite en C++ afin de permettre une plus grande portabilité et pour une meilleure efficacité. Elle peut être utilisée soit telle quelle par un programmeur C++, soit pour générer automatiquement le code à partir des spécifications YAKL, grâce à un traducteur. Les frames définies par l'expert seront des sous-classes de la classe principale de la bibliothèque :Frame qui définit les données et les fonctions membres communes à toutes les frames (par exemple, save(), restore()...). Quatre types de facettes sont utilisables : type, valeur par défaut, domaine de définition et un démon si_besoin. Nous avons aussi connecté FRAMELIB à des classes, utilisées par l'analyseur/traducteur de YAKL, qui permettent de manipuler des informations sur le type des données ou le nom des attributs à l'exécution. Grâce à ces informations, l'introspection pour les traces d'exécution et la mise au point des bases de connaissances est simplifiée.

Compilateur de YAKL vers C++

Afin de passer de la forme externe des spécifications YAKL à des structures informatiques utilisables par un moteur de SBC, il est nécessaire de les traduire dans un langage de programmation. Les langages cibles de YAKL sont soit Lisp, soit C++. La traduction en C++ produit du code utilisant les structures de FRAMELIB. Ceci implique la génération d'une très grande quantité de code, dont une grande partie est liée aux mécanismes de C++. Nous avons étudié les apports de l'utilisation d'un méta-protocole objet pour l'amélioration de cette traduction. Si la totalité du code C++ est générée directement par le traducteur de YAKL, la bibliothèque de frames est difficilement utilisable autrement qu'au travers du traducteur, sauf par un programmeur averti. De plus, cela implique une grande dépendance entre le traducteur et le langage YAKL. Or, YAKL est en continuelle évolution en fonction des demandes des experts. En utilisant un méta-protocole objet, chaque frame est une classe possédant une méta-classe qui contrôle son comportement. Parmi les différents méta protocoles existants pour C++, nous avons choisi Open C++ version 2 [Chi95] qui présente l'avantage essentiel d'être suffisamment général et de fournir les points d'accès qui nous sont nécessaires pour le problème de la génération de code : ajout de méthodes, de données membres aux classes, modification des corps de méthodes ou de constructeurs et extension de la syntaxe du langage C++ afin de faciliter la déclaration des facettes. Les phases de méta-conception (écriture des méta-classes et des fonctionnalités augmentées) et les phases d'utilisation du langage augmenté sont distinctes. L'utilisation de ce méta-protocole a permis de simplifier la traduction de YAKL en C++ en introduisant un langage intermédiaire entre YAKL et C++. La traduction de YAKL dans ce langage intermédiaire est quasiment immédiate et c'est le méta protocole objet qui se charge de générer le code C++ pur. Cette approche permet d'utiliser FRAMELIB de manière autonome, en étant assuré de la cohérence du fonctionnement des frames et simplifie le protocole d'utilisation de la bibliothèque. Les principaux problèmes posés dans la traduction des frames décrites en YAKL en classes C++ étaient la gestion de la persistance des instances de frames, la gestion des attributs et des facettes et l'introspection des frames pour la mise au point. Ces problèmes ont été résolus en définissant une méta-classe qui se charge de la gestion de ces trois points. La répartition des rôles entre le niveau C++ et le niveau méta a été étudiée ; nous avons choisi d'utiliser les mécanismes de C++ lorsqu'ils existent de manière à alléger le travail des méta-classes.

Notre utilisation d'un méta-protocole objet diffère des utilisations habituelles pour les applications réparties, le parallélisme ou les bases de données. Pour nous, le but était plutôt d'assurer l'indépendance la plus large possible entre YAKL et son traducteur d'une part, et FRAMELIB et ses mécanismes de génération de code et d'utilisation d'autre part. Les méta-protocoles pour les langages compilés sont encore à l'état de recherche. Le méta-protocole d'Open C++ évolue d'ailleurs en partie grâce aux contacts que nous avons avec son concepteur, Shigeru Chiba.

Communication avec les programmes

Nous avons enrichi la phase d'exécution du pilotage de programmes pour permettre une communication avec des programmes peu modulaires donc difficiles à piloter. Ce travail se rapproche des travaux sur les applications réparties et sur les systèmes multi-agents (cf. module ) : communication, passage de paramètres, synchronisation, récupération d'erreurs, terminaison. Le contrôle d'exécution peut être en outre compliqué par le caractère éventuellement multi-étapes des programmes (i.e. un programme correspond à plusieurs sous-étapes conceptuelles). Enfin, la gestion des interactions avec l'utilisateur doit être prise en compte par le contrôle d'exécution. Pour résoudre en partie ces problèmes, nous proposons un principe de relais (au sens de «proxy»), qui concentrent pour chaque étape conceptuelle terminale (i.e. opérateur primitif) les connaissances de contrôle associées.

Le relais d'un opérateur se charge donc de déclencher la partie de programme qui lui est associée et de réagir à son exécution en lui fournissant les informations de la base de faits du système de pilotage en temps voulu, en vérifiant son bon déroulement et en faisant appel à l'utilisateur s'il est concerné. A la fin d'une étape, le relais suspend le programme et en informe le moteur du système de pilotage. Toutes les connaissances intervenant dans ce contrôle d'exécution doivent être formalisées dans la base de connaissances de pilotage, au même titre que les connaissances de planification ou de réparation, par exemple. Nous proposons pour cela d'explorer le concept d'événement, qui offre l'avantage de correspondre à la fois à une façon naturelle d'exprimer des connaissances souvent non-ordonnées et à un concept informatique répandu.

Trace et mise au point de bases de connaissances

Lorsqu'un expert met au point un système à base de connaissances, il ne peut pas utiliser les outils de débogage et de trace des langages informatiques classiques car ils ne sont pas adaptés à ses besoins et au niveau d'abstraction auquel il s'exprime. L'expert décrit sa connaissance en utilisant le langage YAKL, qui lui permet de s'exprimer à un haut niveau d'abstraction. En phase d'exécution, lorsqu'une erreur se produit ou que l'expert veut tracer le raisonnement du système, il doit disposer d'outils à son niveau, qui masquent le plus possible les particularités du langage d'implantation. Un certain nombre de vérifications peuvent se faire statiquement sur une base de connaissances avant exécution (cf ). Mais, pendant le raisonnement, des fonctionnalités plus dynamiques sont nécessaires pour visualiser l'état du système à base de connaissances pendant son exécution (objets disponibles dans le contexte d'exécution courant, arguments d'opérateurs, etc.). Le mode débogage doit pouvoir être déclenché soit en lançant le système à base de connaissances, soit lors de l'exécution, par une demande de l'expert, après une erreur ou par un point d'arrêt, soit après l'exécution, pour suivre des traces d'exécution. Nous avons étudié des solutions envisageables aussi bien en Lisp qu'en C++ afin de pouvoir les intégrer dans la plate-forme LAMA. Un prototype de débogueur a été réalisé en C++, en utilisant FRAMELIB. Ce prototype a permis d'inventorier les parties actives du système où des erreurs peuvent se produire (choix de règles, lecture ou écriture d'une valeur d'attribut d'objet, exécution d'un démon ou d'une procédure externe,...) et de proposer des mécanismes de contrôle d'accès aux données, de gestion des appels externes et de mémorisation pour les traces. Quant aux points d'arrêt, ils peuvent se poser sur l'application d'une règle, la surveillance du changement de valeur d'un attribut d'objet ou d'une expression booléenne, le changement d'opérateur ou après l'exécution de règle(s). Les modifications dans la bibliothèque de LAMA, nécessaires pour les traces et la mise au point, ont été spécifiées et leur implantation en C++ est en cours.

Interface graphique

Nous avons développé un outil graphique optionnel pour LAMA nommé LIVE ((L)ama (I)nterface for (V)isualisation and (E)xecution), permettant de visualiser une base de connaissances décrite en langage YAKL sous forme d'une arborescence d'opérateurs (cf. figure ). Il est possible de consulter les opérateurs à différents niveaux de détail (données d'entrée et de sortie, paramètres, bases de règles), de suivre les différents flots des données (entre opérateurs frères, ou père - fils), d'afficher la base de connaissances selon certains critères de visibilité (compactage de sous-arbres, holophrastage par type de liens, par profondeur, zoom). LIVE donne aussi la possibilité d'avoir plusieurs vues différentes et indépendantes de la même base de connaissances. Comme beaucoup d'autres outils graphiques de visualisation, il offre aussi la possibilité de modifier interactivement toutes les ressources graphiques (couleurs, fontes, ajout de motifs graphiques, ...) de l'arbre visualisé, et de l'imprimer le cas échéant. Il tient à jour le nombre d'opérateurs, de bases de règles, et de liens par type de la base de connaissances visualisée.

Figure: Capture d'écran de l'interface LIVE sur la base de connaissances AFSIM.

$\begin{figure}\centerline{\includegraphics [width=13cm]{Figures/live-famis.eps}}\end{figure}$

Interprétation automatique d'images

Participants : François Brémond , Nicolas Chleq , Véronique Clément , Monique Thonnat

Résumé : Cette année, les axes dans lesquels nous avons particulièrement travaillé concernent, d'une part, l'interprétation de séquences d'images afin d'automatiser la compréhension des activités se déroulant dans une scène donnée et, d'autre part, la classification d'objets par l'intermédiaire d'une étude de faisabilité sur la reconnaissance des grains de pollens.

Interprétation de séquences d'images

Participants : François Brémond , Monique Thonnat

Mots-clés : interprétation de scène, reconnaissance de scénarios, analyse de comportements, suivi d'objets non rigides, gestion de l'incertitude, modélisation du contexte

Nous nous intéressons ici à l'interprétation dynamique de scènes à partir de séquences d'images et ce afin d'automatiser la compréhension des activités se déroulant dans une scène donnée. Le capteur utilisé est une caméra fixe et monoculaire, les scènes sont scènes d'intérieur ou d'extérieur et les objets mobiles sont principalement des êtres humains et des véhicules. L'objectif de nos travaux est, d'une part, la modélisation du processus d'interprétation de séquences d'images, et, d'autre part, la validation de ce modèle à travers le développement d'un système générique d'interprétation. Nous exposons ici nos contributions au processus d'interprétation de séquences temporelles d'image, qui ont été apportées au cours de la thèse de F. Brémond [7]. Ces contributions peuvent se regrouper en cinq points concernant le processus global d'interprétation et ses différents composants.

Modèle du processus d'interprétation : nous avons proposé un modèle composé de trois tâches principales : la détection des régions mobiles, le suivi des régions mobiles et la reconnaissance des scénarios. Ce modèle se caractérise également par l'utilisation systématique d'informations contextuelles, par la gestion de l'incertitude tout au long du traitement et par la coopération des tâches du processus d'interprétation.

Contexte : nous avons proposé un formalisme général permettant de définir et de délimiter les informations contextuelles [11]. Nous avons développé une représentation du contexte permettant son utilisation rationnelle et systématique. La réalisation de cette représentation a nécessité la définition d'une vingtaine d'attributs, afin de prendre en compte la diversité des éléments du contexte utilisés dans le cas du processus d'interprétation. Nous avons également développé un logiciel graphique (écrit en langage C et à l'aide de la boîte à outils MOTIF) permettant d'acquérir et de construire une base de contexte.

Suivi de régions mobiles : nous avons conçu un algorithme de suivi dont l'objectif est de suivre des objets mobiles à partir des régions correspondant à la perception de leurs mouvements [14]. Cet algorithme permet en particulier de suivre des objets non rigides tels que des individus. Il peut gérer différents types de problèmes (par exemple, des erreurs de détection et des occultations) et temporiser la résolution des ambiguïtés d'association entre des régions mobiles déjà suivies et des régions nouvellement détectées. Nous avons également implanté un module de suivi de régions mobiles (écrit en langage C++) correspondant à l'algorithme proposé.

Passage du numérique au symbolique : nous avons conçu un modèle de propriété caractérisant de manière symbolique un objet mobile à partir des mesures numériques effectuées sur les régions de l'image, correspondant à la perception des mouvements de l'objet. L'implantation de ce modèle a nécessité la définition d'une quinzaine de propriétés que nous avons organisées en réseaux. Nous avons également développé un modèle de méthodes de diagnostic abductif permettant de calculer et de mettre à jour l'incertitude de ces propriétés tout au long du processus d'interprétation. Ce réseau de propriétés a été intégré au module de reconnaissance de scénarios et a permis de le relier au module de suivi des régions mobiles [12].

Reconnaissance de scénarios : nous avons développé un formalisme permettant de décrire des scénarios relatifs à des activités humaines [10,13]. Nous avons également conçu un modèle de scénario afin de représenter des contraintes temporelles et atemporelles sur la perception des comportements des objets mobiles. La réalisation de ce modèle a nécessité le développement, d'une part, de méthodes permettant de reconnaître un scénario donné et, d'autre part, de méthodes évaluant l'incertitude de ces reconnaissances. En particulier, nous avons développé une méthode à base d'automates d'états finis permettant de reconnaître des scénarios temporels. Nous avons réalisé un module de reconnaissance de scénarios (écrit en langage C++) se conformant au modèle proposé.

Système d'interprétation : nous avons proposé une architecture d'un système d'interprétation correspondant au modèle proposé et vérifiant les spécifications nécessaires à la réalisation d'applications d'interprétation de séquences d'images. Nous avons ainsi développé un système complet d'interprétation (écrit en langages C et C++) intégrant les modules précédemment décrits. Ce système a pour objectifs d'être modulaire, générique et de permettre un traitement proche du temps réel. Il a été testé sur plusieurs séquences d'images de scènes de métro et de parking.

Nous avons testé notre système à l'aide des séquences d'images prises dans le cadre du projet européen Esprit Passwords. Deux séquences de scènes de métro, cinq de parking et une de supermarché ont servi ainsi d'exemple de test. Ces séquences comprennent entre 200 et 1200 images entrelacées, durant ainsi de 40 secondes à 4 minutes. Sur ces séquences nous détectons de un à quinze objets mobiles. La durée moyenne du suivi d'un objet mobile est d'une cinquantaine d'images, c'est-à-dire 12 secondes. Nous avons pu résoudre une dizaine de situations d'occultations statiques et dynamiques (partielles et totales).

Vidéosurveillance de scènes de métro

Participants : Nicolas Chleq , Monique Thonnat

Cette activité a lieu dans le cadre du projet européen AVS-PV qui a démarré le 28 avril 97. Les objectifs de ce projet sont d'étendre l'approche explorée dans le projet Passwords et de l'adapter à l'analyse de comportements dans des scènes prises à l'intérieur de stations de métro. Les comportements qui font l'objet d'étude dans ce projet sont les comportements de groupe et les comportements agités. Comme dans le cas de Passwords, la solution repose sur un enchainement de deux traitements distincts : les traitements d'images qui extraient les régions mobiles et certaines mesures sur celles-ci (programmes réalisés par l'équipe DIBE à l'université de Gènes), et les programmes d'analyse de comportement qui sont réalisés à l'INRIA. Les scènes de métro sur lesquelles le projet est axé sont en général caractérisées par deux phénomènes parasites qui rendent difficile l'analyse : d'une part, la caméra a une position assez basse ce qui produit beaucoup d'occultations dynamiques entre les personnes, d'autre part, les matériaux employés dans ces environnements provoquent de nombreuses réflexions sur le sol et les murs. Ce projet a commencé par une analyse détaillée d'un certain nombre de séquences réelles prises dans différents endroits d'Europe (Charleroi et Bruxelles en Belgique, Nuremberg en Allemagne), ainsi que des critères qui guident l'action et la décision des opérateurs de surveillance dans ces métros. Ensuite, une spécification du logiciel à réaliser a été écrite et les développements sont en cours. Pour les deux classes de comportements jugés intéressants par les utilisateurs et présumés réalisables avec un certain degré de fiabilité, la solution envisagée se base sur une architecture identique qui complémente les calculs faits par les modules de traitement d'images par des analyses mettant en jeu une connaissance minimale de l'environnement et des objets mobiles que l'on peut y trouver (essentiellement des personnes et des rames de métro).

L'analyse des comportements de groupes, c'est-à-dire une homogénéité de comportement entre plusieurs personnes présentes dans la scène se fait par complémentarité entre les traitements d'images et l'analyse des comportements : les programmes de traitement d'images et de suivi des régions mobiles identifient des motifs récurrents de séparation et de fusion au cours du temps entre les régions mobiles ; l'analyse de comportements extrait de ces motifs ceux qui correspondent réellement à des rapprochements et à des séparations de personnes (toutes les régions mobiles ne sont pas des personnes, et réciproquement, de même que beaucoup de rapprochements ne sont que des artefacts dus à des occultations dynamiques). Cette analyse permet d'identifier le noyau d'un groupe de personnes.

L'analyse des comportements agités se fait en intégrant au cours du temps les différences entre le mouvement global des personnes et les mouvements de leur sous-parties qui sont identifiables : ces sous-parties sont actuellement extraites comme des régions de couleur homogènes, ce qui est réaliste dans le cas de scènes dont l'éclairage est assez homogène et où les personnes présentes font preuve de variété dans l'habillement.

Actuellement une première phase de développement s'est achevée fin octobre et les modules réalisés par chacun des partenaires sont en cours d'intégration à l'INRIA.

Description d'images de pollens

Participants : Magali Mazière , Véronique Clément , Monique Thonnat

Mots-clés : reconnaissance d'objets complexes, traitement d'images, reconnaissance de formes, classification, environnement et santé

En collaboration avec le service de pneumologie du CHU de Nice et les analystes pallinologues du CEMBREU, nous avons abordé cette année le problème de la reconnaissance automatique de grains de pollens à partir d'images numérisées (cf module ). Nous nous sommes limités à l'étude des espèces de pollens anémophiles et allergisants présents sur la Côte d'Azur, ainsi qu'aux espèces qui leur sont proches morphologiquement ; les espèces morphologiquement proches nous permettent de mettre au point une méthodologie suffisamment robuste pour permettre son extension aux pollens d'autres territoires géographiques. Avec l'aide d'un analyste, nous avons numérisé 150 images de grains de pollens à l'hopital Pasteur de Nice (cf figures et ) à partir de lames de référence (ces lames ne contiennent que des grains de pollens d'une même espèce) et de lames de travail (celles-ci contiennent des grains de pollens de différentes espèces ainsi que d'autres particules présentes dans l'air).

Figure: Quelques exemples d'images de grains de pollens

$\begin{figure} \centering \includegraphics [width=3cm]{Figures/image45.crop.p... ... \centering \includegraphics [width=3cm]{Figures/image6.crop.ps}\end{figure}$

Figure: Plantain : Mise en évidence de différents pores selon le niveau de profondeur observé.

$\begin{figure} \centering\includegraphics [width=2.8cm]{Figures/plantain1.sub... ...\centering\includegraphics [width=2.8cm]{Figures/plantain3.sub.ps}\end{figure}$

À cause de la complexité des différentes formes de pollens, nous étudions une approche prenant en compte la connaissance des pallinologues. Nous avons donc, en dialogue avec eux, déterminé les caractéristiques visuelles utilisées pour reconnaître les différents types de pollens, sachant que le grain de pollen est identifiable par sa forme, ses dimensions, ses pores et l'architecture de sa surface.

Nous avons ensuite mis en oeuvre des algorithmes de traitement d'images dans le but de calculer automatiquement ces caractéristiques morphologiques. Nous calculons principalement : i) une liste de paramètres globaux, qui sont des mesures réalisées sur l'image du grain de pollen, ii) des courbes monodimensionnelles qui correspondent à des profils de distance ou de niveaux de gris selon les axes d'inertie, ou selon les coordonnées radiales. Les courbes radiales nous permettent par exemple de localiser les apertures que sont les pores et les sillons.

Ces traitements ont été testés sur 30 images, 16 provenant de lames de référence et 14 de lames de travail. Au vu des résultats sur ces images, cette étude de faisabilité [24] a permis aux analystes pallinologues de conclure sur l'intérêt de poursuivre cette approche qui permet de prendre en compte la connaissance en pallinologie ; en effet, les structures visibles sur les images (pores et sillons, par exemple) sur lesquelles s'appuie leur raisonnement ont pu être mises en évidence par le système de traitement d'images. Toutefois, les analystes s'appuient de façon importante sur la structure tridimensionnelle d'un grain de pollen afin de le reconnaître. Pour prendre en compte cette composante tridimensionnelle, nous projetons d'utiliser une plate-forme automatisée d'acquisition d'images permettant d'obtenir plusieurs coupes 2D d'un grain donné avec pilotage par ordinateur des différentes focalisations. Nous pourrons alors détecter, isoler et décrire chacune des sous-parties d'un grain de pollen à savoir le corps, les ballonnets, les pores et les sillons, informations sur lesquelles pourra s'appuyer un système de classification à base de connaissances.

Précédent : Logiciels Remonter : Projet ORION, Environnements de résolution Suivant : Actions industrielles