Je me suis moi-même intéressé à la compression RLE, puisque développant un programme de création d'images on-calc.
Cependant, je n'ai quasiment rien compris aux diverses explications données sur ce sujet...
Je me permet donc de poster ici ma propre version du codage RLE pour TI68k.
Excusez moi si je ne fais que répèter de façon plus simple ce que vous avez dit plus haut.
Donc, en espérant faire avancer les choses:
-On étudie les suites de pixels noirs ou blancs dans l'image.
-On stocke le nombre de pixels de même teinte dans le premier octet.
-On continue avec la deuxième suite de pixels. On stocke uniquement le nombre de pixels de même teinte, et pas de '1' ou de '0' pour indiquer quelle a été la teinte de la suite de pixels stockés.
Par exemple, si dans notre image on a : NNNNNBBNNNNNNNNNBBBBBBNN, le fichier généré sera sous la forme: "5, 2, 9, 6, 2".
En effet il est inutile de faire un fichier de la forme "5, 1, 2, 0, 9, 1, 6, 0, 2, 1" (ou les '1' et les '0' désignent la teinte des suites de pixels) puisque sur une calculatrice TI il n'y a que du noir et du blanc... Donc après une suite de pixels blancs vient forcément une suite de pixels noirs et vice-versa!
Notre fichier de sauvegarde ne contient ainsi que les informations concernant la taille des suites des pixels de même teinte, et pas d'informations inutiles.
Cependant plusieurs problèmes apparaissent:
-Que faire si une suite de pixels de même couleur dépasse 256?
En effet on ne peut pas stocker '270', par exemple, dans un seul octet. Dans ce cas il suffit de stocker de la façon suivante...
Puiqu'on ne peut pas stocker "270", on stocke "256, 0, 14". Ainsi la machine trace les 256 premiers pixels noirs (par exemple), puis 0 blancs, et recommence avec 14 noirs... On obtient notre suite de 270 pixels! On perd ainsi un octet, mais des suites de plus de 256 pixels sont rares sur une TI... ces quelques exceptions ne représenteront donc pas une perte conséquente de mémoire.
-Certaines parties de l'image ne sont pas "rentables" en terme de compression, que faire?
En effet avec le RLE les suites de pixels type BNBNBNBNBN font perdre beaucoup de mémoire. Il suffit dans ce cas là d'appliquer dans le fichier sauvegarde le bandeau "0,0" qui montre qu'on change de système de compression et qu'il faut stopper le RLE (et, par exemple, passer à un système de compression "classique" de 8 pixels par octet).
En effet une suite de deux '0' ne peut pas être rencontrée dans un fichier (elle signifierait que c'est la fin du fichier en théorie, mais en pratique on ne marque pas la fin du fichier, qui se déduit de la fin de la lecture du fichier ou du fait qu'on ait rempli tous les pixels de l'écran avec les données issues du fichier). Ainsi le bandeau "0,0" permet d'écarter la compression RLE des parties non rentables (ces parties peuvent être repérées au préalable par une pré-lecture de l'image à compresser).
Précisons que ma technique marche aussi dans le cas d'une image en niveaux de gris, puisqu'après tout une image en 4 teintes n'est qu'une superposition plus ou moins rapide de pixels noirs et de pixels blancs. Il suffit alors d'enregistrer les deux images (Plan clair et plan foncé) séparement.
Ma technique nécessite de préciser dans le programme qu'on commence toujours une image avec un pixel de même teinte (noir par exemple). Il suffit donc, si l'on veut par exemple commencer l'image avec un pixel blanc, commencer le fichier par un '0'. Ainsi la calculatrice comprendra: "Je trace 0 noirs en premier". Ainsi la première suite de pixels sera bien une suite blanche. Si l'on n'avait pas précisé cela, on se serait retrouvé régulièrement avec des images en négatif!
Voila, j'ai fini, j'espère avoir été clair.
J'espère de tout coeur avoir apporté quelquechose à ton programme.
A bientôt,
Daniel.