XNView, rotation sans pertes, IPTC et taille de fichier...
5 réponses
HyperDupont
bonjour,
J'ai une image en 3008*2000 en jpg fine (produite par mon *ist-DS), que
je comptais pivoter et dont je comptais éditer les infos IPTC sous
Xnview (1.74)
Toutes mes rotations sont faites avec la commande "rotation sans pertes"
qui ne modifie pas la date du fichier, et n'est pas censée modifier le
contenu du fichier (valeurs des points inchangée, pas de changement de
compression). Les tailles de fichier sont celles que donne l'explorateur
de Zindoz, par clic droit "Propriétés"
Je regarde la taille initiale du fichier :
1,69 MO (1 773 728 octets)
Je la rotate à droite sans pertes (le sujet est vertical et apparait
initialement le haut à gauche), sa taille passe à
1.62 Mo (1697031 octets)
Si je la pivote à gauche pour la ramener à sa position initiale:
1.62 Mo (1693978 octets)
Et désormais ces tailles ne changeront plus, sauf si j'ajoute des infos
IPTC dans la version "verticale" qui passe alors de 1.62 Mo (1697031
octets) à 1.62 Mo (1697109 octets), ce qui me parait justifié par le
texte ajouté.
Comment expliquer la différence entre la première et la troisième image
? du bourrage des champs IPTC ??
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
tallguy
"HyperDupont" a écrit dans le message de news: 43175599$0$1012$
bonjour, J'ai une image en 3008*2000 en jpg fine (produite par mon *ist-DS), que je comptais pivoter et dont je comptais éditer les infos IPTC sous Xnview (1.74)
istDS ? excccccellent choix ;-))
Toutes mes rotations sont faites avec la commande "rotation sans pertes" qui ne modifie pas la date du fichier, et n'est pas censée modifier le contenu du fichier (valeurs des points inchangée, pas de changement de compression). Les tailles de fichier sont celles que donne l'explorateur de Zindoz, par clic droit "Propriétés"
Je regarde la taille initiale du fichier : 1,69 MO (1 773 728 octets)
Je la rotate à droite sans pertes (le sujet est vertical et apparait initialement le haut à gauche), sa taille passe à 1.62 Mo (1697031 octets)
Si je la pivote à gauche pour la ramener à sa position initiale: 1.62 Mo (1693978 octets)
Et désormais ces tailles ne changeront plus, sauf si j'ajoute des infos IPTC dans la version "verticale" qui passe alors de 1.62 Mo (1697031 octets) à 1.62 Mo (1697109 octets), ce qui me parait justifié par le texte ajouté.
Comment expliquer la différence entre la première et la troisième image ? du bourrage des champs IPTC ??
Question interessante, je ne me souviens pas qu'elle ait été déjà posée recemment ici. Les spécialistes du sujet vont se manifester très très vite :-) Pour ma part je peux avancer que les algorythmes de compression jpg ne partent pas d'une vue d'ensemble de l'image mais de proche en proche par paquets de 8 donc une même image verticale ou horizontale n'aura pas le même poids c'est encore plus vrai en gif qui utilise une méthode différente (ligne par ligne si mes souvenirs sont bons) Mais cela n'explique pas que lorsqu'on revient en arrière le poids soit encore différent... Ca y est, à cause de toi, comme le capitaine haddock je ne vais pas réussir à m'endormir... au secours ! méchant !
-- tallguy photo : http://jcmoulins.chez.tiscali.fr/panoramas/index.htm jazz : http://jcmoulins.chez.tiscali.fr
"HyperDupont" <HyperDupont@yahoo.fr> a écrit dans le message de news:
43175599$0$1012$8fcfb975@news.wanadoo.fr...
bonjour,
J'ai une image en 3008*2000 en jpg fine (produite par mon *ist-DS), que je
comptais pivoter et dont je comptais éditer les infos IPTC sous Xnview
(1.74)
istDS ? excccccellent choix ;-))
Toutes mes rotations sont faites avec la commande "rotation sans pertes"
qui ne modifie pas la date du fichier, et n'est pas censée modifier le
contenu du fichier (valeurs des points inchangée, pas de changement de
compression). Les tailles de fichier sont celles que donne l'explorateur
de Zindoz, par clic droit "Propriétés"
Je regarde la taille initiale du fichier :
1,69 MO (1 773 728 octets)
Je la rotate à droite sans pertes (le sujet est vertical et apparait
initialement le haut à gauche), sa taille passe à
1.62 Mo (1697031 octets)
Si je la pivote à gauche pour la ramener à sa position initiale:
1.62 Mo (1693978 octets)
Et désormais ces tailles ne changeront plus, sauf si j'ajoute des infos
IPTC dans la version "verticale" qui passe alors de 1.62 Mo (1697031
octets) à 1.62 Mo (1697109 octets), ce qui me parait justifié par le texte
ajouté.
Comment expliquer la différence entre la première et la troisième image ?
du bourrage des champs IPTC ??
Question interessante, je ne me souviens pas qu'elle
ait été déjà posée recemment ici.
Les spécialistes du sujet vont se manifester très très
vite :-) Pour ma part je peux avancer que les algorythmes
de compression jpg ne partent pas d'une vue d'ensemble
de l'image mais de proche en proche par paquets de 8
donc une même image verticale ou horizontale n'aura pas
le même poids c'est encore plus vrai en gif qui utilise une
méthode différente (ligne par ligne si mes souvenirs sont bons)
Mais cela n'explique pas que lorsqu'on revient en arrière le poids
soit encore différent...
Ca y est, à cause de toi, comme le capitaine haddock je
ne vais pas réussir à m'endormir... au secours ! méchant !
--
tallguy
photo : http://jcmoulins.chez.tiscali.fr/panoramas/index.htm
jazz : http://jcmoulins.chez.tiscali.fr
"HyperDupont" a écrit dans le message de news: 43175599$0$1012$
bonjour, J'ai une image en 3008*2000 en jpg fine (produite par mon *ist-DS), que je comptais pivoter et dont je comptais éditer les infos IPTC sous Xnview (1.74)
istDS ? excccccellent choix ;-))
Toutes mes rotations sont faites avec la commande "rotation sans pertes" qui ne modifie pas la date du fichier, et n'est pas censée modifier le contenu du fichier (valeurs des points inchangée, pas de changement de compression). Les tailles de fichier sont celles que donne l'explorateur de Zindoz, par clic droit "Propriétés"
Je regarde la taille initiale du fichier : 1,69 MO (1 773 728 octets)
Je la rotate à droite sans pertes (le sujet est vertical et apparait initialement le haut à gauche), sa taille passe à 1.62 Mo (1697031 octets)
Si je la pivote à gauche pour la ramener à sa position initiale: 1.62 Mo (1693978 octets)
Et désormais ces tailles ne changeront plus, sauf si j'ajoute des infos IPTC dans la version "verticale" qui passe alors de 1.62 Mo (1697031 octets) à 1.62 Mo (1697109 octets), ce qui me parait justifié par le texte ajouté.
Comment expliquer la différence entre la première et la troisième image ? du bourrage des champs IPTC ??
Question interessante, je ne me souviens pas qu'elle ait été déjà posée recemment ici. Les spécialistes du sujet vont se manifester très très vite :-) Pour ma part je peux avancer que les algorythmes de compression jpg ne partent pas d'une vue d'ensemble de l'image mais de proche en proche par paquets de 8 donc une même image verticale ou horizontale n'aura pas le même poids c'est encore plus vrai en gif qui utilise une méthode différente (ligne par ligne si mes souvenirs sont bons) Mais cela n'explique pas que lorsqu'on revient en arrière le poids soit encore différent... Ca y est, à cause de toi, comme le capitaine haddock je ne vais pas réussir à m'endormir... au secours ! méchant !
-- tallguy photo : http://jcmoulins.chez.tiscali.fr/panoramas/index.htm jazz : http://jcmoulins.chez.tiscali.fr
Alf92
tallguy a dit ça :
(...) Comment expliquer la différence entre la première et la troisième image ? du bourrage des champs IPTC ??
Question interessante, je ne me souviens pas qu'elle ait été déjà posée recemment ici
en effet, sujet connu. chaque soft réalisant des rotations sans pertes ajoutes ses petits commentatires qui lui sont propres. j'ai eu le même cas de figure avec des containers video : bourrage d'info inutile...
Ca y est, à cause de toi, comme le capitaine haddock je ne vais pas réussir à m'endormir... au secours ! méchant !
le barbier ne rase que ceux qui ne se rasent pas eux même. question : le barbier se rase-t-il ?
-- Cordialement, Alf92 http://frpn.free.fr
tallguy a dit ça :
(...) Comment expliquer la différence entre la première et la troisième
image ? du bourrage des champs IPTC ??
Question interessante, je ne me souviens pas qu'elle
ait été déjà posée recemment ici
en effet, sujet connu.
chaque soft réalisant des rotations sans pertes ajoutes ses petits
commentatires qui lui sont propres.
j'ai eu le même cas de figure avec des containers video : bourrage d'info
inutile...
Ca y est, à cause de toi, comme le capitaine haddock je
ne vais pas réussir à m'endormir... au secours ! méchant !
le barbier ne rase que ceux qui ne se rasent pas eux même.
question : le barbier se rase-t-il ?
(...) Comment expliquer la différence entre la première et la troisième image ? du bourrage des champs IPTC ??
Question interessante, je ne me souviens pas qu'elle ait été déjà posée recemment ici
en effet, sujet connu. chaque soft réalisant des rotations sans pertes ajoutes ses petits commentatires qui lui sont propres. j'ai eu le même cas de figure avec des containers video : bourrage d'info inutile...
Ca y est, à cause de toi, comme le capitaine haddock je ne vais pas réussir à m'endormir... au secours ! méchant !
le barbier ne rase que ceux qui ne se rasent pas eux même. question : le barbier se rase-t-il ?
-- Cordialement, Alf92 http://frpn.free.fr
M.H
Comment expliquer la différence entre la première et la troisième image ? du bourrage des champs IPTC ??
Pas seulement du champ IPTC mais des "commentaires" ajoutés à l'image pour inscrire par exemple dans le fichier les modifs effectuées et éventuellement les modifs subséquentes du codage.
Le "codage" des infos d'une image, même non compressée, est très variable. C'est en général illisible sauf par exemple en "encapsulated postcript" où on voit avec un éditeur simple (notepad ou ultraedit) le fichier image écrit en ASCII. Avec Photoshop, prenez une petite image en N&B (en .tif par exemple (illisible avec notepad) et enregistrez la en .eps avec ou sans vignette de prévisualisation, en mode noir & blanc 8 bits ou 16 bits (ou RVB) et on peut voir les modifs du fichier image où les niveaux de gris de 0 à 255 (8 bits) sont codés en exa sur deux caractères (0=>00 255=>FF) en allant du haut à gauche vers le bas à droite. Vous pouvez changer ces niveaux "à la main" pour faire des taches noires (00) ou blanches (FF)...
Si on fait la même chose avec Paint Shop Pro le fichier est différent et si on relit l'image avec un autre logiciel, ACDsee par exemple, le résultat ne sera pas le même et il faudra éventuellement fournir des infos complémentaires.
Le décrytage des images est souvent un casse tête car le codage n'est pas toujours documenté (cas des .nef Nikon au début) ou non conforme aux normes (si elles existent). A+ -- M.H. Mettre un bémol à l'adresse antispam.
Comment expliquer la différence entre la première et la troisième image
? du bourrage des champs IPTC ??
Pas seulement du champ IPTC mais des "commentaires" ajoutés à l'image
pour inscrire par exemple dans le fichier les modifs effectuées et
éventuellement les modifs subséquentes du codage.
Le "codage" des infos d'une image, même non compressée, est très variable.
C'est en général illisible sauf par exemple en "encapsulated postcript"
où on voit avec un éditeur simple (notepad ou ultraedit) le fichier
image écrit en ASCII.
Avec Photoshop, prenez une petite image en N&B (en .tif par exemple
(illisible avec notepad) et enregistrez la en .eps avec ou sans vignette
de prévisualisation, en mode noir & blanc 8 bits ou 16 bits (ou RVB) et
on peut voir les modifs du fichier image où les niveaux de gris de 0 à
255 (8 bits) sont codés en exa sur deux caractères (0=>00 255=>FF) en
allant du haut à gauche vers le bas à droite.
Vous pouvez changer ces niveaux "à la main" pour faire des taches noires
(00) ou blanches (FF)...
Si on fait la même chose avec Paint Shop Pro le fichier est différent et
si on relit l'image avec un autre logiciel, ACDsee par exemple, le
résultat ne sera pas le même et il faudra éventuellement fournir des
infos complémentaires.
Le décrytage des images est souvent un casse tête car le codage n'est
pas toujours documenté (cas des .nef Nikon au début) ou non conforme aux
normes (si elles existent).
A+
--
M.H. Mettre un bémol à l'adresse antispam.
Comment expliquer la différence entre la première et la troisième image ? du bourrage des champs IPTC ??
Pas seulement du champ IPTC mais des "commentaires" ajoutés à l'image pour inscrire par exemple dans le fichier les modifs effectuées et éventuellement les modifs subséquentes du codage.
Le "codage" des infos d'une image, même non compressée, est très variable. C'est en général illisible sauf par exemple en "encapsulated postcript" où on voit avec un éditeur simple (notepad ou ultraedit) le fichier image écrit en ASCII. Avec Photoshop, prenez une petite image en N&B (en .tif par exemple (illisible avec notepad) et enregistrez la en .eps avec ou sans vignette de prévisualisation, en mode noir & blanc 8 bits ou 16 bits (ou RVB) et on peut voir les modifs du fichier image où les niveaux de gris de 0 à 255 (8 bits) sont codés en exa sur deux caractères (0=>00 255=>FF) en allant du haut à gauche vers le bas à droite. Vous pouvez changer ces niveaux "à la main" pour faire des taches noires (00) ou blanches (FF)...
Si on fait la même chose avec Paint Shop Pro le fichier est différent et si on relit l'image avec un autre logiciel, ACDsee par exemple, le résultat ne sera pas le même et il faudra éventuellement fournir des infos complémentaires.
Le décrytage des images est souvent un casse tête car le codage n'est pas toujours documenté (cas des .nef Nikon au début) ou non conforme aux normes (si elles existent). A+ -- M.H. Mettre un bémol à l'adresse antispam.
HyperDupont
"HyperDupont" a écrit dans le message de news: .../...
Je regarde la taille initiale du fichier : 1,69 MO (1 773 728 octets) Je la rotate à droite sans pertes (le sujet est vertical et apparait initialement le haut à gauche), sa taille passe à 1.62 Mo (1697031 octets) Si je la pivote à gauche pour la ramener à sa position initiale: 1.62 Mo (1693978 octets)
Et désormais ces tailles ne changeront plus, sauf si j'ajoute des infos IPTC dans la version "verticale" qui passe alors de 1.62 Mo (1697031 octets) à 1.62 Mo (1697109 octets), ce qui me parait justifié par le texte ajouté.
Comment expliquer la différence entre la première et la troisième image ? du bourrage des champs IPTC ??
Question interessante, je ne me souviens pas qu'elle ait été déjà posée recemment ici. Les spécialistes du sujet vont se manifester très très vite :-) Pour ma part je peux avancer que les algorythmes de compression jpg ne partent pas d'une vue d'ensemble de l'image mais de proche en proche par paquets de 8 donc une même image verticale ou horizontale n'aura pas le même poids
oui mis XnView explique que les données purement image du jpg ne sont pas changées si l'image a des dimensions multiples de 8...
en fait, c'est la perte de près de 100KO entre la première image apparaissant horizontale et la seconde, juste pivotée juste peut-être par changement du codage de la rotation d'affichage par rapport à l'affichage "naturel", qui me préoccupe... Ensuite, chaque rotation droite, gauche, droite (C nous les carabiniers) fait osciller entre toujours les mêmes valeurs à moins que l'image soit initialement bourrée de blancs à la longueur maxi de chaque champ IPTC, mais je me demande pourquoi... Pour pouvoir les modifier à coup sûr dans la carte SD elle-même (nouveau fichier toujours <= fichier initial ??) Zut me voilà parssé du "quoi?" au "pourquoi?"
c'est encore plus vrai en gif qui utilise une méthode différente (ligne par ligne si mes souvenirs sont bons) Mais cela n'explique pas que lorsqu'on revient en arrière le poids soit encore différent... Ca y est, à cause de toi, comme le capitaine haddock je ne vais pas réussir à m'endormir... au secours ! méchant !
ben bonne nuit qd-même...
"HyperDupont" <HyperDupont@yahoo.fr> a écrit dans le message de news:
.../...
Je regarde la taille initiale du fichier :
1,69 MO (1 773 728 octets)
Je la rotate à droite sans pertes (le sujet est vertical et apparait
initialement le haut à gauche), sa taille passe à
1.62 Mo (1697031 octets)
Si je la pivote à gauche pour la ramener à sa position initiale:
1.62 Mo (1693978 octets)
Et désormais ces tailles ne changeront plus, sauf si j'ajoute des infos
IPTC dans la version "verticale" qui passe alors de 1.62 Mo (1697031
octets) à 1.62 Mo (1697109 octets), ce qui me parait justifié par le texte
ajouté.
Comment expliquer la différence entre la première et la troisième image ?
du bourrage des champs IPTC ??
Question interessante, je ne me souviens pas qu'elle
ait été déjà posée recemment ici.
Les spécialistes du sujet vont se manifester très très
vite :-) Pour ma part je peux avancer que les algorythmes
de compression jpg ne partent pas d'une vue d'ensemble
de l'image mais de proche en proche par paquets de 8
donc une même image verticale ou horizontale n'aura pas
le même poids
oui mis XnView explique que les données purement image du jpg ne sont
pas changées si l'image a des dimensions multiples de 8...
en fait, c'est la perte de près de 100KO entre la première image
apparaissant horizontale et la seconde, juste pivotée juste peut-être
par changement du codage de la rotation d'affichage par rapport à
l'affichage "naturel", qui me préoccupe...
Ensuite, chaque rotation droite, gauche, droite (C nous les carabiniers)
fait osciller entre toujours les mêmes valeurs
à moins que l'image soit initialement bourrée de blancs à la longueur
maxi de chaque champ IPTC, mais je me demande pourquoi...
Pour pouvoir les modifier à coup sûr dans la carte SD elle-même (nouveau
fichier toujours <= fichier initial ??)
Zut me voilà parssé du "quoi?" au "pourquoi?"
c'est encore plus vrai en gif qui utilise une
méthode différente (ligne par ligne si mes souvenirs sont bons)
Mais cela n'explique pas que lorsqu'on revient en arrière le poids
soit encore différent...
Ca y est, à cause de toi, comme le capitaine haddock je
ne vais pas réussir à m'endormir... au secours ! méchant !
"HyperDupont" a écrit dans le message de news: .../...
Je regarde la taille initiale du fichier : 1,69 MO (1 773 728 octets) Je la rotate à droite sans pertes (le sujet est vertical et apparait initialement le haut à gauche), sa taille passe à 1.62 Mo (1697031 octets) Si je la pivote à gauche pour la ramener à sa position initiale: 1.62 Mo (1693978 octets)
Et désormais ces tailles ne changeront plus, sauf si j'ajoute des infos IPTC dans la version "verticale" qui passe alors de 1.62 Mo (1697031 octets) à 1.62 Mo (1697109 octets), ce qui me parait justifié par le texte ajouté.
Comment expliquer la différence entre la première et la troisième image ? du bourrage des champs IPTC ??
Question interessante, je ne me souviens pas qu'elle ait été déjà posée recemment ici. Les spécialistes du sujet vont se manifester très très vite :-) Pour ma part je peux avancer que les algorythmes de compression jpg ne partent pas d'une vue d'ensemble de l'image mais de proche en proche par paquets de 8 donc une même image verticale ou horizontale n'aura pas le même poids
oui mis XnView explique que les données purement image du jpg ne sont pas changées si l'image a des dimensions multiples de 8...
en fait, c'est la perte de près de 100KO entre la première image apparaissant horizontale et la seconde, juste pivotée juste peut-être par changement du codage de la rotation d'affichage par rapport à l'affichage "naturel", qui me préoccupe... Ensuite, chaque rotation droite, gauche, droite (C nous les carabiniers) fait osciller entre toujours les mêmes valeurs à moins que l'image soit initialement bourrée de blancs à la longueur maxi de chaque champ IPTC, mais je me demande pourquoi... Pour pouvoir les modifier à coup sûr dans la carte SD elle-même (nouveau fichier toujours <= fichier initial ??) Zut me voilà parssé du "quoi?" au "pourquoi?"
c'est encore plus vrai en gif qui utilise une méthode différente (ligne par ligne si mes souvenirs sont bons) Mais cela n'explique pas que lorsqu'on revient en arrière le poids soit encore différent... Ca y est, à cause de toi, comme le capitaine haddock je ne vais pas réussir à m'endormir... au secours ! méchant !
ben bonne nuit qd-même...
Didier Dalbera
bonjour, J'ai une image en 3008*2000 en jpg fine (produite par mon *ist-DS), que je comptais pivoter et dont je comptais éditer les infos IPTC sous Xnview (1.74)
Toutes mes rotations sont faites avec la commande "rotation sans pertes" [...] Je regarde la taille initiale du fichier : 1,69 MO (1 773 728 octets) Je la rotate à droite sans pertes (le sujet est vertical et apparait initialement le haut à gauche), sa taille passe à 1.62 Mo (1 697 031 octets) Si je la pivote à gauche pour la ramener à sa position initiale: 1.62 Mo (1 693 978 octets) Et désormais ces tailles ne changeront plus, [...] Comment expliquer la différence entre la première et la troisième image ? du bourrage des champs IPTC ??
Bonne question.....
Comme il a été dit, la compression JPEG traite des ensembles de 8x8 pixels. Si mes souvenirs de la structure du chier sont bonnes, la rotation sans perte change juste une donnée en entête du fichier qui dit dans quel sens il faut lire chaque groupe. C'est donc un ré-agencement, pas une recompression, les blocs 8x8 n'ont pas changé.
Quant à la perte de 80ko lors de la première manip, je pencherais plutôt pour la suppression de données, comme la miniature EXIF incorporée (ce qui serait le plus probable vu le poids) que XnView ne conserve pas. Pour les 3ko lors de l'autre manip, je ne vois pas...
-- "Trop de rotations tuent la rotation" Didier
bonjour,
J'ai une image en 3008*2000 en jpg fine (produite par mon *ist-DS), que je
comptais pivoter et dont je comptais éditer les infos IPTC sous Xnview (1.74)
Toutes mes rotations sont faites avec la commande "rotation sans pertes" [...]
Je regarde la taille initiale du fichier :
1,69 MO (1 773 728 octets)
Je la rotate à droite sans pertes (le sujet est vertical et apparait
initialement le haut à gauche), sa taille passe à
1.62 Mo (1 697 031 octets)
Si je la pivote à gauche pour la ramener à sa position initiale:
1.62 Mo (1 693 978 octets)
Et désormais ces tailles ne changeront plus, [...] Comment expliquer la
différence entre la première et la troisième image ? du bourrage des champs
IPTC ??
Bonne question.....
Comme il a été dit, la compression JPEG traite des ensembles de 8x8 pixels.
Si mes souvenirs de la structure du chier sont bonnes, la rotation sans perte
change juste une donnée en entête du fichier qui dit dans quel sens il faut lire
chaque groupe. C'est donc un ré-agencement, pas une recompression, les blocs 8x8
n'ont pas changé.
Quant à la perte de 80ko lors de la première manip, je pencherais plutôt pour la
suppression de données, comme la miniature EXIF incorporée (ce qui serait le
plus probable vu le poids) que XnView ne conserve pas.
Pour les 3ko lors de l'autre manip, je ne vois pas...
bonjour, J'ai une image en 3008*2000 en jpg fine (produite par mon *ist-DS), que je comptais pivoter et dont je comptais éditer les infos IPTC sous Xnview (1.74)
Toutes mes rotations sont faites avec la commande "rotation sans pertes" [...] Je regarde la taille initiale du fichier : 1,69 MO (1 773 728 octets) Je la rotate à droite sans pertes (le sujet est vertical et apparait initialement le haut à gauche), sa taille passe à 1.62 Mo (1 697 031 octets) Si je la pivote à gauche pour la ramener à sa position initiale: 1.62 Mo (1 693 978 octets) Et désormais ces tailles ne changeront plus, [...] Comment expliquer la différence entre la première et la troisième image ? du bourrage des champs IPTC ??
Bonne question.....
Comme il a été dit, la compression JPEG traite des ensembles de 8x8 pixels. Si mes souvenirs de la structure du chier sont bonnes, la rotation sans perte change juste une donnée en entête du fichier qui dit dans quel sens il faut lire chaque groupe. C'est donc un ré-agencement, pas une recompression, les blocs 8x8 n'ont pas changé.
Quant à la perte de 80ko lors de la première manip, je pencherais plutôt pour la suppression de données, comme la miniature EXIF incorporée (ce qui serait le plus probable vu le poids) que XnView ne conserve pas. Pour les 3ko lors de l'autre manip, je ne vois pas...
