COMPRESSION HUFFMAN ( INTERFACE EN API WINDOWS )
cs_JCDjcd
Messages postés
1138
Date d'inscription
mardi 10 juin 2003
Statut
Membre
Dernière intervention
25 janvier 2009
-
11 juil. 2006 à 18:38
amira4iag Messages postés 1 Date d'inscription samedi 17 février 2007 Statut Membre Dernière intervention 17 avril 2007 - 17 avril 2007 à 15:34
amira4iag Messages postés 1 Date d'inscription samedi 17 février 2007 Statut Membre Dernière intervention 17 avril 2007 - 17 avril 2007 à 15:34
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/38522-compression-huffman-interface-en-api-windows
https://codes-sources.commentcamarche.net/source/38522-compression-huffman-interface-en-api-windows
17 avril 2007 à 15:34
31 août 2006 à 10:12
PEBKAC =)
28 août 2006 à 02:23
J'ai cependant bien travaillé dessus, mais a vous d'en juger.
5 août 2006 à 23:32
le premier pas tres grave, mais ton code de gere pas les fichiers uniformes (une seul caractere), mais c'est pas important
le second : probleme de liberation memoire, j'ai enregistre chaque Malloc (ou new ...) et chaque Free (ou delete ...) et a la fin du programme il reste des blocs memoires non-liberes. J'ai mene ma petite enquete et le probleme vient de la fonction <nettoyage> : l'instruction "delete noeud;" devrait etre EN DEHORS du "if(noeud->filsg)"
car sinon les feuilles ne sont pas liberees
17 juil. 2006 à 17:10
13 juil. 2006 à 15:37
VECCHIO56> Il s'agit d'une erreur de ma part: je ne savais pas que l'opérateur ^ était en fait un xor, je l'ai pris pour un opérateur puissance. Quant à unitmem il s'agit d'un type(ici un unsigned char) que je pensais changer selon mes besoins (si je souhaitais travailler sur 2 ou 3 octets) mais j'ai finalement implémenté ça autrement.
Tout ça pour dire que "256^sizeof(unitmem)" correspondrait normalement au nombre de symboles codables sur 1 octet (soit 256).
J'ai corrigé tout ça dans la nouvelle version et j'espère avoir le temps de la finir avant de partir en vacances ^^.
13 juil. 2006 à 15:03
12 juil. 2006 à 23:22
Bravo et merci ++
12 juil. 2006 à 15:23
Soit dit en passant, pense à mentionner tes résultats sur les compressions d'images, ça m'intéresserait :).
12 juil. 2006 à 14:30
A voir pour la prochaine version... ^^
12 juil. 2006 à 13:57
12 juil. 2006 à 13:09
KIRUA > En fait j'avais regardé auparavant sur la page de wikipedia http://fr.wikipedia.org/wiki/Taux_de_compression , et puis j'ai vérifié sous WinRAR, ce qu'ils appellent 'ratio' c'est bien la même chose que mon taux de compression...
Enfin tout ça c'est du détail, et je suis d'accord, Huffman est bien cool à programmer :p.
12 juil. 2006 à 10:22
puisque c'est assez logique d'avoir un taux de compression nul si le nouveau fichier à la même taille que l'original. et d'ailleurs, avec huffman, on peut aussi avoir pire. Il n'y a sans doute pas plusieurs définitions, mais il est possible que les gens ne soient pas d'accord sur le sens à donner ^^. Quoi qu'il en soit, dans les programmes pros de compression, plus le taux est élevé, mieux c'est compressé.
Et Huffman, c'est un cooooool algo :).
11 juil. 2006 à 21:39
ca passe sous DevC++ !!
en modifiant 1 ligne dans le fichier "huffman.cpp"
void donnee_construit()
il faut mettre :
// décalage
unsigned int i;
for(i=2;i<nbarbres;i++)
> sortir unsigned int de la boucle for
pour que i soit reconnu en dehors lors de l'appel
listearbre[i-2]=noeud;
pour les warning, ils sont facilement corrigibles ;-)
11 juil. 2006 à 19:14
ca serait bien de pouvoir calculer l'entropie d'un fichier, et tu montrerais la difference d'entropie (ie l'elevation d'entropie due a la compression)
11 juil. 2006 à 19:05
Le taux de redondance, qui est basé sur cette grandeur est peut-etre un peu plus significatif ...
11 juil. 2006 à 18:38