Compression Huffman avec LZ77 - Page 4

Visual C++ rulezzz

Si c'est pour m'insulter ou ce foutre de ma gueule tu peux aller voir ailleurs.

Je vais essayer avec le débogueur VC.

Bon après une compilation difficile sous VC++ j'ai enfin plus lancer le débogueur mais bon c'est pire que DevC++, voici les erreurs qu'il me donne:
DM0025:No attaching process.
comdos.exe hax exited with code 0x0.

J'abandonne après des erreurs passées.

Pollux
:

pour laquelle M$ n'inclut aucune information de débogage

Si, en tout cas pour Visual Studio

Ben oui, ils veulent te forcer à acheter leur compilateur. C'est ce que j'appelle de l'abus de monopole. Mais on peut utiliser msvcrtd.dll avec MinGW si on sait ce qu'on fait. (Il y a un switch -mmsvcrtd dans les versions récentes de MinGW.) Le problème est surtout qu'il faut aussi trouver la DLL, la redistribution des DLLs de débogage de M$ étant en principe illégale.

Et même avec Visual Studio, tu n'as pas les informations de débogage des DLLs de Windows, juste celles du runtime C, donc le problème ne fait que se déplacer en bas d'un cran.

Kevin Kofler
:

Pollux
:

pour laquelle M$ n'inclut aucune information de débogage

Si, en tout cas pour Visual Studio

Ben oui, ils veulent te forcer à acheter leur compilateur. C'est ce que j'appelle de l'abus de monopole. Mais on peut utiliser msvcrtd.dll avec MinGW si on sait ce qu'on fait. (Il y a un switch -mmsvcrtd dans les versions récentes de MinGW.) Le problème est surtout qu'il faut aussi trouver la DLL, la redistribution des DLLs de débogage de M$ étant en principe illégale.
Et même avec Visual Studio, tu n'as pas les informations de débogage des DLLs de Windows, juste celles du runtime C, donc le problème ne fait que se déplacer en bas d'un cran.

Enfin y a tjs la pile d'appel, et puis Visual Studio a aussi un désassembleur intégré. Je ne pense pas que ça soit le cas de MinGW (pour le désassembleur), si?

Si, gdb intègre un désassembleur, et Insight peut très bien te montrer ce désassemblage s'il n'y a pas la vraie source.

D'accord. Et DevC++ aussi ?

Aucune idée, je n'ai encore jamais travaillé avec Dev-C++ 5 avec le débogueur intégré, mais toujours avec Dev-C++ 4.01 + Insight.

geogeo
:

Visual C++ rulezzz

Si c'est pour m'insulter ou ce foutre de ma gueule tu peux aller voir ailleurs.

N'importe quoi, je te narguais juste gentiment D'ailleurs je vois pas en quoi te dire que VC++ est mieux que DevC++ est une insulte


./92>
euh, si tu fais un prog en mode console et que t'arrives pas à le compiler avec VC++, c'est qui doit y avoir un pb qq part, non? tu es sûr qd tu as créé ton projet de bien lui avoir dit que tu faisais un prog _console_? (et pas un prog Win32 normal)

Euh oui mes les erreurs sont absurde du genre il ne connais pas la signification de BOOL ou encore long et même unsigned long long qui lui semble incorrecte. Voir même system.
En tout cas j'ai réussie à compiler mais bon ça change rien.

L'erreur ce précise, j'ai essayé de faire une fonction pour effacer les allocations:

//Suppression d'un arbre de huffman.
H_Tree *HUFF2_DeleteTree (H_Tree *arbre)
{  
  //Noeud
  if (arbre->FDroite->noeud==true)
  {
    arbre->FDroite->ptr=HUFF2_DeleteTree (arbre->FDroite->ptr);
    free (arbre->FDroite);
  }
  //Feuille
  else
    free (arbre->FDroite);
  
  //Noeud
  if (arbre->FGauche->noeud==true)
  {
    arbre->FGauche->ptr=HUFF2_DeleteTree (arbre->FGauche->ptr);
    free (arbre->FGauche);
  }
  //Feuille
  else
    free (arbre->FGauche);
  
  return NULL;
}

Elle fonctionne mais toutes les allocations ne sont pas effacés, ce qui semble très bizarre, de plus, les conditions type noeud ne semblent être jamais validés.

geogeo
: Euh oui mes les erreurs sont absurde du genre il ne connais pas la signification de BOOL

BOOL n'a rien de standard. Avec un compilo C99, tu peux faire #include <stdbool.h> et utiliser bool, true et false, mais je ne sais pas si ta version de VC++ le supporte.

En tout cas, typedef enum { FALSE,TRUE } BOOL devrait fonctionner...

ou encore long

Non, ça marche

et même unsigned long long qui lui semble incorrecte.

Oui, pour le coup c'est de la faute de VC++ qui ne supporte pas le C99.

#ifdef _MSC_VER
#define unsignedlonglong __u64
#else
#define unsignedlonglong unsigned long long
#endif

devrait faire l'affaire.

[cie]Voir même system. [/cite]
Euh là franchement j'ai des doutes. Tu avais inclus stdlib.h ?

En tout cas j'ai réussie à compiler mais bon ça change rien.

Si tu as bien spécifié que ct un prog console en créant ton projet, je vois pas pkoi il refuserait de se lancer.

Il ce lance, la compilation est parfaite mais ce que je veux dire c'est que le débogueur n'apporte rien de plus, il affiche juste un pauvre message d'erreur.
En tout cas la dernière fonction que j'ai faite fonctionne mais n'efface pas toutes les allocations ce qui est vraiment bizarre.

geogeo
: Il ce lance, la compilation est parfaite mais ce que je veux dire c'est que le débogueur n'apporte rien de plus, il affiche juste un pauvre message d'erreur.

Non. Le message d'erreur que tu as donné veut dire que le débogueur n'a pas réussi à lancer le programme, pas que ton programme contient une erreur et que le débogueur n'a rien réussi à en tirer. Essaye de mettre un "return 0;" juste après le début de main(), normalement il devrait te mettre la même erreur... (alors que le prog est parfaitement valide)

Si c'est bien le cas, c'est que tu t'es loupé dans la configuration du projet... Tu as quelle version de VS ?

BOOL n'a rien de standard. Avec un compilo C99, tu peux faire #include <stdbool.h> et utiliser bool, true et false, mais je ne sais pas si ta version de VC++ le supporte.
En tout cas, typedef enum { FALSE,TRUE } BOOL devrait fonctionner...

S'il programme en C++, il peut utiliser bool, true et false directement

Perso, je ne recommenderais pas de faire un mix C / C++. Soit on programme en C (avec des pointeurs de partout), auquel cas il vaut mieux éviter d'utiliser des features C++; soit on programme en C++, et on utilise les classes, les containers STL, etc... Vu comme geo² maîtrise le C, ce serait mieux pour lui de l'approfondir avant de passer au C++.

Toute façon j'abandonne, de plus le Huffman adapatif donne de moins bon résultats que le Huffman semi-adaptatif. Je préfère me pencher sur le LZH.

Et la façon dont tu l'as codé aurait donné un truc assez lent je pense. Moi j'alloue dès le départ un buffer de 512 neuds, comme ça j'ai aucune allocation et aucun redimensionnement à faire pendant la construction de l'arbre. Pareil pour la destruction, y'en a pas. Je reconstruis l'arbre en écrasant l'autre...

Ah ok une allocation complète au début, c'est une bonne idée.
Mais niveau taux de compression, Huffman adapatif est plus puissant que Huffman semi-adapatif? Perso ça m'étonne.

Juste un point pour m'éclairer. Pour le LZH, les couples pos et size peuvent être codés en même temps avec un code de huffman?

Mais niveau taux de compression, Huffman adapatif est plus puissant que Huffman semi-adapatif? Perso ça m'étonne.

Ca dépend de la taille de la fenêtre (si t'en fais une) et de la fréquence des reconstructions.

OK j'ai fais un tour dans les sources d'un compresseur LZSS+Huffman et il y a 2 tables une pour la longueur l'autre pour la position. Donc le couple pos et size n'est pas compressé grace au code de huffman? Faut-il obligatoirement un dico de 4096 items et une dernière question, quel doit être la taille de la table des fréquences pour huffman?

Tu veux dire la table qui indique les fréquences des octets au début du fichier ? tu n'en as pas besoin avec le progressif.

Non pas de cette table là.

J'explique en détails, la compression LZ+Huff utilise 2 tables, une pour les positions et l'autre pour coder les caractères+je sais pas quoi.

Ainsi avec un code précis on code le couple pos et size.
J'en sais pas plus j'ai pas de doc et pas d'infos.

Bon j'ai fait un tour dans cette article:
http://www.fadden.com/techmisc/hdc/lesson11.htm

Je viens enfin de comprendre qu'on ne code qu'avec huffman soit dans le couple pos et size, juste pos, ou soit le caractère qui n'a pas plus être compressé.
Maintenant ils disent d'étendre la table des fréquences de huffman de 253+n, ok 253 car le cas ou pos est égale à 0, 1 et 2 est impossible, ainsi pour coder une position ou un simple caractère je ferais appel à huffman et à la décompression si je vois un code supérieur à 255 c'est que j'ai à faire au couple pos et size. Mais mon problème c'est que je ne vois pas comment remplir cette table de fréquences, car si elle est étendu jusqu'à par exemple 253+(DICO_SIZE-2), la distribution des fréquences sera mal faite? Et surtout que doit-on ajouter dedans, les caractères de sorties non codé? tous les caractères codés et non codés? ou seulement caractères non codé et offset appartenent au couple pos et size?

Voilà je sais que je suis énervant mais ce sujet m'interesse or impossible d'avoir de vraies explications, juste du code qui ne m'aide pas franchement.

Pas de réponses.

Bonjour,
Je souhaite effectuer une compression d'image par FPGA. Ces images issues de la sortie VGA de mon unité centrale, ont préalablement été converties au format YCbCr puis numérisées. Je souhaite dorénavant comprésser un maximum chacun de mes signaux Y,Cb et Cr afin de les transmettre. A noter que d'une image à l'autre, je ne transmet que les portions modifiées. Je suis en train de me documenter sur la compression LZW, mais cette compression est elle avantageuse pour un tel système? Quelqu'un connait il les caractéristiques des compressions par FPGA? Quelqu'un pourrait-il me renseigner sur les avantages ou inconvénients des différents algorithmes de compression, plus particulièrement pour un tel système?
Merci d'avance pour vos réponses.