Modélisation de la vision humaine

Transcription

1 Université Montpellier II UFR Sciences 2007 / 2008 FMIN TER Modélisation de la vision humaine MARIE Sylvain NANARD Marc Encadrants Auteurs CLERC Mickaël DELFOUR Jonathan JULIA Matthieu POTHIN Olivier

2 Remerciements Nous tenons à remercier nos encadrants, Monsieur Marc Nanard du LIRMM et Monsieur Sylvain Marie de NexGen, qui nous ont permis de réaliser ce projet. Nous voulons également remercier un de nos anciens camarades aujourd'hui à l'ens de Lyon. Modélisation de la vision humaine 2/144

3 Table des matières Table des matières 1 Introduction Généralités Public visé Cahier des charges Les ltres Répartition des tâches Diagramme de GANTT Organisation du projet Organisation du travail Organisation interne Organisation du développement Contraintes techniques Plate-forme Technologies Logiciel d'édition de texte et langage Manipulation de scènes en 2 ou 3 dimensions Interface Graphique Documentation Analyse du projet Open Scene Graph (OSG) Qu'est ce qu'un Scene Graph? Les pointeurs intelligents OpenGL Le langage GLSL : OpenGL Shading Language Un shader? Mais pourquoi? Le Vertex Shader Le Fragment Shader Les types Les qualicateurs : attribute, uniform, varying Liaison GLSL-OSG Le glshader Le glprogram La liaison Petit imprécis sur la physiologie de l' il Rétine Modélisation de la vision humaine 3/144

4 Table des matières Cristallin & Pupille Champ de vision Développement Petit imprécis sur la modélisation de la vision humaine avec OpenSceneGraph, OpenGL et le GLSL Render To Texture Modele-Vue-Controleur Modèle Vue Controleur Flou Gaussien Première Approche Premiers Résultats Solutions Les phénomènes d'accomodation La projection sphérique La projection non linéaire L'assemblage de projections non linéaires Manuel d'utilisation 35 6 Perspectives et conclusions Perspectives Accommodation Evolution possible Conclusions Fonctionnement de l'application Fonctionnement du groupe de travail Problèmes rencontrés Notre sentiment sur ce projet A Images 39 B Documents d'analyse 43 C Compte rendus de séances 50 C.1 Séance C.2 Séance C.3 Séance C.4 Séance C.5 Séance C.6 Séance C.7 Séance D Organigrammes 53 Modélisation de la vision humaine 4/144

5 Table des matières E Bibliographie 56 E.1 OpenGL E.2 OpenGL Shaders E.3 OpenSceneGraph E.4 Vision humaine et couleurs E.5 Physiologie de L'oeil F Documentation 58 Modélisation de la vision humaine 5/144

6 Chapitre 1 : Introduction Chapitre 1 Introduction 1.1 Généralités Aujourd'hui, que ce soit dans les jeux vidéos ou dans les simulateurs, la modélisation de la vision humaine n'est pas, ou peu faite. Le problème ne se pose pas pour les premiers, car une modélisation dèle de la vision humaine serait restrictive au niveau de la jouabilité. En revanche, dans les simulations de l'être humain pour la conception de postes de travail (poste d'ouvrier dans une usine, poste de pilotage d'un avion), ou en situation réelle (automobiliste), les simulateurs ne tiennent en général pas compte d'éléments tels que la profondeur de champ, les déformations à la périphérie du champ de vision ou encore d'une éventuelle pathologie, ce qui pose problème dans la mesure où cela peut entraîner une situation radicalement diérente de celle prévue par le logiciel. 1.2 Public visé Ce genre d'application peut se voir utilisée dans plusieurs domaines. Cette application a pour nalité d'être intégrée au logiciel existant de la société canadienne NexGen Ergonomics 1. NexGen Ergonomics est un leader dans le domaine des logiciels d'instrumentations utilisés pour étudier l'ergonomie, la biomécanique,... Leurs produits sont utilisés dans un large panel d'organisations mondiales : les universités, compagnies d'assurances, agences gouvernementales et divers consultants. Notre application apportera un côté réel à une partie de leur application. Par exemple, dans leur logiciel la vision est actuellement représentée par un trait qui indique si l'on voit ou pas. Il existe simplement deux états distincts : objet visible ou non visible. Cet exemple permet d'expliquer la nalité de notre développement. L'objet pourra être nettement visible, perceptible, ou car en arrière plan, non visible... Il permettra d'améliorer une application existante an de la rendre complète et proche de la réalité. Pour réaliser ce genre d'application, nous avons besoin de connaître un minimum la physiologie de l' il. 1 http :// Modélisation de la vision humaine 6/144

7 Chapitre 1 : Introduction 1.3 Cahier des charges Pour modéliser le plus dèlement la vision humaine, notre logiciel prendra en entrée une image et appliquera diérents ltres sur celle-ci an de faire apparaître ce que verrait réellement une personne. Voici une liste des principaux ltres que nous allons réaliser suivi de la manière dont nous nous sommes répartit les tâches Les ltres Pour réaliser notre objectif nous avons introduit la notion de ltre. Voici la dénition d'un ltre tirée de wikipédia : L'action du ltre consiste à retenir, supprimer, rediriger ou modier les éléments indésirables du ux et, à en laisser passer librement les éléments utiles. Dans notre projet, un ltre sera donc un algorithme permettant de passer d'un état à un autre en enlevant, modiant ou ajoutant des eets. 1. Tâche de Mariotte : Le ltre devra simuler la reconstruction de la zone non visible par l' il. 2. Filtres géométriques : (a) Champ de vision : Ce ltre devra cacher ce qui n'est pas visible par l' il. 3. Filtres rétiniens : (a) Profondeur de champ : La modélisation de la profondeur de champ consiste à rendre ou toutes les choses qui ne sont pas à la distance d'accommodation de l' il. (b) Intensité lumineuse : Comment s'adapte la rétine suivant qu'il y ait beaucoup de lumière ou très peu? (c) Projection sphérique : Consiste à étirer fortement l'image au centre et pas du tout ou très peu sur les côtés. (d) Projection en perspective (e) Vision périphérique : C'est la vision de ce que l'on voit ou, vision qui détecte les mouvements. (f) Perception des couleurs et du contraste Répartition des tâches Le sujet se divise en deux parties, comprendre la vision humaine et la modéliser. La première partie est essentielle pour la suite du sujet, c'est pourquoi nous devons tous nous documenter abondamment sur ce sujet an de le maîtriser. Pour la partie modélisation, la répartition des tâches se fera en fonction des forces et faiblesses de chacun. Nous avons fait des estimations en durée sur le travail à faire sachant que nous disposons à ce jour d'environ trois mois. Le développement étant itératif, les mises à jour et modules supplémentaires seront nombreux. Nous avons choisit d'utiliser un framework Décorateur an de pouvoir ajouter les ltres à l'image. Notre connaissance en modélisation 2D/3D étant légère, il nous est dicile d'estimer exactement la durée que nous passerons par module. Modélisation de la vision humaine 7/144

8 Chapitre 1 : Introduction Suite aux premières réunions avec nos tuteurs, nous avons deux ltres à créer, et ne connaissant encore pas trop les bibliothèques, nous avons fait deux groupes de deux an de travailler en extrême programming. Le premier ltre consiste à reproduire le cercle noir de l' il que l'on ne perçoit pas (tâche de Mariotte). Cette zone aveugle se positionne au centre de l' il, et n'est pas perceptible lorsque nous regardons un objet. Un algorithme sera donc établit an d'en reproduire au mieux les caractéristiques. Pour l'instant, l'idée sommaire est de faire la moyenne des couleurs du cercle entourant la tâche aveugle et de reproduire ces couleurs vers l'intérieur. Le deuxième a pour objectif de reproduire les zones de ou. Ces zones de ou apparaissent en arrière plan lorsque nous regardons un objet en premier plan. Pour obtenir une première idée de l'application, nous nirons par déformer l'image rendue an d'en obtenir une vision proche de notre vue. Nous allierons au mieux vue planaire et sphérique an d'obtenir un dosage sans déformation importante et avec un rendu très proche de notre vue. Ces paramètres seront réglables via l'interface mise en place. Ensuite nous ferons diérents ltres sur la déformation, le champ de vision, la profondeur de champ, etc. Tous ces ltres sont décrits dans le chapitre précédent. Nous espérons ces étapes largement terminées pour n mars. Nous souhaitons reproduire les eets de persistance rétinienne que nous pouvons rencontrer lorsque nous regardons un point très lumineux comme le soleil, puis basculons dans une zone avec un éclairage normal. Ces eets temporels sont très important au niveau de la vision humaine. Une autre application serait de voir comment l' il s'habitue à une zone sombre (nuit noire). Est-ce que celui-ci s'adapte au noir? Si le temps nous l'autorise, nous implémenterons toutes sortes d'algorithmes permettant d'améliorer notre rendu visuel, d'appliquer d'autres ltres (vision nocturne, etc), de reproduire certaines maladies de l' il (glaucome, daltonisme, etc). Les applications sont multiples et variées. Nous préférons privilégier des modules de qualité à la quantité Diagramme de GANTT (cf. gure en page 55). Modélisation de la vision humaine 8/144

9 Chapitre 2 : Organisation du projet Chapitre 2 Organisation du projet 2.1 Organisation du travail Notre groupe de travail est constitué de 4 personnes plus nos 2 encadrants. Nous nous sommes réunis avec M. Nanard toutes les semaines sauf lorsque nous avions des empêchements, an de vérier l'avancement du projet et d'exposer de nouvelles idées quand à la direction que devait prendre le développement de l'application. Lors de nos diérents réunions nous avons écrit des comptes rendus que vous pouvez consulter en page Organisation interne An de faciliter la communication entre les membres du groupe, nous avons mis en place un forum 1. Les courriers électroniques, les applications d'instant messaging (Skype, MSN,...), et accessoirement VNC ont été des méthodes de communications annexes entre les membres du groupe. Nous avons utilisé un outil de versionnage an de se partager les sources. Cet outil de versionnage a été utilisé en combinaison avec un système de gestion de billets via Trac 2 permettant d'assigner des tâches Organisation du développement Nous avons décidé d'utiliser le pattern Décorateur dont nous expliciterons les détails dans la partie Développement. Nous avons tout d'abord créé deux sous groupes, un travaillant sur la tâche de Mariotte, l'autre sur l'accommodation. Puis, comme la tâche de Mariotte n'était qu'une étape préliminaire à la découverte du traitement d'images, le groupe qui faisait la tâche de Mariotte s'est attaché à réaliser un ltre pour la projection sphérique. Une fois que ces deux ltres furent terminés, nous avons décidé de nous attacher au débuggage et à l'optimisation de l'application an de traquer les éventuelles erreurs de programmation, bugs et autres fuites de mémoire. 1 http ://vision.frbb.net 2 http ://trac2.assembla.com/vision Modélisation de la vision humaine 9/144

10 Chapitre 2 : Organisation du projet 2.2 Contraintes techniques Plate-forme Les étapes du développement se feront en majeure partie sur Windows mais l'application ayant pour but nal d'être intégrée à un logiciel déjà existant, nous devons nous assurer qu'elle sera portable. Nous réaliserons donc cette application de telle sorte qu'elle soit exécutable pour la majeure partie des plates-formes (Windows, Unix, MAC). Nous pourrons fournir si besoin avec la version nale, une version compilée en 64 bits. 2.3 Technologies Logiciel d'édition de texte et langage Le développement sera eectué en C++ et OpenGL Shader Language (GLSL), nous utiliserons l'ide Microsoft Visual Studio qui ore un puissant débuggeur. GLSL est le langage de programmation des pipelines des cartes graphiques 3D intégrées à OpenGL, cela permet de travailler directement sur le processeur graphique et notamment sur les Pixels Shaders et sur les Vertex Shaders (cf. gure en page 40). Les Fragment Shaders sont des programmes de transformation que nous pouvons appliquer à un pixel, essentiellement liés aux calculs des couleurs. Ces calculs sont eectués directement par le processeur graphique (GPU) ce qui permet de décharger le processeur (CPU). Les Vertex shaders sont des programmes également eectués par le GPU, ils s'occupent essentiellement des transformations géométriques des objets (changement de taille, rotation, translation,...) en agissant sur les attributs des vertex (sommets du triangle) Manipulation de scènes en 2 ou 3 dimensions Nous utiliserons l'api OpenSceneGraph 3. OpenSceneGraph est un toolkit OpenSource, multi plate-forme pour le développement des applications graphiques de haute performance telles que des simulateurs de vol, des jeux, la réalité virtuelle et la visualisation scientique. Basé autour du concept d'un SceneGraph, il fournit un framework sur OpenGL 4 permettant au programmeur de s'abstraire de la couche bas-niveau d'opengl ainsi que d'optimiser les appels graphiques (cf. gure en page 41). Un SceneGraph ou Graphe de Scène en français, est une structure générale de données utilisée communément par les outils de modélisation 3D et les jeux vidéo actuels. Un graphe de scène est une collection de n uds renfermée dans un graphe ou une structure d'arbre. Un n ud peut avoir plusieurs parents et un parent plusieurs enfants ; ceci est très important car lorsque qu'une opération est créée sur un parent, celle-ci est propagée à tout le groupe de n uds ls. Dans notre programme, OpenSceneGraph va donc nous servir à eectuer ces opérations sur des groupes d'objets. OpenSceneGraph possède plusieurs avantages, outre l'abstraction du bas-niveau d'opengl, il est gratuit et portable Interface Graphique Une interface graphique sera créée en wxwidget 5, permettant de visionner, manipuler et régler les paramètres de l'application. Utilisant des librairies open source portables, la licence de 3 http :// 4 http :// 5 http :// Modélisation de la vision humaine 10/144

11 Chapitre 2 : Organisation du projet l'application sera libre Documentation Une documentation de l'application sera générée au format Doxygen 6, le code sera donc commenté avec un style proche de la javadoc. Voici une petite explication de Doxygen tirée de wikipédia : Doxygen est un logiciel informatique libre permettant de créer de la documentation à partir du code source d'un programme. Pour cela, il tient compte de la grammaire du langage dans lequel est écrit le code source, ainsi que des commentaires s'ils sont écrits dans un format particulier. 6 http :// dimitri/doxygen Modélisation de la vision humaine 11/144

12 Chapitre 3 : Analyse du projet Chapitre 3 Analyse du projet Nous développerons dans cette partie notre analyse detaillée du sujet qui comprend en grande partie la compréhension des outils de développement que sont OpenSceneGraph, OpenGl et le GLSL d'une part, et d'autre part les mécanismes inhérents à la physiologie de l' il humain. 3.1 Open Scene Graph (OSG) Commençons par étudier les termes d'openscenegraph avant d'expliquer les bases Qu'est ce qu'un Scene Graph? L'équivalent français serait un graphe de scène. Voici la dénition tirée de Wikipédia : Un graphe de scène est une structure générale de données utilisée communément par les outils de modélisation 3D et les jeux vidéos actuels. Le graphe de scène structure de manière logique la représentation spatiale d'une scène graphique. La dénition d'un graphe de scène est oue, puisque les programmeurs qui implémentent les graphes de scènes dans les applications, plus particulièrement dans l'industrie du jeu vidéo, reprennent les principes généraux et les adaptent à leurs besoins particuliers. D'une manière générale, un graphe de scène est une collection de n uds renfermée dans un graphe ou une structure d'arbre. Ceci signie qu'un n ud peut avoir plusieurs enfants. Ainsi, un eet appliqué sur un n ud se répercute sur ces descendants, ce qui permet de propager l'opération à un groupe de n uds. Dans de nombreux programmes, l'utilisation typique vise à appliquer une transformation géométrique à un groupe d'objets. L'idée principale est qu'une scène est décomposée en plusieurs parties, qui peuvent être liées. D'un point de vue mathématiques, un graphe de scène est un graphe orienté acyclique qui établit une hiérarchie entre les n uds qui la composent. Un n ud dans OpenSceneGraph est représenté par la classe osg : :Node. Même si c'est techniquement possible (niveau langage) d'instancier un n ud, il n'est pas de très grande utilité de le faire. Pour cela, il est intéressant d'étudier les classes qui héritent de osg : :Node. Les classes lles sont nombreuses, ici nous verrons les classes osg : :Geode et osg : :Group. Les objets qui peuvent être graphiquement représentés sont des instances de osg : :Drawable. Mais les osg : :Drawable ne sont pas des n uds, on ne peut pas les attacher directement au graphe de scène : il est nécessaire d'utiliser un osg : :Geode pour lier l'objet au graphe. Cependant, tous les n uds d'un graphe de scène ne peuvent pas avoir des n uds comme ls. En eet, il n'est possible d'ajouter des ls à un n ud que s'ils sont instances de osg : :Group ou d'une de ses sous classes. Modélisation de la vision humaine 12/144

13 Chapitre 3 : Analyse du projet Maintenant, pour gérer tous ces objets, il est nécessaire de disposer d'une mémoire permettant de créer ces ressources. OpenSceneGraph intègre une gestion de pointeurs référencés que nous allons expliciter Les pointeurs intelligents Une mauvaise gestion des ressources mémoires engendre des fuites mémoires et une forte utilisation de mémoire par l'application. Le but est de détruire les pointeurs dès qu'ils ne sont plus utilisés. Par dénition, une ressource mémoire est quelque chose qui doit être alloué avant utilisation et désalloué lorsque l'utilisation est terminée. Dans un graphe de scène, une ressource ne doit pas être désallouée tant qu'il existe d'autres références vers cet objet (lorsqu'un n ud est attaché à deux parents par exemple). Ainsi, le principe d'un pointeur référencé met en jeu un compteur interne associé à chaque objet qui représente le nombre de références pointant vers cet objet. Plus précisemment, les objets qui ont ce compteur intégré sont les instances de classes qui héritent de la classe osg : :Referenced. La ressource sera donc détruite lorsque ce compteur vaudra zéro. Le mot 'intelligent' entre alors en action : ce n'est pas aux programmeurs de gérer ces compteurs. En OpenSceneGraph, ces pointeurs intelligents sont implémentés comme une classe template nommée osg : :ref_ptr<t>. Ces bases acquises, il est alors possible de commencer à utiliser OpenSceneGraph. 3.2 OpenGL OpenGL est le moteur graphique utilisé par OpenSceneGraph pour acher une scène. Notre connaissance en OpenGL est intimement liée à celle que nous avons d'openscenegraph. OpenSceneGraph permet d'abstraire la couche bas niveau d'opengl, ainsi une méthode d'openscenegraph correspond à une autre méthode dans OpenGL, voire à un rassemblement de plusieurs méthodes. 3.3 Le langage GLSL : OpenGL Shading Language Comme nous l'avons présenté dans les premières parties de ce rapport, GLSL est un langage permettant la programmation par le processeur graphique de scènes OpenGL. Il a été développé par 3D Labs et approuvé par l'arb (Architecture Review Board), l'organisme chargé de la standardisation d'opengl. La programmation de notre processeur graphique (que nous appellerons GPU par la suite) se pratique au moyen de deux éléments : le vertex shader et le fragment shader. Les shaders sont des chaînes de caractère que l'on peut écrire comme un programme en C (avec les méthodes inhérantes aux shaders évidemment). Un vertex shader est un programme qui va agir directement sur les sommets de la scène, quand au fragment, il va agir sur tous les pixels de la scène. Nous parlerons tout le long de fragment shader et non de pixel shader, car les fragment sont propres à OpenGL tandis que les pixels sont propres à Direct3D Un shader? Mais pourquoi? L'utilisation des shaders vient entre autres du fait que certains de nos ltres vont essentiellement jouer sur les eets de lumières et sur les couleurs de la scène. Or il s'agit typiquement Modélisation de la vision humaine 13/144

14 Chapitre 3 : Analyse du projet du type d'opérations que l'on va pouvoir réaliser en utilisant le processeur graphique. Améliorer le réalisme d'un rendu, rajouter des eets de ou ou d'antialiasing (anticrénelage) sont un avant-goût des possibilités qu'orent un shader Le Vertex Shader Le processeur vertex est une unité programmable qui opère sur les valeurs et données associées aux vertex en entrée. Les vertex shaders sont exécutés sur ce processeur. Voici quelques opérations réalisables depuis ce processeur : transformation sur les vertex, transformation des normales et normalisation de vecteurs, génération/transformation de coordonnées de textures, éclairage. Entrée Voici une liste non exhaustive des variables d'entrée d'un vertex shader. 1. gl_vertex : Position du sommet. 2. gl_color : Couleur du sommet. 3. gl_normal : Normale du sommet. 4. gl_multitexcoordx : Coordonnées de l'unité de texture x. 5. gl_secondarycolor : Couleur secondaire du sommet. 6. gl_fogcooord : Coordonnées du brouillard. Ces variables sont en entrées, c'est à dire, qu'à partir du moment où nous sommes dans un vertex shader, nous pouvons les utiliser sans aucune autre déclaration, OpenGL nous les fournit. Cependant, lorsque nous écrivons un vertex shader, nous ne sommes pas forcés de les utiliser. Sortie Voici une liste non exhaustive des variables de sortie d'un vertex shader. Ces variables modient directement les attributs du sommet de la scène. 1. gl_position : Position en coordonnées écran du sommet. 2. gl_frontcolor : Couleur du côté avant de la face à laquelle est rattaché le sommet. 3. gl_pointsize : Taille du point du sommet. Les variables de sorties sont évidemment diérentes des variables d'entrées, cependant il y a une variable qui doit être forcément aectée sinon le vertex shader est invalide : gl_position Le Fragment Shader Ce type de shader est exécuté sur le 'fragment processor'. Le 'fragment processor' est une unité programmable qui opère sur les valeurs et données associées aux fragments en entrée. Voici quelques opérations réalisables depuis ce processeur : opération sur des valeurs interpolées, accès aux textures, brouillard (fog), opération sur les couleurs, zoom sur pixel, redimensionnement, bias, convolution... Un fragment shader produit des valeurs de sorties basées sur les valeurs passées en entrée. Modélisation de la vision humaine 14/144

15 Chapitre 3 : Analyse du projet Entrée Voici une liste non exhaustive des variables d'entrée d'un fragment shader. 1. gl_fragcoord : Coordonnées écran du pixel. 2. gl_color : Couleur du pixel. Ces variables d'entrées sont utilisables de la même façon que celles du vertex shader. Sortie Voici une liste non exhaustive des variables de sortie d'un fragment shader. Ces variables modient directement les attributs du pixel de la scène. 1. gl_fragcolor : Couleur nale du pixel. 2. gl_fragdepth : Profondeur du pixel dans le buer de profondeur (depth buer). A la diérence d'un vertex, on ne peut pas modier la position à l'écran du pixel via le fragment shader, cependant la possibilité de pouvoir modier la couleur et la transparence de chaque pixel d'une scène constitue une force remarquable pour la gestion 'microscopique' d'une scène Les types Comme chaque langage, le GLSL possède des types et des fonctions prédénies qui lui sont propres même s'il a tendance à ressembler fortement au C. Ce langage procédural de haut niveau est riche en types : il inclue, outre les types hérités du C, des vecteurs et des matrices qui permettent de rendre le code plus concis pour des opérations 3D graphiques. Nous ne ferons pas un listing complet de ces types et fonctions mais en voici quelques unes comme les vec2, vec3, vec4 qui sont des vecteurs de 2 à 4 éléments, sampler2d, sampler3d qui sont des textures à 2 ou 3 dimensions. Pour comparer des vecteurs il existe des fonctions comme lessthan, equal ou greaterthan, pour lire dans les sampler2d les couleurs d'un pixel par exemple, il existe la fonction texture*d Les qualicateurs : attribute, uniform, varying Ces trois qualicateurs sont très importants, ils permettent au programme GLSL de récuperer des variables du programme principal, mais également aux vertex shader de passer des variables aux fragment shaders. attribute Une variable qualiée attribute est une variable qui peut être uniquement lue par le vertex shader. uniform Une variable qualiée uniform dans le code d'un vertex et/ou d'un fragment shader est une variable aectée par le programme principal sur le processeur (CPU) que pourront lire les vertex et fragment shaders. Cette variable est déclarée dans le code du vertex ou du fragment globalement. varying Une variable dite varying est déclarée globalement dans le vertex et dans le fragment. Elle peut être lue et écrite par le vertex et uniquement lue par le fragment. Typiquement elle permet au fragment de donner des informations sur des paramètres au fragment. Modélisation de la vision humaine 15/144

16 Chapitre 3 : Analyse du projet 3.4 Liaison GLSL-OSG Pour mieux comprendre comment fonctionne un shader et son modèle de construction, faisons une simple analogie avec le système de compilation du C Le glshader Un glshader correspondrait à un chier objet. Il contient le code source du shader. Il est compilé en temps réel (runtime) pour devenir un chier '.obj', et doit être recompilé dès que le code source change Le glprogram Un glprogram correspondrait plus à un chier exécutable. Il contient la liste des shaders à exécuter, il subit une édition de liens (link) pour devenir un chier '.exe' et les liens doivent être réédités dès qu'un shader est modié. Un glprogram doit avoir au moins un glshader attaché. Comme en C, un chier objet (shader) peut être partagé entre plusieurs chiers exécutables (program) La liaison Voici les correspondances d'utilisation de ces types en OpenSceneGraph : glshader -> osg : :Shader glprogram-> osg : :Program gluniform*() -> osg : :Uniform Exemple Un exemple d'utilisation pourrait être : osg::program *pgm = new osg::program; gmpgm->setname("simple"); pgm->addshader(new osg::shader( osg::shader::vertex, vsrc)); pgm->addshader(new osg::shader(osg::shader::fragment, fsrc)); osg::stateset *ss = getorcreatestateset(); ss->setattributeandmodes(pgm, osg::stateattribute::on); ss->adduniform(new osg::uniform("color", osg::vec3(1.0f, 0.0f, 0.0f))); ss->adduniform(new osg::uniform("val1", 0.0f)); Un document très complet sur le langage GLSL et sa liaison avec OpenSceneGraph est disponible ici : http ://mew.cx/osg_glsl_july2005.pdf. 3.5 Petit imprécis sur la physiologie de l' il Nous allons énumérer un certain nombre de propriétés physiologiques de l' il et voir leurs conséquences sur la vision humaine, conséquences que nous aurons donc à modéliser dans notre application Rétine La rétine est une surface (couvrant 75% de la surface du globe oculaire) d'environ 0,5 mm d'épaisseur située au fond de chaque il tapissée de cellules photo réceptrices permettant de transformer en signaux bioélectrique les signaux lumineux reçus et les transmettre au cerveau. Modélisation de la vision humaine 16/144

17 Chapitre 3 : Analyse du projet Cônes et Bâtonnets Ces cellules sont de deux types, les cônes ("verts", "bleus" et "rouges") réceptifs aux couleurs mais peu sensibles à l'intensité lumineuse et les bâtonnets, très sensibles à l'intensité lumineuse (environ 500 fois plus que les cônes) mais imperméables aux couleurs. Elles sont réparties de manière hétérogène sur l'ensemble de la rétine ; les cônes étant beaucoup plus nombreux dans la fovéa (zone centrale de la rétine) et les bâtonnets dans la rétine périphérique (Voir Fig. 1 en annexe). La conséquence de cette répartition est une division de la vision humaine en une vision centrale et une vision périphérique. Nous ne nous en rendons pas compte mais nous sommes en réalité "aveugles" aux couleurs en dehors de la vision centrale, et pouvons distinguer plus facilement les variations de luminosité en périphérie. De même, la vision centrale est plus nette le jour tandis que l'on voit mieux la nuit si l'on regarde légèrement à coté de l'objet ciblé. De plus, la zone fovéale est la seule zone où l'acuité visuelle est vraiment signicative, cette dernière est même considérée comme médiocre en dehors de cette zone, qui ne correspond qu'à un angle de 3 degrés environ. Lors de la simulation de la vision humaine à un instant t, la netteté de l'image n'est donc pas homogène. 1 Enn, les cellules photo réceptrices ont besoin d'un certain temps pour eectuer le traitement biochimique du signal optique, ainsi l' il superposera l'image en cours aux images vues précédemment. Tâche de Mariotte De plus,légèrement excentré par rapport au centre de la rétine vient se brancher le nerf optique ainsi que les vaisseaux sanguins de l' il. En ce point, nommé tâche de Mariotte, la rétine est complètement dépourvue de cellules photo réceptrices, l' il est donc totalement aveugle. Nous ne nous apercevons de rien car le cerveau compense cette "tâche blanche". Cependant, l'absence d'information en ce point est réelle et il est donc important de la prendre en compte dans un simulateur Cristallin & Pupille Cristallin Le cristallin de l' il peut se ramener à une lentille convergente complexe. En eet, des muscles modient les rayons de courbure des deux faces du cristallin permettant le phénomène d'accommodation, c'est à dire modier quels seront les rayons lumineux à atterrir sur la rétine et ainsi pourvoir voir de près comme de loin. Il existe diverses pathologies ou malformations qui peuvent entraver ce processus, le temps d'accommodation et sa qualité peuvent donc varier selon les individus. En outre, un il fatigué, ou exposé pendant longtemps à beaucoup de lumière aura plus de mal à s'accommoder lorsque plongé dans le noir. Ce sont là autant de pistes qu'il nous faudra explorer dans notre application. Pupilles Les pupilles de l' il peuvent s'ouvrir ou se fermer en fonction de la luminosité. Ainsi, les pupilles s'ouvrent largement la nuit an de permettre le passage d'un maximum de lumière, ce qui fait perdre en netteté de profondeur de champ. Modélisation de la vision humaine 17/144

18 Chapitre 3 : Analyse du projet Champ de vision Le champ visuel humain peut être décomposé en deux : la vision centrale et la vision périphérique. Vision centrale La vision centrale, aussi appelée acuité visuelle, permet de distinguer les détails de l'espace, en vision éloignée et en vision rapprochée. C'est une vision nette et précise. L'acuité visuelle correspond à un angle de vision de 3 environ ; en dehors de cette zone, la vision est médiocre. Vision périphérique La vision périphérique est la vision de la sécurité. C'est une vision oue qui permet de détecter le mouvement "ce qui bouge", de sentir "qu'il se passe quelque chose" sur les côtés. La vision périphérique nous permet de voir ou de détecter des mouvements sur les cotés jusqu'à au moins 90 par rapport à la vision centrale, et environ 70 en haut et en bas. Même si nous ne le ressentons pas au quotidien, la vision périphérique est une vision qui déforme les objets présents à notre alentour. Modélisation de la vision humaine 18/144

19 Chapitre 4 : Développement Chapitre 4 Développement 4.1 Petit imprécis sur la modélisation de la vision humaine avec OpenSceneGraph, OpenGL et le GLSL Nous ne reprendrons pas ici les explications données dans la partie analyse, nous les compléterons par : - quelques mots du vocabulaire du programmmeur OSG, GLSL. - quelques techniques utilisées. Vecx (x = 2..4) est un vecteur à x éléments. Geometry est l'attribut qui contient les coordonnées de la gure dans un canvas, ainsi que la manière de colorer la gure, et les coordonnées de la texture (s'il y en a) dans cette gure. Un QUAD est une structure géométrique composée de 4 points (vertex) Render To Texture Comme son nom l'indique, il s'agit de récupérer le rendu d'une scène dans une texture pour pouvoir ensuite y appliquer nos ltres. L'utilisation d'openscenegraph nous a permis de réaliser cela assez simplement. En eet, il nous sut de spécier à une caméra donnée que son "COLOR_BUFFER", c'est à dire le rendu nal de la scène que la caméra observe sera une texture : camera->attach(color_buffer,texture); Cette caméra sera utilisée avant le rendu à l'écran, et elle même n'achera donc rien, du fait du RTT. Il nous faut donc ensuite acher à l'écran la texture que l'on a créée, et pour cela nous utilisons une deuxième caméra, qui "passera" après la première et qui place cette texture sur un rectangle de taille de notre canvas. Modélisation de la vision humaine 19/144

20 Chapitre 4 : Développement 4.2 Modele-Vue-Controleur Nous avons utilisé le patron Modele-Vue-Controleur pour gérer notre application (cf. gure en page 46). An de mieux comprendre comment tout cela est articulé, nous avons également fourni un diagramme de classe d'analyse permettant de se rendre compte de la hiérarchie des composants utilisée dans notre logiciel (cf. gure en page 48) Modèle Nous avons décidé d'utiliser le patron de conception décorateur (cf. gure en page 47) car celui-ci correspond exactement à ce que nous voulions faire. Nous avions une scène de base à laquelle nous voulions pouvoir ajouter diérents attributs (nos ltres). Nous avons donc commencé par créer une classe MScene qui correspond à notre scène chargée via l'interface avec toutes les fonctions nécessaires aux modications sur la scène, puis une classe abstraite DécorateurScene de laquelle hérite nos ltres. Ainsi nous pouvons ajouter des ltres comme bon nous semble et les aecter à la scène très simplement Vue L'interface est la partie qui relie l'utilisateur et l'application. Nous avons voulu créer une interface simple d'utilisation tout en essayant de rendre celle-ci la plus attrayante possible. Pour cela nous avons donc décidé de créer un certain nombre de barre d'outils et de fenêtre d'options qui permettent à l'utilisateur d'ajouter d'actionner des ltres, de les personnaliser de façon très simple. Nous avons aussi choisi de créer une interface dans laquelle, l'utilisateur pourra ouvrir plusieurs projets en même temps, indépendant les uns des autres sans ouvrir plusieurs fenêtres, c'est pourquoi nous avons crée un système d'onglets. Notre interface se compose d'une classe App (cf. gure en page 44) dérivant de wxapp qui est la classe permettant de créer une application. À la création de l'application, une fenêtre principale (MainFrame) dérivant d'une wxframe est créée. Cette fenêtre est gérée par un wxauimanager qui nous permet de choisir un style particulier à celle-ci. En combinant wxauimanager et wxauipaneinfo nous pouvons choisir les options des objets à inclure à cette fenêtre telles l'emplacement, la taille, l'achage d'une croix pour fermer la sous fenêtre, la possibilité de déplacer les fenêtres. La classe MainFrame possède des barres d'outils d'activation ou de désactivation des ltres via des boutons, des fenêtres pour gérer les options des ltres, une barre de menu et un gestionnaire d'onglets. La barre de menu (wxmenubar) contient un certain nombre de menus (wxmenu) tel que le menu chier qui contient lui même des (wxmenuitem) pour charger une nouvelle scène ou fermer la fenêtre. Les barres d'outils sont dérivés de la classe wxtoolbar, ce qui nous permet de personnaliser chaque barre d'outils, chaque bouton par une image (au format xpm) ou du texte. Certains boutons comme les boutons des ltres son sélectionnables an que la personne qui utilise le programme puisse savoir à tout moment quel(s) ltre(s) elle a appliqué sur la scène courante. Nous avons rendus les barres d'outils déplaçables grâce au wxauimanager. m_mgr.addpane(tbfiltre, wxauipaneinfo(). Name(wxT("ToolBarFiltre")).Caption(wxT("ToolBar des différents filtres.")). ToolbarPane().Top().Row(1).Position(1).TopDockable(true).CloseButton(false). DestroyOnClose(true).BottomDockable(false)); Modélisation de la vision humaine 20/144

21 Chapitre 4 : Développement m_mgr est le wxauimanager de la fenêtre principale et tbfiltres est la barre d'outils que l'on souhaite ajouter. Ensuite on peut voir que grâce au wxauipaneinfo on choisit la position de la barre d'outil mais aussi l'endroit ou l'on peut déposer la barre d'outil ainsi que sont style d'achage (ToolbarPane()). Nous avons également choisit d'ajouter une fenêtre à part entière permettant de gérer les diérentes options sur les ltres. Cette fenêtre (OptionFlous) permet de gérer les options sur diérents ltres grâce à de nombreux sliders permettant de régler la distance d'accommodation, la taille de la matrice de calcul du ou et d'autres encore. Nous avons également choisit d'ajouter un bouton updateshader qui permet de mettre à jour le shader de la scène que l'on utilise grâce à ce qui est écrit dans la console. Cette fenêtre agit directement grâce au contrôleur sur l'onglet actif courant. Les onglets sont la partie la plus importante de la fenêtre principale. En eet, pour construire chaque onglet nous mettons en titre le chemin du dossier pour lire la scène et dans l'onglet une classe qui hérite de wxwindow : Projet (cf. gure en page 45). Cette classe est la classe qui va nous permettre d'acher une scène et la console associée à cette scène. La console est une simple boite de texte dans laquelle nous lisons et écrivons selon nos diérentes actions. Pour acher la scène nous avons plusieurs classes, tout d'abord SceneFrame qui hérite de wxscrolledwindow et Canvas qui hérite de wxglcanvas et d'osgviewer : :GraphicsWindow. Dans projet il y a un nouveau gestionnaire de fenêtre au moyen de wxauimanager dans lequel nous mettons au centre la classe SceneFrame et en bas la console. Le canvas est contenu dans la fenêtre de la scène. Lorsque nous créons la fenêtre de la scène, nous lui aectons un canvas sans scène. Puis le programme aecte un viewer au canvas an que le viewer utilise le canvas comme moyen d'achage. Le canvas gère lui-même les évènements comme le clique gauche ou le clique droit sur lui, il met à jour la scène en fonction ; sachant que le clique gauche vous permet de faire pivoter la scène alors que le clique droit vous permet de faire un zoom. Ces fonctions sont gérées par la classe osgviewer : :Viewer. Pour nos diérents ltres la classe SceneFrame possède des pointeurs vers le modèle de la scène an de savoir si celle-ci est oue par exemple. Lorsqu'un évènement est détecté sur les sliders, il faut que le contrôleur puisse savoir si la scène est oue ou non Controleur Le contrôleur est l'articulation du système, c'est vers lui que chaque requête interne ou externe est transmise (sauf pour le canvas). C'est lui qui va appeler les bonnes fonctions selon les évènements du menu, c'est lui qui va choisir si lorsque l'utilisateur bouge un slider, si selon le ltre appliqué en ce moment sur la scène, s'il faut ou non que cette modication soit prise en compte. C'est lui qui eectue la gestion des onglets, lorsqu'une action est détectée, si celle-ci concerne un onglet, alors c'est par le contrôleur que l'action sera envoyée au projet actif. Lors d'un évènement de chargement c'est lui qui lance la boîte de dialogue qui permet de parcourir les dossiers pour choisir une scène à ouvrir. Le contrôleur connait tous les éléments de la fenêtre plus ou moins directement et grâce à cela, il permet d'assurer la liaison entre chaque élément de l'interface. 4.3 Flou Gaussien La réalisation d'une synthèse de ou en temps réel sur une scène donnée va permettre de créer un ltre pour illustrer les phénomènes d'accommodation. Il existe diverses techniques de traitement d'images permettant de réaliser ce type de ltre. Comme nous l'avons vu dans la partie Analyse, nous avons choisi d'utiliser un algorithme de convolution appliqué sur l'ensemble Modélisation de la vision humaine 21/144

22 Chapitre 4 : Développement de la scène 3D au moyen d'un shader GLSL. La réalisation du ltre se fait en trois étapes : Eectuer un Render To Texture de la scène Plaquage de la texture sur un QUAD Application du shader sur la texture Nous ne détaillerons ici que la troisième étape du procédé, car les deux premières sont détaillées dans le petit imprécis Première Approche Entrées : I une image, M un masque Résultat : Y l'image résultante de l'application du masque M à l'image I Dans notre cas, l'image I correspondante à la scène totale est transmise au shader sous la forme d'une texture à deux dimensions au moyen d'une variable de type uniform. Le masque M correspond à une matrice de rayon variable, dont les valeurs ottantes sont calculées de manière à obtenir une distribution gaussienne. Le principe de la convolution est le suivant : pour chaque pixel de l'image, calculer la combinaison linéaire de la valeur rgba de chaque pixel adjacent avec les coecients de la matrice lui correspondant, sachant que la valeur centrale de la matrice correspond au pixel courant. On remplace ensuite la valeur du pixel courant par la valeur de la combinaison linéaire normalisée an de revenir dans les domaines de variation de l'image. Nous eectuerons dans un premier temps les calculs de la matrice à l'intérieur du shader, mais il nous a vite semblé évident que cela était aberrant, nous avons donc décidé de calculer le shader à la volée lors de l'exécution du programme, en eectuant notamment le calcul du noyau sur le CPU. De plus cela nous permet de pouvoir changer le code source du shader pendant l'exécution du programme et ainsi pouvoir faire varier les diérents paramètres gérant l'accommodation en temps réel. Comme il s'agit de traiter chaque pixel, cet algorithme sera implémenté dans le Pixel Shader. Algorithme 1 Convolution Entrées: Kernel une matrice contenant les coecients, Oset une matrice contenant les modicateurs de coordonnées pour chaque coecient de Kernel,colorMap un sampler2d,gltexcoord[0] un vec4 contenant les coordonnées de texture par vertex, Total un ottant Sorties: Valeur un vec4 représentant la valeur du pixel en cours 1: pour inti = 0 to taille de Kernel faire 2: Accéder à la valeur des texels adjacents au texel correspondant au pixel en cours 3: vec4temp = texture2d(colormap, gl T excoord[0].st + Offset[i]); 4: valeur+ = temp Kernel[i]; 5: n pour 6: valeur = valeur/t otal 7: return valeur Du fait de la distribution gaussienne de notre matrice, les coecients qui ont le plus d'inuences, c'est à dire une valeur plus importante, se situent au niveau du centre, et leur inuence décroit avec leur distance au centre. Ainsi, cette convolution revient à atténuer les changements brusques d'intensité de l'image, ce qui rejoint la dénition du ou. Modélisation de la vision humaine 22/144

23 Chapitre 4 : Développement Premiers Résultats Nous avons constaté que les ous "produits" par ce shader ne devenaient vraiment conséquents qu'à partir d'un rayon de matrice supérieur ou égal à 3, ce qui est également la limite supérieure de nos cartes graphiques de tests en terme de puissance de calcul, le nombre d'images par secondes chutant spectaculairement entre une matrice de rayon 2 (60 images par secondes) et une matrice de rayon 3 (entre 5 et 15 images par secondes selon les GPU) sur une scène de dimension 800*600. Ces résultats ne sont pas surprenants dans la mesure où l'implémentation brute de la convolution tel que nous l'avons implémentée est en O(n 2 ). Fig. 4.1 Avion net à gauche et oué à droite par une matrice de rayon Solutions Une première solution envisagée consistait à réduire le nombre de texels sur lesquels on appliquait la convolution, en eectuant un RTT vers une texture de taille inférieure que l'on plaquait ensuite sur un QUAD ayant gardé la taille d'origine. Le problème résultant de cette opération fut l'apparition d'une pixellisation de la scène rendue ou, et plus grave, des parties non oues de la scène. La seconde solution que nous avons nalement retenue consiste à utiliser un paramètre optionnel de la fonction GLSL texture2d de spécier un niveau de detail pour une valeur dans une texture donnée. En eet, une texture peut posséder plusieurs niveaux de détails, dits MIP map levels qui ont l'avantage d'éviter une pixellisation la texture, ainsi que de réduire le nombre de texels à traiter. Cette utilisation du Mip-Mapping est rendu possible du fait de l'extrapolation linéaire de la texture sur le QUAD, ce qui évite les eets d'escaliers lorsque l'on va traiter un texel sur deux par exemple. L'idée est donc d'appliquer une convolution de matrice de rayon moindre sur une image à un niveau de détail moindre, ce qui a pour eet d'obtenir un ou conséquent sans demander beaucoup de calculs au GPU Les phénomènes d'accomodation Nous avons choisit de pouvoir faire varier la distance à laquelle "l'humain" regarde la scène an d'illustrer les phénomènes d'accommodation. C'est pourquoi il nous a fallu récupérer la Modélisation de la vision humaine 23/144

24 Chapitre 4 : Développement Fig. 4.2 Illustration mipmap distance de l' il par rapport à l'objet an de déterminer une première partie de la scène dont les rayons lumineux n'arrivent pas sur la fovéa car n'étant pas à la distance pour laquelle l' il s'accommode. Pour toute cette partie de la scène, nous réalisons alors une interpolation entre une image ou de la scène et une image nette (avec la proportion d'image oue variant selon l'âge, l'acuité visuelle, etc..). Nous avions dans un premier temps tenté de récupérer un buer contenant des informations sur la profondeur d'une scène appelé Depth Buer. Pour cela, nous avons réalisé une capture de ce buer au moyen d'un "render to texture", puis nous avons transmis cette texture au Fragment Shader comme s'il s'agissait d'une texture quelconque. Nous avons ensuite réalisé qu'il n'etait pas nécessaire d'utiliser ce procédé. En eet, un Vertex Shader permet de redénir toutes les transformations géométriques nécessaires à l'achage d'un objet en 3 dimensions sur un ecran, c'est à dire sur une surface en 2 dimensions. Ainsi, nous avons donc écrit un Vertex Shader dans lequel nous transposons les coordonnées de chaque point, qui sont dans le "Model Space" i.e. les coordonnées objet, dans le Eye Space i.e. le système de coordonnées ayant l' il pour origine. Ceci s'eectue en appliquant successivement les deux matrices de transformations que sont la "Model Transformation Matrix" et la "Viewing Matrice" aux coordonnées du point : vec4 positionineyespace = gl_vertex * gl_modelviewmatrix; float depth = - positionineyespace.z / positionineyespace.w; Il ne nous reste plus qu'à passer cette information au shader sous la forme d'un varying et de calculer l'interpolation voulue selon une courbe. Le calcul de cette courbe fût simple, il susait de trouver une courbe variant entre 0 et 1 en fonction de la profondeur. 0 signiant une zone parfaitement nette, 1 une zone la plus oue possible et entre 0 et 1 une zone de plus en plus oue. La zone nette se trouve exactement à la distance d'accommodation de l' il de l'humain et les zones oues à des distances inférieures et supérieures à cette distance d'accomodation. Nous avons utilisé la fonction suivante : f(x) = min(1 ; abs(0.06 * (distance d'accomodation - x ))) Ce résultat aurait pu être satisfaisant cependant dans la réalité l' il humain ne s'accommode pas seulement à une distance précise mais plutôt à une zone plus ou moins grande selon les individus. C'est pour cette raison que nous avons décidé d'ajouter un slider permettant de dénir la taille de cette zone en fonction des individus. Une fois cette fonction calculée, il nous susait d'utiliser ce résultat an de calculer la couleur à acher. Pour cela nous avons utilisé le calcul suivant : Modélisation de la vision humaine 24/144

25 Chapitre 4 : Développement Fig. 4.3 Courbes de l'interpolation entre les zones nettes et oues ou = couleur du pixel ou net = couleur du pixel net coef = résultat du calcul précédent gl_fragcolor = coef*flou + (1 - coef)*net; Une fois la réalisation du ou correcte en fonction de la profondeur des objets de la scène, nous nous sommes attaqués à une modélisation plus ne, qui tient compte de "l'angle de netteté" de la vision. Modélisation de la vision humaine 25/144

26 Chapitre 4 : Développement 4.4 La projection sphérique La projection sphérique va nous permettre de simuler la projection de la lumière sur l' il humain ainsi que les limites du champ visuel. L' il humain permet de voir, pour une personne non déciente, de 94 à 110 degrés environ horizontalement et de 110 à 120 degrés verticalement ; ces chires peuvent varier selon les personnes. Avec nos deux yeux, nous pouvons donc voir à au moins 188 degrés horizontalement, c'est-à-dire que nous pouvons voir légèrement derrière nous. Au niveau de la programmation cela constitue un dé de taille, car aucun logiciel ne vous ore une vue à plus de 180 degrés. Cela est techniquement impossible avec une projection en perspective. Dans notre recherche de la simulation de la vision humaine, nous sommes tout d'abord partis sur une unique projection non linéaire, puis ayant compris qu'il était impossible de résoudre ce problème de cette manière, nous avons entrepris d'assembler plusieurs projections non linéaires an d'en obtenir une projection sphérique d'un angle de vue supérieur à 180 degrés La projection non linéaire La projection linéaire est la projection automatiquement réalisée par opengl. Cette projection ne subit aucune déformation, même minime. Notre objectif ici est de pouvoir simuler les déformations que subit l'image lors de sa projection sur l' il, c'est-à-dire que celle-ci soit peu déformée au centre et à contrario très déformée sur les côtés. Pour eectuer cette modélisation, nous avons recherché une courbe de déformation quasiment idéale, c'est-à-dire qui déforme peu la scène au centre an de laisser celle-ci "lisible" et fortement sur les côtés. Nous avons cherché un compromis entre la ressemblance physiologique et la lisibilité du modèle. Le processus se déroule en 3 étapes, la capture du color buer dans une texture, le calcul des positions de placage de la texture et le placage de la texture. Modélisation de la vision humaine 26/144

27 Chapitre 4 : Développement Algorithme 2 Déformation d'une texture 1: Capturer le color buer dans une texture tex 2: int nosteps = 50 3: Position des sommets : cursor = Vec3(0,0,0) 4: Position des points de la texture : texcoords = Vec2(0,0) 5: Vecteur des positions nales des points de la texture : texcoord. 6: Vecteur des positions nales des points de la gure : vertices. 7: pour int i = 0 to nosteps faire 8: Incrément de cursor en y. 9: Incrément de texcoords en y. 10: pour int j = 0 to nosteps faire 11: Vec2 coords = calculcoords(texcoords.x(), texcoords.y()) ; 12: Empiler coords dans texcoord. 13: Empiler cursor dans vertices. 14: Incrémenter cursor en x. 15: Incrémenter texcoords en x. 16: n pour 17: n pour 18: Création de l'attribut geometry de la scène. 19: Aectation de l'attribut vertices à geometry. 20: Aectation de l'attribut texcoord à geometry. 21: Création d'une scène. 22: Application de geometry à la scène. 23: Placage de la texture tex sur la scène. 24: Création d'une caméra qui ache la nouvelle scène au dessus de la précédente après la caméra principale. Ici nosteps dénit le nombre d'étapes que l'on va faire pour calculer les positions, un nombre trop petit peut rendre la vue complètement inutilisable alors qu'un nombre trop grand peut faire chuter le nombre d'images par seconde. Le calcul des positions de la gure est simple, il sut de recouvrir toute la fenêtre, c'est pourquoi on pose directement cursor dans le tableau de vecteur des nouvelles coordonnées. Cependant pour les points de la texture, on ne calcule pas des coordonnées à l'écran ou sur un canvas, mais des coecients qui varient entre 0 et 1 et dont le centre est en 0,5. Cette diérence explique pourquoi on n'incrémente pas de la même manière cursor et texcoords. calculcoords est une fonction qui prend les deux coordonnées x et y en paramètres et qui renvoie un Vec2 dans lequel on a appliqué la fonction de déformation telle que décrite ci-dessous. Modélisation de la vision humaine 27/144

28 Chapitre 4 : Développement Fig. 4.4 Graphique des diérentes déformations La courbe bleue représente la fonction identité, celle qui n'applique aucune déformation à l'image. Nous avons commencé nos essais avec la courbe (sin(x (pi 0.5)) + 1)/2 mais celleci ne nous donnait pas satisfaction car la déformation n'était pas assez importante nous avons donc cherché et trouvé les autres courbes, nous donnant chacune une déformation bien plus importante. Modélisation de la vision humaine 28/144

29 Chapitre 4 : Développement Fig. 4.5 Déformation d'une scène représentant une vache avec la fonction (sin(x (pi 0.5)) + 1)/2 Finalement, ces déformations faisaient sortir ce que l'on voyait de l'écran en déformant énormément la texture sur les côtés. C'est alors que nous avons vu que la vision humaine s'étendait sur un angle de 188 degrés. Cette étape nous avait donc permis de toucher à la déformation d'une texture tirée du color buer mais elle n'était cependant pas satisfaisante dans le but de simuler la projection de la lumière sur l' il L'assemblage de projections non linéaires Pour simuler la projection sphérique, nous avons dû assembler plusieurs panneaux constituant chacun une projection linéaire. Ces panneaux sont capturés par le biais de 3 caméras qui regardent la scène avec un même angle d'ouverture mais les caméras de gauche et de droite ont subit une rotation de cette angle dans le sens inverse (respectivement dans le sens) des aiguilles d'une montre. Nous avons choisit de n'utiliser que 3 panneaux dans le plan horizontal, et de ne pas ajouter de panneaux verticalement car au niveau du champ visuel on ne voit pas à 180 degrés en hauteur. Ces 3 caméras permettent donc de capturer la scène avec ce que l'on voit au centre, ce que l'on voit à gauche et ce que l'on voit à droite. Modélisation de la vision humaine 29/144

30 Chapitre 4 : Développement Algorithme 3 Capture des 3 vues 1: Créer 3 textures vides diérentes. 2: Dénition d'un angle de rotation ang. 3: Création de matrices de transformations m1, m2, m3 de la caméra principale. 4: m1 est la matrice identité. 5: m2 est la matrice identité sur laquelle on applique une rotation ang sur l'axe des y. 6: m3 est la matrice identité sur laquelle on applique une rotation -ang sur l'axe des y. 7: pour tout matrice faire 8: Création d'une nouvelle caméra. 9: Utilisation du Frame Buer Object lorsque cela est possible sur la caméra. 10: Création d'un Render To Texture avec cette caméra et la texture tx [où x représente le numéro de la caméra]. 11: Aectation de la caméra comme esclave de la caméra principale avec les arguments mx. 12: n pour 13: pour tout texture faire 14: Création d'un n ud. 15: Calcul de la geometry du n ud tel que décrite dans l'algorithme de calcul de la déformation. 16: Application de la geomtry au n ud. 17: Application de la texture au n ud. 18: n pour 19: Création d'une caméra de visualisation. 20: Création d'un n ud aura pour ls les 3 précédents. 21: Aectation de ce groupe de n ud à la caméra de visualisation. 22: Aectation de la caméra comme esclave de la caméra principale. Si on assemble ces 3 panneaux sans déformation, nous pouvons obtenir une vue de plus de 180 degrés, mais sans déformation. An de calculer les déformations sur chacun des panneaux, nous sommes passés par deux approches. La première, mathématiques, consistait à analyser le problème entièrement sous forme d'angles, de tangentes et de bissectrices. La seconde approche, plus pragmatique, consistait à placer à la main les points permettant de déformer l'image. L'approche mathématiques Le but de cette approche était de déterminer la manière de déformer les images capturées par les caméras du centre, de droite et de gauche. Nous avons placé le panneau du centre comme étant celui qui subit le moins de déformation, voir aucune au début, puis les panneaux de droite et de gauche qui subissent de fortes déformations plus on s'excentre. Pour placer les panneaux de droite et de gauche, nous avons décidé de les placer sur la bissectrice entre le panneau central et eux-mêmes. Modélisation de la vision humaine 30/144

31 Chapitre 4 : Développement Fig. 4.6 Disposition des panneaux Pour éviter un problème de continuité en bordure de panneaux, il nous fallait utiliser la même déformation à la n du panneau du centre et de celui de droite (et inversement, au début de celui du centre et à la n de celui de gauche). Si on considère juste la surface de l' il comme un cercle, on s'aperçoit alors qu'il faut projeter les plans sur cette surface en utilisant l'arc tangente. Fig. 4.7 La fonction arc tangente Si on considère ce schéma, O correspond à l' il humain, A au centre de la projection eectuée par le logiciel, et T au point dont on cherche la nouvelle cordonnée. Nous avons donc appliqué la fonction arctan (voir gure courbe atan) sur nos calculs de déformation et nous avons pu voir apparaître une déformation mais nous nous sommes retrouvés avec des cassures très importantes entre les diérents panneaux. An de réduire ces cassures, nous avons décidé de prendre un angle correspondant à 1 radian, c'est à dire 57 degrés. Sachant que tan 1 = 1.06 nous avons déterminé un coecient à appliquer sur notre calcul de déformation puis par tatonnement, nous avons xé une valeur à 1.09 de telle sorte qu'il y ait une déformation et qu'il n'y ait pas de cassure (voir gure courbe orange). Modélisation de la vision humaine 31/144

32 Chapitre 4 : Développement Fig. 4.8 Graphique des diérentes déformations par l'approche mathématiques Finalement, nous avions 3 panneaux, représentants ce que nous voyions à gauche, au centre et à droite mais avec une déformation tellement faible qu'elle n'était presque pas visible. An de vérier cela, nous avons pris un cube avec des lignes et nous avons vu qu'en eet le cube ne subissait aucune déformation. Nous avons alors entrepris de construire à la main les points an de déformer manuellement les images. L'approche pragmatique Lors de notre calcul des points de la texture, nous avons choisi de n'eectuer que 50 itérations, il nous fallait donc trouver 50 points qui nous donneraient une déformation et pas de cassure entre les panneaux. Nous avons commencé par calculer une déformation selon l'axe des x. Cette courbe montre clairement que la déformation est bien plus importante que la fonction y = x originale et que la fonction arc tangente. De plus comme elle est entièrement calculée à la main, nous pouvons la remodeler à notre guise. Une fois cette fonction trouvée, nous n'avions plus qu'à rentrer chaque point dans un tableau contenant les points de la texture, cependant et an de garantir un collage entre les panneaux, cette fonction n'est pas appliquée dès le départ mais après les deux premiers points de collage de la texture, ainsi les panneaux se soudent bien entre eux. Modélisation de la vision humaine 32/144

33 Chapitre 4 : Développement Fig. 4.9 Courbes de déformation en x selon les vues Ensuite nous n'avions plus qu'à trouver une courbe de déformation pour l'axe des y. Nous avions, lors de nos diérents tests sur la projection linéaire, cherché de nombreuses courbes pouvant nous donner satisfaction, une des courbes était totalement inutilisable lors de cette projection, cependant avec notre assemblage de panneau et ce que nous voulions faire, nous avons pu la réutiliser. Pour simuler la déformation en haut et en bas, il nous fallait une courbe qui ressere la scène en haut et en bas et qui l'étende au centre, au niveau graphique cela correspond à être très près du 0,5 (du centre de l'image) et très éloigné du 0 et du 1 puisque ceux ci sont les extrémités du collage de notre texture. Modélisation de la vision humaine 33/144

34 Chapitre 4 : Développement Fig Courbes de déformation en y. Au nal, grâce à nos approches successives nous avons réussi à créer un modèle de projection sphérique an de simuler la projection de la lumière sur l' il et les limites du champ visuel. Nous avons deux courbes et 3 panneaux qui nous permettent cette simulation. Modélisation de la vision humaine 34/144

35 Chapitre 5 : Manuel d'utilisation Chapitre 5 Manuel d'utilisation Tout d'abord lancer le logiciel, une fenêtre appairaît alors. Dans cette fenêtre, faites charger une scène à partir du menu ou de la barre d'outils. Une nouvelle fenêtre s'ouvre vous demandant de choisir la scène à charger. Si vous faites annuler aucune scène ne se chargera, sinon vous allez voir apparaître un nouvel onglet intitulé du chemin par lequel la scène a été chargée. Les formats acceptés sont les chiers avec une extension en.osg ou.3ds. La scène chargée et l'onglet créé, vous allez voir deux parties, la scène et une console. Dans cet onglet vous pouvez faire bouger la scène avec la souris ; en appuyant avec le bouton gauche et en bougeant la souris vous pouvez faire pivoter la scène, avec le clique droit vous pouvez zoomer ou dézoomer de la scène, avec les boutons droit et gauche pressés en même temps vous pouvez modier la position de la scène dans le viewer, avec la barre d'espace vous pouvez remettre la scène dans sa position initiale, vous pouvez activer/désactiver des ltres via le menu ou la barre d'outils, vous pouvez modier les options de ces ltres via la fenêtre de gestion des options. Une fois que vous avez ni avec une scène, vous pouvez en charger une autre ou quitter le logiciel. Modélisation de la vision humaine 35/144

36 Chapitre 6 : Perspectives et conclusions Chapitre 6 Perspectives et conclusions 6.1 Perspectives Notre application est fonctionnelle et relativement simple d'utilisation, cependant nous n'avons réalisé que deux ltres et aurions aimé en faire beaucoup plus, notamment des ltres traitants des maladies comme le glaucome et le daltonisme. Nous aurions également aimé pouvoir montrer l'eet d'un ash de radar lorsque nous sommes au volant, de montrer à quel point cela perturbe la vision humaine. 6.2 Accommodation Un petit nombre de sliders liés à la détermination de la zone peuvent sembler inadéquats dans la mesure où l'on souhaite simuler la vision humaine, cependant leur suppression pose de serieux problèmes de paramétrage car la réalité physiologique de l' il est telle que cette zone dépend d'un nombre de paramètres assez conséquents. Nous ne sommes pas sûr d'avoir réussi à tous les cerner dans nos tentatives de suppression de ces sliders, tels que la luminosité ambiante, l'âge du sujet, etc Evolution possible Nous avons bien entendu tenté de concevoir plus de ltres que ceux réalisés. La tâche de mariotte La tâche de Mariotte ou point aveugle est le premier ltre que nous avons tenté de réaliser. Nous avons commencé par ce problème car il devait nous faire découvrir le traitement d'images et la manipulation de scène en 3 dimensions. La tâche de Mariotte correspond à la partie où le nerf optique est connecté à la rétine, ce qui nous donne une petite partie démunie de photorécepteurs et donc complètement aveugle. Pour simuler cette tâche nous devions réaliser deux convolutions sur deux zones précises de taille xée. Cependant nous ne savions pas comment réaliser une convolution ni comment récupérer un pixel sans faire chuter le nombre d'images par seconde. C'est en travaillant sur la réalisation des autres ltres que nous avons trouvé comment faire une convolution et comment faire des render to texture. Nous avons donc entrepris de continuer cette partie, mais comme les autres parties n'étaient pas terminé, après en avoir parlé avec notre Modélisation de la vision humaine 36/144

37 Chapitre 6 : Perspectives et conclusions tuteur, nous avons décidé de nous concentrer sur nos ltres courants et de ne pas trop nous éparpiller. Eblouissement A l'heure actuelle de la réalisation de ce rapport, le ltre sur l'éblouissement n'est pas nalisé. Nous ne pouvons prédire à l'avance s'il sera terminé pour le jour de la soutenance. C'est pourquoi nous le notons en tant qu'évolution possible de notre projet... Ce ltre qui n'a pas pu voir le jour par manque de temps consistait à simuler un éblouissement dû à un ash, ou à une exposition soudaine à une lumière vive. Il aurait permis de reproduire les facteurs qui entrent en jeu lors de la réadaptation de l' il à la lumière. Pour ce ltre, il aurait fallu, récupérer la luminosité courante, l'augmenter jusqu'à simulation d'un éblouissement, et la réinitialiser à son état initial en fonction d'un facteur temporel (le temps d'adaptation). Nous n'avons pas eu le temps de gérer le facteur temps an de vraiment reproduire la reprise de la vue initiale. 6.3 Conclusions Fonctionnement de l'application Notre application fonctionne correctement, les ltres se chargent et se cumulent correctement, leur suppression est également possible, ce qui permet vraiment de choisir ce que l'on désire simuler au niveau de la vision humaine Fonctionnement du groupe de travail Le groupe de travail a bien fonctionné grâce au fait que nous nous connaissions depuis au moins 5 ans, mais aussi car nous étions très motivés et que le sujet était très interressant. La communication entre chaque membre du groupe s'est ainsi trouvée accrue et bien plus ecace. La division du travail a été faite de manière ecace, selon les forces et faiblesses Problèmes rencontrés Lors de la réalisation de ce projet, nous nous sommes heurtés à plusieurs problèmes. D'une manière générale, notre connaissance en OpenGL et OpenSceneGraph était initialement nulle. Ceci a été une première barrière de taille à franchir. En eet, la documentation sur OpenScene- Graph est quasimment inexistante ou obsolète lorsqu'elle existe. Ce manque de documentation a posé un problème important. Nous avons donc tenté d'obtenir de l'aide sur les listes publiques et forums d'openscenegraph et tiré prot des exemples fournis avec l'api. D'une autre part, les bases d'openscenegraph plus ou moins en mains, il nous a fallu de plus en plus repousser nos limites an d'en apprendre plus. La compréhension d'un shader et la prise en main des techniques propres à OpenGL sont des exemples de ce que nous avons appris Notre sentiment sur ce projet Nous nirons ce rapport par exprimer en quelques lignes ce que ce rapport nous a apporté. Au niveau technique, ce projet nous apporté énormément de connaissances sur la visualisation graphique (2d et 3d). En eet, en partant d'une connaissance nulle dans ce domaine, nous avons, entre autres, manipulé et appris les bases d'opengl, nous avons utilisé OpenSceneGraph et Modélisation de la vision humaine 37/144

38 Chapitre 6 : Perspectives et conclusions tous les avantages qu'il présente et enn nous avons mené à bien l'utilisation avancée du langage GLSL pour manier les shaders. Au niveau relationnel, même si les membres de notre groupe se connaissent depuis assez longtemps, c'est toujours un dé de réaliser un projet dicile. La diculté est d'autant plus accrue si personne ne manie le sujet et le langage à utiliser. Ainsi les techniques d'organisation (cycle de développement, partage de sources, communication, répartition des tâches) n'ont été que renforcées. Nous garderons ce projet dans nos mémoires pour avoir été un projet des plus intéressants et passionnants. Il nous a permis de lier le monde informatique à la réalité de ce que nous vivons tous les jours : la vision humaine. Modélisation de la vision humaine 38/144

39 Chapitre A : Images Annexe A Images Modélisation de la vision humaine 39/144

40 Chapitre A : Images Fig. A.1 Schéma d'un pipeline de carte 3D classique représentant la position des unités de traitement des shaders Modélisation de la vision humaine 40/144