report update
This commit is contained in:
parent
fe41a56c66
commit
b221c07e97
16
rapport.org
16
rapport.org
@ -22,6 +22,13 @@ Le but de ce projet a été de créer un logiciel permettant la compression d’
|
||||
|
||||
Afin de résoudre ce problème, je me suis basé sur un algorithme de M. Jean-Jaques Bourdin et l’ai adapté au problème de la manière suivante : pour chaque pixel de l’image, je teste si le pixel courant a une couleur identique à la couleur d’une surface, ou zone, déjà existante. Si une telle zone n’existe pas déjà, alors je la créé puis pour chaque pixel de la ligne courante je me déplace à l’extrême gauche et à l’extrê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 à l’ajouter à 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.
|
||||
|
||||
Actuellement, avec l’image de test que l’on peut trouver sur mon dépôt git (lien en annexes) d’une taille de 3582016 octets, j’obtiens un taux de compression de 67% environ avec une image compressée à 2403581 octets.
|
||||
|
||||
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).
|
||||
|
||||
* Améliorations possibles
|
||||
** Algorithme
|
||||
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.
|
||||
@ -33,12 +40,21 @@ L’algorithme actuel considère le fichier d’entrée comme étant une image e
|
||||
** Espace de stockage
|
||||
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.
|
||||
|
||||
** Passer à de la compression à pertes
|
||||
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.
|
||||
|
||||
# TODO : bosser dessus
|
||||
|
||||
** Résultats des diverses options
|
||||
|
||||
* Conclusion
|
||||
|
||||
src_latex{\newpage}
|
||||
* Annexes
|
||||
** 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
|
||||
|
BIN
rapport.pdf
BIN
rapport.pdf
Binary file not shown.
Loading…
Reference in New Issue
Block a user