Le projet ayant été presque complètement implémenté à notre arrivé, il va y avoir beaucoup de corrections et d'améliorations.
L'ensemble des sources du projet n'ont pas été dévellopées par des informaticiens, mais par des chercheurs. De plus, plusieurs personnes se sont succédées sur les mêmes programmes, pour ajouter une fonctionnalité ou pour implémenter une nouvelle méthode, comme dans le programme de reconstruction ou trois méthodes cohabitent. C'est pourquoi nous n'avons pas récupérer les sources du projet dans l'état ou nous aurions souhaiter les trouvées:
La première tâche qui a été accomplie a été de créer une hiérarchie pour le projet, avec uniquement les programmes qui étaient encore utilisés (certains programmes comme la détection automatique des points lors de la calibration (sans intéraction) ou l'extraction des silhouettes à partir des images de la séquence ont été abandonnés, obsolète ou incomplet). La hiérarchie sera complétée par la suite.
Le répertoire des bibliothèques à été nettoyé et des modifications ont eu lieu:
Même avec les bibliothèques installées sur le système, on peut trouver des répertoires spécifiques à la machine.
Il faut signaler qu'à cause d'une mauvaise gestion de version, il y avait un programme qui ne compilait pas. L'exécutable fonctionnait lui très bien. Il y a donc des modifications qui ont été apportées et pas testées.
De plus, les répertoires ont étés renommés de telle sorte que l'on puisse retrouver facilement chaque programmes et connaitre l'enchainement des programmes.
repertoire enst/acohir : |-archives Les anciennes versions du projet. |-bin Les binaires de tous les programmes. |-doc La documentation du projet. |-lib Liens vers les binaires des bibliothèques. |-scripts Script de convertion. |-src Source des programmes. | |-doc Source du rapport (en Latex). | |-lib Répertoire des bibliothèques. | | |-bin Binaires. | | |-include Fichiers entêtes. | | |-other bibliothèques tiff, jpeg, Mesa et vips. | | |... Les sources des autres bibliothèques. | |-misc Makefiles standard et autre. | |... Les sources des programmes.
Nous ne pensions pas, au début du stage passer autant de temps sur la reprise des programmes existants, le projet étant commencé depuis longtemps et fonctionnant, les premiers objets reconstruits sont la pour en témoigner. Rapidement, nous sous sommes aperçus de l'ampleur de cette tâche et de son absolue nécessité.
Au début du stage, nous avons été faire l'acquisition au L.R.M.F. d'une statue. Notre premier travail sera de reconstruire cette statue en lui appliquant tous les programmes existants. A chaque nouveau programme, pour comprendre son fonctionnement et l'adapter à nos images, nous sommes rentrés dans le code car il était nécéssaire que nous connaissions le code pour pouvoir exécuter correctement les programmes.
Mais la principale raison pour laquelle nous sommes rentré dans le code, c'est que les programmes n'était absolument pas documentés et sans aucune aide pour savoir ce qu'il prennaient en entrée, ce qu'il généraient en sortie et même à quoi ils servaient.
Il était donc nécessaire pour nous de nettoyer le code des applications que nous ne pouvions reprendre (les programmes de calibration), de refaire les Makefiles pour éviter des problèmes de versions comme avec le programme find_tache (qui ne compilait pas), de refaire les entrées sorties et enfin de documenter. Pour le programme de reconstruction et les programmes de visualisation, nous devions développer dans ses programmes, c'est pourquoi nous les avons repris entièrement, nous permettant ainsi de gagner du temps et de corriger des erreurs.
L'ensemble des outils nécessaires aux calculs de calibration des images ont été dévelloppés et adaptés spécifiquement pour ce projet par un laboratoire de Clermont-Ferrand. Cet ensemble de fichier utilisés par les programmes de calibration a été considéré comme une boite noire, misant sur leur fiabilité avéré. De toute façon, il y avait trop de travail pour reprendre ces fichiers et nous n'avions pas les connaissances nécessaires pour. Nous avons donc travaillé sur le reste du code, à savoir les interfaces des trois programmes ainsi que les entrées sorties.
Pour chaque programme, nous avons commencé par mettre le code à la norme EPITA, afin de le rendre lisible 6. Evidement, il n'est pas possible de respecter la norme dans son ensemble, il s'agit juste de rendre le code lisible.
Tous les Makefiles ont été refaits pour éviter de nouvelles erreurs de gestion ainsi que pour faciliter l'utilisation des programmes et les adapter à la nouvelle hiérarchie de bibliothèque. Les entrées ont été refaites de manière à éviter de se prendre une erreur à l'execution si les paramètres ne sont pas corrects mais plutôt d'afficher un message d'aide, ainsi que pour ajouter des options facilitant l'utilisation des programmes.
Travaux spécifiques à chaques programmes et fonctionnement:
Description:
Programmes qui permettent de calculer les coordonnées des points (taches) de la mire de calibration.
Apport à l'existant:
Il s'agit du programme qui ne fonctionnait pas. Le code a été debuggé, il s'agissait d'un problème graphique, peut-être du au passage de linux vers solaris du projet. Le script shell permettant de le lancer a été réecrit, permettant d'utiliser find_tache ou find_tache_mod indifférement, de s'assurer que le fichier f_tache.info est bien présent et enfin que la compilation a été effectué (dans le cas inverse, la compilation sera faite avant de lancer le programme);
Une limite avait été arbitrairement fixée pour la taille des images, 520 lignes. Il n'était donc pas possible de travailler avec des images de 3008 lignes, elle a été supprimée
Le programnme a été entièrement documenté.
Cali est le programme qui permet de calculer les paramètres intrinsèques et extrinsèques de la caméra.
Ce programme avait deux gros problèmes, son interface qui ne fonctionnait pas et sa sortie:
L'interface graphique de cali est crée par une bibliothèque peu connue du nom de sx. Malheureusement, si elle marche très bien sous linux (mais nous n'avons pas fait de test), il n'en ai pas de même sous solaris. C'est ainsi que l'interface de cali ne permettait plus que... d'appuyer sur trois boutons:
Un quatrième bouton, le bouton reconstruction ne permettait que d'afficher (dans la fenêtre du terminal, pas sur l'interface graphique) l'arctangente de 360, ce qui ne sert pas à grand chose, il faut l'avouer.
Théoriquement, l'interface permet de suivre l'évolution des valeurs et dessine un ensemble de points qui permet de vérifier si le résultat est correct ou non. Ici, rien de tout cela ne fonctionnait.
L'interface a donc été corrigée, en modifiant le type des objets de la bibliothèque sx.
Une fenêtre de dessin permet normalement de visualiser le résultat de la calibration sous forme graphique. Malheureusement, aucun rafraichissement de la fenêtre n'ayant été implémenté, il suffisait qu'une fenêtre passe dessus ou que l'on change d'écran virtuel ou que la mise en veille se mette en route pour définitivement perdre ce résultat. Le bouton reconstruction, qui ne servait à rien, a donc été transformé en bouton redessine qui permet de retrouver le dessin généré par la calibration.
Le deuxième gros problème de cali était ses sorties:
Pour obtenir le résultat de cali, il fallait rediriger la sortie standard du programme, et parmis les centaine de kilo octets qui en sortaient, retrouver les valeurs et les formatter correctement pour les passer au programme suivant.
Le programme cali génère donc à présent directement un fichier exploitable par l'étape suivante de la calibration.
La ligne de commande, refaite, permet de préciser les noms des fichiers utilisés.
Un script à été écrit pour pouvoir utiliser cali plus facilement. Ce script génére trois fichiers, une copie du fichier d'entré de cali, pour toujours savoir quel paramêtres ont servis à éffectuer la calibration, un fichier qui est la redirection de la sortie standard et le fichier rot, qui doit passer à l'étape suivante. Ces trois fichiers sont nommés en fonction de la date pour qu'il n'y ai pas de confusion.
Rot_center est le programme qui, grâce aux résultats de cali, va calculer les matrices de rotation de chaque vue, ainsi que la distance à l'axe de rotation et l'axe lui-même.
Les principales modifications apportées à rot_center ont été les modifications des entrées sorties. Auparavant, on ne pouvait que lui indiquer quel était son fichier d'entrée (nb, celui qui vient de cali), maintenant on peut spécifier:
Des corrections ont également été apportées dans le code car à deux endroits différents, dans deux boucles, il y avait une itération de trop lors de l'écriture du fichier de résultat, utilisé par la reconstruction. Visiblement, cette dernière pouvait être éfféctuée qu'en modifiant le fichier à la main, mais ce n'était pas la méthode la plus ergonomique.
Enfin, le format de sortie de rot_center a été modifié car beaucoup de valeurs n'étaient pas utilisée par la reconstruction, elles étaient lues puis jetées. Maintenant, il y a dans ce fichier le strict nécéssaire.
Il y avait trois bibliothèques dans le projet:
Tous ces fichiers ont été produits par le laboratoire LASMEA (JM lavest). 7
L'ensemble des fichiers partagés a été isolé pour former une bibliothèque appelée libcali. Les autres fichiers ont été répartis dans les programmes qui les utilisaient.
La bibliothèque sx avait été laissée dans son état original, avec des programmes de démonstration, des documentations. Elle a donc été néttoyée. La bibliothèque freq en est issu et est utilisée par une des applications.
Dans le programme implicit, il y avait des fichiers qui concernaient la gestion d'image. Un ensemble de fichier en C et un autre en C++. Ces deux séries de fichiers ont été rassemblés en une bibliothèque, la libbitmap. Cette bibliothèque serat utilisée par tous les programmes nécessitant de manipuler des images. Cela permet de centraliser le traitement des images, de ne gérer qu'a un seul endroit le support des tiff ou des jpeg, ou encore le memory mapping. Grâce à cette bibliothèque, on peux très facilement ajouter un nouveau type d'image, ou un nouveau traitement qui sera accessible à tout les programmes.
Comme il a été précisé précédement, les bibliothèques tiff, jpeg et Mesa ont été installées en local dans les répertoires.
Une nouvelle bibliothèque a été ajoutée, libsil, qui sert à gérer le type sil, images binaires utilisées dans la reconstruction. Elle sera décrite plus loin.
Jusque la, les reconstructions qui avaient été faites étaient réalisées à partir d'images en basse résolution (640 par 480 par exemple) en comparaison avec les images recupérées du LRMF, en 3008 par 2040.
Si en théorie, le fait de travailler sur des petites images ou de grandes images ne change rien, il en est tout autre dans la pratique, un simple calcul permet de la constater:
Evidement, il fallait trouver une solution pour remédier à ce problème, qui ne soit pas d'augmenter la mémoire du serveur, d'autant plus que nous allions devoir en charger encore plus (près de 2Go) pour effectuer une double reconstruction, objectif important pour le projet, et lá, le serveur ne peut plus suivre (1,5 Go maximum).
La première chose qui a été intégrée, c'est le mapping memory. Cette technique permet d'accéder aux fichiers avec une vitesse incomparable par rapport au chargement classique. Le memory mapping ne résolvait pas pour autant la taille de mémoire utilisée.
C'est pour cette raison que le format sil a été devellopé. Il y a deux moments dans le programme de reconstruction ou on touche aux images, à la création de l'octree, c'est à dire du modèle 3D de l'objet et lors de l'affectation des couleurs à chaques particules de l'octree, lors d'une reconstruction par particule, ou l'affectation des textures à chaques faces générées dans le cas d'une génération de triangle.
Lors de la phase de construction du modèle, il n'est pas nécéssaire d'avoir les couleurs, il suffit de savoir si le point appartient oui ou non à la silhouette de l'objet. Il a donc été décidé d'utiliser les silhouettes à place des images de séquence. Auparavant, on se servait des silhouettes pour les extraire des images de séquence, en rendant le fond entièrement noir, ce qui pouvait provoquer des artefacts de construction car l'objet pouvait avoir des parties sombres qui se confondent avec le fond; en utilisant les silhouettes, ce problème a êté réglé. Mais il y avait toujours un problème, c'était que les silhouettes prennaient autant de place que les images, nous avons donc penser à utiliser un format 8 bits par pixel, toutefois ce n'était toujours pas suffisant car les besoins étaient vraiment trop importants.
Nous avons donc implémenter le format sil qui code un pixel sur 1 bits, divisant la taille de l'image à charger par 249.
Il existait certainement des formats d'image similaires, que nous aurions pu intégrer, mais pour l'usage qui en est fait, et pour intégrer plus facilement les méthodes utilisées dans la reconstruction pour atteindre un point, il a été plus facile et plus rapide de l'implémenter en intégralité. Evidement, ce format n'est pas visualisable, mais le gain de mémoire est plus important à nos yeux et des utilitaires de convertion ont été devellopés, permettant de visualiser facilement les images.
Lors de la deuxième phase de la reconstruction où on doit utiliser des images, la méthode a été légèrement modifiée pour que l'on sache, avant de charger les images, quelle particule a besoin de quelle images. Ainsi, on peut ne charger que peu d'images en même temps.
Il est difficile de faire une comparaison du gain de temps et de mémoire avec ces techniques car la reconstruction sur grandes images étaient tous simplement impossible auparavant.
Toutefois, une comparaison effectuée sur des petites images et avec l'ancienne méthode, par triangulation, montre un gain en temps de l'ordre de 30% et un gain de mémoire de l'ordre de 50%, cela étant réalisé en basse résolution.
De manière générale, la reconstruction consiste à définir une fonction volumétrique de l'objet considéré, et de générer des triangles avec celles-ci. Pour cela, l'espace est découpé en voxels, dont la résolution détermine la précision de la reconstruction. Le maillage est généré à partir de ces voxels et de la fonction volumétrique ainsi que d'une table associant une triangulation à chaque configuration. A cela s'ajoute des traitements d'élimination de faces dans le but d'alléger le maillage 3d.
A chaque triangle est associé une texture, l'ensemble étant stocké sous forme d'un patchwork dans un fichier. Pour générer la texture d'un triangle, chaque pixel est échantilloné de la manière suivante: les normales des trois points du triangle sont interpolées de manière à avoir la normale se trouvant au point que l'on veut échantillonner, et l'on va chercher la couleur de ce point dans l'image dont la vue se rapproche le plus de cette normale. A cela est couplé une gestion du problème des reflets engendrés par la lumière spéculaire, ainsi qu'une gestion de l'occlusion, lorsque la vue de la particule est obstruée par une autre partie de l'objet.
Il faut dire que le programme original comportait beaucoup d'erreurs de programmation, qui ralentissaient le programme et consomaient beaucoup de mémoire pour rien. Par exemple, pour un nom de fichier de quelques caractères, un tableau de 1024 caractère était alloué puis copier deux fois, ce qui fait plus de trois mille caractères perdus. Cette erreur est minime et sans conséquence mais elle est permet de se rendre compte des énormités que nous avons trouvé dans ce programme.
|
La surface est contruite par une récursion dans l'espace au moyen d'un octree. La récursion s'arrête au niveau désiré, et les couleurs et normales des particules des niveaux inférieurs sont calculées en remontant l'octree et en moyennant les couleurs et normales de ces particules terminales; une correction de ces valeurs est conservée pour chaque particule afin de gérer les erreurs de précision. Par contre, seules les particules terminales sont conservées car une particule du niveau n - 1 est incluse dans l'ensemble des particules de ces fils de niveau n ( [5]).
Pour chaque particule, sa couleur est prise dans l'image dont la vue se rapproche le plus de la normale à la particule. A cela est couplé une gestion du problème des reflets engendrés par la lumière spéculaire, ainsi qu'une gestion de l'occlusion, lorsque la vue de la particule est obstruée par une autre partie de l'objet.
Il s'agit du visualisateur d'objets décomposés en particules. Il reçoit en entrée un ensemble de particules, et recrée à partir de celles-ci les différents niveaux de l'octree. La visualisation et le chargement du fichier d'entrée se fait de manière progressive par niveau. Il y a donc plusieurs niveaux de détails, et pour charger le niveau n, les niveau 0 a n - 1 doivent avoir été chargés. Ce visualisateur permet d'avoir plusieurs rendus, afin d'observer: l'objet complet, l'objet avec sa surface lissée, l'octree, les particules, l'octree et les particules, l'objet en fils de fer.
Distinction des décimations multiples. I.A un voxel est associé une particule. Un cube de huits voxels voisins est formé (la sphere claire indique l'absence de particule). II. On a ainsi une configuration qui s'inscrit dans un cube. III. A cette configuration est associée une triangulation. IV. Un chemin parcourant les arrêtes qui construisent la surface est recherché, afin de déterminer s'il existe deux triangulation possible. V. Deux triangulations sont trouvées. La meilleure sera choisie en fonction des normales à la surface ou en fonction des autres algorithmes de décimation (on privilégiera par exemple les arrêtes courtes), l'autre triangulation étant tout simplement éliminée. Cette gestion se fait pour tous les polyhèdres s'inscrivant dans un cube.
 |
 |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
Les images issues des acquisitions, en ce qui nous concerne, issues du L.R.M.F., ne sont pas directement exploitables:
De plus, chaque type d'image requiert un traitement particulier:
On peut également souhaiter ne pas travailler directement avec les images dans leur taille originale. Les petites images ne donnent pas un résultat aussi bon qu'en taille réelle mais suffisent pour donner un apercu ou effectuer une mini calibration et tout cela beaucoup plus rapidement qu'avec les grandes.
Avant même de toucher aux sources, en rentrant du L.R.M.F., nous avons donc dévellopés deux filtres de convertion d'images, utilisant tout les deux le programme ``convert'' existant sous linux11.
Imgconvert va chercher les images dans leurs répertoire et crée un répertoire de sortie pour chaque type d'image, permettant de ne pas les mélanger. La sortie standard d'erreur est redirigée afin de créer des logs pérennes.
Il est possible de modifier les traitements appliqués à chaque type d'image en éditant le script.
usage: imgconvert -(sil ou seq ou mir) avec:
usage: img2img format_départ format_arrive
Ces scripts posent deux problèmes. Le premier c'est que convert ne permet pas d'effectuer tous les traitements nécéssaires, car certains traitements comme la convertion au format sil ou le nettoyage des silhouettes sont spécifiques au projet.
Le deuxième problème posé par ces scripts est qu'il ne sont utilisables que sous un environement unix et avec le programme convert. La portabilité, notamment vers windows étant un des objectifs optionnels du projet.
C'est pourquoi nous ne pouvions nous contenter des ces scripts, il a fallu développer des filtres
Au début, il n'y a que quelques filtres qui ont été devellopés. La mauvaise qualité des silhouettes issues de la première acquisition nous a obligé à en développer de nouveaux. Le format sil va être à l'origine de deux filtres de convertion. Enfin, le désire de s'affranchir de convert va nous faire développer les derniers.
Certains filtres n'ont été développés que pour tester les autres, comme cmp_ppm. Ces filtres ont été conservés au cas où nous pourrions en avoir de nouveau besoin.
Ce filtre va permettre d'obtenir le boite englobante de l'objet ou de faire des retouches. Par exemple, s'il y a une tache sur le fond de l'image et qu'aucune silhouette ne la recouvre, on va pouvoir l'effacer. Cette tâche est maintenant réalisé par un autre filtre plus adapté. Ce filtre nous a surtout servi à faire des retouches, comme la découpe du pied de la statue par exemple.
usage: all_points (-blanc ou -noir) silhouette1 ...silhouetteN
usage: ./binarise [-s seuil] image1 ...imageN
Clean_sil ne s'utilise que sur des silhouettes binarisées au préalable.
usage: clean_sil silhouette1 ...silhouetteN
usage: cmp_ppm image1 image2
usage: extract image silhouette
usage: ./gamma [-g gamma_value] image1 ...imageN
usage: img2sil silhouette1 ...silhouetteN
usage: merge_all_points -mode image_base sil1 ...silN
Pour que cette algorithme soit réalisable, il faut donc que le facteur de réduction (à indiquer en ligne de commande) soit un multiple de la hauteur et de la largeur de l'image originale.
usage: resize facteur Image1 ...ImageN
usage: rgr resize gamma rotation image
usage: rotate (90 ou 180 ou 270) Image1 ...ImageN
Mais attention, il faut que l'extraction des silhouettes soit faite avec une majoration des points noirs de l'objet sinon, saveme va prendre les points noirs de l'objet comme appartenant à la silhouette ce qui va faire un trou dans l'objet.
./usage saveme Image1 ...ImageN
usage: ./sil2img Sil1 ...SilN
usage: ./tiff2ppm Image.tif
Tous les filtres décrit ci-dessus suffisent pour traiter les images, mais il est fastidieux de les appliquer les uns après les autres, même avec un script et il est possible d'optimiser le temps de traitement en regroupant les filtres. C'est dans cette optique que imgconvert a été dévellopé.
Imgconvert, qui porte le même nom que le script shell précédement dévellopé, réunis donc une grande parties des filtres précités, et leur associations pour accélérrer les traitements.
L'interface de imgconvert a été réalisée à l'image de celle de convert, son modèle. Mais imgconvert intègre la possibilité de traiter une ou plusieurs séquence d'image. En choississant un mode (SIL, SEQ, CAL ou ALL ou une association), le programme va être capable de parser un répertoire et de traiter l'ensemble des images qu'il contient.
Tous les programmes spécifiques au projet ont été intégrés dans ce logiciel et donc, dans le cas idéal, il est possible de convertir toutes les images d'une acquisition en même temps.
Imgconvert a été partiellement porté sur windows 95, partiellement car des fonctionnalités manques, comme le parsage de répertoire ou le mapping memory.
usage:
./imgconvert processing (mode and paths) or (list of images)
global processing:
-resize : resize the image with average
-gamma : gamma correction
-rotate : rotation from the image
local processing:
-binarise : binarise the silhouettes
-clean : clean the silhouette
-merge : merge a file with silhouette
-all_black : all black point of the image
-all_white : all white points of the image
-extract : extract the silhouette from sequence
-saveas : extention to save the picture
options:
if you want to treat a set of pictures:
-m, --mode : select a set of picture:
ALL: all pictures
SIL: silhouette pictures
SEQ: sequence pictures
CAL: calibration pictures
you can compose like SEQ.SIL or SIL.CAL
if you want to work with a set of pictures, you must
use the following options to locate the pictures:
-i, --silpath : path for the silhouette
-e, --seqpath : path for the sequence
-a, --calpath : path for the calibration picture
-o, --output : path for the output pictures
-l, --nbsil : nombre de silhouette
-q, --nbseq : nombre de sequence
-c, --nbcal : nombre de calibration
-v, --verbose : mode verbose
Toutes les acquisitions ont eues lieu au L.R.M.F., Laboratoire de Recherche des Musées de France, situé au Louvre, sous le Caroussel, aujourd'hui associé avec un laboratoire de restauration situé à Versaille pour former le CRRMF (Centre de Recherche et de Restauration des Musées de France).
Le LRMF est un partenaire dans le cadre du projet ACOHIR de l'ENST. La personne qui s'occupe du projet sur place est M Christian Lahannier, qui à travaillé avec nous lors de la première acquisition.
Cette première acquisition a lieu une semaine après le début du stage. Il était prévu que nous soyons assister par Yucel Yemez, post doc qui travaille depuis longtemps sur ce projet et qui a l'expérience de ce genre de manipulation, malheureusement, il ne sera pas rentré à temps d'une conférence pour venir avec nous. Nous étions donc uniquement deux novices pour éffectuer cette manipulation.
Le choix de l'objet que nous allions acquérir a été fait par M. Lahannier. Il s'agit d'une statue dont la provenance est indeteminée mais qui semble provenir de la religion hindouiste. Nous ne la connaitrons que sous le nom de FZ28462. Il apparaitra que cette statue n'est pas adaptée à notre méthode de reconstruction. D'abord, elle présente une concavité au niveau du chapeau que nous sommes incapable de modéliser correctement. De plus, les bras en avant dissimule la profondeur du ventre aux images. Evidement, il nous est totalement interdit de toucher à l'objet.
La première tache à accomplir sur place est de régler convenablement la caméra CCD en fonction de la luminosité, pour obtenir les meilleurs couleurs possible. L'absence de quelqu'un maitrisant ce genre de problèmes va gacher un temps précieux, qui nous est compté. Au final, la configuration de la caméra ne sera pas correcte et nous ramenerons des images incorrectes au niveau couleur.
Après la configuration de la caméra, il faut éffectuer notre calibration avec la mire. Nous allons réussir à placer la mire devant l'objet, par contre nous ne pourrons pas fixer la lampe annulaire autour de l'objectif. Ignorant son importance, nous l'avons fixé sur le pied de la caméra et la mire n'a pas été assez éclairée. Il nous faudra appliquer plusieurs traitements sur les images de la calibration pour qu'elles soient utilisables. Toutefois, ceci n'a pas eu une grande importance à partir du moment ou la calibration a été possible.
Le problème fut que la lampe annulaire devait être placé dans l'axe pour avoir un effet, donc autour de l'objectif, en dessous, même très proche, son effet fut minimisé et donc les points ne furent pas assez visible. De plus, les lumières ambiantes sont restées allumées pendant les prises de vues.
La sequence effectuée pour l'acquisition des textures ne posera aucun problèmes, à part le fait que la caméra était mal configurée.
Pour les silhouettes, nous devions saturer le fond blanc pour obtenir l'ombre chinoise de l'objet. Nous avions apporté deux petits projecteurs à cet effet mais ils seront insuffisants. De plus, le fond blanc était taché et les taches apparaiteront sur les images. Le devellopement de filtres seront nécéssaires pour rendre les silhouettes utilisables (cf fig 2)
Les principaux buts de cette scéance d'acquisition était:
Malgrés nos déboires, tous ces objectifs seront remplis sauf le dernier, à cause du manque de temps. La mauvaise qualité des couleurs est dommageable mais ne nous à pas empeché de faire une reconstruction.
Toutes les erreurs que nous avons commises lors de cette scéance nous seront profitables d'une certaine manière pour se rendre de compte des problèmes que peuvent apporter de mauvaises images et pour dévelloper les outils nécessaires à leurs correction.
Il faut souligner qu'aucune correction couleur ne sera pratiquée sur les images, comme ce sera le cas pour la deuxième acquisition. Nous ne pratiqueront qu'une correction gamma ce qui est loin de remplacer la correction nécéssaire. Il faut donc relativiser la mauvaise qualité des couleurs des images.
La deuxième scéance de prise de vue ne ressemblera en rien à la première:
Toute l'après-midi du Mardi 14 Décembre va être consacré à la préparation des prises de vues: placement de la caméra, méthode pour la calibration, montage pour que la lampe annulaire soit autour de l'objectif de la caméra, disposition de papier réfléchissant, .... En fait, la moitié du temps passé au Louvre sera consacré à la préparation. Cette durée peux paraitre excessive mais c'est grâce à cela que nos images seront de bonne qualité.
Toutes les prises de vues seront réalisées le Mercredi 15 Décembre en matiné. C'est la que nous allons avoir des problèmes, avec le logiciel d'acquisition d'image, qui a tendance à s'interrompre au milieu d'une séquence. Ces problèmes, indépendants de notre volonté, vont nous retardés et nous seront obligés de réaliser les dernières prise de vues dans l'urgence, avec trois heures de retard.
Un ordinateur portable avait été préparé 13 pour avoir la possibilitée de tester les images obtenues sur place, et éventuellement faire une reconstruction rapide pour tester. Le fait de ne pas pouvoir accéder aux images par le réseau va nous empecher de le faire.
La première reconstruction qui sortira de ces images sera d'une bien meilleure qualité que pour la statue prédente.
