updates on files, removed obsolete file

Makefile

@@ -10,7 +10,9 @@ clean:
 	@rm -rf bin
 	@rm -rf build
 	@rm -rf debug
-	@rm -rf doc/html
-	@rm -rf doc/latex
-	@rm -rf gmon.out
 	@rm -rf cmake-build-debug
+	@rm -rf auto
+	@rm -rf doc/*/
+	@rm -rf _minted*
+	@rm -rf output.*
+	@rm -rf *.tex *.out

TODOs.org

@@ -1,11 +0,0 @@
-* Development
-** TODO Remove y axis on segments
-** TODO Test if the zones detection works
-** TODO Add compressed file output
-** TODO Add file uncompression
-** TODO Add tolerance parameter
-* Tests
-** TODO Add tests for darray
-** TODO Add tests for zones
-** TODO Add tests for files reading
-** TODO Add tests for file comparison after compression and uncompression

rapport.org

@@ -27,25 +27,79 @@ Actuellement, avec l’image de test que l’on peut trouver sur mon dépôt git
 Pour ce qui est du temps d’exécution, j’exécute le script suivant avec la commande ~./run-time.sh 10~ (10 étant le nombre d’exécutions que je souhaite effectuer) afin d’obtenir le temps d’exécution à répétition du programme :
 #+INCLUDE: ./run-time.sh src shell
 
-Ainsi, j’obtient la moyenne sur dix exécutions d’un temps d’exécution de 8,898 secondes sur un CPU Intel i7-6700HQ (3.500GHz).
+Ainsi, j’obtient la moyenne sur dix exécutions d’un temps d’exécution de 7.06 secondes sur un CPU Intel i7-6700HQ (3.500GHz).
 
 * Améliorations possibles
 ** Algorithme
+*** Théorie
 Il est possible d’améliorer l’algorithme par rapport à celui utilisé initialement en ignorant l’étape de test des pixels supérieurs et inférieurs à un segment testé. En effet, cette étape est un résidu de l’algorithem d’origine qui a pour but de ne détecter qu’une zone dont tous les segments sont contigus à au moint un autre segment de la même forme, le tout ne constituant qu’une seule et unique forme continue. Hors ici ce dernier point ne nous intéresse pas, et deux formes de la même couleur n’ont pas à être considérées comme étant deux entités différentes. Ainsi, en ignorant cette étape cela permet de passer de manière itérative sur tous les pixels, simplifiant ainsi l’algorithme.
-# TODO: faire cette version de l’algo
+
+*** Modifications apportées
+La modification apportée au code source est relativement simple étant donné qu’il suffit de commenter les deux dernières boucles ~for~ de la fonction ~addPixelToSelectedZone~ du fichier ~compress.c~. Cela bloque l’exécution de la fonction créant les segments à partir des pixels au dessus et en dessous du segment courant.
+#+BEGIN_SRC text
+     }
+     darrayPushBack(t_zone->segments,
+                    newSegment((uint32_t)right_limit, (uint32_t)left_limit));
+  -  for (; left_limit <= right_limit; ++left_limit) {
+  -    addPixelToSelectedZone(t_img, t_idx + t_img->sizeX, t_zone);
+  -  }
+  -  for (; left_limit <= right_limit; ++left_limit) {
+  -    addPixelToSelectedZone(t_img, t_idx - t_img->sizeX, t_zone);
+  -  }
+  +  /* for (; left_limit <= right_limit; ++left_limit) { */
+  +  /*   addPixelToSelectedZone(t_img, t_idx + t_img->sizeX, t_zone); */
+  +  /* } */
+  +  /* for (; left_limit <= right_limit; ++left_limit) { */
+  +  /*   addPixelToSelectedZone(t_img, t_idx - t_img->sizeX, t_zone); */
+  +  /* } */
+   }
+#+END_SRC
+
+*** Résultats
+Avec dix exécutions successives, sur le même processeur avec les mêmes arguments et le programme également compilé avec les options d’optimisation `-O3` également, j’obtiens une vitesse d’exécution moyenne à la compression/décompression successives de 7.23s, soit une perte de 2.35% du temps d’exécution d’origine. J’explique cela par le fait que pour chaque nouveau pixel non-traité, il est nécessaire de trouver la zone correspondant à la couleur du nouveau pixel, ce qui en soit prend du temps alors qu’avec la méthode d’origine, on connaît déjà la zone et on n’a qu’à explorer les pixels de couleur unie, sachant que là où on a le plus de chance de trouver des pixels de couleur identique sur des images de type comics est au niveau des pixels adjascents au pixel actuel. Ainsi, cette piste s’est révélée non concluante, et je ne continuerai pas dans cette direction.
 
 ** Sortir du concept d’image avec des lignes et colonnes
+*** Théorie
 L’algorithme actuel considère le fichier d’entrée comme étant une image en deux dimensions, limitant ainsi les segments au début d’une ligne de pixels même si le pixel précédent dans le vecteur dans lequel ces derniers sont stockés est de la même couleur, divisant ainsi des segments en plusieurs segments inutilement. En ignorant ces fins de lignes pour ne procéder qu’à l’analyse des pixels comme ne faisant partie que d’une ligne unique permettrait d’éviter ces ajouts inutiles de segments, et ainsi économiser un peu d’espace avec le fichier compressé. Cependant, je ne pense pas que cette solution soit aussi efficace que la possibilité suivante avec laquelle la possibilité actuelle d’optimisation n’est pas compatible.
+*** Modifications apportées
+Les deux boucles de la fonction ~addPixelToSelectedZone~ cherchant les segments ont été modifiées ainsi :
+#+BEGIN_SRC C
+  for (right_limit = t_idx; right_limit < img_size; ++right_limit) {
+    current_pixel = darrayGet(t_img->pixels, (size_t)right_limit);
+    if (!sameColor(current_pixel, t_zone)) {
+      break;
+    }
+    (*current_pixel).visited = 1;
+   }
+
+  for (left_limit = t_idx; left_limit > 0; --left_limit) {
+    current_pixel = darrayGet(t_img->pixels, (size_t)left_limit);
+    if (current_pixel->visited || !sameColor(current_pixel, t_zone)) {
+      break;
+    }
+    (*current_pixel).visited = 1;
+   }
+#+END_SRC
+Cette modification permet d’ignorer les retours à la ligne et ainsi potentiellement économiser de l’espace lors de l’écriture de fichier compressés.
+
+*** Résultats
+    Hélas le gain d’espace n’est pas flagrant, et cela s’explique par le faible nombre de lignes de pixels de l’image, 1500 dans ce cas, et du fait qu’économiser deux ~uint32_t~ par ligne est une amélioration mineure, permettant dans le cas de l’image ~asterix.ppm~ d’économiser uniquement 12 kilo octets. La différence sur le fichier compressé de 2.3 méga octets d’origine est donc négligeable. Je ne continuerai donc pas de travailler sur cette piste.
 
 ** Espace de stockage
+*** Théorie
 Actuellement, chaque position de pixel est stockée via deux ~uint64_t~ donnant l’extrême gauche et l’extrême droite d’un segment, ainsi stockant le segment individuel sur seize octets. L’emplacement est considéré comme étant l’emplacement sur un vecteur à dimension unique stockant successivement tous les pixels. Il est possible à la place de cette méthode de considérer la dimension duelle de l’image et de ne stocker que la position verticale du segment et ses extrêmes gauche et droit sur un ~uint32_t~. Cela permet donc d’indexer des segments sur des images de 2^{64} pixels (plus de quatre milliards de pixels) de haut et de large, ce qui est largement suffisant pour la majorité des cas, tout en utilisant quatre octets de moins que pour la version actuelle du programme. Il serait également possible de stocker ces valeurs sur trois ~uint16_t~, n’utilisant ainsi que six octets au total et limitant la taille maximale de l’image d’entrée à 2^{16} pixels de haut et de large.
+*** Modifications apportées
+*** Résultats
 
 ** Passer à de la compression à pertes
+*** Théorie
 Il existe toujours la possibilité de ne plus faire que de la compression sans pertes mais de faire également de la compression avec pertes, en acceptant en argument un taux de tolérance quant à la similarité des couleurs entre elles. Ainsi, cela éliminera certaines couleurs de l’image et économisera ainsi des zones disposant d’un petit nombre de zones ou de segments en les assimilant aux couleurs qui leur sont proches. L’inconvénient est qu’avec ce paramètre, il sera impossible de restituer l’image d’origine à l’identique.
+*** Modifications apportées
+*** Résultats
 
-# TODO : bosser dessus
+* Associations des différentes propositions
 
-** Résultats des diverses options
+Il est également possible d’associer certaines des propositions précédentes améliorantes afin de tester si elles peuvent davantage améliorer le projet.
 
 * Conclusion
 

run-time.sh

@@ -8,6 +8,7 @@ echo "Starting $1 runs of surfaces-unies"
 start=$(date +%s.%N)
 for i in `seq 1 $1`; do
 	./bin/surfaces-unies -c -i ./img/asterix.ppm
+	./bin/surfaces-unies -u -i output.su
 done
 end=$(date +%s.%N)    
 runtime=$(python -c "print((${end} - ${start}) / ${1})")

src/compress.c

@@ -39,7 +39,6 @@ void addPixelToSelectedZone(Image *t_img, int64_t t_idx, Zone *t_zone) {
   const uint32_t y = (uint32_t)(t_idx / t_img->sizeX);
   int64_t left_limit, right_limit;
   const int64_t xd_limit = (int64_t)t_img->sizeX * (y + 1);
-
   if (t_idx >= (int64_t)img_size || t_idx < 0) {
     return;
   }
@@ -48,6 +47,7 @@ void addPixelToSelectedZone(Image *t_img, int64_t t_idx, Zone *t_zone) {
     return;
   }
   (*current_pixel).visited = 1;
+
   for (right_limit = t_idx; right_limit < xd_limit; ++right_limit) {
     current_pixel = darrayGet(t_img->pixels, (size_t)right_limit);
     if (!sameColor(current_pixel, t_zone)) {
@@ -55,7 +55,6 @@ void addPixelToSelectedZone(Image *t_img, int64_t t_idx, Zone *t_zone) {
     }
     current_pixel->visited = 1;
   }
-
   for (left_limit = t_idx; left_limit - (y - 1) * (int64_t)t_img->sizeX >= 0;
        --left_limit) {
     current_pixel = darrayGet(t_img->pixels, (size_t)left_limit);
@@ -64,6 +63,7 @@ void addPixelToSelectedZone(Image *t_img, int64_t t_idx, Zone *t_zone) {
     }
     (*current_pixel).visited = 1;
   }
+
   darrayPushBack(t_zone->segments,
                  newSegment((uint32_t)right_limit, (uint32_t)left_limit));
   for (; left_limit <= right_limit; ++left_limit) {