Bonjour Gotcha et merci !

Voici l'originale prise avec un vieil FinePix AV230 :

et celle traitée avec jpegexiforient switch à -8 :

edit : images supprimées car dénudées de leurs exif par l'hébergeur.

Dernière modification par polowigo (2026-07-24 11:20:41)

Au départ elles y sont, je vais vérifier si zupimages ne les a pas squeezées.

Effectivement, elles ont été lessivées par zupimages !  :-/

Dernière modification par polowigo (2026-07-24 10:51:29)

Bonjour polowigo,

Je me suis intéressé à la problématique des orientations avec face_tag_editor, et à l'écriture des métadonnées sans exiftool avec geo_tag_editor.
Dans ce dernier cas j'utilise la librairie PEL (PHP Exif Library ) pour écrire les métadonnées.

J'ai posé la question à Claude concernant l'écriture de l'orientation (rotation et miroir) avec PEL.
Voilà sa réponse :

Claude a écrit:

Oui, techniquement PEL fait exactement ça : il réécrit le segment APP1 sans toucher aux données image, donc c'est du sans perte, comme exiftool -Orientation#=. Et l'avantage pour un plugin distribuable, c'est que c'est du PHP pur, sans dépendance externe (contrairement à ExifTool, qu'on ne peut pas supposer installé chez tout le monde).

Rappel des valeurs : 1 = normal, 2 = miroir H, 3 = 180°, 4 = miroir V, 5 = miroir H + 90° CCW, 6 = 90° CW, 7 = miroir H + 90° CW, 8 = 90° CCW.

Si tu veux composer une rotation avec l'orientation existante (et pas l'écraser), il te faut deux tables de transition, sinon tu casses le résultat pour les images déjà orientées :

php
// rotation 90° CW appliquée à l'orientation courante
$rot90 = [1=>6, 2=>7, 3=>8, 4=>5, 5=>2, 6=>3, 7=>4, 8=>1];
// miroir horizontal
$flipH = [1=>2, 2=>1, 3=>4, 4=>3, 5=>8, 6=>7, 7=>6, 8=>5];
Le vrai piège, côté Piwigo

Modifier le tag ne suffira pas : Piwigo ne relit pas l'EXIF à l'affichage. Il stocke un code dans la colonne rotation de piwigo_images (0/1/2/3 = 0/90/180/270), calculé à la synchro via pwg_image::get_rotation_code_from_orientation(). Donc après l'écriture PEL il faut :

mettre à jour rotation en base pour cette image ;
purger les dérivées — delete_element_derivatives($infos) dans include/functions.inc.php, sinon les vignettes en cache restent dans l'ancien sens.

Et surtout : Piwigo ne gère pas les miroirs. Le mapping orientation → code de rotation ne retient que 1/3/6/8 ; les valeurs 2/4/5/7 sont ramenées à une rotation pure ou ignorées. Pour le miroir, tu as donc deux options :

retourner réellement les pixels (Imagick flopImage()) et remettre l'orientation à 1 — mais ça réencode le JPEG ;
gérer le flip toi-même à la génération des dérivées via un hook, en lisant ta propre valeur d'orientation stockée en base.
Limites de PEL à connaître
JPEG et TIFF uniquement. Pas de PNG, WebP, HEIC, ni de RAW propriétaires (ORF exclu, donc).
Mémoire : PEL charge tout le fichier en objets PHP. Sur ton NAS, avec des JPEG de 20-25 Mpx, surveille memory_limit — c'est le point qui fait le plus souvent capoter un traitement par lot.
La vignette embarquée (IFD1) n'est pas retournée. Certains logiciels l'affichent telle quelle. Le plus propre est de la supprimer ou de la régénérer.
XMP non synchronisé : si tes images portent un tiff:Orientation en XMP (c'est fréquent quand elles sont passées par digiKam), PEL ne le touchera pas et certains lecteurs privilégient le XMP. Divergence garantie.
Maker notes : PEL les recopie en bloc, mais leurs offsets internes ne sont pas relocalisés. Sur des fichiers OM System, teste avant de lancer un batch.

C'est un peu plus complexe que ce que je pensais au départ.
Ce qui est sûr c'est qu'il faut exclure les solutions qui réécrivent le jpg et donc le dégrade.

Si j'ai bien compris ton problème c'est une image qui apparaît correctement dans un visualiseur mais qui perd l'orientation dans Piwigo
Voilà la réponse de Claude

Claude a écrit:

Ah, ça change complètement le diagnostic. Si l'image est correcte dans digiKam et fausse dans Piwigo, le tag EXIF est probablement déjà bon — c'est Piwigo qui a une valeur périmée en base. Dans ce cas, écrire avec PEL ne corrigerait rien : tu réécrirais une valeur déjà correcte, et l'affichage resterait faux.

Ce qui se passe très probablement

Piwigo ne relit pas l'EXIF à l'affichage. Il fige un code dans la colonne rotation de piwigo_images au moment où la photo entre dans la galerie, et c'est cette valeur qui pilote la génération des dérivées ensuite.

Or ce moment-là n'est pas fiable selon la voie d'entrée. C'est un classique du forum Piwigo : à l'upload via l'interface web, Piwigo lit l'EXIF et renseigne correctement l'entrée « rotation » ; en revanche avec un dépôt FTP suivi d'une synchronisation, l'orientation EXIF n'est pas vérifiée. Vu ton setup NAS, tu es sans doute dans le second cas.

Deuxième cause fréquente, à vérifier en premier parce que c'est gratuit : l'extension PHP EXIF doit être installée pour que la rotation soit gérée correctement, précisément pour les images orientées par métadonnées et non tournées physiquement. Sur DSM, selon le paquet PHP actif, elle n'est pas toujours chargée. Un php -m | grep -i exif te le dira tout de suite, et $conf['use_exif'] doit être à true.
Piwigo

Troisième piste : le miroir. Si digiKam a écrit une orientation 2, 4, 5 ou 7, Piwigo ne sait pas la traduire (il ne connaît que 0/90/180/270) et tombera à côté quoi que tu fasses.

Le diagnostic à faire sur une image fautive
bash
exiftool -Orientation# -Orientation photo.jpg

puis en base :

sql
SELECT id, path, width, height, rotation FROM piwigo_images WHERE id = ...;

Correspondance attendue : orientation 1 → rotation 0, 6 → 1, 3 → 2, 8 → 3. Si ça ne colle pas, c'est bien la base qui est décalée, pas le fichier.

La correction propre, au cas par cas

Ne touche pas au JPEG. Deux instructions suffisent :

php
single_update(IMAGES_TABLE, array('rotation' => $code), array('id' => $image_id));
delete_element_derivatives($infos);   // include/functions.inc.php

C'est instantané, sans perte, et ça règle vignettes et tailles dérivées d'un coup. Si les dimensions sont aussi inversées en base (largeur > hauteur sur un portrait), corrige width/height dans la même requête.

En espérant alimenter ta réflexion.
Tu peux m'envoyer la photo ?

Dernière modification par Charles69 (2026-07-24 15:04:23)

Bonjour polowigo,

J'ai testé avec exiftool

Tourner de 90° anti-horaire
exiftool -overwrite_original -Orientation#=8 photo.jpg

Mettre IFD1 (miniature embarquée) en conformité avec IFD0 (l'image)
exiftool -overwrite_original "-IFD1:Orientation<IFD0:Orientation" photo.jpg

Afficher les deux orientations
exiftool -G1 -a -s -Orientation photo.jpg
affiche
[IFD0]          Orientation                     : Rotate 270 CW
[IFD1]          Orientation                     : Rotate 270 CW

Si tu essaies de faire les deux opérations en une seule fois (exiftool -overwrite_original -Orientation#=8 "-IFD1:Orientation<IFD0:Orientation" photo.jpg) , ça ne fonctionne pas  !! l'image est bien tournée mais l'orientation de la miniature n'est pas modifiée.

Dernière modification par Charles69 (2026-07-25 11:32:56)

Au final, j'adopte la solution exiftool qui est simple à comprendre et facile à mettre en œuvre dans un script avec le code obtenu par Charles pour une rotation de 90° dans le sens antihoraore :

exiftool -Orientation#=8 mon-image.jpg
exiftool -overwrite_original -Orientation#=8 "-IFD1:Orientation<IFD0:Orientation" mon-image.jpg

Merci à vous trois pour votre aide.  :-)

Oui mais je suis encore loin d'un script car, bien sûr, j'ai pivoté l'appareil dans les deux sens, désolation que je suis.
Je ne vois que le tri visuel en deux classes : sens direct et sens inverse, c'est toujours mieux que rien.