Fichier, taille

Salut à tous.
Une question m’occupe la tête depuis presque 5-6 ans (pas en boucle rapide heureusement :laughing:).

Je m’explique, prenons l’exemple d’un fichier gros: film 700 mb ou 20-50 gb ou comme les uhd qui pèse énorme.
Quand on le récupère (exemple) par réseaux, on le récupère à la même taille, ce qui est énorme pour la consommation (électrique/limite internet/notre argent).

Pourquoi n’utilisons pas un algorithme pour diminuer la taille.
Pour des utilisations ciblé (comme le partage publique), pas n’importe lesquels.

Ce qui permettrait dans notre exemple:

  • d’envoyer quelques mb au lieu des centaines/milliers/ou plus de mb
  • on peut remettre le fichier à l’état initial via l’algorithme et la puissance de l’ordinateur

Parfois la mise en état initial avec un ordinateur faible puissance, peut-être plus lent, que de télécharger le fichier brute à cause de la vitesse haute du réseaux.
Il y a aussi les cas, où il est inutile d’utiliser la méthode selon l’utilisation, comme des petits donnée utilisé de manière temporaire.

Salut
Question très générale (à laquelle je n’ai rien compris d’ailleurs…) je déplace dans PC.

Parce que les vidéos sont déjà compressées et qu’en compressant un fichier compressé on ne gagne pas grand chose ?

Gaffe kripteks ! Je crois que ces gens-là t’ont piqué ton idée :
7-zip.org/

:mrgreen:

Tu as 2 type d’algo de compression :
– Avec perte (JPG, MPEG, MP3 …)
– Sans perte (ZIP, FLAC, …)

Donc suivant le cas il faut prendre des algo en relation. Pour une image tu accepteras quelques perte, pour un logiciel aucune …
Bien sur les algo de compression sans perte sont bien moins performant que ceux avec perte.
Beaucoup de format de fichier inclus la compression dans les specs, PDF et ODT en font parti il me semble.

Je vais vous donnée un exemple.
Imaginez un algorithme, qui permet d’avoir une donnée de ce type: 4987129512092190-32-27-89 à partir d’un fichier de 100 mb.

Dans notre donnée réduit (4987129512092190-32-27-89), on a 4 parties:
1- suite de chiffres pas trop grande
2- 1ér niveau
3- 2ème niveau
4- 3ème niveau

Pour remettre notre fichier à l’état initial, on fait des opérations à chaque niveaux, avec le résultat final du précédent, jusqu’au dernier niveau:
opération suitedechiffres et 1ér niveau = a
opération a et 2ème niveau = b
opération b et 3ème niveau = c
c = donnée final = même que le fichier initial 100 mb.

A chaque étape le fichier est agrandi, à la fin de l’étape final, les données seront les même que le fichier initial.

PS: pour les pertes.
Il n’y en aurait, car le but est pas de diminuer la taille du fichier réel.
Comme dans mon exemple, on réduit par étape, puis on remet par étape à état inital.
La remise en état initial permet à la fin du dernier étape d’avoir ce fichier à état initial intact, il n’y a pas de diminution de taille réel, donc pas de perte.

C’est beau la naïveté des fois… :115

J’en déduis que je c’est pas réalisable ?
(C’est juste une idée théorique, à savoir si c’est possible ou pas, d’où mon sujet.)

C’est le principe de Shannon. Essaye de faire un zip d’un zip, tu verras tout de suite le problème. Autre chose, fais par exemple

dd if=/dev/urandom of=/tmp/toto bs=1M count=1 gzip /tmp/totoet regarde la taille du fichier obtenu par rapport au 1M d’origine, tu comprendras.

La différence de taille plus élevé et l’augmentation de taille <- tous le contraire qu’on veut :laughing:

Mais nous devrions trouver un moyen, si c’est possible.

@kripteks > :laughing: :laughing: :laughing:

Désolé mais c’est relativement drôle. D’autres ici (Fraçois en tête) t’expliquerais mieux que moi que c’est une question de mathématiques.

Comme tu le sait, on peut voir un fichier comme un nombre (disons n). On peut voir un algorithme de compression comme une fonction (disons f).

Pour compresser ton fichier tu fait un simple :

Bon ça c’est bien beau mais un algorithme de compression ne sert à rien sans son pendant qui décompresse (disons f’) et tu veux obtenir à tout prix que :

On est bien d’accord que pour un nombre n la fonction f doit associer une valeur unique et de même pour f’. Dis de manière plus mathématiques :

pour e = f(n) et e' = f(n') si e = e' alors n = n'
C’est ce que l’on appel la bijection si je ne me trompe pas.

Maintenant n doit être n’importe quel fichier, donc n est n’importe quel entier naturel (on dit que f est défini pour tout N (le beau N pour les entier naturel).

Ce que tu recherche c’est à ce que c (le résultat), soit dans disons 50 digits.

Donc c peut prendre 10⁵⁰, donc si on respecte la bijection on ne peut compresser que 10⁵⁰ fichiers différents.

C’est là tout le problème des algorithmes de hashage. Ils donnent une même valeur pour des fichiers différents. On appel ça les collisions. Ce ne sont pas des fonctions bijectives.

Les algorithmes de compressions ne se donnent pas de limitent dans la taille de la sortie. Ils essaient juste que log_2© < log_2(n), mais ce n’est en aucun cas une garantie ! (tu peut même avoir des cas où log_2© > log_2(n)).

Note : pourquoi je parle du log_2 (log en base 2). En informatique on compte en binaire (et pas en base 10). Le log en base 2 d’un nombre indique le nombre de bits (-1) nécessaire pour coder un nombre (c’est une grosse approximation). Par exemple pour 4, log_2(4) = 2, donc il faut 3 bits pour stocker 4 en binaire (100). Le +1 viens du fait qu’il faut coder le 0, donc log_2(4) donne le place qu’il faut pour coder 4 valeurs différentes (0, 1, 2 et 3).

Voila je pense ne pas avoir dis trop de conneries ni en mathématiques, ni en théorie de l’information (je serais content si quelqu’un m’écharpe là dessus histoire que je ravive un petit peu mes vieux cours).

La compression selon kripteks
Désolé, je n’ai pas pu m’empêcher… :033

[quote=“lroy”]La compression selon kripteks
Désolé, je n’ai pas pu m’empêcher… :033[/quote]
Bah oui :laughing:
C’est exactement comme sa expliqué graphiquement quoi de plus :smiley:, oublié pas la formule magique.

Aller je vais te donner le logiciel dont tu rêve.
Après avoir appliquer sa méthode de compression révolutionnaire ton fichier sera réduit à 1 seul octet :mrgreen: :mrgreen: :mrgreen:
fr.wikipedia.org/wiki/NABOB

Regarde aussi ses concurrents en bas de page :005

En fait il existe réellement un logiciel de compression à 1 octet, mais il suppose qu’on peut avoir un nom aussi grand que l’on veut. Je ne me souviens plus de son nom («Bof» ou «Bah» ou «Miam» je crois, à vérifier). Les octets étaient rejoutés dans l’ordre en hexadécimal au nom. Le fichier final faisait 1 octet mais avait un nom gigantesque…

“barf” (cf lien du dessus)

Barf, c’est ça… Où est ce dans le lien?

edit: vu, je suis un âne.

Je ne me permettrais pas tout de même.