Bonjour à tous,
l'heure est grave !

Ce qui sera dit sur ce post est très sérieux et pourra provoquer des bouleversements gigantesques !

Non, relativisons :

Si ce système est bon, il faudra défendre son utilisation qui ne devra pas être commerciale, ok ?

Bon après les prémices, voila ce que je vous propose :

Un gars que je connaissait il y a deux ans m'a parlé d'une idée, de son idée, un nouveau format de compression.
Il n' arrivait pas du tout à programmer son idée et il a laissé tombé je crois, je n'ai pas repris contact avec lui...

L'idée était pas mal, mais si ça se trouve ça existe déjà :

Prenez un fichier, c'est un ensemble d'octets alignés...

Pour convertir un octet en système décimal comme nous, il suffit d'employer un tableau de conversion :

256 128 64 32 16 8 4 2 1
0 0 0 0 0 0 0 0 0

Imaginons que une variable soit représentée par deux octets
le tableau devient:

64.... 32668 16334 8192 4096 2048 1024 512 256 128 32 16 8 4 2 1

Imaginons qu'on considère le fichier représentant UN SEUL nombre intersidéral codé avec 110 ko (par exemple) ce qui représente une
valeur décimale énorme..

Imaginez qu'on divise ce nombre par deux et qu'on le réencode avec le meme tableau : cela fera (au maximum un fichier 2x plus petit) si le nombre est impair on stock un bit à la fin du fichier pour le dire.

Toute ces opération sont évidemment répêtables, on reprend le fichier compresser on convertit, on divise par deux ...
jusqu'a que le fichier ne change plus de taille.

Avez vous compris l'idée ?
Est-Elle bonne ?

Si oui, recherche personne pour m'aider à coder ce nouveau format !

Avez vous compris l'idée ?
Est-Elle bonne ? << à moins que je n'ai pas compris ton idée : non, elle n'est pas bonne. Tu as au final besoin d'autant de bits pour stocker les données, tu les exprime juste sous une forme différente. Je ne suis pas sûr d'avoir compris une partie de tes explications, cependant : tu écris dans le fichier le nombre décimal transmis, textuellement (sous forme ascii) : "34766" (par exemple) ou bien "en binaire" ? parce que si dans la seconde solution (binaire) tu as besoin d'autants de bits pour coder ton nombre, dans la premiere (ascii) tu en as besoin de beaucoup, beaucoup plus. Mais dans tous les cas, soit ça ne change rien, soit la taille de ton fichier est multipliée par beaucoup

Si c'étais aussi simple, crois moi, ça ferait longtemps qu'un tel algo de compression aurait été trouvé .

Je pense aussi mais je vais quand même essayer, ca coute rien !
D'abord tu lis ton fichier en binaire, mais tu lis tous les bits (0,1) comme si ils représentaient un nombre codé sur la taille du fchier au lieu d'un nombre codé sur 1 octet (255)

Je vais taché de faire une explication plus clair avec un schéma

ON attend !

Ben ctaprem je vais à la piscine ... Alors ce soir ptet !

Je pense aussi mais je vais quand même essayer, ca coute rien << si tu veux

mais c'est "logique" : comme si ils représentaient un nombre codé sur la taille du fchier au lieu d'un nombre codé sur 1 octet c'est exactement la même chose. Tu peux soit interpréter le fichier comme une série de nombres codés sur un octet, soit comme un nombre gigantesque en prenant en compte tous les bits de tous les octets. Mais dans les deux cas, il est inscrit de façon identique dans le fichier. Tu ne peux pas diminuer le nombre de bits utilisés de cette façon.

Essaie pour t'en rendre compte

D'accord avec Solozerk. C'est évident que ça prend autant de place. Il suffit que tu reprennes ton tableau avec les bits
Quand tu veux réencoder ton nombre tu vas être obligé de le faire en binaire ce qui va donner la même chose. Ensuite tu dis si je divise le nombre par 2 ça prend deux fois moins de place. Là aussi c'est faux. Ca va juste prendre un bit de moins. Enfin même si j'ai pas bien compris c'est pas grave dans tous les cas c'est faux . Sinon pense bien que ça aurait déjà été trouvé.

La compression (sans perte) repose sur de l'analyse mathématique et la redondance des caractères qui va, soit en utilisant un dictionnaire, soit en utilisant un code plus petit (moins de 8 bits) pour les caractères qui reviennent le plus, diminuer la taille d'un fichier. Pour le dictionnaire pas besoin d'explications c'est assez compréhensible. Pour ce qui est de diminuer le nombre de bit d'un caractère qui revient souvent c'est déjà plus embêtant bien que le principe soit simple.
Imagine que tu es une suite de caractère comme ceci
AABBBAACCDAAAAAADDEEFFAAA
chaqu'un de ces caractères est codé sur 8 bits. Mais le caractère A revient souvent. Au lien de le coder 01000001 par exemple le mieux serait de le coder 1. le B par exemple 10, le C 11, le D 100 le E 101, le F 110. Enfin tu comprends le principe de base
ce qui donnerait
1110101011 etc...
Le problème (car ce n'est pas aussi simple) c'est lors de la relecture comment savoir qui est quoi ? C'est pour ça qu'il faut trouver une méthode pour être sûr qu'il n'y est pas d'interferences entre les suites de bits. C'est surtout en ça que ce distingue les différentes méthodes de compression zip, rar, etc... : Comment trouver les codes les plus courts tout en étant sûr qu'il n'y est pas de problèmes de relecture. En s'appuyant également sur un dictionnaire on obtient une compression efficace. On peut noter également que c'est en cela que les fichiers textes sont bien mieux compressés que les programmes car ils contiennent moins de caractères différents que leurs homologues les executables.
Il existe d'autres types de méthodes je pense à la méthode fractale. Où on essaye de décomposer une suite de caractères en fonctions mathématiques (en fait c'est surtout utilisé pour les compressions type "avec perte"). On peut citer le jpeg qui repose là encore sur l'application de la DCT et de diverses formules mathématiques bien lourdes (tout comme mon message d'ailleurs)...

Bon je m'étend un peu trop sur le sujet. Mais tout ça pour dire qu'une compression sans perte repose plus sur des analyses mathématiques plutôt que sur des petits trucs comme celui là

Pour ceux qui veulent en savoir plus, huffman est trés cool pour comprendre comment fonctionne un algorithme de compression d'une maniere générale :

http://tcharles.developpez.com/Huffman/
http://www.howtodothings.com/ViewArticle.aspx?article=392
http://www.alphabeta-net.com/Huffman.html

COPYRIGHT
COPYRIGHT
COPYRIGHT
COPYRIGHT

Je dépose un brevet !

Cette routine marche au dela de mon espérence !
Chais pas sur quoi chui tombé

Je suis en train de programmer la rourtine de déécompression !

Je vous montrerais ca quand ce sera finit, attention c'est pas dit que mon algorythme fonctione bien , j'ai pas finit !!!!!

Je suis très déçu, je me suis gourré dans un calcul :

x=255*y
à la place de
x=255^y

ce qui change tout au niveau taille !

BOUHOUOUOU, m'enfin je continurais à rechercher !

[edit] Un seul smiley suffit dans le tire, inutile de déformer l'affichage [/edit]

Edité par neliger (11/06/2005 22:22:28)

dommage... de fausses esperances !