JPEG XR

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**.

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.

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 ?

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

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.

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)

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 :

~ $ echo -n {a..z}{a..z} | tr -d ' ' >fich
~ $ cat fich
aaabacad[...]zxzyzz

puis je compresse sans pertes :

~ $ gzip -9cv <fich >fich.gz
38.0%
~ $ l fich*
-rw-r--r-- 1 lhh lhh 1352 2008-02-08 19:29 fich
-rw-r--r-- 1 lhh lhh 856 2008-02-08 19:29 fich.gz

--
Jacques L'helgoualc'h

[...] 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 :

~ $ echo -n {a..z}{a..z} | tr -d ' ' >fich
~ $ cat fich
aaabacad[...]zxzyzz

puis je compresse sans pertes :

~ $ gzip -9cv <fich >fich.gz
38.0%
~ $ l fich*
-rw-r--r-- 1 lhh lhh 1352 2008-02-08 19:29 fich
-rw-r--r-- 1 lhh lhh 856 2008-02-08 19:29 fich.gz

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 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" <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...

enfin bon...