[C#] Pourquoi mon fichier est plus gros après compression ?

Tout est dans le titre ;)

J'utilise la classe GZipStream et certains fichiers sont plus gros après compression. Cela fonctionne bien avec des fichiers texte, mais pour les images, les pdf et d'autres, le fichier compressé est plus gros que le fichier à compresser, je ne crois pas faire d'erreur pourtant.

Code:

---

1 2 3 4 5 6

string filename = "monFichier"; byte[] buffer = File.ReadAllBytes(filename); MemoryStream ms = new MemoryStream(); GZipStream compressedzipStream = new GZipStream(ms, CompressionMode.Compress, true); compressedzipStream.Write(buffer, 0, buffer.Length); compressedzipStream.Close();

---

Est-ce moi qui débloque ou bien le GZipStream est à éviter ?

Salut,

Ben si tu compresses un mp3, un divx ou une image ce sont des formats déjà compressés donc tu ne peux pas plus les compresser et la taille augmente puisque tu changes de format donc tu dois rajouter des infos pour la décompression.

Bon avec winrar t'arriveras toujours à gagner quelques ko car c'est un des must en ce qui concerne la compression mais pour GZip ça ne m'étonne pas plus que ça :)

Citation:

---

Envoyé par StormimOn

Cela fonctionne bien avec des fichiers texte, mais pour les images, les pdf et d'autres, le fichier compressé est plus gros que le fichier à compresser...

---

Là par contre c'est étonnant vraiment, tu es sûr que celà ne fonctionne que sur du .txt 8O :question:

Salut,

Quelle est la taille du fichier original ? Quelle est la difference de taille ?

Pace que la classe GZipStream ajoute un header qui permettera de decompresser ton strean avec un outil GZip, alors comme a dit neo.51, si ton fichier est deja compressé, le header peut augmenter la taille de ton fichier mais seulement de quelques Ko.

Si la decompression va se passer seulement dans ton systeme alors utilise plutot la classe DeflateStream.

Je referais des tests ce soir, si je peux, avec plusieurs types de fichier pour vous donner des chiffres si vous voulez, mais les résultats ne sont en général probants que pour les fichiers texte.

J'ai une API qui possède des méthodes pour faire ce genre de chose (compression GZip + encodage base 64) et je cherchais à faire pareil avec le framework pour pouvoir me passer de l'API à ce niveau. Je mettrais également en correspondance les résultats de compression avec l'API pour info.

bon, c'est normal. Comme déjà dit précédemment, les images codé en JPEG sont deja compressées, PNG aussi.
Meme s'il s'agit d'une compression avec perte de données, c'est une compression.

Que ta compression marche sur du texte c'est normal. Ensuite il doit bien y avoir des règlages de performances.
En effet, il ya plusieurs algorithmes de compressions, mais ils sont tous plus ou moins basés sur le meme concept.
Ensuite, si c'est une compression par dictionnaire, ce qui je pense est le cas, il doit y avoir quelque part une option permettant de changer la taille du dictionnaire.
Plus la taille est grande, plus tes chances de compresser sont grandes, mais attention il y a un revers de médaille. Ca peut également fortement augmenter la taille du fichier de sortie, car l'enthropie et les infos stoquées dans le dictionnaire serons trop nombreuses et la compression peut échouer.
Générallement, des images jpeg devraient quand meme pouvoir etre compressées car la compression utilisée est de type huffman ou norme similaire. Dans tous les cas, la compression de jpeg ne vient pas de l'algorithme de compression en lui meme mais, de l'algorithme de lissage qui détermine les pertes.
En revanche, compresser un flux binaire, style .exe ne garantie pas une compression sure à 100%, tout dépend si des modeles extrait dénotes une certaine anthropie.

Donc meme avec des compresseurs comme Winrar, il n'est pas rare de voir un flux compressé plus important que le flux non compressé. Et oui, il ne faut pas tenir compte que du header. Ce serait une erreur. Un flux compressé peut dépasser de 25% le flux non compressé en moyenne, lorsque la compression est "impossible". Si toutefois, l'écart devait dépassé 25%, là il faudrait se poser des question, sauf si tu travail sur des flux particulierement cours et petits (< 10ko)
Ah oui les compressions sont souvent inutiles sur des flux inférieur à 10ko, les résultats sont très souvent décevant si le flux est binaire sans redondance (comme les fichiers textes ou la redondance est "normale").

J'ai juste un petit problème, car quand je compress un fichier word de 1,2 Mo avec GZipStream il se trouve que le résultat est un fichier de 1,44Mo.
Alors, admettez que pour un fichier Word c'est un petit génant, j'éspère que Microsoft va faire un éffort pour améiorer tout ça ;-)