Problème de rotation JPG

jdd a écrit :

Le 07/04/2017 à 16:35, Alf92 a écrit :

exemple d'une image qui refuse le *rotate lossless* :
http://www.cjoint.com/c/GDhoFSc7eZH
certains softs refusent même de l'ouvrir (ACDSee, PhotoFiltre)

gwenview les ouvre et les tourne. Pas terrible, le pano, il coupe les têtes
:-))

http://www.cjoint.com/doc/17_04/GDhqBKP1jVs_GDhoFSc7eZH-20170403-115222-2.jpg

je ne sais pas si la rotation est lossless, mais ps sur

1) que ce soit possible
2) que ca vaille le coup
3) que ce ne soit pas déjà fait (changement du tag?)

le fichier tourné est là:

http://www.cjoint.com/doc/17_04/GDhqDkRHxis_GDhoFSc7eZH-20170403-115222.jpg

et cjoint ne veut pas l'afficher...

Je viens de lui filer un coup de mon FastStone favori : ça tourne sans
problème.

http://archaero.com/Tampon/Redresse-gauche-20170403-115222.jpg


--
Jacques DASSIÉ
Toujours sçavoir plus
http://archaero.com/

--
Jacques DASSIÉ
Toujours sçavoir plus
http://archaero.com/

Alf92 :

Alf92 :

J'ai un problème.
Habituellement je redresse et débarasse mes photos du tag d'orientation
avec jhead + jpegtran.
Pour cela je mets dans le dossier de mes photos à traiter jhead.exe +
jpegtran.exe + un fichier.bat contenant la commande
jhead -se -ft -autorot *.jpg

Là j'ai un milliers de photos à redresser, issu d'un smartphone
(Samsung), or sur certaines images (panoramas verticaux et selfies
verticaux) ça plante avec le message suivant :
*Invalid SOS parameters for sequential jpeg*
De plus ça stope le traitement par lot.

A ce niveau, il est clair que vous auriez intérêt à faire un vrai
script qui encapsule les appels à jhead, jpegtran, exiftool, etc. Je
fais systématiquement comme ça (en Python), vous utilisez un
try...except, au final vous avez la liste des fichiers non traités avec
la raison, et possiblement ces fichiers dans la même dossier. Je peux
voir faire parvenir du code si vous le souhaitez.

Quand je tente un retournement manuel *lossless* avec ACDSee, ce
dernier plante également.

Je pense donc qu'il y des données foireuses dans un coin...
Comment s'en débarasser SANS RECOMPRESSER mes JPEG, tout en conservant
les EXIF hors tag d'orientation ?
Une idée ? Une solution ?

exemple d'une image qui refuse le *rotate lossless* :
http://www.cjoint.com/c/GDhoFSc7eZH
certains softs refusent même de l'ouvrir (ACDSee, PhotoFiltre)

et Gimp Linux, Gimp Windows, etc.

J'ai perdu beaucoup trop de temps avec l'orientation, jpegtran et
consort. J'ai également été impressionné par le mot "lossless" accolé à
jpegtran.
Apparté sur jpegtran: à ma connaissance c'est la seule tentative de
passer outre le fait qu'un fichier compressé jpeg n'est pas décrit
pixel par pixel. Ça marche si l'image peut être découpé exactement en
blocs 8x8. A mon avis - sans certitude toutefois - ça peut être utile
pour diminuer la charge CPU dans les opérations par lot coté serveur.

La réponse à votre question principale est "c'est pas possible", il va
vous falloir négocier et laisser tomber certaines certitudes.
Par exemple on lit partout, parce que c'est évident, que décompresser
puis recompresser est dramatique. Or, c'est faux, au moins sur l'image
que vous avez posté. L'image redressée via Windows est plutôt un peu
meilleure en visu 100% que l'originale. C'est pas magique, l'image
arrive un peu suraccentuée, elle est bitmapisée avec les artefacts
(légers) de la compression originale, puis recompressée.

Peu importe, de toute façon, vous n'aurez pas le choix.

Les images qui posent problème sont incompatibles avec la lib 'c'
libjpeg, en tout cas celle de la chaine GNU. Je ne sais pas si le
format est pourri ou non, c'est comme ça et ça gonfle. S'il est
pertinent de redresser niveau bitmap les images orientée via tag, il
l'est tout autant de ne pas délivrer des images illisibles sur Gimp,
ACDSeee, etc. Or si vous parveniez à redresser "SANS RECOMPRESSER",
évidemment le défaut de codage resterait. Idem d'ailleurs si vous
publiiez sans redresser.

Je vous suggère de faire la manip suivant:
Sous Windows 10 (adaptez), copiez l'image en trois versions. La
première est inchangée. La deuxième, clic-droit, ouvrir avec Paint (pas
Paint.Net !), sauver, fermer. La troisième, ouvrir avec Photoshop,
sauver en écrasant, à la qualité souhaitée, j'ai testé avec 12. On
pourrait ajouter l'export LightRoom (et Bridge). Vous comparez les
tailles et la qualité visuelle.

Après, vous décidez.


--
Pierre Maurette

Pierre Maurette :

Alf92 :

Alf92 :

J'ai un problème.
Habituellement je redresse et débarasse mes photos du tag d'orientation
avec jhead + jpegtran.
Pour cela je mets dans le dossier de mes photos à traiter jhead.exe +
jpegtran.exe + un fichier.bat contenant la commande
jhead -se -ft -autorot *.jpg

Là j'ai un milliers de photos à redresser, issu d'un smartphone
(Samsung), or sur certaines images (panoramas verticaux et selfies
verticaux) ça plante avec le message suivant :
*Invalid SOS parameters for sequential jpeg*
De plus ça stope le traitement par lot.

A ce niveau, il est clair que vous auriez intérêt à faire un vrai
script qui encapsule les appels à jhead, jpegtran, exiftool, etc. Je
fais systématiquement comme ça (en Python), vous utilisez un
try...except, au final vous avez la liste des fichiers non traités avec
la raison, et possiblement ces fichiers dans la même dossier. Je peux
voir faire parvenir du code si vous le souhaitez.

Quand je tente un retournement manuel *lossless* avec ACDSee, ce
dernier plante également.

Je pense donc qu'il y des données foireuses dans un coin...
Comment s'en débarasser SANS RECOMPRESSER mes JPEG, tout en conservant
les EXIF hors tag d'orientation ?
Une idée ? Une solution ?

exemple d'une image qui refuse le *rotate lossless* :
http://www.cjoint.com/c/GDhoFSc7eZH
certains softs refusent même de l'ouvrir (ACDSee, PhotoFiltre)

et Gimp Linux, Gimp Windows, etc.

J'ai perdu beaucoup trop de temps avec l'orientation, jpegtran et
consort. J'ai également été impressionné par le mot "lossless" accolé à
jpegtran.
Apparté sur jpegtran: à ma connaissance c'est la seule tentative de
passer outre le fait qu'un fichier compressé jpeg n'est pas décrit
pixel par pixel. Ça marche si l'image peut être découpé exactement en
blocs 8x8. A mon avis - sans certitude toutefois - ça peut être utile
pour diminuer la charge CPU dans les opérations par lot coté serveur.

La réponse à votre question principale est "c'est pas possible", il va
vous falloir négocier et laisser tomber certaines certitudes.
Par exemple on lit partout, parce que c'est évident, que décompresser
puis recompresser est dramatique.

"dramatique" ? fichtre...

Or, c'est faux,

bin ça dégrade quand même.

au moins sur l'image que vous avez posté.
L'image redressée via Windows est plutôt un peu
meilleure en visu 100% que l'originale. C'est pas magique, l'image
arrive un peu suraccentuée, elle est bitmapisée avec les artefacts
(légers) de la compression originale, puis recompressée.

c'est un choix, un goût...

Peu importe, de toute façon, vous n'aurez pas le choix.

?

Les images qui posent problème sont incompatibles avec la lib 'c'
libjpeg, en tout cas celle de la chaine GNU. Je ne sais pas si le
format est pourri ou non, c'est comme ça et ça gonfle. S'il est
pertinent de redresser niveau bitmap les images orientée via tag, il
l'est tout autant de ne pas délivrer des images illisibles sur Gimp,
ACDSeee, etc. Or si vous parveniez à redresser "SANS RECOMPRESSER",
évidemment le défaut de codage resterait. Idem d'ailleurs si vous
publiiez sans redresser.

rien n'est moins sûr.

Je vous suggère de faire la manip suivant:
Sous Windows 10 (adaptez), copiez l'image en trois versions. La
première est inchangée. La deuxième, clic-droit, ouvrir avec Paint (pas
Paint.Net !), sauver, fermer. La troisième, ouvrir avec Photoshop,
sauver en écrasant, à la qualité souhaitée, j'ai testé avec 12. On
pourrait ajouter l'export LightRoom (et Bridge). Vous comparez les
tailles et la qualité visuelle.

Après, vous décidez.

encore plus simple : sous windows, clique droit sur l'image puis "faire
pivoter vers la gauche".
mais le problème reste : il y a recompression.

Alf92 :

Pierre Maurette :

Alf92 :

Alf92 :

J'ai un problème.
Habituellement je redresse et débarasse mes photos du tag d'orientation
avec jhead + jpegtran.
Pour cela je mets dans le dossier de mes photos à traiter jhead.exe +
jpegtran.exe + un fichier.bat contenant la commande
jhead -se -ft -autorot *.jpg

Là j'ai un milliers de photos à redresser, issu d'un smartphone
(Samsung), or sur certaines images (panoramas verticaux et selfies
verticaux) ça plante avec le message suivant :
*Invalid SOS parameters for sequential jpeg*
De plus ça stope le traitement par lot.

A ce niveau, il est clair que vous auriez intérêt à faire un vrai
script qui encapsule les appels à jhead, jpegtran, exiftool, etc. Je
fais systématiquement comme ça (en Python), vous utilisez un
try...except, au final vous avez la liste des fichiers non traités avec
la raison, et possiblement ces fichiers dans la même dossier. Je peux
voir faire parvenir du code si vous le souhaitez.

Quand je tente un retournement manuel *lossless* avec ACDSee, ce
dernier plante également.

Je pense donc qu'il y des données foireuses dans un coin...
Comment s'en débarasser SANS RECOMPRESSER mes JPEG, tout en conservant
les EXIF hors tag d'orientation ?
Une idée ? Une solution ?

exemple d'une image qui refuse le *rotate lossless* :
http://www.cjoint.com/c/GDhoFSc7eZH
certains softs refusent même de l'ouvrir (ACDSee, PhotoFiltre)

et Gimp Linux, Gimp Windows, etc.

J'ai perdu beaucoup trop de temps avec l'orientation, jpegtran et
consort. J'ai également été impressionné par le mot "lossless" accolé à
jpegtran.
Apparté sur jpegtran: à ma connaissance c'est la seule tentative de
passer outre le fait qu'un fichier compressé jpeg n'est pas décrit
pixel par pixel. Ça marche si l'image peut être découpé exactement en
blocs 8x8. A mon avis - sans certitude toutefois - ça peut être utile
pour diminuer la charge CPU dans les opérations par lot coté serveur.

La réponse à votre question principale est "c'est pas possible", il va
vous falloir négocier et laisser tomber certaines certitudes.
Par exemple on lit partout, parce que c'est évident, que décompresser
puis recompresser est dramatique.

"dramatique" ? fichtre...

Or, c'est faux,

bin ça dégrade quand même.

au moins sur l'image que vous avez posté.
L'image redressée via Windows est plutôt un peu
meilleure en visu 100% que l'originale. C'est pas magique, l'image
arrive un peu suraccentuée, elle est bitmapisée avec les artefacts
(légers) de la compression originale, puis recompressée.

c'est un choix, un goût...

Peu importe, de toute façon, vous n'aurez pas le choix.

?

Les images qui posent problème sont incompatibles avec la lib 'c'
libjpeg, en tout cas celle de la chaine GNU. Je ne sais pas si le
format est pourri ou non, c'est comme ça et ça gonfle. S'il est
pertinent de redresser niveau bitmap les images orientée via tag, il
l'est tout autant de ne pas délivrer des images illisibles sur Gimp,
ACDSeee, etc. Or si vous parveniez à redresser "SANS RECOMPRESSER",
évidemment le défaut de codage resterait. Idem d'ailleurs si vous
publiiez sans redresser.

rien n'est moins sûr.

Vous savez ce que vous répondez et à quoi ?

Je vous suggère de faire la manip suivant:
Sous Windows 10 (adaptez), copiez l'image en trois versions. La
première est inchangée. La deuxième, clic-droit, ouvrir avec Paint (pas
Paint.Net !), sauver, fermer. La troisième, ouvrir avec Photoshop,
sauver en écrasant, à la qualité souhaitée, j'ai testé avec 12. On
pourrait ajouter l'export LightRoom (et Bridge). Vous comparez les
tailles et la qualité visuelle.

Après, vous décidez.

encore plus simple : sous windows, clique droit sur l'image puis "faire
pivoter vers la gauche".

Rien à voir. "Faire pivoter vers la droite|gauche" positionne juste le
tag d'orientation. Avec Paint, Photoshop ou ce que vous voulez vous
faites ce que vous souhaitiez (mais avec décodage puis encodage) c'est
à dire positionner le tag à 1 et pivoter les pixels.

mais le problème reste : il y a recompression.

Mais sans, c'est pas mieux, ou pas possible. Et puis il vous faut bien
corriger vos images "vérolées".


--
Pierre Maurette

Pierre Maurette :

Alf92 :

Pierre Maurette :

Alf92 :

Alf92 :

J'ai un problème.
Habituellement je redresse et débarasse mes photos du tag d'orientation
avec jhead + jpegtran.
Pour cela je mets dans le dossier de mes photos à traiter jhead.exe +
jpegtran.exe + un fichier.bat contenant la commande
jhead -se -ft -autorot *.jpg

Là j'ai un milliers de photos à redresser, issu d'un smartphone
(Samsung), or sur certaines images (panoramas verticaux et selfies
verticaux) ça plante avec le message suivant :
*Invalid SOS parameters for sequential jpeg*
De plus ça stope le traitement par lot.

A ce niveau, il est clair que vous auriez intérêt à faire un vrai
script qui encapsule les appels à jhead, jpegtran, exiftool, etc. Je
fais systématiquement comme ça (en Python), vous utilisez un
try...except, au final vous avez la liste des fichiers non traités avec
la raison, et possiblement ces fichiers dans la même dossier. Je peux
voir faire parvenir du code si vous le souhaitez.

Quand je tente un retournement manuel *lossless* avec ACDSee, ce
dernier plante également.

Je pense donc qu'il y des données foireuses dans un coin...
Comment s'en débarasser SANS RECOMPRESSER mes JPEG, tout en conservant
les EXIF hors tag d'orientation ?
Une idée ? Une solution ?

exemple d'une image qui refuse le *rotate lossless* :
http://www.cjoint.com/c/GDhoFSc7eZH
certains softs refusent même de l'ouvrir (ACDSee, PhotoFiltre)

et Gimp Linux, Gimp Windows, etc.

J'ai perdu beaucoup trop de temps avec l'orientation, jpegtran et
consort. J'ai également été impressionné par le mot "lossless" accolé à
jpegtran.
Apparté sur jpegtran: à ma connaissance c'est la seule tentative de
passer outre le fait qu'un fichier compressé jpeg n'est pas décrit
pixel par pixel. Ça marche si l'image peut être découpé exactement en
blocs 8x8. A mon avis - sans certitude toutefois - ça peut être utile
pour diminuer la charge CPU dans les opérations par lot coté serveur.

La réponse à votre question principale est "c'est pas possible", il va
vous falloir négocier et laisser tomber certaines certitudes.
Par exemple on lit partout, parce que c'est évident, que décompresser
puis recompresser est dramatique.

"dramatique" ? fichtre...

Or, c'est faux,

bin ça dégrade quand même.

au moins sur l'image que vous avez posté.
L'image redressée via Windows est plutôt un peu
meilleure en visu 100% que l'originale. C'est pas magique, l'image
arrive un peu suraccentuée, elle est bitmapisée avec les artefacts
(légers) de la compression originale, puis recompressée.

c'est un choix, un goût...

Peu importe, de toute façon, vous n'aurez pas le choix.

?

Les images qui posent problème sont incompatibles avec la lib 'c'
libjpeg, en tout cas celle de la chaine GNU. Je ne sais pas si le
format est pourri ou non, c'est comme ça et ça gonfle. S'il est
pertinent de redresser niveau bitmap les images orientée via tag, il
l'est tout autant de ne pas délivrer des images illisibles sur Gimp,
ACDSeee, etc. Or si vous parveniez à redresser "SANS RECOMPRESSER",
évidemment le défaut de codage resterait. Idem d'ailleurs si vous
publiiez sans redresser.

rien n'est moins sûr.

Vous savez ce que vous répondez et à quoi ?

Je vous suggère de faire la manip suivant:
Sous Windows 10 (adaptez), copiez l'image en trois versions. La
première est inchangée. La deuxième, clic-droit, ouvrir avec Paint (pas
Paint.Net !), sauver, fermer. La troisième, ouvrir avec Photoshop,
sauver en écrasant, à la qualité souhaitée, j'ai testé avec 12. On
pourrait ajouter l'export LightRoom (et Bridge). Vous comparez les
tailles et la qualité visuelle.

Après, vous décidez.

encore plus simple : sous windows, clique droit sur l'image puis "faire
pivoter vers la gauche".

Rien à voir. "Faire pivoter vers la droite|gauche" positionne juste le
tag d'orientation.

je viend de tester : ça marche !
et en plus la photo devient lisible dans Firefox, ACDSee,
PhotoFiltre...
youpi !

Avec Paint, Photoshop ou ce que vous voulez vous
faites ce que vous souhaitiez (mais avec décodage puis encodage) c'est
à dire positionner le tag à 1 et pivoter les pixels.

mais le problème reste : il y a recompression.

Mais sans, c'est pas mieux, ou pas possible. Et puis il vous faut bien
corriger vos images "vérolées".

cf ci-dessus
la photo retournée :
http://www.cjoint.com/doc/17_04/GDiueusAgTS_GDhoFSc7eZH-20170403-115222.jpg

dans exif on retrouve tout sauf la dernière ligne :

Marque de l’appareil: samsung
Modèle de l’appareil: SM-G930F
Date et heure de la photo: 2017-04-03 11:52:22 (pas de fuseau horaire)
Distance focale: 4.2 mm (équivalence 35 mm : 26 mm)
Ouverture: ƒ/1.7
Mode de mesure: Moyenne
Exposition: Programme (automatique)
Balance des blancs: automatique
Utilisation du flash: Non (forcée)
Orientation: Normale
Espace colorimétrique: sRGB
Coordonnées GPS: undefined, undefined
Logiciel: *Microsoft Windows Photo Viewer 6.1.7600.16385*

Alf92 :

Alf92 :

J'ai un problème.
Habituellement je redresse et débarasse mes photos du tag d'orientation
avec jhead + jpegtran.
Pour cela je mets dans le dossier de mes photos à traiter jhead.exe +
jpegtran.exe + un fichier.bat contenant la commande
jhead -se -ft -autorot *.jpg

Là j'ai un milliers de photos à redresser, issu d'un smartphone
(Samsung), or sur certaines images (panoramas verticaux et selfies
verticaux) ça plante avec le message suivant :
*Invalid SOS parameters for sequential jpeg*
De plus ça stope le traitement par lot.

Quand je tente un retournement manuel *lossless* avec ACDSee, ce
dernier plante également.

Je pense donc qu'il y des données foireuses dans un coin...
Comment s'en débarasser SANS RECOMPRESSER mes JPEG, tout en conservant
les EXIF hors tag d'orientation ?
Une idée ? Une solution ?

exemple d'une image qui refuse le *rotate lossless* :
http://www.cjoint.com/c/GDhoFSc7eZH
certains softs refusent même de l'ouvrir (ACDSee, PhotoFiltre)

Par curiosité, j'aimerais savoir si les images "normales normales" et
"selfies normales" issues du même appareil s'ouvrent dans ces
logiciels.

--
Pierre Maurette

Alf92 :

Pierre Maurette :

Alf92 :

[...]

Sous Windows 10 (adaptez)

je viend de tester : ça marche !
et en plus la photo devient lisible dans Firefox, ACDSee,
PhotoFiltre...
youpi !

[...]

cf ci-dessus
la photo retournée :
http://www.cjoint.com/doc/17_04/GDiueusAgTS_GDhoFSc7eZH-20170403-115222.jpg

Cette image est recompressée.

dans exif on retrouve tout sauf la dernière ligne :

Marque de l’appareil: samsung
Modèle de l’appareil: SM-G930F
Date et heure de la photo: 2017-04-03 11:52:22 (pas de fuseau horaire)
Distance focale: 4.2 mm (équivalence 35 mm : 26 mm)
Ouverture: ƒ/1.7
Mode de mesure: Moyenne
Exposition: Programme (automatique)
Balance des blancs: automatique
Utilisation du flash: Non (forcée)
Orientation: Normale
Espace colorimétrique: sRGB
Coordonnées GPS: undefined, undefined
Logiciel: *Microsoft Windows Photo Viewer 6.1.7600.16385*

Vous utilisez une version de Windows plus ancienne que la mienne, le
serial de Photo Viewer est celui de la dernière version de Windows 7.
Il y a entre 7 et 10 au moins une grosse différence pour ce qui nous
concerne: dans l'explorateur, clic-droit puis "Pivoter vers ..."
modifie juste le tag (modification-tag) sur 10 et pivote le bitmap
(modification-bitmap) par appel silencieux à un bout de Photo Viewer
sur 7. Sur les deux OS, ouvrir dans Photo Viewer, pivoter, juste fermer
pivote le bitmap (modification-bitmap).


Je précise ce que j'entends par:
- modification: changement d'orientation. Orientation: toute
combinaison pivotement 90 - 180 - 270 et symétrie H - V, soit 6
possibilités (tag de 2 à 7), plus rien (tag 1, 0 même effet).
- modification-tag: juste modifier le tag d'orientation. 1, 0,
"Normal", "0° (haut:gauche)", absence, non-reconnaissance ont le même
effet, c'est à dire aucune modification.
- modification-bitmap: modification des données "image compressée" dans
le fichier. Lecture de ces données vers un tableau de pixels puis
nouvelle compression JPEG.

Pour chaque modification-tag, il existe une modification-bitmap
inverse, et Lycée de Versailles, tels que l'application des deux ne
modifie pas l'affichage.

L'orientation via tag différent de 1 (0, rien, etc.) pose problème,
particulièrement dans un navigateur(*). Votre but, légitime et
habituel, est d'appliquer *si besoin* le couple modification-tag +
modification-bitmap tel que le tag d'orientation final soit 1 (0,
effacé, etc.).

En général, "modification lossless" est à prendre comme
modifcation-tag. Selon le contexte, il peut s'agir d'une
modification-bitmap via jpegtran, qui est plus ou moins un hack.

Il existe semble-t-il un format JPEG "bizarre", en ce sens qu'il pose
problème à certains décodeurs. Si (ma tante en avait...) un outil
utilisé pour une modification-bitmap est capable de le décoder, alors
il génèrera selon son propre format, non bizarre. En plus d'avoir été
redressée, l'image aura été "réparée". Je suppose que si jpegtran était
capable de lire ces fichiers, il produirait le même format "bizarre" en
sortie, mais on ne sait pas, il ne peut pas traiter. Alors, non
seulement il est impératif de passer par une modification-bitmap avec
recompression pour redresser ces images, mais peut-être serait-ce une
bonne idée de le faire également pour les images ne demandant pas à
être redressées.


(*): on pourrait penser qu'il ne devrait plus y avoir de problème, mais
ce n'est pas vrai.
Mozilla propose un CSS:
image-orientation: from-image; /* Use EXIF data from the image */
Il semblerait possible de positionner cette valeur dans la feuille de
style par défaut des navigateurs. Or, ce truc n'est supporté par aucun
navigateur hors Firefox, et ça semble volontaire et assumé. La raison
en est certainement que tout ce qui avait pris en compte le problème
(javascript, php, à la volée ou en dur) se retrouveraient avec des
images dans tous les sens.

--
Pierre Maurette

Le 09/04/2017 08:18, Pierre Maurette a écrit :

tout ça est d'une complexité ahurissante.

il suffirait de bannir ce tag, c'est trivial qu'un APN
enregistre le jpg physiquement en "portrait" suivant le capteur
d'orientation.

on en est quand même à avoir besoin d'un examinateur d'exif pour
connaitre le vrai sens d'une photo... l'ouvrir étant un tirage du Loto.

Charles Vassallo a écrit :

Alf92 a écrit :

exemple d'une image qui refuse le *rotate lossless* :
http://www.cjoint.com/c/GDhoFSc7eZH
certains softs refusent même de l'ouvrir (ACDSee, PhotoFiltre)

Idem pour SeaMonkey et Firefox (dans MacOS) mais ça s'ouvre dans Safari.
Ça s'ouvre sous Photoshop ou GraphicConverter, mais pas dans Affinity Photo

Tu vis dangereusement

charles

Oui, aucun de mes softs ne l'ouvre, sauf PaintShop-7 , normal, PSP7 ne gère pas
les EXIF ni IPTC, or il semble que c'est l'entêe qui a dégusté.

Eye of Gnome affiche bien l'image, et la tourne et... refuse de la
réenregistrer: pas d'entête conforme à itiliser ?

--
En marge de "nuit debout" :
On signale un collectif de gastéropodes réclamant le droit au pouce opposable.

Stephane Legras-Decussy a écrit :

Le 07/04/2017 18:30, jdd a écrit :

et cjoint ne veut pas l'afficher...

le tag orientation est un boulet qui peut vraiment me mettre les nerfs en
boule.... ça ne devrait pas exister.

Bien, sûr que si, je bénis cette balise tous les jours, juste qu'il faut avoir
les bons outils.
ça permet des tas de trucs, y compris quand ton capteur d'orientation (cas de
mon G11) devient un peu aléatoire, où quand tu tiens ton APN incliné selon
plusieurs axes: tu choisis après-coup l'orientation d'affichage.

Le pb des images d'Alf n'est pas la balise, mais l'entête cassé; et comme il a
ça pour plusieurs images, ça sent le disque dur qui a eu des misères , prions
pour qu'il ait des sauvegardes!!


--
En marge de "nuit debout" :
On signale un collectif de gastéropodes réclamant le droit au pouce opposable.