Discuter:Compression de données

Un article de Wikipédia, l'encyclopédie libre.

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

[modifier] 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)

[modifier] 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)

[modifier] 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 tentée de rendre 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)