Discussion :

[mistick1400001]

Bonjours, j'essai de faire une fonction qui me permettra de compresser mes données Héxa
alors j'ai penser utilisé la méthode RLE mais je voudrai un octet de contrôle qui permettra de m'indiquer le début de ma série qui doit être compressé
et aussi un octet qui me donnera le nombre de répétition dans le bloc avant la compression.

Car pour moi le but de la compression de donnée est de transformé ce bloc qui est une séquence d'octets en une autre séance mais compresser ducoup qui sera plus petite
et j'essaye aussi de faire ça mais dans les 2 sens en gros compression décompression

[Sve@r]

Bonjour

Y a-t-il un lien entre ce post et celui-là ???

Sinon quelle est ta question car je n'en ai vu aucune dans tout ce que as écrit (toutes tes phrases sont "j'ai pensé faire ceci" ou "j'essaye de faire cela" ce qui ne sont pas des questions auxquelles on peut répondre).

Car pour moi le but de la compression de donnée est de transformé ce bloc qui est une séquence d'octets en une autre séance...

séance de... cinéma ?

[chrtophe]

Pourquoi ne pas utiliser la zlib ?

[Matt_Houston]

Car pour moi le but de la compression de donnée est de transformé ce bloc qui est une séquence d'octets en une autre séance mais compresser ducoup qui sera plus petite

En effet, c'est bien le principe. Cependant tu ne mentionnes dans ton message ni les contraintes posées par l'énoncé, ni l'algorithme que tu as pu concevoir, ni son (début d') implémentation et ni surtout les difficultés rencontrées : qu'attends-tu de nous ? Nous ne pourrons t'aider que sur des points bien précis.

Pourquoi ne pas utiliser la zlib ?

Si l'on considère le premier sujet initié par l'OP et cité par Sve@r, il s'agit d'un exercice scolaire.

[mistick1400001]

Bonjour

Y a-t-il un lien entre ce post et celui-là ???

Sinon quelle est ta question car je n'en ai vu aucune dans tout ce que as écrit (toutes tes phrases sont "j'ai pensé faire ceci" ou "j'essaye de faire cela" ce qui ne sont pas des questions auxquelles on peut répondre).


séance de... cinéma ?

une autre séquence*

Pourquoi ne pas utiliser la zlib ?

une décompression d'octet en héxa

[Sve@r]

enfaite je dois reproduire la fonction dump en c

On s'éloigne assez drastiquement d'une fonction de compression là. Et on se rapproche de plus en plus avec ton autre topic que j'ai déjà cité. Or ce n'est pas en ouvrant X topics identiques que tu auras X fois plus de réponses.
Si les réponses données par ailleurs ne te conviennent pas, c'est surtout parce que

1. tu ne les lis pas (je veux dire que tu ne réfléchis absolument pas à ce qu'on écrit). D'ailleurs tu ne réfléchis même pas non plus à ce que toi tu écris (quand tu parles de "séance" au lieu de "séquence" => on avait tous bien compris de quoi il s'agissait évidemment !!! mais je tenais à te montrer que nous on lit les choses avec attention, montrant ainsi plus de respect pour toi que ce que toi tu ne nous en montre)
2. tu ne précises pas, comme le mentionne Matt_Houston, ce que tu attends de nous. Je vais d'ailleurs faire clairement et ouvertement l'hypothèse que tu attends de nous qu'on fasse ton code à ta place comme ça au-moins tu sauras qu'on est au courant et que cela n'arrivera pas

Donc tant que tu te cantonneras à ton attitude de "je veux faire ceci" et "j'ai pensé à cela" nous (enfin au-moins moi) continuerai à faire le neuneu en répondant des phrases du style "oui c'est une bonne idée" ou bien "je suis totalement d'accord avec toi". Parce que faire une fonction "dump" tout le monde sur ce forum sait la faire. Mais ce n'est pas en la faisant à ta place que ça te fera progresser (sinon te suffit simplement d'attendre le corrigé du prof) sans parler de l'injustice vis à vis des autres élèves qui, eux, étudient leurs cours et font ce qu'ils peuvent sur ce même TP tout seuls.

J'ai répondu aussi sur ton autre topic. Toutefois là-bas comme tu as (un peu) progressé j'ai répondu de façon moins sévère et plus précise.

[Bousk]

Compression RLE : https://fr.wikipedia.org/wiki/Run-length_encoding
Bonne chance, tu vas clairement en avoir besoin parce qu'à te lire, tu n'as pas le niveau pour ça - et pourtant c'est loin d'être complexe.

[mistick1400001]

En effet j'ai pas un niveau excellent en c pour celà. Je suis meilleur avec le SDL

[Sve@r]

Compression RLE : https://fr.wikipedia.org/wiki/Run-length_encoding

J'ai trouvé ceci plus détaillé. J'espère ne pas faire de bêtise en en parlant sur ce forum (pardon aux modérateurs si je me trompe)

[mistick1400001]

merci de ton lien !

[Médinoc]

Ensuite, on peut optimiser le RLE pour réduire l'augmentation de taille si les données reçues ne sont pas propices à la compression.
Par exemple, un codage comme suit (tout avec des octets non-signés, unsigned char):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Un octet de taille
	Si son bit de poids fort est zéro, c'est la taille d'un run
		Il est suivi d'un octet indiquant la valeur du run.
	Si son bit de poids fort est 1, ses 7 bits de poids faibles sont la taille d'une zone non-compressée
		Il est suivi de N octets, la zone non-compressée

L'avantage de ça, c'est que dans le pire des cas de données non-compressibles, on rajoute un octet tous les 127 octets.

Par contre, ça complique l'algorithme de compression: On a désormais besoin d'un buffer de 127 octets minimum pour prédire la taille des zones non-compressées.

On constate aussi qu'au milieu d'une zone non-compressée, si une suite fait moins de trois octets, il n'est pas rentable de la noter comme un run, parce que noter le run prend trois octets:

• Un pour la taille du run
• Un pour la valeur du run
• Un pour la taille de la zone non-compressée suivante

(par contre, si ensuite il y a d'autre runs, c'est jouable à partir de deux)
Je vais voir si je peux pondre un tel algorithme...