Discussion:Compression de données

il est très bizarre le tableau récapitulatif. on y mélange allègrement format de fichier, algorithmes, (que fait le RLE dans le tableau ???) et normes. il y aurai besoin d'un peu de ménage, nan ? Sylenius 27 janvier 2006 à 22:13 (CET)

Vu l'état de la page, je suis d'avis que ce n'est plus une ébauche à compléter. Qu'en pensez-vous ? (il y a toujours place à amélioration, mais je pense que ça commence à être très bien...)

BenoitStandre 16 aoû 2004 à 17:10 (CEST)

Dtcube

Le terme de compactage, pour compression sans perte, me semble d usage peu courant pour ne pas dire plus... Par contre, on parle de compression conservative, ainsi que de compression non conservative.

Une remarque sur le tableau, qui en amene une autre plus generale, GIF n est pas conservative (ie sans perte). La palette de couleur est limite et si une image est transformee en gif, alors qu elle contient plus de 256 couleurs (de memoire) alors il y aura degradation.

Ceci etant dit, il apparait que le probleme du codage de l information, c est a dire sa representation, numerique en l occurrence, est disjointe de la compression. Par exemple, je ne considere pas le format BMP, ou PPM qui est libre, comme des algorithmes de compression, mais des formats de representation. L'information y est essentiellement brut. Pourtant, il y a effectivement quantification si la source d origine est analogique, ce qui est souvent le cas des images ou du son. Bien entendue, cette quantification represente une perte d information : on represente un signal continu par une serie de valeurs discretes et de precision finie, mais cela s apparente plus a tronquer le signal qu a une veritable compression, au sens JPEG ou GIF peuvent compresser.

Quant a la remarque sur le fait que certains algos non conservatifs puissent être sans perte, cela vient bien du probleme de representation. Prendre une image GIF et la transforme en JPEG peut tout a fait être sans perte (ie reversible) mais cela vient du fait que l image gif passe par un format type BMP avant d être compresser en JPEG et que l'image compressee a partir de cette representation BMP, n a pas de mal a être fidele puisque la BMP est de qualite mediocre. Ceci etant, le simple fait que JPEG puisse être non conservatif, fait de lui un algo non conservatif. Un algo n est conservatif que si il l est systematiquement. Comme algo non conservatif designe un algo qui n est pas conservatif ....

---

Yoann 02 jul 2004 à 15:30 (CEST)

Salut, j'aimerais savoir si vous connaissez JPEG2000. Est-ce la même chose que SPIHT? Il faudrait le mettre dans le tableau non?

Non, SPIHT n'est pas la même chose que JPEG2000. Par contre, ils sont tous deux basés sur les ondelettes, ondelettes qui sont déjà présente, tout comme SPIHT, dans le tableau. Il serait possible d'ajouter une entrée dans le tableau pour jpeg2000 si tu veux, il ne s'y trouve pas.Dirac 3 jul 2004 à 04:59 (CEST)

---

Dans les methodes (la 1ere ligne du tableau) il en manque quelques unes, comme par exemple "Minimum Redundancy Coding" mais je ne connais pas s'il existe un terme francais pour celà ? ou si on emploie le terme anglais (comme DCT par exemple) dans l'article il y a un titre "codage huffman", (qui utilise justement la methode "Mini Redundancy Coding", s'il n'y a rien (titre sans paragraphe) il faudrait le mettre uniquement dans le tableau non ?

PS : a oui, pour le tableau si le vert ne vous plait pas, changez le, je l'ai fait au hazard total à la main. il en faudrait un plus pastel...

Fab97 27 jul 2003 à 02:57 (CEST)

Je ne suis pas d'accord avec le fait de classer les types de compressions selon qu'elles soient avec perte ou non. Il est possible de compresser une image en format jpeg en le faisant sans perte. De plus lorsqu'on utilise des familles très générales comme « ondelettes » et « fractales » il faut être très précautionneux sur ce que l'on dit. J'enlèverais tout simplement le tableau.

Pour les traductions, je recommande chaudement le Grand dictionnaire terminologique, quoiqu'il n'y ait rien à propos de "Minimum Redundancy Coding".

Dirac 28 jul 2003 à 00:52 (CEST)

Bah, si on enleve le tableau, qu'est-ce qu'il reste : deux chapitres : "avec perte" et "sans perte" (donc un classement avec/sans perte, un peu ce que tu n'aimes pas..). En fait ce n'est pas le tableau qui definie ces deux modes, le tableau c'est juste une vue synthetique.

Si on enleve le tableau ca veux dire qu'on ne parle pas de DCT, wavelet, RLE... (et surtout ca enleve ces liens.. certes vides pour l'instant) c'est domage.

C'est quoi le probleme avec les familles (ondelette et fractales) ? et quand à être tres «précautionneux», je ne suis pas contre , la preuve il n'y a rien de «dit» , c'est juste des liens !

Le tableau n'est pas fini, il merite d'être complété.

Mais je trouve sympas de voir d'un coups d'oeuil que en "image" il existe des algo basé sur DCT (JPEG) de d'autre sur les ondelettes (SPIHT)... c'est pas complet, il y a sans doute d'autre algo, mais on à déjà cette info.

si on veux en savoit plus, on clique sur le lien.

Perso je suis septique sur toute suppression (hors vandalisme), ce tableau ne demande qu'a être amélioré, il etait presque 3 heures du mat quand le l'ai pondu, un peu d'indulgeance ;) Fab97 28 jul 2003 à 16:34 (CEST)

Si tu veux on peut laisser les liens, pas nécessairement sous forme de tableau, mais dire que la compression JPEG, par exemple, est une compression avec perte est quelque chose qui est faux. Idem pour les ondelettes, les fractales, alouettes. Faire une fausse classification en disant que si les gens sont vraiment intéressés ils n'ont qu'à suivre les hyperliens pour voir de quoi il retourne, c'est faire fausse route. On fait quelque chose en disant ce que c'est vraiment ou on n'écrit rien, quitte à moins en mettre. Je propose d'enlever la distinction avec perte/sans perte et de faire une section principaux types de compressions avec les hyperliens qu'on retrouve dans le tableau. Dirac 29 jul 2003 à 13:35 (CEST)

Bon,c'est vrai que l'on peux faire du sans perte et avec perte avec du JPEG ou SPIHT.. d'un autre coté c'est pas tres courant. si tu va voir l'article en en: , tu vera "Lossless" avec LZW,PCX.. et "Lossy" avec MP3,JPEG... c'est donc pareil... aussi je cite le 1er paragraphe : "la compression dite avec perte... par exemple JPEG)" ce n'est pas une histoire de tableau, donc. c'est tout l'article qui faudrait refaire...

Au pire moi j'aurai suggerer de mettre JPEG dans les 2 colonnes (avec et sans) et il est interressant de savoir qu'il y a des methodes qui sont sans perte tel RLE et d'autre qui sont generalement avec perte (même si le JPEG peu être sans perte.. dans certains cas) et d'autre qui sont avec perte (toujours) : le MP3 (il me semble). que penses tu de cette classification ? celà te paraît'il plus correct? exemple :

Domaines	sans pertes	avec pertes
Général binaires/données	RLE(Run-Length Encoding), LZW(Dictionaire)	DCT(Discrete Cosine Transform), Ondelettes(wavelet), compression fractale
Audio	-	MP3(DCT), ogg vorbis
Image	PCX(RLE),JPEG(DCT)	JPEG(DCT),SPIHT(wavelet)
Vidéo	-	MPEG(DCT)

Aprés, moi... si tu veux supprimer le tableau, je ne vais pas me battre, mais alors tu mets comme dans l'article en: la liste hierarchique qui explique que PCX c'est une compression de type RLE qui est sans perte. elle est pas mal cette liste, ce que j'ai fait (en moins complet) c'est qu'en plus j'ai decoupé par domaine (image/son...)

comme tu veux...

Si tu veux on peut laisser les liens Mettre des liens sans les classer un peu, c'est domage non ? La liste de l'article en: va t'elle nous mettre d'accord ? Fab97 29 jul 2003 à 15:08 (CEST)

Salut Fab97,

J'ai discuté avec les copains avec qui j'ai étudié en traitement de signal et on est arrivé au consensus suivant: Les algorithmes que tu as classé comme "avec pertes" ne le sont pas nécessairement, quoiqu'ils aient été conçu pour être efficaces lorsqu'ils y a perte d'informations. Autrement dit, il faudrait les mettres dans les deux colonnes comme tu l'as suggéré et j'ajouterais une note qui explique qu'il soit possible d'utiliser ces algorithmes pour qu'ils soient sans pertes mais que ce ne serait pas un choix brillant. Notons que l'article en anglais est donc erroné. Ça arrive, on n'a juste à faire mieux de notre côté :)

Petite note technique, il est possible de faire une "compression" sans perte en format mp3 et ogg. Ce serait douteux comme choix, mais c'est possible.

---

Moi pas comprendre ce que veux dire: "L'information à compresser est vue comme la sortie d'une source de symboles qui produit des textes finis selon certaines règles."

Dirac 6 déc 2003 à 13:47 (CET)

Je pensse qu'il faudrai aussi ajouter l'algorythme de type 'topologique' qui est certe tres simple mais qui expliques bien la notion de compactage

tgz

Peut-être peut-on indiquer au lecteur pour le rassurer que le tgz ne constitue pas un format en soi, mais tout simplement un gz effectué sur un tar. François-Dominique 5 aoû 2004 à 12:43 (CEST)

Je ne crois pas que ça ait sa place ici. C'est un article sur la compression de données, pas sur les formats de fichier de compression de données. Les noms des fichiers sont là à titre informatif.Dirac 5 aoû 2004 à 15:26 (CEST)

Il semble que rassurer le lecteur en lui indiquant qu'il n'existe pas de compression tgz constitue bien une information. Ou alors ne pas parler du tout de tgz. Mais si on cite le terme (ah, putaing, cette manie du name-dropping!) la moindre des choses est de dire en une ligne de quoi il s'agit. Ou alors on est chez Vadius et Trissotin. François-Dominique 5 aoû 2004 à 15:31 (CEST)

Dans ce cas-là, je prone le retrait pur et simple de tgz. C'est effectivement la même chose que gz.Dirac 6 aoû 2004 à 14:30 (CEST)

stéganographie

Je lis :

Une compression avec pertes suivie de décompression déjoue également les risques de stéganographie.

Cette affirmation est fausse : toutes les méthodes de watermark invisible (qui sont en fait une sorte de stégano) fonctionnent avec des fichiers jpeg. --Serged 28 jun 2005 à 19:21 (CEST)

exact. donc j'ai supprimé ;-) Sylenius 14 février 2006 à 21:35 (CET)

Compression & distance

Bonjour,

Je contribue en général dans le domaine des mathématiques et je souhaiterais vous soumettre 2 articles qui font le lien entre compression informatique et distance au sens similitude :

• http://homepages.cwi.nl/~paulv/papers/SimilarityV3.pdf
• http://homepages.cwi.nl/~paulv/papers/cluster.pdf

Dans un cadre professionnel, un collègue et moi avons appliqué le principe décrit avec la formule indiquée (que j'ai rendue symétrique pour respecter la définition d'une réelle distance) et, il se trouve que cela fonctionne plutôt bien ;-). --Claudius 8 décembre 2006 à 23:03 (CET)

C'est intéressant ton bidule. Je pense qu'au niveau du domaine, cette technique a plutot sa place en recherche d'information ou en classification. Et pour remarque, c'est un peu abusif de dire de pouvoir utiliser cette technique sur des images ou des vidéos: il est très rare que de tels contenus soient compressées avec des algorithmes sans pertes, (et en plus ça marcherait pas: la similarité entre deux images n'a pas forcément de lien avec les valeurs pixels, un petit changement de luminosité, et hop -> dans les paquerettes . Je ne suis pas contre une petite (attention, petite hein!) mention dans l'article, en tant qu'application inattendue de la compression. Sylenius 9 décembre 2006 à 19:35 (CET)

C'est vrai que cela est assez déroutant. D'une part, je pense qu'il faut partir d'une "information exacte" (codage midi pour les sons et non mp3, images brutes et non codées avec perte d'informations, textes originaux non déjà compressés, etc.) et d'autre part, l'appliquer à des "objets d'une même famille" dont on sait à l'avance qu'ils sont comparables. Le but étant de fournir une distance de similitude, d'où le lien avec l'article Distance (mathématiques) dont j'attends quelques réactions dans sa page de discussion avant de le compléter. --Claudius 9 décembre 2006 à 20:18 (CET)

la compression de donnée

la compression de donnée c'est de l'archivage. Elle est toujours sans perte de donnée et on doit toujours pouvoir récupérer le fichier original. Si ce n'est pas le cas, ce n'est plus de la compression de donnée.

Ce que vous appelez compression avec perte n'est pas de la compression, mais plutôt un codage décodage en gros un codec. Convertir le fichier original dans un autre format plus compact dont le but est de restituer le signal le plus proche et optimal de la vidéo, image, son original...

un gif et png sont des codecs avec leur propre compression se que vous appeler sans perte c'est sans perte visuelle, vous ne pourrez pas récupéré la source exacte aux niveaux des données.

Ajout d'une phrase clé (ou d'un objectif clé) ; suggestion modifiable / ajustable :

Bonjour à tous, et merci d'avance :

La compression de données traite de la manière dont on peut réduire l'espace nécessaire à la représentation d'une certaine quantité d'information. Elle a donc sa place aussi bien lors de la transmission que lors du stockage des données. Elle fait partie des applications de la théorie de l'information.

“« Comment compresser et obtenir le maximum d'information dans le minimum de place »”

“« La récupération d'informations compressées devant être totalement réversible »”

On peut classifier les méthodes de compressions en deux types, compression avec perte — également dite non conservative — et compression sans perte.

--- ********* :

J'apprécierai des références, et exemples, pour des projets de compression ultime.

L'exemple physique “ultime”, c'est l'antenne de voiture ou la canne à pêche.

Le taux de compression, est égale aux dimensions du dernier morceau restant, après réduction.

• Le but en informatique, c'est de conservé “virtuellement” les informations réduites.

--- ********* :

Pour moi, cette article, doit être considéré, comme d'une importance capitale ! MERCI.

Je parle de l'article “Compression de données”, sur Wikipedia®. MERCI.

Compression avec perte mais presque sans perte

A mon avis la distinction "compression presque sans perte" n'a pas lieu d'être. Le procédé de compression utilise des algorithmes de compression avec pertes, mais réglés avec des paramètres qui rendent les pertes insignifiantes (ou du moins insensible pour l'usager).--Silex6 (d) 29 avril 2010 à 13:31 (CEST)

Il ne s'agit pas d'algorithmes de compression avec peu de pertes, mais d'algorithmes sans perte de signification (j'ai essayé d'insister un peu dessus, mais je me rends bien compte que je n'ai pas réussi, la différence étant assez subtile).

Il y a une catégorie d'algorithmes qui dans l'absolu rentre dans les algorithmes de compression avec pertes, mais qui sont souvent présentés comme « sans pertes » (avec de gros guillemets — c'est plus un argument marketing qu'une réalité scientifique). C'est le cas d'une partie des algos de Stuffit, par exemple (cf. http://my.smithmicro.com/stuffitcompression/index.html).

La distinction n'est pas anodine, car dans certains domaines (l'imagerie médicale, par exemple), l'utilisation d'algorithmes de compression avec pertes (JPEG...) est prohibée, mais celle d'algorithmes presque sans perte (pixel-perfect : BMF...) est autorisée. Certains formats ne supportent pas la compression avec pertes, mais supportent la compression presque sans perte (exécutables, données déjà compressées...). — Arkanosis ^✉ 29 avril 2010 à 15:12 (CEST)

Selon l'explication qui est donnée dans le lien ci-dessus, StuffIt implémente des algorithmes de compression sans perte. En plus de ca il analyse le format de données de chaque fichier qui est ajouté à l'archive, en vue de supprimer du fichier à archiver tout les attributs qui sont inutilisés. Ce qui signifie que l'information contenue dans le fichier est identique à l'original, mais c'est la structure qui la contient qui est "nettoyée".

Si je regarde l'explication qui est donnée dans l'article, c'est cohérent, cependant l'explication tourne un peu autour du pot, et le nettoyage des métadonnées qui est la clé de cette compression est tout juste mentionnée entre parenthèses.--Silex6 (d) 29 avril 2010 à 19:24 (CEST)

je suis du meme avis que Silex6. Je ne suis pas d'accord sur cet ajout du presque sans perte, d'accord pour expliquer la technique, mais stuffit et juste un programme qui dans un premier tant vas modifier le fichier original et faire un nettoyage donc perte tu fichier original suivant filtre puis après ce nettoyage qui fait réduit la taille il y a une vraie compression sans perte sur le fichier modifier puis la décompression il restitue le fichier modifier.donc au final il y a une conversion du fichier avant la compression. il y a d'autres techniques avec une vraie précompression avec restitution de l'original sans aucune perte--Intercepte (d) 31 mai 2010 à 16:45 (CEST)

Compression physique / logique

On trouve sur internet des pages (parfois des cours d'informatique) énonçant les équivalences

   Compression Logique  ==   avec "pertes"
   Compression Physique  ==   sans "pertes"

(à vérifier : est-ce que ces notions sont officiellement reconnues ?)

— Le message qui précède, non signé, a été déposé par l'IP 129.20.55.107 (discuter)

Jamais entendu cette "distinction" entre les deux types de compression, les termes "avec/sans pertes" ((en) lossy/lossless) sont universellement utilisés... Cela ressemble plutôt au jargon d'un prof en particulier, j'en ai eu des comme ça.

Je pense avoir trouvé ta référence : Institut d'électronique et d'informatique Gaspard-Monge, et je dois dire que je ne suis pas d'accord avec ce choix de termes. J'explique :

* « La compression logique est effectuée par un raisonnement logique en substituant une information par une information équivalente. ».

Ceci est vrai quel que soit l'algorithme de compression, étant donné qu'un algorithme EST un raisonnement logique.

* « La compression physique agit sur les données même, il s'agit de regarder les données redondantes d'un train de bits à un autre. ».

Là encore, c'est vrai quel que soit l'algo de compression : en effet, dans une compression "avec pertes", il y a TOUJOURS une compression supplémentaire du flux de bits compressés avec perte, souvent par un codage de Huffman ou un LZ rapide. Et même en restant au niveau de l'algo avec pertes, les séquences de bits identiques dans le flux original seront compressées (avec pertes bien sûr) de la même façon, la seule différence étant que la notion de redondance est modulée par le fait d'être "presque" redondantes.

Donc, cette notion de "logique/physique" s'applique absolument à TOUS les algos de compression, rendant donc la "nuance" totalement inutile, voire trompeuse.

 Mac LAK ^{[ Discuter ]} 25 septembre 2015 à 19:47 (CEST)