Compression RLE - Page 1

Je m'intéresse à ce type de compression pour des images noir/blanc, mais malgré ce que j'ai pu lire sur Internet, je crois que je n'ai pas saisi quelques subtilités...
On regroupe donc les suites de plus de 3 bytes identiques, et on code ceci sur 3 bytes : flag|nombre_de_fois|byte_à_reproduire. Mais comment fait-on au décodage si le byte flag apparaît précédé de n'importe quel autre et suivi d'un groupe de deux autres bytes, différents entre eux, et dont le premier est différent du byte flag ?

J'aurai peut-être d'autres questions qui apparaîtront au long de mes recherches...
Merci d'avance

J'ai rien compris

Ymox > Je ne connais pas le RLE (ou en tout cas qu'en théorie) et je ne suis pas certain d'avoir compris ta question, mais le flag ne doit jamais être reproduit dans les séquences nb_fois / byte_reprod ; pour ça je pense qu'il doit y avoir une séquence d'échappement qui permet d'encoder une chaîne d'octets équivalente au flag mais n'était pas un flag.

Ymox (./1) :
Je m'intéresse à ce type de compression pour des images noir/blanc, mais malgré ce que j'ai pu lire sur Internet, je crois que je n'ai pas saisi quelques subtilités...
On regroupe donc les suites de plus de 3 bytes identiques, et on code ceci sur 3 bytes : flag|nombre_de_fois|byte_à_reproduire. Mais comment fait-on au décodage si le byte flag apparaît précédé de n'importe quel autre et suivi d'un groupe de deux autres bytes, différents entre eux, et dont le premier est différent du byte flag ?

comme dit Nil il faut que tu aies une séquence commençant par "flag" qui te permette de représenter l'octet flag isolé ; une solution simple serait de prendre tout simplement "flag|1|flag" -- l'avantage c'est que tu n'auras pas à prévoir spécialement ce cas dans le décodeur, c'est juste un RLE comme les autres

après tu peux faire qqch de plus fin, par exemple étant donné que "flag|1|<un autre octet que flag>" n'aurait aucun intérêt (prend 3 octets au lieu d'un) tu peux décréter que si la longueur de la séquence RLE vaut 1 alors l'octet à reproduire sera systématiquement flag : ça permet de ne prendre que 2 octets au lieu de 3 quand tu tombes sur un flag cela dit c'est pas forcément une bonne idée, parce que ça va rajouter au bas mot une dizaine d'octets dans ton décodeur alors que ça n'apportera au mieux qu'une amélioration de 1/256 = 0.4% du taux de compression... (et sur un fichier "normal" l'amélioration sera nettement plus faible)

Ca dépend de beaucoup de choses, peut-être que son décodeur peut se permettre de faire quelques octets de plus mais qu'il cherche une optimisation maximale (pour un exercice, pour une plateforme donnée...) - même si sur le principe, je suis totalement d'accord avec toi.

Pollux (./4) :
alors que ça n'apportera au mieux qu'une amélioration de 1/256 = 0.4% du taux de compression...

Non, au mieux ça apporte une amélioration de 25%, sur la séquence d'entrée flag x flag x flag x flag x ....

je suppose bien entendu que flag est variable plutôt qu'une constante fixe... dans ce cas-là quelle que soit l'entrée on peut choisir flag comme étant le caractère non répété le plus rare, donc il faut l'échapper au plus une fois sur 256 ^^

et tu peut aussi avant de compresser faire une stat sur l'utilisation des caracteres dans le fichier, et regarder celui qui apparais le moins souvent et/ou pas du tout est l"utiliser comme marquer flag. Apres il faut ajouter une en-tete dans ton fichier compresser pour pouvoir stoquer quel es le caractere de flag, mais ça peut aussi etre un bon moyen d'éviter d'utiliser malencontreusement le caractere le plus utilisé dans le fichier comme flag. #pasclair#

Merci tout le monde sauf peut-être Sasume pour son très constructif ./2

Nil (./3) :
pour ça je pense qu'il doit y avoir une séquence d'échappement qui permet d'encoder une chaîne d'octets équivalente au flag mais n'était pas un flag.

---

Pollux (./4) :comme dit Nil il faut que tu aies une séquence commençant par "flag" qui te permette de représenter l'octet flag isolé ; une solution simple serait de prendre tout simplement "flag|1|flag"

Oui, effectivement, il y aurait eu cette possibilité, mais cela fait 3 octets au lieu d'un...

Pollux (./4) :
après tu peux faire qqch de plus fin, par exemple étant donné que "flag|1|" n'aurait aucun intérêt (prend 3 octets au lieu d'un) tu peux décréter que si la longueur de la séquence RLE vaut 1 alors l'octet à reproduire sera systématiquement flag : ça permet de ne prendre que 2 octets au lieu de 3 quand tu tombes sur un flag cela dit c'est pas forcément une bonne idée, parce que ça va rajouter au bas mot une dizaine d'octets dans ton décodeur alors que ça n'apportera au mieux qu'une amélioration de 1/256 = 0.4% du taux de compression... (et sur un fichier "normal" l'amélioration sera nettement plus faible)

Le fait que je n'aie pas compris tout de suite montre bien qu'une autre subtilité m'avait échappée.
Je pensais que les bytes "esseulés" seraient repris tel quels. On prendrait donc 3 bytes pour des séquences de 4 et plus, mais le même nombre de bytes et les mêmes pour des chaînes de 3 et moins. Et en cas de byte flag isolé, à bien y réfléchir, la solution "flag|1|flag" me conviendrait. Après vient le problème de quel byte prendre comme flag...

./5 : Je préférerais gagner de la place en compression et en perdre un peu sur l'algorithme de décodage, oui. Du moment que l'algorithme est une seule chose, il n'y aura pas qu'une seule chose à décoder, donc ce sont les données qu'il faut compresser le mieux possible.

./7 : Je pensais faire un flag qui soit immuable, mais pour la variable en question (voir en fin de post), mais comme je peux utiliser quelques bytes à côté des données réelles, c'est vrai que ta proposition est intéressante...

./8 : Ouais, c'est certainement une bonne idée et devine quoi : j'ai compris !
Ce que je cherche à faire, c'est de grouper des informations d'images en 4 ou 8 niveaux de gris - de taille maximale 7020 et 10530 bytes respectivement - dans une seule variable. Sachant que je n'ai jamais réussi à avoir de variable de plus de 65520 bytes sur ma voyage 200, et qu'il me faudra encore utiliser 9 bytes sur toute la variable, je peux me permettre de choisir un flag variable pour chaque composant.
Au passage, quelqu'un pourrait me proposer un convertisseur d'images *.bmp et/ou *.jpeg en images TI 4 niveaux de gris avec tramage ? J'ai déjà essayé TI Paint Plus, mais les fichiers de sortie sont apparemment illisibles...

Fonctionnent plus, les balises [hide]test[/hide] ?

De mémoire, il y a un convertisseur pas mal dans une "suite dédiée à la programmation pour TI", mais je ne me souviens plus du tout du nom. Sinon, tu peux voir ce que ça donne avec The Gimp en convertissant avec du dithering (genre Floyd-Steinberg, c'est plutôt bon).

Merci, je m'en vais voir ça ! (J'avais jamais fait attention au fait que The GIMP proposait de telles options à l'enregistrement ; ça va grandement me faciliter les choses)

Presque tout a été dit en ./4 et ./8, je me permettrai juste d'ajouter une légère optimisation à la proposition de ./4.
En effet, le fait de simplifier « flag|1|flag » par « flag|1 » fonctionne aussi avec une répétition de 2 ou 3 fois le flag en tant que valeur codante, puisque la compression « flag|nbr|byte » n'est utilisée, pour byte != flag, que si nbr > 3 (donc si nbr vaut 1, 2 ou 3, c'est forcément que byte représente flag, donc inutile de le dupliquer).
Mais comme le précise Pollux, cette optimisation en taille du fichier résultant s'accompagne d'un codec (compresseur/décompresseur ) un chouïa plus gros et plus lent.

./9 > Si si, justement, les bytes « isolés » différents de flag (et situés ailleurs que juste après un flag) sont pris tels quels.

Merci Ethaniel pour la précision quant à l'encodage
Apparemment, j'avais mieux compris le principe que ce que je pensais.

TIPaintPlus fonctionne, je n'avais pas la dernière version. Seulement... il me génère bien l'image - je peux l'ouvrir avec TIScreenCapture - mais il me semble qu'elle contient les deux calques, et ce que je vois avec TIScreenCapture, c'est l'image comme si l'on avait coupé au milieu verticalement et interverti les deux parties. Pas moyen de l'envoyer sur la machine...

Fichier joint : HP1_001.bmp : l'image de départ

Fichier joint : test.v2i : le fichier de sortie.

Ce qu'il y a de bizarre, c'est le fait que les propriétés du dernier fichier joint ne sont pas modifiables, et ce qui est mis par défaut n'est pas reconnu... je vais voir comment faire pour éventuellement corriger le fichier.

[Edit] Ah, oui : il n'y a qu'un fichier *.v2i de sortie, c'est apparemment normal

Bonjour.

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.

Un grand merci Daniel, tu m'as convaincu d'utiliser ta solution !
Tu aurais pas par hasard un taux moyen de compression à nous proposer !? #angélique#
Juste une question : comment fais-tu pour départager ce qui sera encodé de ce qui ne le sera pas ? Tu fais une compression totale que tu nettoies par la suite ?

[Edit] : français peu correct corrigé

Oui mais ce n'est pas du RLE, et c'est une format spécialisé pour le N&B alors que le RLE proposé dans les post précédents est indépendant du format de ce qu'on compte compressé, une simple amélioration a ce format :

quand tu compte coder sur plus de 256 (enfin 255 plutot) ton décompresseur sais que l'octet suivant est pour la meme suite de pixel, ça permet de gagner 1 octet pour bcp de cas, et a chaque fois qu'il rencontre 255, il l'additionne avec l'octet suivant, donc

256 donne

255, 1

255 donne

255, 0

260 :

255, 5

etc..

ben disons qu'avant de décider quel algorithme utiliser il faudrait déjà savoir quel type d'images tu veux compresser... une équation prettyprintée ne se compresse pas du tout pareil qu'une image convertie à partir d'une photo en niveau de gris, par exemple

Pour l'instant, j'aimerais simplement compresser des groupes de deux images TI qui font les deux plans d'ine image en 4 niveaux de gris. Compresser des groupes de trois pour 8 niveaux, c'est autre chose, car le plan médium est peu propice à une compression de ce genre.

Ah, content de savoir que ma solution te plait .
Pour déterminer si une portion de l'image ne vaut pas la peine d'être codée en "RLE-Adapté-TI", il te suffit de lire ton image (avec une boucle for basique) et de voir dans quelles parties de l'image les suites de pixels ne font pas une longueur supérieure à 8.
Après réflexion ça doit même être possible à déterminer durant la compression, mais je t'avoue ne pas trop avoir réfléchi à ce problème.

Pour ce qui est de la compression en tant que telle, je n'ait pas de taux à te proposer, car je n'ai jamais pris le temps de mettre ce système en pratique (je n'en suis pas encore arrivé là dans mon projet) et je me suis concentré seulement sur la partie théorique.

Cependant vu que ce système est adapté au mode de fonctionnement de la TI, je pense obtenir un taux de compression supérieur à un RLE standard.

Godzil> Si j'ai bien compris ce que tu veux dire, tu voudrais créer une particularité du '255', en considérant qu'on obtiendra plus souvent des nombres supérieurs à 255 qu'égaux à 255 eux-mêmes?
Je réexplique l'idée à ma façon et tu me diras si c'est bien ça:
-Quand le compresseur rencontre une suite de 255 pixels ou plus, il réserve l'octet suivant, qu'on ajoutera au 255 initial (ce qui permet en effet d'économiser de la place dans bien des cas).
L'idée est intelligente, et fera gagner de la place (surtout dans le cas d'images type 'écran blanc').

Sinon mon format permet aussi de stocker des suites de bits ('1' et '0'), donc peut s'appliquer à n'importe quel fichier non?

Tu as compris la même chose que moi.
Imaginons une image qui noircit totalement l'écran d'une V200, soit 240x128 pixels noirs. Une image ainsi codée fait 3847 bytes, en comptant ceux pour la taille de la variable et ceux qui déterminent les dimensions et le flag d'image. Une compression avec la proposition du post ./14 améliorée avec le post ./16, elle, ne fait plus que... 132 bytes avec le flag pour le type "OTH", un type de 4 caractères, les deux bytes de taille de variable et les quatre pour les dimensions de l'image... Moins de 4 % de la taille initiale...
Vous me demanderez cependant à quoi peut bien servir une telle image ? Rabats-joie !
Encore une question qui m'est venue en faisant quelques essais à la main : comment fais-tu pour savoir quelle est la couleur après une séquence dont on a pris les bytes tel quels ? Tu continues avec le système alterné, et reprends là où tu en étais, quitte à ajouter un nouveau zéro ?
Je m'explique à l'aide d'un exemple : on prend une image qui débute par une suite de 17 pixels noirs, puis vient une séquence qu'il serait superflu de compresser, et à nouveau une suite de plus de 8 pixels noirs. Comment faire comprendre au décodeur que la suite après la séquence en clair est noire ? Est-ce là le comportement par défaut ? Du coup, comment le changer ?

Plus terre à terre, y a-t-il moyen d'écrire bit par bit dans un buffer, ou au moins un byte en écrasant une partie seulement de celui d'avant ?
Si on reprend l'exemple plus haut :
0x11, 0x00, 0x69, 0x00, 0x99 (compréssé)
Les bits qu'on aimerait seraient
11111111|11111111|10100010|11111111|etc...
Est-ce possible ? Sinon, ben ça compresse moins bien, de faire des groupes de bytes, en fait...

Et allez, autant passer pour un *** et avoir une réponse : The GIMP permet vraiment de convertir une image couleur n'importe quel format en deux images TI pour du 4 niveaux de gris, avec tramage ? Parce que après essais avec les fichiers fournis en ./13, je constateTIPaintPlus ne me génère qu'une image et qu'elle est bel et bien coupée en deux verticalement, avec les deux parties interchangées... Peut-être même qu'il s'agit d'une partie du plan sombre, et l'autre du plan clair... Donc, soit je code mon propre convertisseur (#flemme# au possible, et si ce n'était que ça), soit je cherche un peu mieux... (#flemme²#)

Godzil (./16) :
quand tu compte coder sur plus de 256 (enfin 255 plutot) ton décompresseur sais que l'octet suivant est pour la meme suite de pixel, ça permet de gagner 1 octet pour bcp de cas, et a chaque fois qu'il rencontre 255, il l'additionne avec l'octet suivant, donc

Mouais mais le unaire (même avec des gros bâtons de 255 unités), c'est pas le mieux.
Si tu as une grosse image noire, tu vas prendre 128 octets.
Une idée c'est lorsque tu trouves un 255 de considérer ensuite les octets suivants comme la représentation binaire d'un entier, en gardant un bit de tag.
Par exemple, on réserve l'octet de poids faible pour signifier 0 = fin de la représentation binaire, 1 = lire encore un byte.

b = read ()
if (b = TAG_UEULE) {
 v = read ()
 n = 0
 b = read ()
 if (b = 255) {
   b = read ()
   while (b & 1) {
     n = n << 7 | b >> 1
     b = read ()
   }
    n += 255
 } else {
   n = b
 }
  for i = 1 to n do {
    output (v)
 }
} else {
 output (b)
}

avec ça, une image noire prend 5 octets

Ymox> Comme tu l'as dit toi-même, il suffit de rajouter un '0' ou non après le bandeau "0,0" pour déterminer la couleur de la suite de pixels suivant une suite non-rentable. Le '0' doit se mettre ou non en fonction de la couleur de la dernière suite de pixels rentable avant la partie non-rentable (puisque l'alternance se "met en pause" le temps de la lecture de la partie non-rentable).
Par contre je n'ai pas tout compris à ton histoire de bits :/

BookeldOr> Je ne comprends pas tout à fait ton idée. Que fais-tu de la "représentation binaire d'un entier"? De plus, changer le poids faible ne risque pas de modifier un peu les données, donc une éventuelle perte de qualité de l'image?

Dans tous les cas cette discussion me donne bien envie de créer le compresseur en tant que tel pour voir ce que ça donne ^^ .

Ymox (./18) :
Pour l'instant, j'aimerais simplement compresser des groupes de deux images TI qui font les deux plans d'ine image en 4 niveaux de gris. Compresser des groupes de trois pour 8 niveaux, c'est autre chose, car le plan médium est peu propice à une compression de ce genre.

mais quel genre d'image ? le RLE ne sera efficace que s'il y a des gros aplats de couleur unie...
et si c'est du 4 ndg tu pourrais peut-être avoir intérêt à regrouper les plans : une zone blanche dans l'image se traduit en deux zones blanches dans chacun des plans, c'est du gâchis d'avoir à décrire deux séquences RLE identiques au lieu d'une

Quel genre d'images ? Ben principalement des photos, ou des screenshots pour être plus précis. Donc des images avec peu de plages totalement unies...
Quant à regrouper les plans, tout à fait d'accord, seulement ça pose le problème de savoir à quel plan les données lues sur le moment appartiennent...

Ymox (./24) :
Quant à regrouper les plans, tout à fait d'accord, seulement ça pose le problème de savoir à quel plan les données lues sur le moment appartiennent...

Bah, c'est trivial : entrelacement bit à bit.
Ce qui, d'ailleurs, reconstitue directement les 4 NdG, chaque pixel étant codé sur 2 bits adjacents (les pairs venant d'un des plans, les impairs venant du second).

Daniel Vouaux (./19) :
Sinon mon format permet aussi de stocker des suites de bits ('1' et '0'), donc peut s'appliquer à n'importe quel fichier non?

Non car contrairement a une image N&B tu risque d'avoir des taux de compression misérables

./25 : pardon, c'est vrai que c'est trivial
Du coup, à la lueur du post précédent, il faut peut-être un autre type de compression que celui proposé en ./14, car ce ne sont plus des bêtes images noir/blanc.

Godzil> Oui c'est vrai que tenter de compresser les bits de ma façon serait totalement inutile

Ymox> Soit j'ai pas compris l'histoire de l'entrelacement, soit je comprend pas tout court.
Si j'ai bien compris, ce que propose Ethaniel c'est, plutôt que séparer les deux images N&B formant les 4 niveaux de gris, de "mélanger" les deux images en mettant les deux pixels relevant d'une même position sur l'écran (mais provenant de plans différents) cote-à-cote. Ben ouais mais qu'est ce que ça apporterait?

Ca m'étonerait qu'on y gagne de la mémoire, puisque, d'accord, on économiserait quand les deux images seraient noir ou blanc à une position, mais dès qu'on rentrerait dans du gris ça nous donnerait en mémoire du '101010101010101' (puisque un pixel d'un plan est allumé et pas le pixel de même position de l'autre plan, c'est le principe même du niveau de gris!).
Donc, à moins d'avoir plus de zones noires ou blanches dans une image que de zones en gris, on perd de la mémoire. Et comme quand on met les NDG dans une image c'est en général pour les utiliser...

Enfin, bien sur faire passer une image en NDG rajoute un plan supplémentaire qu'il faut lui aussi stocker en mémoire, mais il faut bien noter une chose: l'utilisation de niveaux de gris est propice aux grands applats de noirs ou de blancs. En effet comme les détails sont créés par les niveaux de gris et pas uniquement par l'alternance de noir et de blanc, on a plus de zones "unies".

Je pense que ma technique, bien qu'améliorable (comme tout système de compression d'ailleurs), n'est pas disqualifiée dès qu'on rentre dans le monde des niveaux de gris.

Daniel Vouaux (./28) :
Ymox> Soit j'ai pas compris l'histoire de l'entrelacement, soit je comprend pas tout court.
Si j'ai bien compris, ce que propose Ethaniel c'est, plutôt que séparer les deux images N&B formant les 4 niveaux de gris, de "mélanger" les deux images en mettant les deux pixels relevant d'une même position sur l'écran (mais provenant de plans différents) cote-à-cote. Ben ouais mais qu'est ce que ça apporterait?

Oui tu as bien compris. Et ça apporte simplement qu'au lieu d'avoir deux plages de données séparées, il n'y en aurait plus qu'une.

Daniel Vouaux (./28) :
Je pense que ma technique, bien qu'améliorable (comme tout système de compression d'ailleurs), n'est pas disqualifiée dès qu'on rentre dans le monde des niveaux de gris.

Ben en fait, avec l'entrelacement bit à bit, ce sont les grandes plages de noir et de blanc qui pourraient être compressées (logique : un pixel noir est codé 11 en binaire, un pixel blanc 00, du gris clair 01 et du gris foncé 10 par exemple). Si l'on conserve les deux plans séparés, on pourrait gagner de la place sur les surfaces noires, blanches ET grises, car on compresse les plans, pas les images... Le noir et le blanc étant commun aux deux plans, ce qui est gris clair apparaît comme du noir dans l'un, donc compressible en même temps que les deux couleurs "de base", et le même raisonnement s'applique au gris foncé dans l'autre plan.
En résumé, j'ai l'impression toute personnelle que si l'on veut compresser au nombre de bits, il vaudrait peut-être mieux conserver les plans séparés.

Ymox (./29) :
En résumé, j'ai l'impression toute personnelle que si l'on veut compresser au nombre de bits, il vaudrait peut-être mieux conserver les plans séparés.

Ça y est, tu as trouvé tout seul !
Le fait est qu'il ne faut pas coder la répétition du nombre de bits, et ce, pour 2 raisons :[ul][li]c'est inefficace sur les aplats de gris en plans entrelacés (comme « 1010101010101010 »), ainsi que l'a remarqué Daniel ;[/li][li]techniquement, quand on lit ou écrit un fichier, on ne travaille pas bit par bit, mais octet par octet, le travail bit à bit est extrêmement plus coûteux.[/li][/ul]Avec des plages de noir, blanc et gris, les octets le plus souvent répétés seront 00000000 = 0x00, 01010101 = 0x55, 10101010 = 0xAA et 11111111 = 0xFF (pour votre culture, notez que 0xAA55 est la signature de fin du Master Boot Record sur une partition FAT32 ), ce qui est propice à la compression RLE... mais en codant la répétition des octets !

Ymox et Daniel, je vous enjoins à tenter quand même le codage par répétition des bits, vous vous rendrez compte par vous-même que le codec sera une horreur à coder (et vas-y que je te fasse des rotations, des shifts ou des bit-masks dans tous les sens).