HAL Id: hal-00869596
https://hal.archives-ouvertes.fr/hal-00869596
Submitted on 4 Oct 2013
HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
Un système interactif d’aide à la construction d’applications de traitement d’images
Valérie Ficet-Cauchard, Christine Porquet, Marinette Revenu, Régis Clouard
To cite this version:
Valérie Ficet-Cauchard, Christine Porquet, Marinette Revenu, Régis Clouard. Un système interactif
d’aide à la construction d’applications de traitement d’images. 16e Colloque GRETSI, 1997, Grenoble,
France. pp.949-952. �hal-00869596�
Un système interactif d’aide à la construction d’applications de traitement d’images
Valérie FICET-CAUCHARD, Christine PORQUET, Marinette REVENU, Régis CLOUARD
GREYC-ISMRA - 6 bd Maréchal Juin - F-14050 Caen cedex - tél: 02-31-45-27-21 - fax: 02-31-45-26-98 e-mail: [email protected]
R ÉSUMÉ
Dans le cadre de la mise au point d’applications de traitement d’images, nous proposons un système d’aide fondé sur la modélisation et l’explicitation de la démarche du traiteur d’images.
Les traitements à effectuer y sont représentés sous une forme compréhensible et modifiable par l’utilisateur (enchaînements d’opérateurs sous forme de plans), dans un souci de réutilisation de parties entières de traitement. L’organisation de ce système repose sur une modélisation naturelle des connaissances sous forme de Tâches, Méthodes et Outils. La construction et l’exécution des plans de traitement d’images s’effectuent via une interface graphique qui facilite l’expérimentation de diverses techniques sur une image.
A BSTRACT
In this paper, a system that can provide some assistance for developing of Image Processing (IP) applications is described. The idea is to represent and make explicit the thought processes of IP developers. Sequences of IP operators are represented as plans following a twofold motivation : one the one hand making plans easy to understand and modify, and on the other hand enabling to reuse whole parts of plans. The system’s organization hinges on a natural knowledge modelling based on Tasks, Methods and Tools.
Building and executing IP plans is done through a graphical interface desingned to ease the trying out various experiments of images.
Introduction
Le Traitement d’Image (TI) s’applique maintenant à des secteurs d’activité très variés (biomédical, géographique, industriel) et dans lesquels une multitude de problèmes peuvent être posés, chacun de ces problèmes ayant une solution particulière. Pour aider les experts en TI à mettre au point leurs applications, des bibliothèques d’opérateurs ont été développées dans différents laboratoires, parmi celles-ci on peut citer SIMPA [1], la bibliothèque de méthodes de traitement du signal et des images du GDR-PRC ISIS, ou PANDORE [2], la bibliothèque d’opérateurs de TI développée dans notre laboratoire. Se pose alors le problème de l’aide à l’utilisation de ces bibliothèques : deux familles de systèmes tentent d’y apporter une réponse. La première correspond aux outils de programmation graphique, tels que KHOROS [3] ou VISILOG [4], qui permettent à l’utilisateur de sélectionner et d’enchaîner des opérateurs. Dans ces systèmes, les opérateurs ou les regroupements d’opérateurs effectués par l’utilisateur sont vus comme des boites noires : il n’y a pas d’explication ni de modélisation du raisonnement de l’utilisateur et le travail doit être repris à zéro pour chaque nouvelle application. Il est donc difficile de réutiliser les éléments de solution construits lors d’une application précédente. La deuxième famille correspond aux systèmes de construction automatique d’application tels que les planificateurs automatiques OCAPI [5], BORG [6] et ExTI-SATI [7]. Dans ces systèmes, il n’y a pas ou peu d’interventions de l’utilisateur, hormis pour la formulation des objectifs, et les connaissances qui y sont explicitées et représentées le sont plus dans un souci d’opérationnalisation que pour la compréhension de l’utilisateur.
Le but de nos recherches est la mise au point d’un système d’aide à l’utilisateur qui permette, non seulement à ce dernier de créer ses enchaînements d’opérateurs sous forme de plans, mais aussi d’expliquer et de représenter son
raisonnement de façon à pouvoir réutiliser des parties de traitements qui ont été mises au point dans d’autres applications. Pour cela, nous lui proposons de modéliser ses plans à l’aide de tâches (buts ou sous-buts à atteindre), de méthodes (techniques pour atteindre un but) et d’outils (opérateurs réifiés), qui sont les principaux composants de l’architecture « TACHE - METHODE - OUTIL » ( TMO ) [8].
Spécifications
Le but de « l’Atelier d’Intégration de Connaissances en Traitement et Interprétation d’Images » de l’Équipe Image du GREYC est la création d’un environnement informatique qui facilite la construction de programmes de TI. Cet environnement doit constituer une aide pour l’expert en TI lors de l’élaboration d’une application comme lors de son exécution. Il doit donc comporter une base de plans pour le stockage des applications créées et des modules de contrôle pour gérer la création et l’exécution de ces plans. Il doit aussi offrir une modélisation des traitements qui favorise la réutilisation d’éléments de solution de n’importe quel niveau d’abstraction, car on veut pouvoir réutiliser des parties entières de traitement, par exemple un pré-traitement. Enfin, notre modèle doit permettre de représenter et de tester différentes méthodes pour satisfaire un but ou un sous-but.
La première fonctionnalité de notre système est la construction d’applications. L’expert en TI n’a plus à faire de programmation au sens classique : il programme au
« niveau connaissance » en utilisant des blocs prédéfinis.
Contrairement aux outils de programmation graphique
classiques, dans lesquels l’utilisateur doit obligatoirement
adopter une démarche ascendante lors de la construction de
son plan, dans notre système, il est possible de choisir entre
une démarche ascendante (par regroupement), descendante
(par décomposition de problème en sous-problèmes) ou
mixte. Contrairement aux systèmes de résolution
automatique, dans notre système, la modélisation de
plusieurs méthodes de résolution pour un même problème n’impose pas l’écriture immédiate de règles de choix entre ces méthodes.
La deuxième fonctionnalité est l’exécution d’une application préalablement mise au point à l’aide du système.
Pour cela, l’utilisateur doit déterminer le plan à exécuter en reconnaissant son problème dans une liste prédéfinie, ce qui ne l’oblige pas à définir entièrement son problème a priori comme c’est le cas dans les systèmes de résolution automatique. Si des choix doivent être faits entre différentes techniques pendant l’exécution, les critères pour effectuer ces choix ne seront demandés qu’au moment nécessaire.
La possibilité de tester plusieurs de ces techniques pour comparer leurs résultats, de visualiser des images intermédiaires comme dans VSDE [9] ou dans CONNY [10]
et d’accéder à la représentation graphique d’un plan font de notre système un outil d'expérimentation pour l'expert en TI.
Par ailleurs, le système possède une interface graphique qui permet de visualiser le plan sous forme d’arbre de tâches pendant l’exécution. Une tâche correspond à un but ou a un sous-but de l’application et l’interface graphique permet d’accéder aux informations concernant les tâches et les méthodes de résolution existantes.
Enfin, lorsqu’il a validé son application, l’expert en TI peut soit stocker son plan dans la bibliothèque de plans, soit générer du code C++ pour une exécution en routine.
Architecture du système
Notre système est un système à base de connaissance composé de trois niveaux. Le premier niveau est celui des connaissances du domaine qui contient des connaissances sur l'application en cours (pour donner un sens et un sujet à l’image), des connaissances en TI (qui permettent la détermination des stratégies à utiliser pour atteindre des buts) et des connaissances sur les opérateurs (qui permettent leur sélection, la détermination des valeurs de paramètres et la réalisation d’enchaînements syntaxiquement corrects). Le deuxième niveau est celui des connaissances de contrôle qui facilitent l’exploitation des connaissances du domaine. On peut séparer ces connaissances en deux catégories : les connaissances sur le contrôle du domaine (pour la gestion des plans de TI) et les connaissances sur le contrôle du système (affichage des opérations à effectuer, sélection des traitements accessibles à l’utilisateur, contrôle des enchaînements, ...). Le dernier niveau est celui des connaissances de métacontrôle qui définissent les règles de comportement du système, vis à vis de l’utilisateur: le contrôle sera différent suivant le type de l’utilisateur et suivant ses désirs (explicitation de la méthodologie ou non, ...).
Les trois niveaux de notre système sont représentés à l’aide de l'architecture « TACHE - METHODE - OUTIL » .
Une TACHE est la représentation d’un but ou d’un sous- but dans le système. Elle décrit un but à atteindre et rassemble les éléments nécessaires à l’atteinte de ce but : les données à traiter, les types de résultat à produire et les méthodes de résolution connues. Quand une tâche résout un problème général, elle se décompose en sous-tâches qui résolvent des problèmes plus élémentaires, ces sous-tâches
pouvant être décomposées à leur tour. Une tâche peut être accomplie de plusieurs manières, on lui associe donc une ou plusieurs méthodes (fig.1). Les tâches servent à représenter tous les buts du système, quel que soit leur niveau. Au niveau domaine, elles représentent un objectif de TI ou une sous-partie de celui-ci : « extraire les regroupements d'objets » est une tâche principale du domaine et « éliminer le fond d’image » en est une sous-tâche. Au niveau contrôle domaine, elles représentent les opérations que l’on veut effectuer sur les plans de traitement d’images : « exécuter un plan » et « sauvegarder un plan » sont des tâches de ce niveau, « instancier un plan » est une sous-tâche de
« exécuter un plan ». Au niveau contrôle système, elles représentent les opérations telles que « initialiser le système » et « gérer l’interface du système », qui sont des opérations de contrôle du bon déroulement des opérations.
Enfin au niveau métacontrôle, elles représentent des opérations de contrôle sur le contrôle, telles que « exécuter une tâche » ou « choisir une méthode ».
méthode1.3 méthode1.2
methode1.1
tâche1
ou ou
Fig.1 : une tâche associée à plusieurs méthodes Une METHODE spécifie comment une tâche peut être accomplie. Chaque méthode est associée à une seule tâche, mais une tâche peut être associée à plusieurs méthodes. Pour cela, on cherche à expliciter, pour chaque méthode, quand il est possible et réellement souhaitable de l’utiliser. Le corps de la méthode peut prendre deux formes (fig.2) : soit une décomposition en sous-tâches qui prend l’aspect d’un arbre
« ET - PUIS » (on parle alors de méthode complexe), soit l’appel à un code informatique par l’intermédiaire d’un outil (on parle alors de méthode terminale). L’ensemble des sous- tâches à exécuter pour exécuter une tâche est dépendant de la méthode choisie, ce sont donc les méthodes qui gèrent les flux de données entre tâche et sous-tâches et entre tâche et outil.
tâche
outil méthode
tâche1
tâche1.3 tâche1.2
tâche1.1
et puis
