surfaces-unies/rapport.org

152 lines
10 KiB
Org Mode
Raw Normal View History

#+TITLE: Compression dimages par surfaces unies
#+SUBTITLE: Rapport de projet
#+AUTHOR: Lucien Cartier-Tilet
#+EMAIL: phundrak@phundrak.fr
#+CREATOR: Lucien Cartier-Tilet
#+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{xcolor} \usepackage{hyperref}
#+LATEX_HEADER: \hypersetup{colorlinks=true,linkbordercolor=red,linkcolor=blue,pdfborderstyle={/S/U/W 1}}
#+OPTIONS: toc:nil
src_latex{\newpage}
#+TOC: headlines
src_latex{\newpage}
* Le problème
Le but de ce projet a été de créer un logiciel permettant la compression dimages via la détection de surfaces dune même couleur, ainsi que de permettre la décompression du fichier ainsi généré à la compression en une image identique à limage dorigine. Il est à noter que cet algorithme est orienté vers les images de style /comics/ ou avec peu de couleurs, doù limage test que vous trouverez en [[*Image de test][annexe]] qui fut mon image de test principale.
* Résolution initiale du problème
Afin de résoudre ce problème, je me suis basé sur un algorithme de M. Jean-Jaques Bourdin et lai adapté au problème de la manière suivante : pour chaque pixel de limage, je teste si le pixel courant a une couleur identique à la couleur dune surface, ou zone, déjà existante. Si une telle zone nexiste pas déjà, alors je la créé puis pour chaque pixel de la ligne courante je me déplace à lextrême gauche et à lextrême droite du segment de la même couleur que le pixel courant. Ainsi on obtient un segment de couleur unie, et il est donc possible de maintenant stocker uniquement les limites de ce segment et à lajouter à la collection de segments de la zone, qui elle contient les informations de la couleur de la zone. Ensuite, pour chaque pixel en dessus puis en dessous de ce segment, on répète la même procédure. Cela permet de lister toutes les zones contigües et de les ajouter ainsi à la zone courante.
2018-11-27 14:49:34 +00:00
Actuellement, avec limage de test que lon peut trouver sur mon dépôt git (lien en annexes) dune taille de 3582016 octets, jobtiens un taux de compression de 67% environ avec une image compressée à 2403581 octets.
Pour ce qui est du temps dexécution, jexécute le script suivant avec la commande ~./run-time.sh 10~ (10 étant le nombre dexécutions que je souhaite effectuer) afin dobtenir le temps dexécution à répétition du programme :
#+INCLUDE: ./run-time.sh src shell
Ainsi, jobtient la moyenne sur dix exécutions dun temps dexécution de 7.06 secondes sur un CPU Intel i7-6700HQ (3.500GHz).
2018-11-27 14:49:34 +00:00
* Améliorations possibles
** Algorithme
*** Théorie
Il est possible daméliorer lalgorithme 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 lalgorithem dorigine qui a pour but de ne détecter quune zone dont tous les segments sont contigus à au moint un autre segment de la même forme, le tout ne constituant quune seule et unique forme continue. Hors ici ce dernier point ne nous intéresse pas, et deux formes de la même couleur nont 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 lalgorithme.
*** Modifications apportées
La modification apportée au code source est relativement simple étant donné quil suffit de commenter les deux dernières boucles ~for~ de la fonction ~addPixelToSelectedZone~ du fichier ~compress.c~. Cela bloque lexé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 doptimisation `-O3` également, jobtiens une vitesse dexécution moyenne à la compression/décompression successives de 7.23s, soit une perte de 2.35% du temps dexécution dorigine. Jexplique 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 quavec la méthode dorigine, on connaît déjà la zone et on na 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 sest révélée non concluante, et je ne continuerai pas dans cette direction.
** Sortir du concept dimage avec des lignes et colonnes
*** Théorie
Lalgorithme actuel considère le fichier dentrée comme étant une image en deux dimensions, limitant ainsi les segments au début dune 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à lanalyse des pixels comme ne faisant partie que dune ligne unique permettrait déviter ces ajouts inutiles de segments, et ainsi économiser un peu despace avec le fichier compressé. Cependant, je ne pense pas que cette solution soit aussi efficace que la possibilité suivante avec laquelle la possibilité actuelle doptimisation nest 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 dignorer les retours à la ligne et ainsi potentiellement économiser de lespace lors de lécriture de fichier compressés.
*** Résultats
Hélas le gain despace nest pas flagrant, et cela sexplique par le faible nombre de lignes de pixels de limage, 1500 dans ce cas, et du fait quéconomiser deux ~uint32_t~ par ligne est une amélioration mineure, permettant dans le cas de limage ~asterix.ppm~ déconomiser uniquement 12 kilo octets. La différence sur le fichier compressé de 2.3 méga octets dorigine 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 lextrême gauche et lextrême droite dun segment, ainsi stockant le segment individuel sur seize octets. Lemplacement est considéré comme étant lemplacement 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 limage et de ne stocker que la position verticale du segment et ses extrêmes gauche et droit sur un ~uint32_t~. Cela permet donc dindexer 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~, nutilisant ainsi que six octets au total et limitant la taille maximale de limage dentrée à 2^{16} pixels de haut et de large.
*** Modifications apportées
*** Résultats
2018-11-27 14:49:34 +00:00
** Passer à de la compression à pertes
*** Théorie
2018-11-27 14:49:34 +00:00
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 limage et économisera ainsi des zones disposant dun petit nombre de zones ou de segments en les assimilant aux couleurs qui leur sont proches. Linconvénient est quavec ce paramètre, il sera impossible de restituer limage dorigine à lidentique.
*** Modifications apportées
*** Résultats
2018-11-27 14:49:34 +00:00
* Associations des différentes propositions
Il est également possible dassocier certaines des propositions précédentes améliorantes afin de tester si elles peuvent davantage améliorer le projet.
2018-11-27 14:49:34 +00:00
* Conclusion
src_latex{\newpage}
* Annexes
2018-11-27 14:49:34 +00:00
** Liens
- Dépôt :: [[https://labs.phundrak.fr/phundrak/surfaces-unies/]]
- Image de test :: [[https://labs.phundrak.fr/phundrak/surfaces-unies/blob/master/img/asterix.ppm]]
src_latex{\newpage}
** Image de test
#+ATTR_LATEX: :width 4.0in
[[./img/asterix.png]]
src_latex{\newpage}
** Code source
~main.c~
#+INCLUDE: ./src/main.c src C -n
~compress.h~
#+INCLUDE: ./src/compress.h src C -n
~compress.c~
#+INCLUDE: ./src/compress.c src C -n
~uncompress.h~
#+INCLUDE: ./src/uncompress.h src C -n
~uncompress.c~
#+INCLUDE: ./src/uncompress.c src C -n
~ppm.h~
#+INCLUDE: ./src/ppm.h src C -n
~ppm.c~
#+INCLUDE: ./src/ppm.c src C -n
~utilities.h~
#+INCLUDE: ./src/utilities.h src C -n
~utilities.c~
#+INCLUDE: ./src/utilities.c src C -n
~darray.h~
#+INCLUDE: ./src/darray.h src C -n
~darray.c~
#+INCLUDE: ./src/darray.c src C -n