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

[Fangio]

ça a été évoqué mais je n'ai pas le fin mot : mon boîtier enregistre l'orientation de l'image dans les exifs. Je n'ai aucune photo mal tournée en utilisant PMB ou en visionnant sur l'écran arrière, il n'y a qu'avec la visionneuse XP que ça merdouille, soit je ne sais pas la paramétrer, soit c'est vraiment une méga bouse.
Certes il y a d'autres visionneuses, mais quand on veut faire du tri, du classement, c'est quand même avec l'explorateur Windows qu'on va le plus vite.
Je vais passer sur Mac de toute façon, ce n'est pas le seul inconvénient sous Windows.

[Snoopy]

rah ce que j'ai honte

Je viens de me rendre compte que le passage IDC -> Toshop ne garde pas la position de la photolors de la conversion Tiff, j'ai toujours fait une rotation par réflexe et était persuadé que ça se faisait tout seul.... Sorry, sorry, sorry

[vroum]

J'ai testé irfanview, donc avec le défaut de n'ètre qu'en anglais ou en allemand mis à part, j'en suis toujours au point de départ, car lui aussi il lis les exifs et donc affiche une photo verticale ...en verticale!
Je ne peux donc pas la tourner vu qu'elle l'est déjà, verticale. Les voir sur mon ordi ça peut passer, mais si je dois obliger toutes les personnes de mon entourage a installer faststone par ex cela va pas ètre très pratique .
Donc pour l'instant je n'ai pas encore de solution pour tourner sans perte une image afin qu'elle s'affiche dans le bon sens quel que soit le logiciel .

[Equinoxe]

IrfanView a dans les options le choix de la langue. Il faut évidemment avoir chargé les plugins de langage
Intéressant comme visualisateur et convertisseur par défaut puisqu'il n'encombre pas le disque dur par une base de données ou de vignettes, il est bien plus lent cependant que Faststone.
Et puisque l'on parle parfois à tort et à travers du jpeg, faites ce qui suit avec Faststone.
D'abord sauvegarder une copie d'un fichier jpeg.
Sur cette sauvegarde, faire quatre rotations sans perte (bien sûr, dans les options F12, d'abord mettre la qualité à 100%).
Enfin, lancez une comparaison (P) entre l'original et le fichier qui a été réenregistré quatre fois à ... 2000 ou 3000 %, de façon à bien visualiser dans chaque fenêtre les pixels.
Je laisse chacun à ses conclusions.

[Bug Killer]

Une vraie rotation sans perte ne modifie pas les donnees representant les pixels, juste l'octet d'orientation des exif. Si IrfanView procede autrement, sa commande porte un nom inapproprie.

[Equinoxe]

Je parle de Faststone.
Exact, les "données pixels" sont strictement inchangées ... on peut le vérifier avec un éditeur hexadécimal.
Mais la démo ne s'arrête pas là.
Puisque Faststone dispose d'un petit module de dessin, on trace une ligne, de préférence placée en marge de deux à-plats et se prolongeant sur un dégradé (car c'est souvent dans les à-plats et les dégradés que l'on reproche au jpeg d'être destructif).
On enregistre sous un nouveau nom et on compare à nouveau pixel à pixel en particulier dans la zone où a été tracée la ligne.
Résultat ...
Il y a donc bien quelques logiciels qui font du travail propre et non destructeur sur du jpeg.
J'ai bien des vieux photoshop mais resté fidèle aux produits Corel, j'avais constaté depuis le Corel Paint 8 (donc ça date de ... windows 98 !) que si la compression et le lissage étaient à zéro, on pouvait faire des dizaines de modifications d'un même jpeg sans altérer la qualité.
Et pourtant le jpeg dit "lossless" n'existait pas.
Attention aux dérapages que je sens venir... cela ne signifie nullement qu'on peut travailler en jpeg à la prise de vue. Tous les avantages des raw ne sont à l'évidence plus à démontrer.
Attention aussi aux idées reçues telles : le jpeg est systématiquement destructeur .
On peut très bien ajouter à un jpeg un titre, un watermark etc sans dégrader sa qualité.
Et puisque le sujet était "quelle visionneuse ?", il me semble que ce Faststone réunit beaucoup d'avantages pour un logiciel qui pourrait bien - au vu de ses qualités - ne plus rester longtemps gratuit.

[vroum]

Alors j'ai pris faststone, dans les paramètres j'ai mis:
- qualité jpeg 100 (maxi)
- "utiliser la qualité jpeg pour les fichiers originaux si possible" laissé coché.
- sous échantillonage: aucun(meilleure qualité).
- "optimiser la table huffman" laissé coché.

L'image horizontale fait 7635kb.
Je clique sur le bouton "rotation à droite sans perte".
Il tourne l'image et l'enregistre.
Et une fois en verticale elle ne fait plus que 6751kb...
Pas mal non pour une rotation sans perte?
Alors bug du programme? Fonction mensongère? ou mauvaise manip?

[JJ]

Le jpeg utilisant un algorithme de compression, n'est-il pas naturel de voir la taille d'une meme image differente quand elle est lue a la verticale ou a l'horizontale ? J'ai fait l'experience avec Gimp et je rencontre le meme probleme ...
En ce qui me concerne, je garde tous les originaux quelque part et je ne tripatouille que des copies ... vieux reflexe d'informati-chien !!!

[Equinoxe]

Non...
Le changement de taille provient de ce que la taille (élastique) des zones de stockage des données exif, iptc etc (donc n'ayant rien à voir avec les données des pixels) a été changée par Faststone.
Ces zones de fichier restent en général incomplètement utilisées et Faststone les réduit.
La comparaison pixel à pixel est à faire. Elle est très démonstrative : l'image est bien inchangée.
En quelque sorte, un jpeg est un container, tout comme un fichier avi en vidéo. Ce n'est pas parce que la taille de l'emballage est modifiée que le contenu a été changé.

[vroum]

Quand je pose un tirage sur une table je peux le tourner dans tout les sens sans que des ciseaux viennent le couper .
Je ne vois pas ce qui l'empèche en informatique, d'autant plus que si je laisse le mode auto il y arrive bien, alors qu'en manuel il n'y arrive plus...
Donc ce n'est pas une impossibilité physique mais une erreur du programmeur.

[Equinoxe]

J'ajoute d'ailleurs que dans ce cas de figure (rotations successives de 90°), le réglage de qualité à 100% n'a pas d'importance : il n'y a en fait aucune recompression des "données pixels", ainsi que l'a bien signalé Bug.
Ce n'est que si des modifications de pixels sont faites : ligne, titre, modification d'une dominante qu'il y a un risque de dégradation.
Donc c'est dans ces situations qu'il serait intéressant d'identifier les logiciels qui à compression zéro présentent des risques de dégradation et ceux qui sont réellement à compression zéro.
Il y a là tout un travail de fourmi à faire et certainement quelques surprises à la clé.

[vroum]

Tiens je viens de refaire un test, l'image de 7635ko en horizontal en fait 6751 tourné en vertical par faststone, mais 7072 tourné par windows, soit 321ko d'écart.
Ce qui fait que faststone retire 884ko pour la rotation, alors que windows ne retire que 563ko...
J'ai besoin d'une explication là, je comprends plus grand chose, celui qui est sensé ètre le plus performant est celui qui réduit le plus

[JJ]

Bon, quand on lit un jpeg compresse, on le decompresse, non ? On fait tourner l'image de 90 degres (ou 100 grades). Quand on l'enregistre, on utilise bien l'algorithme de compression qui va bien. Comme on ne lit plus la meme image, il me semble logique qu'on modifie alors la taille du fichier, non ?
Voir ici :http://fr.wikipedia.org/wiki/JPEG les histoires de jpeg ... Bonne nuit. Et n'oubliez pas l'aspirine avant d'aller sur ce site ...

Mais comme l'a souligne qulequ'un, la taille du fichier est modifie, mais la qualite des infos contenues dans le fichier est inchangee ...

Bonne nuit a tous ...

[tomazi]

c'est quand même "space" cette histoire.
va falloir que je motorise mon écran pour qu'il pivote tout seul et que j'arrête de faire des rotations sur le fichier. (ça va être pratique çà )

[Equinoxe]

Un fichier informatique n'a rien à voir avec un document papier. S'il manque un seul bit ou à plus forte raison un octet, ce fichier deviendra la plupart du temps illisible.
Les premiers fichiers d'images satellites étaient juste constitués de valeurs de réflectance alignées les unes derrière les autres.
Le logiciel de lecture affichait l'image parce que dans l'entête du fichier se trouvait indiquée la largeur de l'image.
Donc à chaque fois que l'on comptait les "l" pixels correspondant à cette largeur, le logiciel "savait" que le pixel suivant devait être placé à la ligne suivante.
Imaginons qu'un pixel soit manquant et tout est décalé sauf si de temps en temps on place des "balises" de contrôle.
Imaginons maintenant que l'octet indiquant la largeur soit inexact et là c'est toute l'image qui est fichue.

Les algorithmes de compression jpeg nécessitent d'indiquer combien de pixels peuvent former un même "paquet" parce qu'il ont la même couleur. Mais le degré de compression va faire considérer des teintes voisines comme étant identiques. J'ai simplifié car s'ajoutent de algorithmes de lissage...
Dans une compression zéro, on se contente de mettre dans le même "paquet" uniquement les pixels vraiment identiques...
L'identification et le décodage des "paquets" n'a absolument plus rien à voir avec un découpage au ciseaux...
Edition de mon message : l'analyse de l'image se fait par "surfaces" de pixels considérés comme identiques mais lors de l'écriture du fichier, ensuite les transformées de Fourier (cf wilkipédia DTC) sont écrites octet à octet. En quelque sorte la géométrie de la disposition physique des pixels n'existe plus du tout comme elle l'était dans les premiers fichiers d'images numériques "bitmap" BMP.

[vroum]

J'ai testé sur une autre image qui fait 8804ko, elle tombe à 8077 après rotation windows, soit 727ko d'écart.
En plus la diminution n'est constante mais varie suivant la taille du fichier, dans un rapport qui n'est pas constant non plus
Si je tourne mon image de 8804ko avec faststone soit-disant sans perte le fichier après rotation tombe à 6601ko, soit 2203ko d'écart ! Trois fois plus qu'avec windows !