159 lines
8.9 KiB
Markdown
159 lines
8.9 KiB
Markdown
# Cahier des charges
|
|
|
|
## Description du besoin
|
|
|
|
Dans le cadre du projet long de 3ème année et en étroite collaboration avec
|
|
Bastien Durix dont la thèse porte sur le sujet de l'extraction de squelettes,
|
|
notre rôle est de fournir un pipeline complet allant partant d'un ensemble
|
|
d'images en entrée dont on segmente les contours. On extrait ensuite le
|
|
squelette. En parallèle, on apparie les points. Une fois ces deux premières
|
|
étapes faites, on cherche à habiller et enfin à animer le squelette ainsi
|
|
habillé en définissant des points de rotation.
|
|
|
|
Nous définissons ici un cahier des charges aussi précis que possible : dans un
|
|
premier temps, nous spécifions le besoin, puis nous dressons une liste
|
|
d'exigences.
|
|
|
|
## Livrables attendus et dates de livraison souhaitées
|
|
|
|
On s'appliquera à livrer une archive contenant :
|
|
- une documentation détaillée
|
|
- les codes sources : une partie calibrage et mise en correspondance dont la
|
|
date de livraison espérée est prévue pour le 6 février, puis une partie
|
|
habillage et animation dont la date de livraison est fixée au 13 mars
|
|
- une formation au C++ 11
|
|
|
|
## Fournitures du client
|
|
|
|
Le client s'engage à fournir les éléments suivants :
|
|
- les programmes réalisant l'extraction de squelette
|
|
- les formules mathématiques permettant l'habillage du squelette
|
|
- les références aux articles sur lesquels s'appuyer pour l'animation
|
|
|
|
## Contraintes techniques imposées
|
|
|
|
Les contraintes techniques sont les suivantes :
|
|
- le langage de programmation sera le C++
|
|
- il est suggéré de s'appuyer sur la librairie OpenCV
|
|
- l'utilitaire de compilation suggéré est CMake
|
|
- les librairies utilisées doivent toutes être portables entre Windows et
|
|
Linux
|
|
|
|
## Contraintes de gestion de projet et de suivi qualité
|
|
|
|
Les contraintes de gestion de projet sont les suivantes :
|
|
- la programmation sera effectuée par pair programming
|
|
- au moins une réunion par semaine sera effectuée avec le client
|
|
- une réunion par semaine est programmée chaque jeudi après-midi de 15h30 à
|
|
16h30 avec l'industrielle
|
|
|
|
## Organisation client
|
|
Les clients sont une équipe de chercheurs composée de :
|
|
- Bastien Durix, en thèse à l'IRIT
|
|
- Sylvie Chambon, maître de conférence à l'IRIT
|
|
- Géraldine Morin, maître de conférence à l'IRIT
|
|
|
|
Au moins une réunion par semaine sera effectuée avec le client, deux en début
|
|
de projet pour la rédaction du cahier des charges.
|
|
|
|
# Gestion des risques
|
|
|
|
## Tableau des risques
|
|
|
|
| Id | Description | Cause du risque | Proba(1-5) | Conséquence | Gravité(1-5) | Actions préventives | Actions correctives | Etat du risque |
|
|
| --- | --- | --- | :---: | --- | :---: | --- | --- | --- |
|
|
| 1 | Mauvaise estimation du temps | Sous-estimation de la difficulté du problème | 3 | Livraison en retard | 4 | Prendre de la marge sur le planning, nommer un responsable de l'avancement des différentes tâches | Augmenter la charge de travail, revoir le planning | Ouvert |
|
|
| 2 | L'autre groupe ne livre pas à temps | Sous-estimation de la difficulté de leur problème, augmentation de la charge de travail au dernier moment | 2 | Retard pour les tests de la partie mise en 3D du squelette | 3 | Envisager une autre méthode pour pouvoir tester sur des cas simples | Implémenter soi-même une méthode de segmentation plus simple se basant sur un simple seuil | Ouvert |
|
|
| 3 | L'autre groupe ne livre pas les bonnes sorties | Mauvaise compréhension des termes du sujet | 3 | Les tests ne fonctionneront pas correctement | 1 | Se mettre d'accord sur le format | Développement d'une fonction de transition | Ouvert |
|
|
| 4 | Les binaires fournis par le client ne sont pas compatibles | Complexité des systèmes | 2 | On ne peut pas continuer le pipeline | 3 | Discuter avec le client à propos du binaire fourni | Emuler le système permettant d'utiliser les binaires | Ouvert |
|
|
| 5 | L'entente au sein du groupe est fragile | Différentes habitudes de gestion de projet, de programmation | 1 | Tensions, ambiance accablante, stress intense | 5 | Nommer un responsable de la cohésion | Organiser une médiation entre les deux partis | Ouvert |
|
|
| 6 | L'entente avec l'autre groupe est périlleuse | Le découpage un peu bancal du projet pourrait amener des tensions | 2 | Difficultés à gérer les parties communes | 3 | Apporter une offrande en gage de bonne entente | Faire des compromis | Ouvert |
|
|
| 7 | L'un des membres est absent pendant une période donnée | Maladie, évènement | 5 | Absence d'une personne | 1 | Mettre en place des solutions de télétravail | Adaptation du planning | Ouvert |
|
|
| 8 | Production de code non fiable, non maintenable et non lisible | Manque de maîtrise des technologies utilisées | 4 | Pertes de temps, mauvaise qualité, devoir refaire des programmes | 3 | Formation au C++ par un expert technique | Appel de l'expert | Ouvert |
|
|
| 9 | Besoin d'accéder à une ressource supprimée de manière urgente | Utilisation d'une commande de suppression, crash du matériel | 2 | Pertes de temps, devoir refaire des programmes | 5 | Utiliser git | Utilisation de techniques de récupération de fichiers, longues et compliquées | Ouvert |
|
|
|
|
|
|
## Spécifications
|
|
|
|
### Partie appariement
|
|
|
|
- En entrée : $n$ images d'un même objet photographiées selon $n$ points de vue
|
|
différents sur un fond unis de même couleur (vert, rouge ou bleu) dont une
|
|
sera l'image de référence. Pour un même objet, les conditions de prises de
|
|
vue (éclairage, appareil photo, position de l'objet) doivent être les mêmes :
|
|
entre deux photos, l'objet ne doit pas bouger, c'est l'utilisateur qui se
|
|
déplace. Si le temps le permet, on pourra envisager de suspendre l'objet pour
|
|
les prises de vue. On définira une résolution minimale. Un marqueur (croix)
|
|
servant à calibrer par la suite la caméra sera visible sur le papier. On
|
|
définira précisément la façon dont ces marqueurs seront présents : un damier
|
|
risque de géner la segmentation. Des croix espacées régulièrement seraient
|
|
plus discrètes mais pourraient aussi géner. On se demande s'il serait
|
|
possible de n'afficher que 4 croix pour définir 4 coins.
|
|
|
|
- Traitement :
|
|
1. Appliquer SIFT sur chaque photo pour récupérer un ensemble de points
|
|
d'intérêt par photo. Les paramètres de l'algorithme SIFT seront à définir.
|
|
1. Définir les paramètres intrinsèques de la caméra sous la forme d'un fichier
|
|
au format xml (matK).
|
|
1. Définir les paramètres extrinsèques de la caméra à l'aide des marqueurs :
|
|
les détecter puis calculer l'homographie.
|
|
1. Appariement des points d'intérêt.
|
|
|
|
- En sortie : Des paires de correspondances de points d'intérêt entre l'image
|
|
de référence et une autre image.
|
|
|
|
### Partie habillage
|
|
|
|
- En entrée : un squelette 3D (B-Splines) et une fonction de rayon.
|
|
|
|
- Traitement : Utilise les surfaces canales.
|
|
|
|
- En sortie : Un maillage 3D (points et faces).
|
|
|
|
### Partie animation
|
|
|
|
- En entrée : le maillage 3D, les points d'articulations sur le squelette
|
|
et leur degré de liberté associé.
|
|
|
|
- Traitement: à élucider ?
|
|
|
|
- En sortie : l'affichage d'une animation.
|
|
|
|
### Définition des tâches
|
|
| | Détection des points d'intérêts | Appariement | Calibrage interne de la caméra | Calibrage externe de la caméra | Reconstruction 3D du squelette | Habillage | Animation |
|
|
| --- | --- | --- | --- | --- | --- | --- | --- |
|
|
| Conception | | | | | | | |
|
|
| Rédaction de la documentation | | | | | | | |
|
|
| Préparation des tests | | | | | | | |
|
|
| Implémentation | | | | | | | |
|
|
|
|
|
|
### Matrice de Rasci
|
|
| | Groupe 8 | Chef de projet | Service qualité | Equipe 1 | Equipe 2 | Client | Régine Nigris|
|
|
| --- | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
|
|
| Prise des photos | R | I | I | A-R | R | C | |
|
|
| Détection des points d'intérêts | | C | I | A-R | | C | |
|
|
| Appariement | | C | I | A-R | | C | |
|
|
| Calibrage interne de la caméra | | C | I | | A-R | C | |
|
|
| Calibrage externe de la caméra | | C | I | | A-R | C | |
|
|
| Reconstruction 3D du squelette | | C | I | R | A-R | C | |
|
|
| Habillage | | C | I | | | C | |
|
|
| Animation | | C | I | | | C | |
|
|
| Gestion de projet | | A | R | R | R | | C |
|
|
|
|
### Exigences
|
|
|
|
1. L'algorithme doit pouvoir évaluer les paramètres extrinsèques à partir des
|
|
marqueurs.
|
|
1. L'algorithme doit pouvoir évaluer les paramètres intrinsèques de la caméra.
|
|
|
|
### Rôles
|
|
|
|
Afin de réaliser le projet dans de bonnes conditions, nous avons choisis de développer notre prototype en travaillant par *pair-programming*, c'est à dire travailler en parallèle par groupe de deux. La cinquième personne serait quand à elle mobile et servirait de support aux deux groupes en cas de blocage sur un aspect technique. Le poste de *support technique* pourra éventuellement être tournant.
|
|
|
|
La répartition initiale des rôles est la suivante :
|
|
- Le chef de projet : Thomas Forgione
|
|
- Responsable qualité : Amandine Pailloux
|
|
- Expert algorithmique : Thierry Malon
|
|
- Gestion des ressources humaines : Marion Lenfant
|