Le nouveau format développé par Microsoft avance : http://www.clubic.com/actualite-93812-jpeg-microsoft-photo-jpeg-xr.html
Pour le tester sur Photoshop CS2 ou CS3 : http://tinyurl.com/2ptfmr
Le JPEG 2000 a échoué contre le JPEG de base, que fera le nouveau JPEG XR ?
Je ne sais pas, en tout cas il se raconte pas mal de c........es sur ce
forum, comme d'envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Zipper, rar-er, 7z-er un fichier dont **toutes** les valeurs sont différentes à très peu de chances de donner un résultat plus petit, et pas mal de chances de donner plus gros. La compression sans perte et réellement efficace (taille résultat < taille départ) est jouable (gif et png + efficace) quand on peut ramener une image à une palette, grosso-modo quand le nombre de valeurs possibles et petit devant le nombre de points à encoder, et ça c'est une donnée **mathématique**.
Hello,
Le nouveau format développé par Microsoft avance :
http://www.clubic.com/actualite-93812-jpeg-microsoft-photo-jpeg-xr.html
Pour le tester sur Photoshop CS2 ou CS3 :
http://tinyurl.com/2ptfmr
Le JPEG 2000 a échoué contre le JPEG de base, que fera le nouveau JPEG XR ?
Je ne sais pas, en tout cas il se raconte pas mal de c........es sur ce
forum,
comme d'envisager de la compression sans perte (et quand-même des
fichiers de taille manipulable) sur des images en dizaines de mégapixels
et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans
perte possible si tous les points sont susceptibles d'avoir une valeur
différente de celle de tous les autres.
Zipper, rar-er, 7z-er un fichier dont **toutes** les valeurs sont
différentes à très peu de chances de donner un résultat plus petit, et
pas mal de chances de donner plus gros. La compression sans perte et
réellement efficace (taille résultat < taille départ) est jouable (gif
et png + efficace) quand on peut ramener une image à une palette,
grosso-modo quand le nombre de valeurs possibles et petit devant le
nombre de points à encoder, et ça c'est une donnée **mathématique**.
Le nouveau format développé par Microsoft avance : http://www.clubic.com/actualite-93812-jpeg-microsoft-photo-jpeg-xr.html
Pour le tester sur Photoshop CS2 ou CS3 : http://tinyurl.com/2ptfmr
Le JPEG 2000 a échoué contre le JPEG de base, que fera le nouveau JPEG XR ?
Je ne sais pas, en tout cas il se raconte pas mal de c........es sur ce
forum, comme d'envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Zipper, rar-er, 7z-er un fichier dont **toutes** les valeurs sont différentes à très peu de chances de donner un résultat plus petit, et pas mal de chances de donner plus gros. La compression sans perte et réellement efficace (taille résultat < taille départ) est jouable (gif et png + efficace) quand on peut ramener une image à une palette, grosso-modo quand le nombre de valeurs possibles et petit devant le nombre de points à encoder, et ça c'est une donnée **mathématique**.
Jean-Claude Ghislain
comme d'envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Petit test avec une photo Tiff prise au hasard :
Tiff non compressé : 13200 Ko Tiff compressé LZW : 8220 Ko Le nouveau format en position "Lossless" : 6355 Ko
Comparaison des images en mode "Différence", tout pixels à 0, les images semblent identique.
A tester.
-- Jean-Claude Ghislain
comme d'envisager de la compression sans perte (et quand-même des
fichiers de taille manipulable) sur des images en dizaines de
mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune**
compression sans perte possible si tous les points sont susceptibles
d'avoir une valeur différente de celle de tous les autres.
Petit test avec une photo Tiff prise au hasard :
Tiff non compressé : 13200 Ko
Tiff compressé LZW : 8220 Ko
Le nouveau format en position "Lossless" : 6355 Ko
Comparaison des images en mode "Différence", tout pixels à 0, les images
semblent identique.
comme d'envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Petit test avec une photo Tiff prise au hasard :
Tiff non compressé : 13200 Ko Tiff compressé LZW : 8220 Ko Le nouveau format en position "Lossless" : 6355 Ko
Comparaison des images en mode "Différence", tout pixels à 0, les images semblent identique.
A tester.
-- Jean-Claude Ghislain
markorki
comme d'envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Petit test avec une photo Tiff prise au hasard :
Tiff non compressé : 13200 Ko Tiff compressé LZW : 8220 Ko Le nouveau format en position "Lossless" : 6355 Ko
Comparaison des images en mode "Différence", tout pixels à 0, les images semblent identique.
A tester.
oui mais tes images sont petites par rapport à ce dont je parle (et eux
parlent) peux-tu nous donner le nombre de pixels et le nombre de bits par point ?
comme d'envisager de la compression sans perte (et quand-même des
fichiers de taille manipulable) sur des images en dizaines de
mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune**
compression sans perte possible si tous les points sont susceptibles
d'avoir une valeur différente de celle de tous les autres.
Petit test avec une photo Tiff prise au hasard :
Tiff non compressé : 13200 Ko
Tiff compressé LZW : 8220 Ko
Le nouveau format en position "Lossless" : 6355 Ko
Comparaison des images en mode "Différence", tout pixels à 0, les images
semblent identique.
A tester.
oui mais tes images sont petites par rapport à ce dont je parle (et eux
parlent)
peux-tu nous donner le nombre de pixels et le nombre de bits par point ?
comme d'envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Petit test avec une photo Tiff prise au hasard :
Tiff non compressé : 13200 Ko Tiff compressé LZW : 8220 Ko Le nouveau format en position "Lossless" : 6355 Ko
Comparaison des images en mode "Différence", tout pixels à 0, les images semblent identique.
A tester.
oui mais tes images sont petites par rapport à ce dont je parle (et eux
parlent) peux-tu nous donner le nombre de pixels et le nombre de bits par point ?
Jean-Claude Ghislain
oui mais tes images sont petites par rapport à ce dont je parle (et eux parlent)
Je ne prends pas un monstre pour un petit test ;-))
peux-tu nous donner le nombre de pixels et le nombre de bits par point ?
4498641 pixels et 24 bits (3x8).
-- Jean-Claude Ghislain
oui mais tes images sont petites par rapport à ce dont je parle (et
eux parlent)
Je ne prends pas un monstre pour un petit test ;-))
peux-tu nous donner le nombre de pixels et le nombre de bits par point
?
oui mais tes images sont petites par rapport à ce dont je parle (et eux parlent)
Je ne prends pas un monstre pour un petit test ;-))
peux-tu nous donner le nombre de pixels et le nombre de bits par point ?
4498641 pixels et 24 bits (3x8).
-- Jean-Claude Ghislain
François Jouve
markorki wrote:
Hello,
Le nouveau format développé par Microsoft avance : http://www.clubic.com/actualite-93812-jpeg-microsoft-photo-jpeg-xr.html
Pour le tester sur Photoshop CS2 ou CS3 : http://tinyurl.com/2ptfmr
Le JPEG 2000 a échoué contre le JPEG de base, que fera le nouveau JPEG XR ?
Je ne sais pas, en tout cas il se raconte pas mal de c........es sur ce
forum,
En effet. Quand on commence comme ça, il faut ensuite assurer...
comme d'envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Bien entendu. Mais sauf à photographier du bruit blanc (c'est ton droit) c'est quand même rarement le cas. La plupart des photos réelles ont de fortes potentialités de compression sans perte.
Zipper, rar-er, 7z-er un fichier dont **toutes** les valeurs sont différentes à très peu de chances de donner un résultat plus petit, et pas mal de chances de donner plus gros. La compression sans perte et réellement efficace (taille résultat < taille départ) est jouable (gif et png + efficace) quand on peut ramener une image à une palette, grosso-modo quand le nombre de valeurs possibles et petit devant le nombre de points à encoder, et ça c'est une donnée **mathématique**.
C'est une vision très naïve du problème de compression. Il y a bien d'autres outils qui permettent de faire de la compression, mais ils sont un peu délicats à présenter ici. D'autre part, sauf applications très particulières, la compression sans perte n'est pas ce qu'il y a de plus intéressant. Il est beaucoup plus utile de savoir compresser avec discernement, en évitant les artefacts visuellement disgracieux (comme ceux que l'on observe avec du jpeg à fort taux de compression). Le jpeg2000 allait dans ce sens.
-- F.J.
markorki wrote:
Hello,
Le nouveau format développé par Microsoft avance :
http://www.clubic.com/actualite-93812-jpeg-microsoft-photo-jpeg-xr.html
Pour le tester sur Photoshop CS2 ou CS3 :
http://tinyurl.com/2ptfmr
Le JPEG 2000 a échoué contre le JPEG de base, que fera le nouveau JPEG
XR ?
Je ne sais pas, en tout cas il se raconte pas mal de c........es sur ce
forum,
En effet. Quand on commence comme ça, il faut ensuite assurer...
comme d'envisager de la compression sans perte (et quand-même des
fichiers de taille manipulable) sur des images en dizaines de mégapixels
et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans
perte possible si tous les points sont susceptibles d'avoir une valeur
différente de celle de tous les autres.
Bien entendu. Mais sauf à photographier du bruit blanc (c'est ton droit)
c'est quand même rarement le cas.
La plupart des photos réelles ont de fortes potentialités de compression
sans perte.
Zipper, rar-er, 7z-er un fichier dont **toutes** les valeurs sont
différentes à très peu de chances de donner un résultat plus petit, et
pas mal de chances de donner plus gros. La compression sans perte et
réellement efficace (taille résultat < taille départ) est jouable (gif
et png + efficace) quand on peut ramener une image à une palette,
grosso-modo quand le nombre de valeurs possibles et petit devant le
nombre de points à encoder, et ça c'est une donnée **mathématique**.
C'est une vision très naïve du problème de compression. Il y a bien
d'autres outils qui permettent de faire de la compression, mais
ils sont un peu délicats à présenter ici.
D'autre part, sauf applications très particulières, la compression
sans perte n'est pas ce qu'il y a de plus intéressant. Il est beaucoup
plus utile de savoir compresser avec discernement, en évitant les
artefacts visuellement disgracieux (comme ceux que l'on observe
avec du jpeg à fort taux de compression).
Le jpeg2000 allait dans ce sens.
Le nouveau format développé par Microsoft avance : http://www.clubic.com/actualite-93812-jpeg-microsoft-photo-jpeg-xr.html
Pour le tester sur Photoshop CS2 ou CS3 : http://tinyurl.com/2ptfmr
Le JPEG 2000 a échoué contre le JPEG de base, que fera le nouveau JPEG XR ?
Je ne sais pas, en tout cas il se raconte pas mal de c........es sur ce
forum,
En effet. Quand on commence comme ça, il faut ensuite assurer...
comme d'envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Bien entendu. Mais sauf à photographier du bruit blanc (c'est ton droit) c'est quand même rarement le cas. La plupart des photos réelles ont de fortes potentialités de compression sans perte.
Zipper, rar-er, 7z-er un fichier dont **toutes** les valeurs sont différentes à très peu de chances de donner un résultat plus petit, et pas mal de chances de donner plus gros. La compression sans perte et réellement efficace (taille résultat < taille départ) est jouable (gif et png + efficace) quand on peut ramener une image à une palette, grosso-modo quand le nombre de valeurs possibles et petit devant le nombre de points à encoder, et ça c'est une donnée **mathématique**.
C'est une vision très naïve du problème de compression. Il y a bien d'autres outils qui permettent de faire de la compression, mais ils sont un peu délicats à présenter ici. D'autre part, sauf applications très particulières, la compression sans perte n'est pas ce qu'il y a de plus intéressant. Il est beaucoup plus utile de savoir compresser avec discernement, en évitant les artefacts visuellement disgracieux (comme ceux que l'on observe avec du jpeg à fort taux de compression). Le jpeg2000 allait dans ce sens.
-- F.J.
markorki
oui mais tes images sont petites par rapport à ce dont je parle (et eux parlent)
Je ne prends pas un monstre pour un petit test ;-))
peux-tu nous donner le nombre de pixels et le nombre de bits par point ?
4498641 pixels et 24 bits (3x8).
ben oui, c'est déjà petit par rapport à ce que je (et sans doute tu)
manipule(s) depuis 3 ans : même nombre de bits, mais plus de pixels ;-) même un **excellent** algo non destructif fonctionne avec un "dictionnaire" , et avec bien plus de 3*8 bits, **toutes** les valeurs ont de fortes chances d'être différentes. S'il n'y a qu'un point concerné par valeur, et que chaque valeur a autant de bits qu'au départ, le dictionnaire est juste un supplément de volume. Je crois qu'on peut optimiser un algo pour minimiser les pertes à compression égale, pas comprimer sans perte dès que le nombre de bits est important (dans le cas général d'une image photographique, qui est un continuum de valeurs quasi **toutes** différentes si on code sur un nombre de bits important, le pb est différent avec des images en nombre limité de couleurs, où le principe de la palette est extrèmement efficace)
oui mais tes images sont petites par rapport à ce dont je parle (et
eux parlent)
Je ne prends pas un monstre pour un petit test ;-))
peux-tu nous donner le nombre de pixels et le nombre de bits par point
?
4498641 pixels et 24 bits (3x8).
ben oui, c'est déjà petit par rapport à ce que je (et sans doute tu)
manipule(s) depuis 3 ans : même nombre de bits, mais plus de pixels ;-)
même un **excellent** algo non destructif fonctionne avec un
"dictionnaire" , et avec bien plus de 3*8 bits, **toutes** les valeurs
ont de fortes chances d'être différentes. S'il n'y a qu'un point
concerné par valeur, et que chaque valeur a autant de bits qu'au départ,
le dictionnaire est juste un supplément de volume.
Je crois qu'on peut optimiser un algo pour minimiser les pertes à
compression égale, pas comprimer sans perte dès que le nombre de bits
est important (dans le cas général d'une image photographique, qui est
un continuum de valeurs quasi **toutes** différentes si on code sur un
nombre de bits important, le pb est différent avec des images en nombre
limité de couleurs, où le principe de la palette est extrèmement efficace)
oui mais tes images sont petites par rapport à ce dont je parle (et eux parlent)
Je ne prends pas un monstre pour un petit test ;-))
peux-tu nous donner le nombre de pixels et le nombre de bits par point ?
4498641 pixels et 24 bits (3x8).
ben oui, c'est déjà petit par rapport à ce que je (et sans doute tu)
manipule(s) depuis 3 ans : même nombre de bits, mais plus de pixels ;-) même un **excellent** algo non destructif fonctionne avec un "dictionnaire" , et avec bien plus de 3*8 bits, **toutes** les valeurs ont de fortes chances d'être différentes. S'il n'y a qu'un point concerné par valeur, et que chaque valeur a autant de bits qu'au départ, le dictionnaire est juste un supplément de volume. Je crois qu'on peut optimiser un algo pour minimiser les pertes à compression égale, pas comprimer sans perte dès que le nombre de bits est important (dans le cas général d'une image photographique, qui est un continuum de valeurs quasi **toutes** différentes si on code sur un nombre de bits important, le pb est différent avec des images en nombre limité de couleurs, où le principe de la palette est extrèmement efficace)
Jacques L'helgoualc'h
Le 08-02-2008, markorki a écrit :
[...] envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Aucune compression /garantie/, mais dans une photo on peut espérer avoir des aplats (ne serait-ce qu'en (sous|sur)exposant :) ; par ailleurs, un dégradé régulier peut aussi être compressé, bien que toutes les valeurs soient différentes.
Exemple sommaire : je génère un fichier des 26^2 paires de lettres, donc des mots de 16 bits tous différents :
[...] envisager de la compression sans perte (et quand-même des
fichiers de taille manipulable) sur des images en dizaines de mégapixels
et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans
perte possible si tous les points sont susceptibles d'avoir une valeur
différente de celle de tous les autres.
Aucune compression /garantie/, mais dans une photo on peut espérer avoir
des aplats (ne serait-ce qu'en (sous|sur)exposant :) ; par ailleurs, un
dégradé régulier peut aussi être compressé, bien que toutes les valeurs
soient différentes.
Exemple sommaire : je génère un fichier des 26^2 paires de lettres,
donc des mots de 16 bits tous différents :
[...] envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Aucune compression /garantie/, mais dans une photo on peut espérer avoir des aplats (ne serait-ce qu'en (sous|sur)exposant :) ; par ailleurs, un dégradé régulier peut aussi être compressé, bien que toutes les valeurs soient différentes.
Exemple sommaire : je génère un fichier des 26^2 paires de lettres, donc des mots de 16 bits tous différents :
[...] envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Aucune compression /garantie/, mais dans une photo on peut espérer avoir des aplats (ne serait-ce qu'en (sous|sur)exposant :) ; par ailleurs, un dégradé régulier peut aussi être compressé, bien que toutes les valeurs soient différentes.
Exemple sommaire : je génère un fichier des 26^2 paires de lettres, donc des mots de 16 bits tous différents :
oui, bien sûr, un encodage analogue au jpg (codage de différences
successives constantes et faibles, comme le jpg fonctionne par différences faibles entre voisins) ça marche... il n'y a que 25 exceptions aux croissances limitées et régulières as-tu essayé avec un petit "rand" sur chaque terme de la paire ?
mais bon, tu as raison, il n'y a pas que le dictionnaire comme méthode et certains algos sont plus rusés, et détectent par exemple des "motifs" mais là aussi c'est relativement facile, après tout il y a moins de 700 valeurs possibles
[...] envisager de la compression sans perte (et quand-même des
fichiers de taille manipulable) sur des images en dizaines de mégapixels
et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans
perte possible si tous les points sont susceptibles d'avoir une valeur
différente de celle de tous les autres.
Aucune compression /garantie/, mais dans une photo on peut espérer avoir
des aplats (ne serait-ce qu'en (sous|sur)exposant :) ; par ailleurs, un
dégradé régulier peut aussi être compressé, bien que toutes les valeurs
soient différentes.
Exemple sommaire : je génère un fichier des 26^2 paires de lettres,
donc des mots de 16 bits tous différents :
oui, bien sûr, un encodage analogue au jpg (codage de différences
successives constantes et faibles, comme le jpg fonctionne par
différences faibles entre voisins) ça marche... il n'y a que 25
exceptions aux croissances limitées et régulières
as-tu essayé avec un petit "rand" sur chaque terme de la paire ?
mais bon, tu as raison, il n'y a pas que le dictionnaire comme méthode
et certains algos sont plus rusés, et détectent par exemple des "motifs"
mais là aussi c'est relativement facile, après tout il y a moins de 700
valeurs possibles
[...] envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Aucune compression /garantie/, mais dans une photo on peut espérer avoir des aplats (ne serait-ce qu'en (sous|sur)exposant :) ; par ailleurs, un dégradé régulier peut aussi être compressé, bien que toutes les valeurs soient différentes.
Exemple sommaire : je génère un fichier des 26^2 paires de lettres, donc des mots de 16 bits tous différents :
oui, bien sûr, un encodage analogue au jpg (codage de différences
successives constantes et faibles, comme le jpg fonctionne par différences faibles entre voisins) ça marche... il n'y a que 25 exceptions aux croissances limitées et régulières as-tu essayé avec un petit "rand" sur chaque terme de la paire ?
mais bon, tu as raison, il n'y a pas que le dictionnaire comme méthode et certains algos sont plus rusés, et détectent par exemple des "motifs" mais là aussi c'est relativement facile, après tout il y a moins de 700 valeurs possibles
markorki
markorki wrote:
Hello,
Le nouveau format développé par Microsoft avance : http://www.clubic.com/actualite-93812-jpeg-microsoft-photo-jpeg-xr.html
Pour le tester sur Photoshop CS2 ou CS3 : http://tinyurl.com/2ptfmr
Le JPEG 2000 a échoué contre le JPEG de base, que fera le nouveau JPEG XR ?
Je ne sais pas, en tout cas il se raconte pas mal de c........es sur
ce forum,
En effet. Quand on commence comme ça, il faut ensuite assurer...
comme d'envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Bien entendu. Mais sauf à photographier du bruit blanc (c'est ton droit) c'est quand même rarement le cas. La plupart des photos réelles ont de fortes potentialités de compression sans perte.
Zipper, rar-er, 7z-er un fichier dont **toutes** les valeurs sont différentes à très peu de chances de donner un résultat plus petit, et pas mal de chances de donner plus gros. La compression sans perte et réellement efficace (taille résultat < taille départ) est jouable (gif et png + efficace) quand on peut ramener une image à une palette, grosso-modo quand le nombre de valeurs possibles et petit devant le nombre de points à encoder, et ça c'est une donnée **mathématique**.
C'est une vision très naïve du problème de compression. Il y a bien d'autres outils qui permettent de faire de la compression, mais ils sont un peu délicats à présenter ici. D'autre part, sauf applications très particulières, la compression sans perte n'est pas ce qu'il y a de plus intéressant. Il est beaucoup plus utile de savoir compresser avec discernement, en évitant les artefacts visuellement disgracieux (comme ceux que l'on observe avec du jpeg à fort taux de compression). Le jpeg2000 allait dans ce sens.
Bien sûr que ma remarque était simplificatrice, mais c'était en réaction
à des propos eux aussi simplificateurs: c'est eux qui parlent de "sans perte", ce qui, c'est vrai, n'est intéressant que pour comprimer des données où **tous_les_bits** comptent: en fait certaines données cryptées, données de sécurité telles que clés, et bien sûr exécutables. Pour une image ou su son, bien sûr que ça n'a pas de sens de comprimer sans perte, la numérisation étant **déjà** une perte d'information puisqu'on se fixe une nombre de bits de codage a-priori alors que le monde est continu jusqu'à une échelle très fine. Ce qui est intéressant est bien "sans perte perceptible dans l'usage et par l'utilisateur visé", pas "sans perte" tout court.
markorki wrote:
Hello,
Le nouveau format développé par Microsoft avance :
http://www.clubic.com/actualite-93812-jpeg-microsoft-photo-jpeg-xr.html
Pour le tester sur Photoshop CS2 ou CS3 :
http://tinyurl.com/2ptfmr
Le JPEG 2000 a échoué contre le JPEG de base, que fera le nouveau
JPEG XR ?
Je ne sais pas, en tout cas il se raconte pas mal de c........es sur
ce forum,
En effet. Quand on commence comme ça, il faut ensuite assurer...
comme d'envisager de la compression sans perte (et quand-même des
fichiers de taille manipulable) sur des images en dizaines de
mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune**
compression sans perte possible si tous les points sont susceptibles
d'avoir une valeur différente de celle de tous les autres.
Bien entendu. Mais sauf à photographier du bruit blanc (c'est ton droit)
c'est quand même rarement le cas.
La plupart des photos réelles ont de fortes potentialités de compression
sans perte.
Zipper, rar-er, 7z-er un fichier dont **toutes** les valeurs sont
différentes à très peu de chances de donner un résultat plus petit, et
pas mal de chances de donner plus gros. La compression sans perte et
réellement efficace (taille résultat < taille départ) est jouable (gif
et png + efficace) quand on peut ramener une image à une palette,
grosso-modo quand le nombre de valeurs possibles et petit devant le
nombre de points à encoder, et ça c'est une donnée **mathématique**.
C'est une vision très naïve du problème de compression. Il y a bien
d'autres outils qui permettent de faire de la compression, mais
ils sont un peu délicats à présenter ici.
D'autre part, sauf applications très particulières, la compression
sans perte n'est pas ce qu'il y a de plus intéressant. Il est beaucoup
plus utile de savoir compresser avec discernement, en évitant les
artefacts visuellement disgracieux (comme ceux que l'on observe
avec du jpeg à fort taux de compression).
Le jpeg2000 allait dans ce sens.
Bien sûr que ma remarque était simplificatrice, mais c'était en réaction
à des propos eux aussi simplificateurs: c'est eux qui parlent de "sans
perte", ce qui, c'est vrai, n'est intéressant que pour comprimer des
données où **tous_les_bits** comptent: en fait certaines données
cryptées, données de sécurité telles que clés, et bien sûr exécutables.
Pour une image ou su son, bien sûr que ça n'a pas de sens de comprimer
sans perte, la numérisation étant **déjà** une perte d'information
puisqu'on se fixe une nombre de bits de codage a-priori alors que le
monde est continu jusqu'à une échelle très fine.
Ce qui est intéressant est bien "sans perte perceptible dans l'usage et
par l'utilisateur visé", pas "sans perte" tout court.
Le nouveau format développé par Microsoft avance : http://www.clubic.com/actualite-93812-jpeg-microsoft-photo-jpeg-xr.html
Pour le tester sur Photoshop CS2 ou CS3 : http://tinyurl.com/2ptfmr
Le JPEG 2000 a échoué contre le JPEG de base, que fera le nouveau JPEG XR ?
Je ne sais pas, en tout cas il se raconte pas mal de c........es sur
ce forum,
En effet. Quand on commence comme ça, il faut ensuite assurer...
comme d'envisager de la compression sans perte (et quand-même des fichiers de taille manipulable) sur des images en dizaines de mégapixels et en 3*16bits , 3*24bits ou plus: il n'y a **aucune** compression sans perte possible si tous les points sont susceptibles d'avoir une valeur différente de celle de tous les autres.
Bien entendu. Mais sauf à photographier du bruit blanc (c'est ton droit) c'est quand même rarement le cas. La plupart des photos réelles ont de fortes potentialités de compression sans perte.
Zipper, rar-er, 7z-er un fichier dont **toutes** les valeurs sont différentes à très peu de chances de donner un résultat plus petit, et pas mal de chances de donner plus gros. La compression sans perte et réellement efficace (taille résultat < taille départ) est jouable (gif et png + efficace) quand on peut ramener une image à une palette, grosso-modo quand le nombre de valeurs possibles et petit devant le nombre de points à encoder, et ça c'est une donnée **mathématique**.
C'est une vision très naïve du problème de compression. Il y a bien d'autres outils qui permettent de faire de la compression, mais ils sont un peu délicats à présenter ici. D'autre part, sauf applications très particulières, la compression sans perte n'est pas ce qu'il y a de plus intéressant. Il est beaucoup plus utile de savoir compresser avec discernement, en évitant les artefacts visuellement disgracieux (comme ceux que l'on observe avec du jpeg à fort taux de compression). Le jpeg2000 allait dans ce sens.
Bien sûr que ma remarque était simplificatrice, mais c'était en réaction
à des propos eux aussi simplificateurs: c'est eux qui parlent de "sans perte", ce qui, c'est vrai, n'est intéressant que pour comprimer des données où **tous_les_bits** comptent: en fait certaines données cryptées, données de sécurité telles que clés, et bien sûr exécutables. Pour une image ou su son, bien sûr que ça n'a pas de sens de comprimer sans perte, la numérisation étant **déjà** une perte d'information puisqu'on se fixe une nombre de bits de codage a-priori alors que le monde est continu jusqu'à une échelle très fine. Ce qui est intéressant est bien "sans perte perceptible dans l'usage et par l'utilisateur visé", pas "sans perte" tout court.
Stephane Legras-Decussy
"markorki" <moicestmarkorkichezorangefr> a écrit dans le message de news: 47ac9fa8$0$858$ [snip]
sans vouloir briser l'euphorie technophile ambiante, ça sert à quoi de mettre un million de photo sur un cm2 ?
ça me fait l'effet d'une sorte de trou noir de technologie ou le (bon) sens se dissous dedans...
enfin bon...
"markorki" <moicestmarkorkichezorangefr> a écrit dans le message de news:
47ac9fa8$0$858$ba4acef3@news.orange.fr...
[snip]
sans vouloir briser l'euphorie technophile ambiante,
ça sert à quoi de mettre un million de photo
sur un cm2 ?
ça me fait l'effet d'une sorte de trou noir de technologie
ou le (bon) sens se dissous dedans...
