La compression est a base d'un langage haut bas niveau?
Résolu/Fermé
extrazlove
Messages postés
2
Date d'inscription
Statut
Membre
Dernière intervention
-
Utilisateur anonyme -
Utilisateur anonyme -
Bonjour,
Les logiciels de compression sont a base d'un langage haut niveau ou bas niveau?
Si tout fichier A est codée en binaire tout fichier A peuvent être écrit dans un nouveau fichier.c .
ou le fichier.C il y un tableau qui contient une suite de nombre(le fichier A)
la décompression se fera en écrivent le tableau de fichier.C dans un fichier.
exemple imagine un fichier =01010101010101010001010110101 0...1 en binaire et en décimale=12345678.....3 avec une taille de 1ko=1024 octet=8192 bit
short int peut contenir de 0 a 65 535 dans un taille de 16 bit
conversion de fichier en suite de chiffre
{ tableau case0 =10 tableau case 0+tableau case 1=10*1+2=12
....
tableau case i =10 tableau case i+tableau case i+1=tableau case i tableau case i+1
resulat tableau case i=fichier
}
donc une une simple case mémoire de int de taille 16 octet en peut encoder un fichier( ou plutôt un chiffre) assez grand que 1ko.
l'encodeur de décompression envoi un chiffre qui représente le fichier et aussi le nombre i d'octet de fichier.
avec ses deux informations(chiffre de fichier et nombre d'octet de fichier orignal)en peu faire facilement la décompression.
fichier=tableau case i= tableau case i tableau case i+1
puisque en connais le nombre de i de puis l'encodeur c'est facile de reconstitué le fichier original.
que pensez vous.
Les logiciels de compression sont a base d'un langage haut niveau ou bas niveau?
Si tout fichier A est codée en binaire tout fichier A peuvent être écrit dans un nouveau fichier.c .
ou le fichier.C il y un tableau qui contient une suite de nombre(le fichier A)
la décompression se fera en écrivent le tableau de fichier.C dans un fichier.
exemple imagine un fichier =01010101010101010001010110101 0...1 en binaire et en décimale=12345678.....3 avec une taille de 1ko=1024 octet=8192 bit
short int peut contenir de 0 a 65 535 dans un taille de 16 bit
conversion de fichier en suite de chiffre
{ tableau case0 =10 tableau case 0+tableau case 1=10*1+2=12
....
tableau case i =10 tableau case i+tableau case i+1=tableau case i tableau case i+1
resulat tableau case i=fichier
}
donc une une simple case mémoire de int de taille 16 octet en peut encoder un fichier( ou plutôt un chiffre) assez grand que 1ko.
l'encodeur de décompression envoi un chiffre qui représente le fichier et aussi le nombre i d'octet de fichier.
avec ses deux informations(chiffre de fichier et nombre d'octet de fichier orignal)en peu faire facilement la décompression.
fichier=tableau case i= tableau case i tableau case i+1
puisque en connais le nombre de i de puis l'encodeur c'est facile de reconstitué le fichier original.
que pensez vous.
A voir également:
- La compression est a base d'un langage haut bas niveau?
- Base de registre - Guide
- Formules mathématiques de base - Télécharger - Études & Formations
- Formules excel de base - Guide
- S avec trait en haut et en bas - Forum Clavier
- Gigaset as470h base ✓ - Forum telephonie fixe
9 réponses
Peu importe que le langage soit de haut ou bas niveau pour la compression de données, il faut juste pouvoir manipuler les valeurs à l'échelle du bit, ce qui est toujours possible avec les opérations de base...
Par contre, tu confonds 8192 bits et valeur de 0 à 8191! 8192 bits = valeur de 0 à 2^8192 - 01, ça n'a rien à voir!
Donc au risque de t'étonner, 8192 bits ça tient dans...8192 bits, point!
Par contre des techniques moins simplistes et plus réalistes donnent des vrais résultats: https://fr.wikipedia.org/wiki/Compression_de_donn%C3%A9es
Par contre, tu confonds 8192 bits et valeur de 0 à 8191! 8192 bits = valeur de 0 à 2^8192 - 01, ça n'a rien à voir!
Donc au risque de t'étonner, 8192 bits ça tient dans...8192 bits, point!
Par contre des techniques moins simplistes et plus réalistes donnent des vrais résultats: https://fr.wikipedia.org/wiki/Compression_de_donn%C3%A9es
- Une structure sont la taille est 32 bits ne peut pas contenir plus de ... 32 bits.
- La structure qui peut représenter un entier compris entre 0 et 65535 est un short int dont la taille est 16 bits.
- La structure qui peut représenter un entier compris entre 0 et 65535 est un short int dont la taille est 16 bits.
Oui, mais t'es quand même en train de dire qu'on peut mettre 8192 bits dans 16 bits... car c'est bien le principe de la compression dont tu parles, n'est-ce pas!
Tu te trompe en faisant des conversions qui ne sont plus comparables, et tu les compares quand même!
Une valeur de 0 à 8191 tient dans 13 bits.
8192 bits contiennent 512 structures short int...
Tu te trompe en faisant des conversions qui ne sont plus comparables, et tu les compares quand même!
Une valeur de 0 à 8191 tient dans 13 bits.
8192 bits contiennent 512 structures short int...
oui ,pour moi le fichiers décompressé contient qu un short int de valeur=au fichier original en décimal et d'un taille de 16 octet
pour avoir le fichier originelle il faut écrire se chiffre dans un nouveau fichier de même type que l'orignal.
pour avoir le fichier originelle il faut écrire se chiffre dans un nouveau fichier de même type que l'orignal.
Ha oui excuse-moi j'avais interprété 16 bits et non pas 16 octets, pour moi un short int c'est un mot, de deux octets donc (en delphi).
Mais bon ça change absolument rien, tu parles de décimal, alors que ce n'est qu'une représentation différente et qui n'a aucun sens ici, l'ordinateur ne comprend pas le décimal, ça sert simplement à l'humain qui l'utilise, et parfois, l'induit en erreur!
Oublie un instant la représentation décimale, et dis-toi que 16 octets ça fait 128 bits, et que dans ces 128 bits tu veux faire tenir 8192 bits!
Autrement dit:
128 = 8192
Donc maintenant sur cette base quelque peu extra-terrestre, essaie de t'expliquer comment tu parviens à le faire...
Et ensuite, de nous l'expliquer!
Mais bon ça change absolument rien, tu parles de décimal, alors que ce n'est qu'une représentation différente et qui n'a aucun sens ici, l'ordinateur ne comprend pas le décimal, ça sert simplement à l'humain qui l'utilise, et parfois, l'induit en erreur!
Oublie un instant la représentation décimale, et dis-toi que 16 octets ça fait 128 bits, et que dans ces 128 bits tu veux faire tenir 8192 bits!
Autrement dit:
128 = 8192
Donc maintenant sur cette base quelque peu extra-terrestre, essaie de t'expliquer comment tu parviens à le faire...
Et ensuite, de nous l'expliquer!
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
tout fichier écrire en binaire est un chiffre qui grandi selon la taille qui occupe le fichier dans la mémoire.
et si je prend ce chiffre je met dans une case mémoire voir plusieurs ca dépend de grandeur de chiffre
quand je veut avoir le fichier orignal j'écris simplement ce chiffre dans un fichier vide de même type que l'orignal.
et si je prend ce chiffre je met dans une case mémoire voir plusieurs ca dépend de grandeur de chiffre
quand je veut avoir le fichier orignal j'écris simplement ce chiffre dans un fichier vide de même type que l'orignal.
En fait, non!
Un fichier écrit en binaire... ça ne veut rien dire, un fichier ne peut pas être écrit autrement qu'en binaire, ce n'est qu'une facilité si tu peux écrire du texte, mais ce texte est converti en binaire, bien sûr!
Et tu parles de chiffre qui grandi, ou plutôt un nombre, alors d'accord, si on considère les bits d'un fichier comme constituants d'un même nombre, on obtient un nombre de plus en plus grand au fur et à mesure qu'on avance dans le fichier effectivement. Mais ce nombre, plus il grandi, plus il faut de bits pour le représenter, n'est-ce pas? D'ailleurs c'est bien ce qui se passe, on ajoute la valeur de chaque bit, à une position de plus en plus élevée! En fait ton fichier faisant 1 ko, on a un nombre occupant 1ko, tu comprends? Autrement dit si on reprend l'exemple avec ton smallint de 2 octets, hé bien dans ce fichier on peut en mettre 512, t'es d'accord? Donc, le fichier contient 512 smallint, comment veux-tu faire tenir ces 512 smallint dans un seul smallint?! Est-ce que tu me suis!
Là en fait ça revient à dire que 512 = 1!
Un fichier écrit en binaire... ça ne veut rien dire, un fichier ne peut pas être écrit autrement qu'en binaire, ce n'est qu'une facilité si tu peux écrire du texte, mais ce texte est converti en binaire, bien sûr!
Et tu parles de chiffre qui grandi, ou plutôt un nombre, alors d'accord, si on considère les bits d'un fichier comme constituants d'un même nombre, on obtient un nombre de plus en plus grand au fur et à mesure qu'on avance dans le fichier effectivement. Mais ce nombre, plus il grandi, plus il faut de bits pour le représenter, n'est-ce pas? D'ailleurs c'est bien ce qui se passe, on ajoute la valeur de chaque bit, à une position de plus en plus élevée! En fait ton fichier faisant 1 ko, on a un nombre occupant 1ko, tu comprends? Autrement dit si on reprend l'exemple avec ton smallint de 2 octets, hé bien dans ce fichier on peut en mettre 512, t'es d'accord? Donc, le fichier contient 512 smallint, comment veux-tu faire tenir ces 512 smallint dans un seul smallint?! Est-ce que tu me suis!
Là en fait ça revient à dire que 512 = 1!
Voilà, ce qu'il faut que tu comprennes, c'est qu'un bit c'est un chiffre, mais binaire! Donc par exemple on a un compteur à quatre chiffres décimaux, avec ce compteur on peut aller jusqu'à 9999, d'ac? Maintenant si on enlève un chiffre, on ne peut plus dépasser les 999, évidemment... Et en binaire, c'est pareil! Si tu enlève un chiffre, tu limites la valeur maximale de la même manière! Avec 4 bits, tu peux compter jusqu'à 15 (1111), si t'enlève un bit tu dépassera plus 7 (111), et voilà!
Tu t'embrouille tout simplement en faisant des conversions qui perdent leur sens! Reste dans les même mesure pour pouvoir les comparer, et tu comprendras mieux!
Tu t'embrouille tout simplement en faisant des conversions qui perdent leur sens! Reste dans les même mesure pour pouvoir les comparer, et tu comprendras mieux!
Oui mais justement c'est bien ce que tu n'as pas compris, un nombre c'est un octet! Un octet peut contenir n'importe quel nombre de 0 à 255, c'est tout, rien de plus! Pour mettre un nombre plus grand, ou pour mettre des chiffre derrière une virgule, il faut plus de bits, c'est tout!
Et chaque variable fait une certaine taille, cette taille est indépendante de son contenu bien sûr!
Donc si tu as un smallint qui occupe 16 bits, que tu y mette 1 ou 32000 n'y change rien, il occupe 16 bits dans tous les cas! La taille d'une variable en défini les limites sans qu'il y ait de chevauchement malheureux avec une autre variable! Donc l'espace occupé est fixe!
Et chaque variable fait une certaine taille, cette taille est indépendante de son contenu bien sûr!
Donc si tu as un smallint qui occupe 16 bits, que tu y mette 1 ou 32000 n'y change rien, il occupe 16 bits dans tous les cas! La taille d'une variable en défini les limites sans qu'il y ait de chevauchement malheureux avec une autre variable! Donc l'espace occupé est fixe!
c pas grave en va mettre dans les cases mémoire que des nombres assez grand
imagine que mon fichier et sous cette forme A1A2A3....Ai en binaire
en fixons une limite pour avoir A1 assez grand avec un type long ou double combien en aura du gain de mémoire
imagine que mon fichier et sous cette forme A1A2A3....Ai en binaire
en fixons une limite pour avoir A1 assez grand avec un type long ou double combien en aura du gain de mémoire
Le type employé n'y change rien!
Imagine! Dans 16 bits on peut mettre une valeur jusque 65535, donc une valeur de 0 à 65535 peut tenir dans 16 bits.
Pour représenter 16 bits, il faut donc retenir une valeur comprise entre 0 et 65535... et pour retenir cette valeur comprise entre 0 et 65535 il nous faut...16 bits!
Imagine! Dans 16 bits on peut mettre une valeur jusque 65535, donc une valeur de 0 à 65535 peut tenir dans 16 bits.
Pour représenter 16 bits, il faut donc retenir une valeur comprise entre 0 et 65535... et pour retenir cette valeur comprise entre 0 et 65535 il nous faut...16 bits!
Allez va, travaille donc un peu tes bases pour éviter de te casser la tête pour rien! C'est important de bien comprendre comment les nombres sont traités par l'ordinateur, tu y verras plus clair!
https://fr.wikipedia.org/wiki/Syst%C3%A8me_binaire
https://fr.wikipedia.org/wiki/Syst%C3%A8me_binaire
un fichier1 ko possède 1024 octet =8192 bit donc un chiffre entre 0 et un chiffre trop grand mais c pas grave même ce chiffre peut être contenu dans un structure plus petit .
chiffre trop grand impossible de le mettre dans 16 bit
mais fonction(chiffre trop grand )=un chiffre petit que en peut mettre dans 16 bit non?
et fonction-1 (un chiffre petit )= chiffre trop grand.
chiffre trop grand impossible de le mettre dans 16 bit
mais fonction(chiffre trop grand )=un chiffre petit que en peut mettre dans 16 bit non?
et fonction-1 (un chiffre petit )= chiffre trop grand.
Salut.
belle patiente nicocorico !
Je pense que la confusion viens du double, qui peut stocké des nombres allant jusqu'à 1e330 (en décimal) je crois, c'est à dire qu'on a l'impression que la valeur codé par 8192bits tiendrais dans un double. C'est en partie vrai MAIS c'est oublié certaines spécificités des nombres à virgules flottante.
un double est codé sur 64 bits, https://en.wikipedia.org/wiki/Double_precision avec seulement 52 bits pour la mantisse. La conséquance, c'est qu'il n'y a plus aucune information au dela de 15 chiffres (décimaux) après la virgule.
Pour s'en convaincre, essai le code suivant :
tu verra que b-a retourne 0, car 1. est sous la précision de 3e20.
Renseigne toi sur les algorithmes de compression, tu verra que les plus efficaces font des hypothèses sur le type de grandeur représenté (texte, son, image).
belle patiente nicocorico !
Je pense que la confusion viens du double, qui peut stocké des nombres allant jusqu'à 1e330 (en décimal) je crois, c'est à dire qu'on a l'impression que la valeur codé par 8192bits tiendrais dans un double. C'est en partie vrai MAIS c'est oublié certaines spécificités des nombres à virgules flottante.
un double est codé sur 64 bits, https://en.wikipedia.org/wiki/Double_precision avec seulement 52 bits pour la mantisse. La conséquance, c'est qu'il n'y a plus aucune information au dela de 15 chiffres (décimaux) après la virgule.
Pour s'en convaincre, essai le code suivant :
double a=3e20;
double b=a;
for (double c=0.;c<1e13;c+=1.)
b+=1.0;
cout<<b-a;
tu verra que b-a retourne 0, car 1. est sous la précision de 3e20.
Renseigne toi sur les algorithmes de compression, tu verra que les plus efficaces font des hypothèses sur le type de grandeur représenté (texte, son, image).
@Char sniper, n'est-ce pas! C'est utile, là!
En fait Extrazlove pense qu'un nombre quel que soit sa taille est un octet, et donc tiens dans 8 bits!
Donc voilà, à nouveau:
Un nombre décimal est constitué de chiffres décimaux, si tu enlèves des chiffres, tu perds des informations, n'est-ce pas! Donc on ne peut pas diminuer ce nombre sans perdre des informations!
En binaire, c'est pareil! Un bit c'est un chiffre aussi, mais binaire cette fois.. Si tu enlève des bits, tu perd des informations! Donc tu peux considérer qu'un fichier d'un KiloOctet c'est un très grand nombre unique, mais dans ce cas c'est un nombre qui fait 8192 bits! Et tu ne peux pas en retirer sans perte! Ou alors il faut passer par des techniques de compression, et rien d'autre!
En fait Extrazlove pense qu'un nombre quel que soit sa taille est un octet, et donc tiens dans 8 bits!
Donc voilà, à nouveau:
Un nombre décimal est constitué de chiffres décimaux, si tu enlèves des chiffres, tu perds des informations, n'est-ce pas! Donc on ne peut pas diminuer ce nombre sans perdre des informations!
En binaire, c'est pareil! Un bit c'est un chiffre aussi, mais binaire cette fois.. Si tu enlève des bits, tu perd des informations! Donc tu peux considérer qu'un fichier d'un KiloOctet c'est un très grand nombre unique, mais dans ce cas c'est un nombre qui fait 8192 bits! Et tu ne peux pas en retirer sans perte! Ou alors il faut passer par des techniques de compression, et rien d'autre!
pour avoir des variable avec grand précision il faut utilisé des calcules des algorithmes voir https://openclassrooms.com/forum/sujet/calcul-de-precision-46590
si on a A1 et A2 notre compression et fini.
pour trouver A1 et A2 faut juste faire une comparaison entre factoriel(A1 8bit)+(A2 8bit) ) et notre fichier .
si on a A1 et A2 notre compression et fini.
pour trouver A1 et A2 faut juste faire une comparaison entre factoriel(A1 8bit)+(A2 8bit) ) et notre fichier .
Bonjour à tous !
Discussion passionnante ( ou monologue persistant ? ) ..
Je soumet à votre sagacité le problème suivant :
"comment compresser quelques milliards de bits sur DEUX octets ?"
Réponse :
"Pi" ( 2 octets = 16 bits )
permet de stocker un nombre de quelques milliards de digits, inclus ceux qui ne sont pas encore connus , ou ne le seront jamais ..
ou encore :
0
contient toute la présente discussion ( pas encore prête d'être terminée, j'imagine )
A+
Nyctaclope
Discussion passionnante ( ou monologue persistant ? ) ..
Je soumet à votre sagacité le problème suivant :
"comment compresser quelques milliards de bits sur DEUX octets ?"
Réponse :
"Pi" ( 2 octets = 16 bits )
permet de stocker un nombre de quelques milliards de digits, inclus ceux qui ne sont pas encore connus , ou ne le seront jamais ..
ou encore :
0
contient toute la présente discussion ( pas encore prête d'être terminée, j'imagine )
A+
Nyctaclope
oui mais la mémoire dans un ordinateur sais pas très bien gérer des nombres flottant tel que pi avec prisions....
Bon voila mon but c'est avoir un t entier assez petit qui peut s'écrire dans un octet voir deux.
Si n représente un grand nombre entier écrit en binaire sur plusieurs Go alors son image représente un couple former par (t,a) avec t et a qui peuvent s'écrire dans un octet voir deux.
tel que n=t!+a pour retrouver notre n suffit de mettre t!+a un simple calcule pour enregistrer tout un fichier en binaire a partir de deux variable t et a.
Bon voila mon but c'est avoir un t entier assez petit qui peut s'écrire dans un octet voir deux.
Si n représente un grand nombre entier écrit en binaire sur plusieurs Go alors son image représente un couple former par (t,a) avec t et a qui peuvent s'écrire dans un octet voir deux.
tel que n=t!+a pour retrouver notre n suffit de mettre t!+a un simple calcule pour enregistrer tout un fichier en binaire a partir de deux variable t et a.
imaginons une image en noir et blanc ...
elle est donc constituer de pixel noir et blanc, en partant d principe que l image est faite d un carrée de 1000*1000 pixel.
que dans la mémoire la valeur des pixel est aligné avec un retour de ligne tous les 1000 pixel.
voila le début de l image 0 = blanc 1 = noir ..
000001111000001111110000111111000000000111
la compression va alors consisté a compte le nombre de pixel blanc et et noir ce qui donne :
5041506140619031...
sachant que chaque valeur prend 16 bit ... quel soi compresser ou non, le but de la compression réduit bien le nombre de valeur a garder mais pas la taille des octet.
dans mon exemple on passe alors de 42 paquet de 16 bit a seulement ...
16 paquet de 16 bit ... et il est la le gain de place.
mon exemple est le mode de compression le plus basique.
il en existe des bien plus complexe, par exemple pour des images la compression vectoriel, cela transforme l image en plusieurs "équation" , ansi l arc de cercle ne sera pas compresser au pixel, mais ce sera la formule de l arc de cercle qui sera utilise..
l ordi recalculera alor la forme de l arc de cercle avec la formule contenu dans le fichier, ce mode de compression est très utile pour des dessins car peu de nuance de couleur.
exemple pour un cercle : se sera la formule du cercle qui ne contiens que quelque caractère qui sera utilise.
le mp3 et le mpg sont des méthode de compression dégradante, car il réduise le nombre de valeurs a compresser, c est a dire pour le mp3 , les fréquences inaudible et pour les images, les couleurs que l on ne peu voir.
une image faite de 1 million de nuances, sera a nos yeux la même que celle a 100 000 nuances.
au passage, c est grâce a la compression direct des apn que l on peut faire des trucage photo sans retouché l image, la compression fessant le travaille de gommage du fil de pèche tenant la soucoupe volante par exemple.
elle est donc constituer de pixel noir et blanc, en partant d principe que l image est faite d un carrée de 1000*1000 pixel.
que dans la mémoire la valeur des pixel est aligné avec un retour de ligne tous les 1000 pixel.
voila le début de l image 0 = blanc 1 = noir ..
000001111000001111110000111111000000000111
la compression va alors consisté a compte le nombre de pixel blanc et et noir ce qui donne :
5041506140619031...
sachant que chaque valeur prend 16 bit ... quel soi compresser ou non, le but de la compression réduit bien le nombre de valeur a garder mais pas la taille des octet.
dans mon exemple on passe alors de 42 paquet de 16 bit a seulement ...
16 paquet de 16 bit ... et il est la le gain de place.
mon exemple est le mode de compression le plus basique.
il en existe des bien plus complexe, par exemple pour des images la compression vectoriel, cela transforme l image en plusieurs "équation" , ansi l arc de cercle ne sera pas compresser au pixel, mais ce sera la formule de l arc de cercle qui sera utilise..
l ordi recalculera alor la forme de l arc de cercle avec la formule contenu dans le fichier, ce mode de compression est très utile pour des dessins car peu de nuance de couleur.
exemple pour un cercle : se sera la formule du cercle qui ne contiens que quelque caractère qui sera utilise.
le mp3 et le mpg sont des méthode de compression dégradante, car il réduise le nombre de valeurs a compresser, c est a dire pour le mp3 , les fréquences inaudible et pour les images, les couleurs que l on ne peu voir.
une image faite de 1 million de nuances, sera a nos yeux la même que celle a 100 000 nuances.
au passage, c est grâce a la compression direct des apn que l on peut faire des trucage photo sans retouché l image, la compression fessant le travaille de gommage du fil de pèche tenant la soucoupe volante par exemple.
