Quelle visionneuse? - celle de Windows "abime" les photos?

[vroum]

Un fichier informatique n'a rien à voir avec un document papier.

Ca je le savais , mais comment expliquez-vous que si je met le paramètre "rotation auto par tag rotation exif" il m'affiche une image de 8804ko en vertical sans perte, alors que si je décoche cette fonction et le fait en cliquant manuellement sur une fonction de rotation dite sans perte elle fait alors 2203ko de moins?
Si de manière automatique en lisant un tag il y arrive, pourquoi ne le peut-il pas en mode manuel? C'est l'explication que je cherche et que je ne trouve pas .

[Equinoxe]

Pour JJ, on n'utilise pas l'algorithme qui va bien.
On utilise un seul algorithme qui joue sur des valeurs d'identification de teintes ( entre autres..) que l'on va assimiler.
Tout comme si j'avais 10 personnes de tailles différentes.
Sans compression, je "vois" et je sépare au décodage chacune des 10 personnes.
Je peux aussi dire que je fais trois sous populations ; celle des individus de taille comprise entre 1,60 et 1,70 m; ceux de 1,71 m à 1,80 m et ceux compris entre 1,81 et 1,90 m.
J'ai compressé ma population de 10 individus en trois éléments... C'est ça le jpeg et si pour cent personnes j'écris 25A 45B 30C et que A , B et C sont mes trois tailles, j'ai bien une représentation de cent personnes plus rapide que si j'aligne la centaine de tailles.
Mais cette "image" de la population elle est moins précise que si je décide de faire 5 tranches de taille.
Même raisonnement pour les teintes de sous population d'un fichier de pixels...
Bon ... ensuite, les explications de wilkipédia sont... exactes.
Donc bon amusement. C'est une bonne récréation mathématique !

[Equinoxe]

A Vroum.
Bug a donné la réponse
Avec Faststone, en rotation par tag, on change juste la valeur d'un octet pour indiquer dans quel sens lire le fichier donc pas de changement de taille
En rotation 'manuelle' qualité 100%, on réécrit le fichier ligne à ligne sans changer les valeurs des "données pixels" mais par la même occasion les "containers exif et iptc" sont réduits s'ils ne contiennent pas de données. C'est la seule explication puisque la taille est réduite mais que les pixels gardent exactement les mêmes nuances.

[vroum]

A Vroum.
Bug a donné la réponse
Avec Faststone, en rotation par tag, on change juste la valeur d'un octet pour indiquer dans quel sens lire le fichier donc pas de changement de taille
En rotation 'manuelle' qualité 100%, on réécrit le fichier ligne à ligne sans changer les valeurs des "données pixels" mais par la même occasion les "containers exif et iptc" sont réduits s'ils ne contiennent pas de données. C'est la seule explication puisque la taille est réduite mais que les pixels gardent exactement les mêmes nuances.

Oui mais alors pourquoi cet octet ne peut pas ètre changé manuellement plutot que de réécrire le fichier complet?
Comme faststone ne peut pas le faire alors quel logiciel le permet manuellement?

[Bug Killer]

Plusieurs eclaircissement :

Il n'y a pas de methode standard pour compresser un jpeg, chaque programmeur peut inventer la sienne. Pour utiliser l'analogie d'Equinoxe, un logiciel peut choisir de compresser l'info de taille, un autre peut se baser sur la couleur des yeux. L'algorithme de decompression est unique en revanche.

De tous ceux que j'ai essayes, le moins destructif est Paint Shop Pro en cochant l'option "Pas de sous-echantillonnage de la chroma".

Pour eliminer les differences dues a la reecriture des metadonnees et ne considerer que les donnees image, il faut supprimer les premieres sans toucher aux secondes. Des logiciels le font, ExifTool le fait, Exifer aussi. Sous Linux il y a jpegoptim.

[JJ]

Pour JJ, on n'utilise pas l'algorithme qui va bien.
On utilise un seul algorithme qui joue sur des valeurs d'identification de teintes ( entre autres..) que l'on va assimiler.

Ce qui est raconte chez wikipedia, c'est ceci : JPEG normalise uniquement l’algorithme et le format de décodage. Le processus d'encodage est laissé libre à la compétition des industriels et universitaires, du moment que l’image produite est décodable par un décodeur standard.
Et il ajoute :
JPEG définit deux classes de processus de compression :
avec pertes ou compression irréversible. C’est le JPEG « classique ». Il permet des taux de compression de 3 à 100.
sans pertes ou compression réversible. Il n’y a pas de pertes d’information et il est donc possible de revenir aux valeurs originales de l’image. Les gains en termes de compression sont alors plus modestes, avec un taux de compression de l’ordre de 2. Cette partie fait l’objet d’une norme spécifique JPEG-LS.

En raccourci, on part d'une image brute pour en faire une image compressee (par codage). Puis de cette image compressee on va en faire un decodage pour en lire une image restituee (a l'ecran). Cette image restituée n'est en aucun cas l'image brute. Entre l'image brute et l'image restituée, il y a des écarts, qui seront d'autant plus importants que l'opération de quantification a été forte. Donc pertes d'infos. Quand tu tournes une image jpeg de 90 degres, tu obtiens (informatiquement parlant) une autre image qui sera codees differement. En gros, dans la rotation tu as change tes lignes de pixels. Quand tu l'enregistres, tu codes une image differente, donc ton fichier n'est plus le meme. Je me suis amuse a partir d'une photo jpeg a faire une premiere rotation de 90 degres ( resultat une taille plus petite) puis a faire la rotation inverse.Resultat, une taille plus grande mais pas la meme que la taille originale. Mais visuellement la photo n'avait pas change.

Sans compression, je "vois" et je sépare au décodage chacune des 10 personnes.
Je peux aussi dire que je fais trois sous populations ; celle des individus de taille comprise entre 1,60 et 1,70 m; ceux de 1,71 m à 1,80 m et ceux compris entre 1,81 et 1,90 m.
J'ai compressé ma population de 10 individus en trois éléments... C'est ça le jpeg et si pour cent personnes j'écris 25A 45B 30C et que A , B et C sont mes trois tailles, j'ai bien une représentation de cent personnes plus rapide que si j'aligne la centaine de tailles.
Mais cette "image" de la population elle est moins précise que si je décide de faire 5 tranches de taille.
Même raisonnement pour les teintes de sous population d'un fichier de pixels...
Bon ... ensuite, les explications de wilkipédia sont... exactes.
Donc bon amusement. C'est une bonne récréation mathématique !

Ouich, mais si tu couches tes personnes, tu auras une classification differente selon l'epaisseur des cuisses, la rondeur des ventres, et la longueur des nez !!!!

[Equinoxe]

En raccourci, on part d'une image brute pour en faire une image compressee (par codage). Puis de cette image compressee on va en faire un decodage pour en lire une image restituee (a l'ecran). Cette image restituée n'est en aucun cas l'image brute. Entre l'image brute et l'image restituée, il y a des écarts, qui seront d'autant plus importants que l'opération de quantification a été forte.
Evidemment... . Dans tout ce qui précède, on suppose qu'on reste à lissage zéro et à compression zéro !
Donc pertes d'infos. Quand tu tournes une image jpeg de 90 degres, tu obtiens (informatiquement parlant) une autre image qui sera codees differement. En gros, dans la rotation tu as change tes lignes de pixels. Quand tu l'enregistres, tu codes une image differente, donc ton fichier n'est plus le meme. Je me suis amuse a partir d'une photo jpeg a faire une premiere rotation de 90 degres ( resultat une taille plus petite) puis a faire la rotation inverse.Resultat, une taille plus grande mais pas la meme que la taille originale. Mais visuellement la photo n'avait pas change.
C'est bien que qui était recherché pour une bonne visionneuse au départ, non? Et c'est ce que j'ai dit il y a deux jours

Plusieurs eclaircissement :

Il n'y a pas de methode standard pour compresser un jpeg, chaque programmeur peut inventer la sienne. Pour utiliser l'analogie d'Equinoxe, un logiciel peut choisir de compresser l'info de taille, un autre peut se baser sur la couleur des yeux. L'algorithme de decompression est unique en revanche.

De tous ceux que j'ai essayes, le moins destructif est Paint Shop Pro en cochant l'option "Pas de sous-echantillonnage de la chroma".

Pour eliminer les differences dues a la reecriture des metadonnees et ne considerer que les donnees image, il faut supprimer les premieres sans toucher aux secondes. Des logiciels le font, ExifTool le fait, Exifer aussi. Sous Linux il y a jpegoptim.

On est presque entièrement d'accord ; à ceci près que derrière méthode je mets les diverses phases de constitution du fichier : constitution de blocs ... matriçage et transformée de Fourier etc : tout ce qui précède l'écriture du résultat.
Possible qu'il y ait eu plusieurs variantes de calcul ( je ne considère pas les taux de compression ou confusion de teintes comme des variantes.) pour chaque étape et c'est peut être bien pour cela que les divers logiciels réussissent plus ou moins bien ce qu'on a pris l'habitude de trop simplifier sous le terme codage...
Je citais précédemment Corel car cela fait bien longtemps que j'ai constaté qu'il ne dégrade pas les images (expérimentations faites après 10 enregistrements, relecture avec ajout d'une ligne d'1pixel de large à chaque nouvel enregistrement et examen des pixels adjacents à cette ligne sur une zone en dégradé et deux à-plats).
Paint Shop Pro est devenu Corel PSP par la suite et je ne suis pas surpris qu'il soit parmi les meilleurs pour la préservation de la qualité originelle de l'image.
Et c'est bien vrai que les logiciels permettant de traiter les exifs ne touchent absolument pas aux infos des pixels... heureusement !
Donc en principe, avant de se livrer à des comparaisons de taille, il faudrait effectivement se débarrasser des données exif iptc et compagnie...car c'est vrai que voir la taille du fichier changer peut inquiéter. Mais dans la pratique, il n'y a que l'examen des photos qui est important.

Si on revient au sujet, ce serait intéressant de faire avec faststone des rotations de cette fois quelques degrés, enregistrer le fichier puis reprendre ce fichier, faire la contre-rotation équivalente et comparer avec l'original.
Si j'ai le temps, je vais traiter quelques fichiers.

[JJ]

Il serait peut-etre interessant de savoir quel logiciel fait du JPEG-LS, considerant que tous font du JPEG « classique ». On saurait ainsi qui fait du codage destructif et qui peut ne pas en faire.
Un fichier jpeg contient d'autres infos que le seul code de l'image. Mais on peut supposer que c'est peanuts dans le poids du fichier. Pour comparer, il faudrait pouvoir lire les fichiers en hexadecimal. Mais 5Mo, tres peu pour moi !!!
Bonne soiree a tous ...

[vroum]

Bon on en est ou niveau tournage de photo pour tout système de visionnage et sans perte ?

[JJ]

Bon on en est ou niveau tournage de photo pour tout système de visionnage et sans perte ?

Completement perdus dans la compression ...

[Equinoxe]

Bon, je terminerai un peu plus tard un long travail de comparaison...
Long parce que s'il y a des différences, elles ne sautent pas aux yeux après trois ou six enregistrements successifs...et ce n'est pas du tout facile d'aller repérer les pixels qui ont subi des modifications. Même sur "seulement" le 6 Mpixels de D7D !

Quelques éléments, pour rester dans le fil de cette discussion.
J'ai aussi examiné des jpeg en héxadécimal.
Dans le "container" jpeg, il n'y a pas que les exifs et iptc qui peuvent faire varier la taille mais aussi l'enregistrement des tables de Huffman.

De toutes façons il est certain qu'il n'y pas de miracle, sinon le lossless n'aurait pas vu le jour.
Le but du jeu est de savoir jusqu'à combien d'enregistrement on peut aller sans altération visible.
Si je me souviens bien, un logiciel utilisé les astro physiciens permet la comparaison pixel à pixel de fichiers bruts de capteurs d'astronomie. C'est peut être bien le logiciel Iris mais je n'ai pas trop envie de le réinstaller car son paramétrage est plutôt "chinois" pour du jpeg photographique.

Honnêtement, depuis qu'est apparu le terme jpeg lossless, je n'ai pas trouvé d'application qui l'utilise, excepté quelques essais de développement sous linux.
Et les éditeurs semblent bien discrets à ce sujet!

Bon, avant de continuer mes investigations, puisque je parlais des tables d' Huffman, voici des copies d'écran qui montrent qu'elles influencent notablement la taille du fichier.

[Bug Killer]

Pour comparer des jpeg il suffit de faire un masque différence de l'un sur l'autre. Pour amplifier les différences, appliquer un filtre seuil pour passer à 255,255,255 tout ce qui n'est pas à 0,0,0.

[Equinoxe]

Eh bien oui, effectivement c'est la meilleure solution. Le tout est de bien superposer des deux images.
Je vais finir par remettre ce logiciel d'astronomie sur un ordi... Il faisait tout cela automatiquement !

[Bug Killer]

Dans Paint Shop Pro, la superposition exacte est automatique.

[fredophoto]

Je trouve que le meilleur moyen de régler pour de bon ces problèmes, c'est de shooter en raw !
Comme ça, tu exportes les images qui t'intéressent en jpg et elles sont directement dans le bon sens sans avoir à se poser de questions métaphysiques sur la quadrature des paquets de pixels (même si elles sont intéressantes par ailleurs).
Et comme je suis une grosse feignasse qui n'aime pas se compliquer la vie, je fais du raw+jpg pour avoir l'image visualisable de suite et que je peux tourner à loisir sans me préocuper le moins du monde de la perte éventuelle puisque le fichier est destiné à la poubelle de toute façon ^^ .
Ca ne répond pas forcément à la question d'origine mais c'est une méthode qui marche .

[Equinoxe]

A Fredphoto... Il ne s'agit pas de ce problème vingt fois -si ce n'est pas plus - déjà débattu.
Et je pense qu'il y en a plus d'un ici qui a redressé un horizon ... pas toujours ... bien placé !
Il s'agit de savoir si Faststone est une bonne visionneuse et si quelques opérations faites sur du jpeg sont ou non destructrices et à quel degré elles le sont.

A Bug K ... ça va quand même avec mon vieux Corel : il a une fonction centrer et au clavier si des écarts subsistent, je peux ajuster au pixel près.

Voilà donc le fruit de mes investigations.

Le protocole était le suivant:
-rotation de 2 degrés - enregistrement sans l’option recadrage de Faststone (donc l’image possède un cadre blanc et elle est obligatoirement “recalculée” avant enregistrement) ;
- reprise de cet enregistrement - rotation inverse nouvel enregistrement ;
- recadrage pour la suppression du cadre blanc et enregistrement.

Ensuite sur l’image finale le même traitement est refait avec 7 degrés de rotation

Pour trois enregistrements, il n’y a pas visuellement de différence constatable lors de l’examen pixel à pixel.
La comparaison des composantes RVB d’une centaine de pixels choisis dans des zones de dégradés ne montre pas d’altération par rapport à l’image d’origine.
Mais une comparaison sur masque montre des modifications sur les zones de contours marqués : on observe l’apparition de quelques liserés sur ce masque de test.

En revanche après la seconde série de rotation et contre rotation, même si c’est visuellement indécelable, il y a quelques pixels dont la teinte a été modifiée (1 à 3 points sur chaque composante). Ces pixels sont toujours situés dans les zones de transition correspondant à des contours assez marqués.
Ils déterminent des liserés sur le masque de comparaison, sont plus nombreux mais limités à une largeur de 1 pixel.

Dans tous les cas, la netteté des contours n’est pas affectée.
Le test par rotation de quelques degrés est particulièrement sévère puisque lors de l’enregistrement le logiciel doit refaire toutes les étapes de calculs propres au format jpeg.
---------------------
En revanche, avec des rotations à 90̊, les masques de comparaison montrent que les fichiers enregistrés, même s’ils changent de taille, fournissent des images absolument conformes aux originaux.
---------------------
Sur tracé d’un texte ou de quelques traits, il est impossible d’identifier visuellement d’autres modifications que celles engendrées par le trait lui-même ou du texte.
Mais elles existent bien : il s’agit de quelques pixels situés là encore au niveau de transitions marquées et parfois très loin de la zone modifiée par le texte ou le trait.
Là comme pour les rotations, Corel Draw est parfait (aucune zone altérée).
Cependant il faut tempérer ces observations : sur deux ou trois enregistrements successifs par Faststone, la différence reste visuellement indécelable.

Une curiosité quand même : Zsoft (c’est l’éditeur du vieux paintbrush racheté par microsoft) avait un format propriétaire PCX, compressé mais non destructeur.
Si, sous Faststone, on procède aux mêmes tests de rotation avec ce format, il y a les mêmes phénomènes situés à la limite des transitions, un peu comme si faststone procédait un imperceptible rehaussement du contraste autour des contours marqués.
---------------------
Au final, le bilan est positif donc pour ce logiciel gratuit.