doc

memoire/chapters/content/besoins.tex

@@ -29,7 +29,7 @@ La librairie devra être séparé en deux parties distinctes. Une devra fournir
      \begin{itemize}
       \item charge certaines informations du fichier de config si disponible
       \item fournit les methodes de calibration
-      \item sauve la config dans un fichier
+      \item sauvegarde la config dans un fichier
      \end{itemize}
 \end{itemize}
 Il faudra aussi fournir une application de calibration qui produira un fichier de configuration pour faciliter la calibration de la librairie avec son environnement et ne pas devoir la répéter à chaque utilisations de la librairie d'usage. L'application utilisera la librairie de calibration.

memoire/chapters/content/existant.tex

@@ -2,6 +2,8 @@
 \chapter{Etude de l'existant}
 Le projet duquel est inspiré celui-ci était une application qui permettait l'utilisation du bac en réalité augmentée. Malheureusement, il était impossible de partir de ce projet pour faire d'autres applications.
 \\
+site ar sandbox université california : \url{https://arsandbox.ucdavis.edu/}
+\\
 Dans la version précédente réalisé par mon prédécesseur, le but était faire une première version de la librairie.
 \begin{figure}[H]
 	\centering

memoire/chapters/content/implementation.tex

@@ -144,7 +144,7 @@ La méthode permettant de déterminer le masque de découpage utilise les mêmes
 
 \subsection{Beamer}
 La classe Beamer propose elle aussi des méthodes liées à la calibration. En effet c'est même le cas pour la majorité d'entre elles.
-\subsubsection{Procédure}
+\subsubsection*{Procédure}
 Ces méthodes sont basées sur une procédure de calibration précise. L’utilisateur devra ce munir d’une cible comme ci-dessous afin de la réaliser.
 
 \begin{figure}[H]
@@ -168,9 +168,9 @@ Afin de trouver la position du vidéoprojecteur à la fin de cette procédure, l
 
 L’utilisateur positionnera sa cible à l’endroit où les croix seront projetées. La méthode getCrossList nous permet de récupérer les positions des croix à afficher. Lorsqu’une croix est projetée, nous roix projetée, une capture est prise afin de localiser la cible, après l’avoir convertie en noir et blanc, nous pouvons modifier le constraste et la luminosité (avec editContrast), puis la passer à la méthode findCircles qui nous retournera les cercles détectés. Ensuite nous pouvons construire l’image à afficher avec la croix à l’aide de buildCrossFrame, qui affichera la croix à suivre et si la cible est détectée, en plus d’indiquer à quelle étape du processus nous en sommes.\\
 Lors de la validation d’un point de l’utilisateur, il faut s’assurer d’avoir une cible détectée, car c’est à ces coordonnées que nous allons établir un point sur un répère en 3D, pour cela il suffira d’utiliser deprojectPixel. Une fois plusieurs points validés, nous pouvons calculer la droite passant au mieux par ces points grâce à la méthode findLinearLineFrom. Enfin, lorsque nous avons assez de droites, nous pouvons approximer la position du vidéoprojecteur avec approximatePosition.
-\subsubsection{getCrossList}
+\subsubsection*{getCrossList}
 Retourne une liste de coordonnées correspondant aux croix à viser lors de la calibration. Elles devront être affichées les unes après les autres.
-\subsubsection{editConstrast}
+\subsubsection*{editConstrast}
 Cette méthode adapte le constraste et la luminosité d’une image en noir et blanc en suivant cette equation :\\
 g(i,j) = alpha * f(i,j) + beta où  alpha > 0\\
 \url{https://docs.opencv.org/2.4/doc/tutorials/core/basic_linear_transform/basic_linear_transform.html}
@@ -189,18 +189,18 @@ HoughCircle est basé sur une matrice de compteurs, appelée accumulateur. Pour
  \item "minRadius" et "maxRadius" permettent de gérer le rayon minimum et maximum du cercle lors du parcoure de l’image de contours incrémentant l’accumulateur
 \end{itemize}
 \url{https://docs.opencv.org/2.4/modules/imgproc/doc/feature_detection.html?highlight=houghcircles#houghcircles}
-\subsubsection{buildCrossFrame}
+\subsubsection*{buildCrossFrame}
 Construit une image où l’on indique la position de la croix à placer. Indique si un cercle a été trouvé, si c’est le cas, un carré vert sera visible, sinon il sera rouge. Il est aussi indiqué à quelle étape nous nous trouvons sur le total.
-\subsubsection{deprojectPixel}
+\subsubsection*{deprojectPixel}
 Permet de récupérer les coordonnées 3D à partir d’un cercle détecté et de la matrice de profondeurs.
-\subsubsection{findLinearLineFrom}
+\subsubsection*{findLinearLineFrom}
 Cette methode permet de trouver la droite passant le mieux entre les points données. Elle utilise la méthode fitLine d’OpenCV.
 \begin{figure}[H]
 	\centering
     \includegraphics[scale=0.5]{linear_regression.jpg}
 \end{figure}
 Regression linéaire Adow .p37
-\subsubsection{approximatePosition}
+\subsubsection*{approximatePosition}
 Cette méthode permet d’approximer la position 3D du vidéoprojecteur grâce à une liste de droites (qui sont définies par un point et une direction). Elle fait appel à la méthode LineLineIntersect qui permet de trouver les points les plus proches entre deux droites :\\
 Pa = P1 + mua * (P2 - P1)
 Pb = P3 + mub * (P4 - P3)
@@ -213,7 +213,7 @@ Où Pa et Pb sont les points les plus proches.
 Distance la plus courte entre deux droite Adow p.40
 \\
 Une fois les points trouvés, nous faisons la moyenne de tout nos points pour approximer la position du vidéoprojecteur.
-\subsubsection{FrameProcessProfil}
+\subsubsection*{FrameProcessProfil}
 Cette classe sert à accompagner la classe Beamer lors de la phase de calibration, son but est de contenir les différents paramètres liés au traitement d’images que nous utiliserons plus tard dans les fonctions de Beamer. Elle contient notamment les variables de luminosité et constraste utilisable dans "editContrast", ainsi que les paramètres utilisés lors dans la fonction "findCircles" liés au traitement de "HoughCircles" d’OpenCV. Plus précisement : "minDist", "param1", "param2", "minRadius" et "maxRadius". Où "param1" fait référence au seuil supérieur lié à la méthode de contour Canny, et "param2" au seuil déterminant un cercle dans notre accumulateur dans la méthode de Hough. Les variables "minDist", "minRadius" et "maxRadius" sont tout trois en pourcentage par rapport à la largeur de l’image traitée.
 Donc nous avons :
 \begin{itemize}

memoire/chapters/content/intro.tex

 % !TeX spellcheck = fr_FR
-\chapter*{Introduction}
+\chapter{Introduction}
 \addcontentsline{toc}{chapter}{Introduction} % Adding toc entry
 
 Produire une maquette en tant qu'architecte ou paysagiste a un coût en ressources et en temps. C'est pourquoi il est fastidieux de modifier une maquette une fois contrsuite.

memoire/chapters/content/resultats.tex

 
 \chapter{Tests et résultats}
 \section{Optimisation}
-La librairie fonctionne, mais elle souffre de mauvaise performances, c’est pourquoi le but est d’entâmer une amélioration de celles-ci. Tout d’abords nous avons commencé à utiliser Valgrind, car son interface permettait de lire les données graphiquement, contrairement à Gprof qui retourne les informations dans la console. Ensuite en analysant les données retournées par Valgrind, nous nous voulions voir si les conclusions tirées d’un outil de profiling s’appliquaient pour tout outils. Nous avons donc testé avec Gperftools, qui est un autre outil graphique de profiling. Nous avons remarqué que les deux ne nous donnaient différent retours, mais que certaines informations étaient quand même redondantes dans nos deux cas. Enfin en testant avec Gprof, nous avons aussi remarqué qu’une fonction se démarquaient des autres. Cette fonction permettait de reconstruire l’image lors de l’ajustement de l’image projetée en parcourant chaque pixel pour ajuster sa valeur.\\
-L’idée de modifier le code pour qu’il fonctionne sur GPU était alors concevable, mais pas raisonnable pour le moment, car il fallait s’assurer que le code était bien optimisé sur CPU, avant de l’adapter sur GPU. Donc nous avons décidée d’améliorer le code existant.\\
+La librairie fonctionne, mais elle souffre de mauvaise performances, c’est pourquoi le but est d’entâmer une amélioration de celles-ci. Pour ce faire, nous avons utilisé des outils de profiling, afin de localiser les zones à améliorer. Tout d’abords nous avons commencé à utiliser Valgrind, car son interface permettait de lire les données graphiquement, contrairement à Gprof qui retourne les informations dans la console. Ensuite en analysant les données retournées par Valgrind, nous nous voulions voir si les conclusions tirées d’un outil de profiling s’appliquaient pour tout outils. Nous avons donc testé avec Gperftools, qui est un autre outil graphique de profiling. Nous avons remarqué que les deux nous donnaient différents retours, mais que certaines informations étaient quand même redondantes. Enfin en testant avec Gprof, nous avons aussi remarqué qu’une fonction se démarquaient des autres. Cette fonction permettait de reconstruire l’image lors de que la fonction d’ajustement de l’image projetée resortait, plus précisément à cause du parcours de chaque pixel qu'elle effectue pour ajuster les valeurs de la sortie.\\
+L’idée de paralléliser le traitement de l'image était alors concevable, mais pas raisonnable pour le moment, car il fallait s’assurer que le code était bien optimisé sur CPU, avant de l’adapter sur GPU. Donc nous avons décidée d’améliorer le code existant.\\
 Pour ce faire, nous nous sommes atardés sur la gestion de la mémoire des buffers utilisées lors d’une utilisation standard de la librairie. C’est à dire, récupération d’une image de couleur ou profondeur, puis ajustement de l’image projetée. En ce qui concerne la caméra, nous avons limité les buffers à la capture des images couleurs et profondeurs (avec chacunes leur buffer) et le retour d’une copie de ces buffers lors de la récupération de ces images.\\
 Puis lors de l’ajustement de l’image, nous gardons en mémoire les buffers utilisés dans la fonction. C’est à dire celui contenant l’image de sortie et les quatres autres utilisés dans la fonction d’ajustement. Ce qui nous fait cinqs zones mémoires de la taille de l’image de sortie. Enfin une copie est faite de l’image de sortie, ce qui nous rajoute un buffer.\\
 Lors de l’analyse avec Gperftools, nous avons eu ce graphique :