probably the last commit, university project is done

CMakeLists.txt

@@ -39,16 +39,6 @@ target_compile_features(${TGT} PRIVATE cxx_std_17)
 target_include_directories(${TGT} PRIVATE include/genimg)
 target_link_libraries(${TGT} ${CONAN_LIBS} stdc++fs)
 
-# Tests
-if(TESTS)
-  set(TESTTGT genetic-image-tests)
-  file(GLOB TEST_FILES "tests/tests.cc")
-  add_executable(${TESTTGT} ${TEST_FILES})
-  target_compile_features(${TESTTGT} PRIVATE cxx_std_17)
-  target_include_directories(${TESTTGT} PRIVATE include/genimg)
-  target_link_libraries(${TESTTGT} ${CONAN_LIBS} stdc++fs)
-endif()
-
 # OS specific instructions.
 if(APPLE)
 elseif(WIN32)

benchmarks.fish

@@ -1,29 +0,0 @@
-#!/usr/bin/env fish
-# This script was written to work with the fish shell. If you do not have the
-# fish shell installed on your system, please install it before executing this
-# script.
-# The results will be stored in the output file `results.txt`
-set nb_amelioration 10 50 100 200 500 1000
-set nb_execution 200 100 50 20 10 5
-set available_methods 1 2 3 4
-set output results.txt
-rm -f $output
-for method in $available_methods
-		set nb_options (count $nb_execution)
-		echo "Method $method:" >> $output
-		echo "|                  / | <               | <                     |" >> $output
-		echo "| Nb d’améliorations | Nb d’exécutions | Temps d’exécution (s) |" >> $output
-		echo "|--------------------+-----------------+-----------------------|" >> $output
-		for i in (seq $nb_options)
-				set total_exec_time 0
-				set startexec (date +%s.%N)
-				for j in $nb_execution[$i]
-						./build/bin/genetic-image -i ./img/mahakala-monochrome.jpg \
-						-n $nb_amelioration[$i] -m $method
-				end
-				set endexec (date +%s.%N)
-				set total_exec_time (math "$total_exec_time+($endexec-$startexec)/$i")
-				echo "|$nb_amelioration[$i]|$nb_execution[$i]|$total_exec_time|" >> $output
-		end
-		echo "" >> $output
-end

report/report.org

@@ -6,30 +6,88 @@
 #+LANGUAGE: fr
 #+LATEX_CLASS: article
 #+LaTeX_CLASS_OPTIONS: [a4paper,twoside]
-#+LATEX_HEADER: \usepackage{xltxtra,fontspec,xunicode}\usepackage[total={6.5in,9.5in}]{geometry}\setromanfont[Numbers=Lowercase]{Charis SIL}
+#+LATEX_HEADER: \usepackage{xltxtra,fontspec,xunicode}
+#+LATEX_HEADER: \usepackage[total={6.5in,9.5in}]{geometry}
+#+LATEX_HEADER: \setromanfont[Numbers=Lowercase]{Charis SIL}
 #+LATEX_HEADER: \usepackage{xcolor} \usepackage{hyperref}
 #+LATEX_HEADER: \hypersetup{colorlinks=true,linkbordercolor=red,linkcolor=blue,pdfborderstyle={/S/U/W 1}}
 #+STARTUP: latexpreview
-#+OPTIONS: toc:nil
+#+OPTIONS: H:3 toc:nil
+#+OPTIONS: auto-id:t
+#+MACRO: newline @@latex:\hspace{0pt}\\@@ @@html:<br>@@
+#+MACRO: newpage @@latex:\newpage@@
+{{{newpage}}}
+#+TOC: headlines
+{{{newpage}}}
+
+* Avant-propos
+  :PROPERTIES:
+  :CUSTOM_ID: h-e3612e77-a5ab-4dd1-bb43-ed6f10fa845d
+  :UNNUMBERED: t
+  :END:
+
+Ce document est un rapport de projet dont le sujet est décrit ci-dessous. Si
+vous souhaitez obtenir le code source sans avoir à recopier celui contenu dans
+ce fichier PDF, vous pouvez vous rendre sur son dépôt Git situé à l’adresse
+suivante : [[https://labs.phundrak.fr/phundrak/genetic-images]]
+
+* Notes sur le code
+  :PROPERTIES:
+  :CUSTOM_ID: h-e784b2a1-801d-4f70-9889-534100c06ca8
+  :UNNUMBERED: t
+  :END:
+Le code source de ce projet repose sur trois dépendances :
+- ~boost_options~
+- ~spdlog~
+- ~opencv~
+
+Cependant, seul ~opencv~ est une dépendance que l’on peut appeler « cœure » au
+projet ; en effet, c’est grâce à cette bibliothèque que sont exécutées toutes
+les opérations de manipulation d’images, allant de la simple ouverture de
+fichier image à la génération des images telle que décrite ci-dessous.
+~boost_options~ est utilisé afin de parser les options du programme passées dans
+le terminal, et ~spdlog~ permet de générer une sortie utile pour la version
+~debug~ du programme, affichant des données utiles pour un développeur
+travaillant sur le code source (en l’occurrence moi-même). Ces deux dernières
+dépendances n’ont pas d’impact sur la rapidité du programme.
+{{{newpage}}}
 
 * Sujet
+  :PROPERTIES:
+  :CUSTOM_ID: h-d5b7a742-a9eb-4860-8872-c5342d46cec9
+  :END:
 
 Le sujet de ce projet est la création d’un logiciel pouvant recréer une image
-fournie grâce à des générations aléatoires et successives de formes aux,
-positions, couleurs et taille aléatoires. L’algorithme commence par créer une
-image vide aux dimensions identiques à l’image de référence, puis applique une
-de ces formes aléatoires. Si la ressemblance de l’image ainsi générée augmente
-par rapport à sa version précédente par rapport à l’image de référence, alors
-cette modification est conservée, sinon elle est annulée. Répéter jusqu’à
-satisfaction.
+fournie grâce à des générations aléatoires et successives de formes aux
+positions, couleurs et taille aléatoires. À chaque étape, une évaluation de la
+ressemblance entre l’image générée et l’image de référence est effectuée. Si
+l’algorithme constate que l’application d’une de ces formes aléatoire à l’image
+générée améliore cette ressemblance entre cette dernière et l’image de
+ressemblance, la modification est conservée. Sinon elle est ignorée, et une
+nouvelle image candidate au remplacement de l’image générée est créée. En
+d’autres mots, il s’agit d’un équivalent de sélection naturelle au sein des
+images générées aléatoirement ; seules les meilleures sont retenues et seront la
+base des images générées aléatoirement ultérieures. Ce processus se répètera
+autant de fois que l’utilisateur le souhaite.
 
+{{{newpage}}}
 * Les méthodes utilisées
+  :PROPERTIES:
+  :CUSTOM_ID: h-703b5f08-24ce-480d-bfbb-e3b51844138f
+  :END:
 
 Plusieurs approches au problème sont possibles, allant de la simple
-implémentation naïve du problème à des moyen pouvant au moins décupler la
-vitesse de génération de l’image. Sauf indication contraire, j’ai utilisé dans
-l’implémentation de chaque méthode des carrés comme forme d’éléments appliqués
-aléatoirement à l’image.
+implémentation naïve du problème à des moyen pouvant fortement accélérer la
+vitesse de génération de l’image ainsi que sa qualité. Deux types de formes
+aléatoires ont été implémentés : des triangles et des carrés. Les triangles sont
+pour l’instant restreint dans leur dimensions –en effet, ils tiennent tous dans
+un carré, leur hauteur et largeur sur les axes ~x~ et ~y~ étant égales. Il
+serait toutefois possible d’implémenter une version de ce programme générant une
+hauteur et une largeur toutes deux indépendantes l’une de l’autre pour une
+version future du programme. Le choix de la forme se fait via l’utilisation
+d’une option du programme, ~-f [--form]~ prenant pour valeur soit ~1~, le choix
+par défaut, activant alors d’utilisation des carrés, ou bien la valeur ~2~
+activant l’utilisation des triangles.
 
 Pour évaluer la ressemblance entre deux image, j’évalue une distance euclidienne
 entre le vecteur de leurs pixels qui peut se résumer à ceci :
@@ -41,8 +99,9 @@ pixels de l’image générée, et ~n~ la taille de ces deux vecteurs.
 
 Les tests de temps sont réalisés sur un Lenovo Ideapad Y700, disposant d’un
 processeur Intel® Core™ i7-6700HQ à 2.6GHz et un turbo à 3.5GHz, composé de
-quatre cœurs supportant chacun deux threads, et de 16Go de RAM. Le programme est
-compilé avec les options d’optimisation ~-O3~ et ~-flto~.
+quatre cœurs supportant chacun deux threads, et l’ordinateur dispose d’un total
+de de 16Go de RAM. Le programme est compilé avec clang 8.0 et avec les options
+~-Wall -Wextra -Wshadow -Wpedantic -pedantic -O3 -flto~.
 
 Voici également ci-dessous la liste des options et arguments possibles
 concernant l’exécution du logiciel.
@@ -51,20 +110,26 @@ concernant l’exécution du logiciel.
   Allowed options:
     -h [ --help ]           Display this help message
     -i [ --input ] arg      Input image
-    -o [ --output ] arg     Image output path (default: input path + "_output")
+    -o [ --output ] arg     Image output path (default: "output_" + input path)
+    -n [ --iterations ] arg Number of iterations (default: 2000)
     -m [ --method ] arg     Method number to be used (default: 1)
-    -n [ --iterations ] arg Number of iterations (default: 5000)
+    -f [ --form ] arg       Select shape (1:square, 2:triangle)
+    -c [ --cols ] arg       For method 5 only, number of columns the reference
+                            image should be divided into. If the value is equal
+                            to 0, then it will be assumed there will be as many
+                            rows as there are collumns. (default: 0)
+    -r [ --rows ] arg       For method 5 only, number of rows the reference image
+                            should be divided into. (default: 1)
+    -S [ --submethod ] arg  Sub-method that will be used to generate the
+                            individual tiles from method 5. (default: 1)
+    -s [ --size ]           Enables controlled size of the random shapes
     -v [ --verbose ]        Enables verbosity
 #+end_src
 
-Voici le script grâce auquel les valeurs de temps d’exécution ont été obtenues :
-
-#+INCLUDE: ../benchmarks.fish src shell -n
-
-Quelques-unes de ces lignes commençasont là uniquement pour de la mise en forme des
-données afin que je puisse
-
-** Méthode naïve
+** Méthode naïve (méthode 1)
+   :PROPERTIES:
+   :CUSTOM_ID: h-34ace9fe-4c22-434a-8dc5-b913cdf631c6
+   :END:
 
 J’ai tout d’abord implémenté la méthode naïve afin d’avoir une référence en
 matière de temps. Cette dernière est implémentée dans ~src/methods.cc~ avec la
@@ -74,29 +139,32 @@ en l’état essaiera d’appliquer des couleurs n’existant pas dans l’image
 référence, voire complètement à l’opposées de la palette de couleurs de l’image
 de référence.
 
-Voici les moyennes de temps d’exécution selon le nombre d’itérations réussies
-sur le nombre d’exécutions indiqué.
+Voici les options de la commande utilisée ici :
+#+begin_src shell
+  -i img/mahakala-monochrome.jpg -n2000 -m1 -f1 # carrés
+  -i img/mahakala-monochrome.jpg -n2000 -m1 -f2 # triangles
+#+end_src
 
-|                  / |               < |                     < |
-| Nb d’améliorations | Nb d’exécutions | Temps d’exécution (s) |
-|--------------------+-----------------+-----------------------|
-|                 10 |             200 |              0.065881 |
-|                 50 |             100 |              0.130041 |
-|                100 |              50 |              0.186012 |
-|                200 |              20 |              0.385982 |
-|                500 |              10 |              1.437486 |
-|               1000 |               5 |              3.608983 |
+Voici les moyennes de temps d’exécution de cette méthode pour 2.000
+améliorations :
 
-Naturellement, la variation en temps d’exécution croît en même temps que le
-nombre d’améliorations nécessaires à apporter à l’image à améliorer, dû à la
-nature aléatoire de l’algorithme. Cependant, on constate également une
-croissance importante du temps d’exécution suivant également ce nombre
-d’itérations réussies.
+| carrés        | triangles    |
+|---------------+--------------|
+| 10m 40s 615ms | 4m 57s 987ms |
 
-Vous trouverez en Annexes (§[[*M%C3%A9thode 1]]) un exemple d’image générée à partir de
+On constate une plus grande rapidité d’exécution lors de l’utilisation de
+carrés. Je suppose que cela est dû à une facilité avec les triangles à créer des
+traits et bordures inclinées pour lesquelles plusieurs carrés seraient
+nécessaires, ainsi qu’une meilleure flexibilité quant aux formes pouvant être
+créées.
+
+Vous trouverez en Annexes un exemple d’image générée à partir de
 ~img/mahakala-monochrome.png~ avec 2000 améliorations via cette méthode.
 
-** Réduction du panel des couleurs
+** Réduction du panel des couleurs (méthode 2)
+   :PROPERTIES:
+   :CUSTOM_ID: h-dd67b1e5-04ed-4cdf-a9e3-7b3fbf1b2353
+   :END:
 
 Constatant que la majorité des échecs d’ajout de formes de couleur par la
 première méthode échouent dû à une couleur incorrecte, voire n’appartenant pas à
@@ -108,18 +176,17 @@ référence, leur détection étant réalisée avec des threads parallèles pour
 de rapidité à l’exécution. Cette méthode est celle implémentée dans la fonction
 ~method2()~ dans ~src/methods.cc~.
 
-Voici les moyennes de temps d’exécution selon le nombre d’itérations réussies
-sur le nombre d’exécutions indiqué.
+Voici les options de la commande utilisée ici :
+#+begin_src shell
+  -i img/mahakala-monochrome.jpg -n2000 -m2 -f1 # carrés
+  -i img/mahakala-monochrome.jpg -n2000 -m2 -f2 # triangles
+#+end_src
 
-|                  / |               < |                     < |
-| Nb d’améliorations | Nb d’exécutions | Temps d’exécution (s) |
-|--------------------+-----------------+-----------------------|
-|                 10 |             200 |              0.072979 |
-|                 50 |             100 |              0.114426 |
-|                100 |              50 |              0.157965 |
-|                200 |              20 |              0.290475 |
-|                500 |              10 |              0.785426 |
-|               1000 |               5 |              2.664046 |
+Voici le temps moyen d’exécution pour cette méthode avec 2.000 améliorations :
+
+| carrés       | triangles    |
+|--------------+--------------|
+| 7m 23s 774ms | 2m 57s 152ms |
 
 On peut remarquer une amélioration quant à la rapidité d’exécution du logiciel.
 Cependant, le résultat n’est pas aussi important qu’escompté. Je suppose que
@@ -127,15 +194,20 @@ cela est dû au fait que l’algorithme précédent peut considérer un rapproch
 d’une zone déjà colorée vers la couleur d’origine comme une amélioration, avec
 une possibilité plus large sur ce plan-là que pour le second algorithme qui se
 doit d’être plus précis concernant les couleurs. Une nette amélioration du
-résultat est toutefois visibles, voir Annexes (§[[*M%C3%A9thode 2]]) pour une image
-générée à partir de ~img/mahakala-monochrome.png~ via la méthode 2 et avec 2000
-améliorations.
+résultat est toutefois visibles (voir Annexes pour une image générée à partir de
+~img/mahakala-monochrome.png~ via la méthode 2 et avec 2000 améliorations).
+
+À nouveau, on constate également un meilleur temps avec les triangles qu’avec
+les carrés.
 
 Étant donné que cette modification ne sera à priori pas en conflit avec d’autres
 méthodes, cette amélioration sera conservée pour toutes les autres avancées
 suivantes.
 
-** Une taille des formes aléatoire mais contrôlée
+** Une taille des formes aléatoire mais contrôlée (méthode 3)
+   :PROPERTIES:
+   :CUSTOM_ID: h-058e4525-07bb-4a62-8be5-56ad93c5b2e7
+   :END:
 
 Une autre méthode peut être de contrôler la taille des éléments en spécifiant
 une taille minimale et maximale selon le nombre d’éléments posés et le nombre
@@ -147,37 +219,25 @@ forme à appliquer est définie comme suit :
 
 #+begin_export latex
 $$coef=\frac{nbIterRestantes}{totalIter}$$
-$$tailleMinimale=coef \frac{min(Width,Height)}{2}$$
-$$tailleMaximale=tailleMinimale*2+1$$
+$$tailleMinimale=coef\cdot\frac{min(Width,Height)}{2}$$
+$$tailleMaximale=tailleMinimale\cdot2+1$$
 $$taille=Rand([\![tailleMinimale;tailleMaximale[\![)$$
 #+end_export
 
-Voici les moyennes de temps d’exécution selon le nombre d’itérations réussies
-sur le nombre d’exécutions indiqué.
-
-|                  / |               < |                     < |
-| Nb d’améliorations | Nb d’exécutions | Temps d’exécution (s) |
-|--------------------+-----------------+-----------------------|
-|                 10 |             200 |              0.082068 |
-|                 50 |             100 |              0.244236 |
-|                100 |              50 |              0.418075 |
-|                200 |              20 |              1.453703 |
-|                500 |              10 |              4.777205 |
-|               1000 |               5 |              20.33209 |
-
 Cette version du logiciel est nettement plus lente que ses versions précédentes
 du fait de la contrainte de taille pour les formes pouvant potentiellement
-améliorer l’image, cependant la qualité des images générées est plus haute que
-celle des version précédentes, voir en Annexes (§[[*M%C3%A9thode 3]]).
+améliorer l’image, et cela à un tel point que pour 2.000 améliorations, le
+programme tourne durant plus d’une heure. De plus, la qualité de l’image ainsi
+générée n’est pas nécessairement meilleure, ainsi cette méthode n’est pas
+nécessairement bonne. Toujours est-il que j’ai laissé pour les méthodes
+suivantes une option pour l’utilisateur lui permettant d’activer le contrôle de
+la taille des éléments s’il le souhaite via l’option ~-s [--size]~. Toutefois,
+les temps d’exécution des méthodes suivantes n’en tiendront pas compte.
 
-Cette méthode ne me semble que moyennement concluante, certes la vitesse
-d’exécution du logiciel est beaucoup plus faible, mais il est également vrai que
-la qualité des images générées est supérieure aux deux autres méthodes. Ainsi,
-il sera possible d’utiliser les modifications apportées par cette méthode en
-utilisant une option ~-s [ --size ]~ avec les méthodes suivantes pour activer
-cette modification de l’algorithme.
-
-** Concurrence entre threads
+** Concurrence entre threads (méthode 4)
+   :PROPERTIES:
+   :CUSTOM_ID: h-ea0ba369-6334-4013-ae8c-bcba78a77a37
+   :END:
 
 Une utilisation de calculs parallèles pourrait être intéressante afin
 d’accélerer la génération des images : l’utilisation de threads mis en
@@ -187,40 +247,31 @@ résultats sont récupérés et évalués, et parmi les résultats améliorant l
 générée, celle avec le meilleur score est conservée. Cela permet ainsi de
 multiplier les chances d’avoir une amélioration de l’image par tentative.
 
-Voici les benchmarks d’exécution de cette méthode sans contrôle de la taille des
-formes aléatoires :
-|                  / |               < |                     < |
-| Nb d’améliorations | Nb d’exécutions | Temps d’exécution (s) |
-|--------------------+-----------------+-----------------------|
-|                 10 |             200 |              0.080525 |
-|                 50 |             100 |              0.139892 |
-|                100 |              50 |              0.169113 |
-|                200 |              20 |              0.273342 |
-|                500 |              10 |              0.610812 |
-|               1000 |               5 |              1.403816 |
+Voici les options de la commande utilisée ici :
+#+begin_src shell
+  -i img/mahakala-monochrome.jpg -n2000 -m4 -f1 # carrés
+  -i img/mahakala-monochrome.jpg -n2000 -m4 -f2 # triangles
+#+end_src
 
-Et voici les benchmarks d’exécution de cette même méthode avec contrôle de la
-taille des formes aléatoires :
-|                  / |               < |                     < |
-| Nb d’améliorations | Nb d’exécutions | Temps d’exécution (s) |
-|--------------------+-----------------+-----------------------|
-|                 10 |             200 |              0.085981 |
-|                 50 |             100 |              0.156099 |
-|                100 |              50 |               0.29183 |
-|                200 |              20 |               0.59844 |
-|                500 |              10 |              2.513782 |
-|               1000 |               5 |              6.457168 |
+Voici les moyennes de temps d’exécution de cette méthode pour 2.000
+améliorations sans contrôle de la taille des éléments générés :
 
-Pour résumer, ces deux tableaux montrent la parallélisation de la seconde
-méthode et de la troisième méthode respectivement via des threads
-concurrentiels. On peut remarquer que le temps d’exécution s’est nettement
-amélioré, avec un temps d’exécution à peu près deux fois plus rapide pour
-l’exécution sans contrôle de taille des formes que la seconde méthode, et
-pouvant être jusqu’à trois fois plus rapide que la troisième méthode avec le
-contrôle de la taille des formes activée. On a donc une véritable amélioration
-significative avec cette nouvelle version parallèle.
+| carrés       | triangles |
+|--------------+-----------|
+| 2m 30s 636ms | 58s 885ms |
 
-** Collaboration entre threads
+Nous avons cette fois-ci une très nette amélioration de la vitesse d’exécution
+de l’algorithme, ce dernier étant jusqu’à environ trois fois plus rapide que la
+seconde méthode. Il s’agit d’une claire amélioration de la seconde méthode, qui
+elle-même présentait une amélioration de rapidité et de qualité d’image par
+rapport à la première méthode. En revanche, il n’y a pas de différence de
+qualité d’image visible au bout de ces 2.000 améliorations de visible à l’œil nu
+entre les deuxième et quatrième méthodes.
+
+** Collaboration entre threads (méthode 5)
+   :PROPERTIES:
+   :CUSTOM_ID: h-38045bea-a1cb-49e8-ab0e-b8f9861ceb9b
+   :END:
 
 Une différente approche au parallélisme peut être réalisée : plutôt que
 d’essayer de mettre en concurrence plusieurs threads, il serait possible
@@ -233,27 +284,180 @@ alors à nous une fois les différents threads lancés concernant leur méthode
 génération d’image, il est possible d’utiliser chacune des méthodes précédentes.
 Ce choix se fera via une option supplémentaire ~--sub-method~ ou ~-S~.
 
+J’ai choisi d’utiliser les deux méthodes les plus efficaces comme sous-méthodes,
+la deuxième et la quatrième. J’ai choisi la deuxième car il s’agit actuellement
+de la méthode la plus efficace qui ne soit pas parallélisée, et je pense que
+cela pourrait peut-être présenter un avantage par rapport à la quatrième méthode
+qui risque de se retrouvée ralentie par un trop grand nombre de threads lancés
+en même temps ; une image découpée en deux lignes et cinq colonnes, comme cela
+va être le cas ci-dessous, lancera sur le processeur de tests au maximum 2×4×8
+threads en même temps, soit 16 threads simultanés potentiels, deux fois plus
+donc qu’avec la méthode 2 en sous-méthode, qui ne tournera que sur huit threads.
+
+Voici les options de la commande utilisée ici :
+#+begin_src shell
+  -i img/mahakala-monochrome.jpg -n2000 -m5 -c2 -r4 -S4 -f1 # carrés
+  -i img/mahakala-monochrome.jpg -n2000 -m5 -c2 -r4 -S4 -f2 # triangles
+#+end_src
+
+Voici les temps moyens d’exécution pour la cinquième méthode, utilisant en
+sous-méthode la seconde présentée :
+
+| carrés       | triangles   |
+|--------------+-------------|
+| 6m 26s 520ms | 2m 6s 865ms |
+
+Et voici les temps moyens d’exécution pour la même méthode utilisant la
+quatrième méthode comme sous-méthode :
+
+| carrés      | triangles   |
+|-------------+-------------|
+| 4m 26s 78ms | 1m 6s 984ms |
+
+Bien que les deux méthodes n’aient pas nécessairement bénéficiées d’amélioration
+quant à leur temps d’exécution, les images générées via cette cinquième méthode
+sont d’une qualité nettement supérieure aux images générées jusqu’à présent,
+avec un niveau de détail largement meilleur. La quatrième méthode utilisée en
+sous-méthode présente un avantage sur la seconde en considérant le temps
+d’exécution, et il semblerait que l’on puisse remarquer une légère amélioration
+de l’image également. Cependant, et bien que cela soit plus lent, la génération
+à base de carrés présente cette fois-ci un avantage par rapport à la génération
+à base de triangles : ces derniers cachent beaucoup plus aisément la séparation
+entre les différentes zones de génération de l’image que les triangles, sans
+doutes dû à la difficulté d’obtenir des zones de remplissages dont un des côtés
+soit parfaitement vertical ou horizontal avec ces derniers.
+
+J’ai également remarqué que si l’on utilise un grand nombre de colonnes et de
+lignes, le programme peut mettre énormément de temps pour effectuer sa tâche.
+Avec l’image de test, j’ai exécuté le logiciel en divisant l’image de test en
+cinq colonnes et lignes, donnant un total de vingt-cinq threads exécutant chacun
+une méthode sur une zone de l’image ; j’ai dû manuellement arrêter le programme
+au bout de plus d’une heure de travail afin de ne pas perdre de temps. Je pense
+que cela est dû à certaines zones étant très homogènes, rendant le travail
+d’amélioration de cette zone très difficile quand la majorité de la zone est à
+peu près identique à sa version originale, chaque amélioration ne pouvant
+s’effectuer que sur quelques pixels tout au plus.
+
+{{{newpage}}}
+* Conclusion
+  :PROPERTIES:
+  :CUSTOM_ID: h-ba75708b-da5b-445b-b4d1-624e20a37ad9
+  :END:
+
+Plusieurs approches ont été abordées lors de ce projet quand à la meilleure
+méthode de génération d’images basée sur des formes aléatoires, aux couleurs
+aléatoires. Quelques unes d’entre elles portent sur un certain contrôle du
+facteur aléatoire, tandis que d’autres tentent de tirer profit du matériel
+utilisé afin de disposer d’une plus grande puissance de calcul. Alors que l’on a
+constaté qu’une limitation de l’arbitraire quant au panel de couleurs possibles
+est intéressante, celle de leur taille l’est moins, tout du moins avec la
+formule utilisée. Il serait néamoins intéressant de réitérer cette tentative
+avec une autre approche, comme par exemple réduire la taille maximale des
+éléments suite à un certain nombre d’échecs de génération de successeurs
+successifs.
+
+En revanche, les méthodes consistant à répartir la charge de travail sur
+plusieurs threads ont été chacune couronnées de succès, et ultimement la
+combination d’une méthode se basant sur la concurrence entre threads elle-même
+lancée en collaboration avec d’autres de cette même méthode s’est prouvée être
+l’une des méthodes les plus efficaces afin de re-créer avec fidélité une image
+de référence.
+
+Note intéressante : la génération d’image avec des triangles est plus rapide
+qu’une génération d’image basée sur des carrés, mais ces derniers seront la
+forme la plus efficace visuellement lors de cette cinquième et meilleure méthode
+présentée dans ce rapport.
+
+{{{newpage}}}
 * Annexes
+  :PROPERTIES:
+  :CUSTOM_ID: h-077e6074-6117-4baf-93ce-723faea5cde2
+  :END:
+** Code
+   :PROPERTIES:
+   :CUSTOM_ID: h-561530b8-dd10-4bd7-9918-0afa79bd6f2e
+   :END:
+*** ~src/main.cc~
+    :PROPERTIES:
+    :CUSTOM_ID: h-023c2313-f912-4f8b-ad40-0c5dace0b7aa
+    :END:
+#+INCLUDE: ../src/main.cc src c++ -n
+
+*** ~include/genimg/shapes.hh~
+    :PROPERTIES:
+    :CUSTOM_ID: h-2ac81b89-94d9-48de-a020-d838a8655dce
+    :END:
+#+INCLUDE: ../include/genimg/shapes.hh src c++ -n
+
+*** ~src/shapes.cc~
+    :PROPERTIES:
+    :CUSTOM_ID: h-d039100c-a975-4200-964e-b5f2091cce5f
+    :END:
+#+INCLUDE: ../src/shapes.cc src c++ -n
+
+*** ~include/genimg/methods.hh~
+    :PROPERTIES:
+    :CUSTOM_ID: h-6a670e34-4292-4e13-8a7c-df091375d980
+    :END:
+#+INCLUDE: ../include/genimg/methods.hh src c++ -n
+
+*** ~src/methods.cc~
+    :PROPERTIES:
+    :CUSTOM_ID: h-3321dadc-c768-44b6-863a-51b5c45115c8
+    :END:
+#+INCLUDE: ../src/methods.cc src c++ -n
+
+*** ~include/genimg/parseargs.hh~
+    :PROPERTIES:
+    :CUSTOM_ID: h-497e47cb-1bde-4bdc-9cd0-c5547a93f20f
+    :END:
+#+INCLUDE: ../include/genimg/parseargs.hh src c++ -n
+
+*** ~src/parseargs.cc~
+    :PROPERTIES:
+    :CUSTOM_ID: h-c43eaaf6-c963-4a45-8ae1-b939b9750d88
+    :END:
+#+INCLUDE: ../src/parseargs.cc src c++ -n
+
 ** Images
+   :PROPERTIES:
+   :CUSTOM_ID: h-9eb043df-229e-461e-9d2c-1b7cbeda88af
+   :END:
 *** Image de référence
-#+CAPTION: Image de référence utilisée pour les tests du logiciel
+    :PROPERTIES:
+    :CUSTOM_ID: h-ba67dd5b-2918-4128-8521-c88329392744
+    :END:
+
+#+CAPTION: Image de référence
 [[../img/mahakala-monochrome.jpg]]
-*** Méthode 1
-#+CAPTION: Image générée à partir de ~img/mahakala-monochrome.png~ avec 2000 améliorations avec la première méthode
-[[./output1.png]]
 
-*** Méthode 2
-#+CAPTION: Image générée à partir de ~img/mahakala-monochrome.png~ avec 2000 améliorations avec la seconde méthode
-[[./output2.png]]
 
-*** Méthode 3
-#+CAPTION: Image générée à partir de ~img/mahakala-monochrome.png~ avec 2000 améliorations avec la troisième méthode
-[[./output3.png]]
+#+CAPTION: Méthode 1, carrés
+[[./output1-1.png]]
 
-*** Méthode 4
-**** Taille des formes non contrôlée
-#+CAPTION: Image générée à partir de ~img/mahakala-monochrome.png~ avec 2000 améliorations avec la quatrième méthode sans l’option ~-s~
+#+CAPTION: Méthode 1, triangles
+[[./output1-2.png]]
+
+#+CAPTION: Méthode 2, carrés
+[[./output2-1.png]]
+
+#+CAPTION: Méthode 2, triangles
+[[./output2-2.png]]
+
+#+CAPTION: Méthode 4, carrés
 [[./output4-1.png]]
-**** Taille des formes contrôlée
-#+CAPTION: Image générée à partir de ~img/mahakala-monochrome.png~ avec 2000 améliorations avec la quatrième méthode avec l’option ~-s~
+
+#+CAPTION: Méthode 4, triangles
 [[./output4-2.png]]
+
+#+CAPTION: Méthode 5, sous-méthode 2, carrés
+[[./output5-2-1.png]]
+
+#+CAPTION: Méthode 5, sous-méthode 2, triangles
+[[./output5-2-2.png]]
+
+#+CAPTION: Méthode 5, sous-méthode 4, carrés
+[[./output5-4-1.png]]
+
+#+CAPTION: Méthode 5, sous-méthode 4, triangles
+[[./output5-4-2.png]]

src/parseargs.cc

@@ -81,7 +81,6 @@ void processFilenames(po::variables_map const &t_vm, path const &t_input,
   ret.output_path = output_path;
   ret.iterations  = vm.count("iterations") ? vm["iterations"].as<int>()
                                           : DEFAULT_ITERATIONS;
-  spdlog::debug("arg: {}", vm.count("form") ? vm["form"].as<int>() : 1);
   ret.method = vm.count("method") ? vm["method"].as<int>() : 1;
   switch (vm.count("form") ? vm["form"].as<int>() : 1) {
   case 2: ret.shape = Shape::ShapeType::Triangle; break;

tests/tests.cc

@@ -1,19 +0,0 @@
-#include <gtest/gtest.h>
-
-TEST(SquareRootTest, PositiveNos)
-{
-	ASSERT_EQ(6, 2 * 3);
-	ASSERT_EQ(6, -2 * -3);
-}
-
-TEST(SquareRootTest, NegativeNos)
-{
-	ASSERT_EQ(-6, -2 * 3);
-	ASSERT_EQ(-6, 2 * -3);
-}
-
-int main(int argc, char** argv)
-{
-	testing::InitGoogleTest(&argc, argv);
-	return RUN_ALL_TESTS();
-}