Résolu importer descriptions IPTC dans fichiers jpg à partir d'un CSV

Dans GC tu vas dans l'onglet exiftool et tu descends jusqu'à IPTC tu devrais trouver ton commentaire.
Pas de problème pour voir une de tes images si necessaire .

Tu as raison, on peut aussi le trouver là en cherchant bien, ce n'est pas tout à fait à la fin d'ailleurs, si on observe l'ascenseur.
Mais c'est plus simple avec pomme-i tout de même.
Capture d’écran 2017-01-15 à 11.20.03.webp

Bon, mais malgré tout, les images que j'ai traitées par GC n'ont pas fait migrer leur commentaire vers IPTC, que je regarde dans l'onglet EXIF tools, ou dans pomme i de GC ou d'aperçu, ou que je les uploade sur flickr, ça reste vide. Alors que les ajouts de légendes IPTC fais manuellement dans GC ou Bridge, ça passe.
Donc on n'est pas loin de la solution, tout de même.
 
Dans ta copie d'écran: l'action que je fait, tu choisis bien "Copier le commentaire spotlight dans le champ IPTC légende"
Et la vérification dans l'onglet EXIFTOOL donne quoi ?
Oui oui, le premier de la liste (je ne sais pas pourquoi, 2 fois je fais la capture, à chaque coup le surlignement disparait dans la dernière colonne).
 
Non le premier de la liste ne correspond pas à Copier le commentaire SPOTLIGHT , c'est le treizième de la liste LOL.
 
Bon là on m'attend pour l'apéro .... :D :) mais cela va fonctionner .... allez courage ! ! ! MDR
 
Non le premier de la liste ne correspond pas à Copier le commentaire SPOTLIGHT , c'est le treizième de la liste LOL.


Oh nom de…

Ah désolé, j'étais à côté de la plaque.

Je n'avais pas vu qu'il y en avait un autre aussi similaire !

Bon apéro et merci merci !
 
Et ça marche cette fois ci.
J'illustre pour les comme-moi qui loupent des mots dans leur tête. Une image vaut les mille mots qu'on vient de s'échanger pour comprendre mon erreur.

Capture d’écran 2017-01-15 à 11.12.24.webp
 
Bonjour,

Alors il s'avère qu'il y a un problème avec cette manière de procéder (fichier txt -> commentaire spotlight -> GC -> description IPTC)
En effet, j'ai constaté (un peu tard, malheureusement) que les voyelles accentuées sont mal encodées. Au résultat final, dans Flickr, j'obtiens des combinaisons curieuses. Genre un e accent aigü devient un e simple suivi d'un accent aigü isolé mais pas tout à fait ça quand-même. En tout cas, ce qui est certain, c'est que le résultat obtenu n'est pas très joli à l'écran et surtout ça empèche d'utiliser mes textes comme des mots-clés, alors que c'est leur but.

En effet : si j'ai le mot écran qui devient e´cran, il n'apparaît plus dans mes recherches sur le mot écran.

Pourtant, l'import de description IPTC faites à la main via Adobe Bridge n'avait pas provoqué ce genre de problème. (enfin, pour être précis, au début les voyelles accentuées passaient mal mais une fois que j'ai compris qu'il fallait attendre que le lot d'image ait fini de se télécharger sans rien toucher pour qu'elles redeviennent correcte, ça roulait). Donc on pouvait déjà supposer que le pb ne se situait pas au moment de télécharger vers flickr mais ailleurs dans la chaîne d'action.

J'ai donc fait en sorte d'être méthodique pour pouvoir identifer à quel moment se situe le problème. Voici la méthode suivie : un texte court comportant des caractères accentué (très court, le texte c'est « éà ») que je réintroduis par saisie clavier (pas par copier coller pour éviter les bugs invisibles) à chaque étape du processus.
donc le premier « éà » que je saisis dans le tableur ods/xls, puis export en txt, je saisis un 2e éà dans le fichier txt, puis je passe ça à la moulinette de l'AppleScript, je saisis un 3e « éa » dans le commentaire Spotlight via pomme-i de finder, puis je passe le tout par Graphic Converter comme indiqué plus haut, ensuite j'ajoute un 4e « éà » dans la desription IPTC, toujours via GraphicConverter, enfin j'uploade le fichier sur Flickr et j'ajoute un 5e et dernier « éà » via la page d'import de flickr.
Cette méthodologie un peu longuette (plus longue à décrire qu'à réaliser, d'ailleurs) me permet d'identifier les ruptures dans le résultat final.

Et le verdict me semble être le suivant : tout ce qui est AVANT l'action « copier les commentaires Spotlight vers la description IPTC » (de mémoire, la dénomination n'est pas forcément exacte) est corrompu, tout ce qui se situe après est correct.
Donc c'est au moment de cette action qu'il y aurait un os. J'ignore lequel.

Pour les plus balèzes en informatique et en encodage de caractères, voici les résultats en images, peut-être que la façon dont les caractères sont affichés vous permettrai de définir ce qui pose souci.

Affichage dans la page d'import de Flickr (au moment de la capture je n'ai pas encore saisi la 5e variante du « éà »). Il est intéressant d'ailleurs de constater que l'affichage est différent à gauche, sur le résumé, d'à droite, dans le champ de saisie que j'ai sélectionné pour l'occasion (il se remplit bien tout seul mais là je l'avais ouvert pour copier le texte obtenu). Notez que cet affichage est celui obtenu AVANT que le téléchargement ne soit terminé. Il est intéressant justement car je pense qu'il montre un peu « l'arrière cuisine » des caractères spéciaux (comme j'expliquais plus haut, une fois le téléchargement terminé, les caractères « bizarres » redeviennent en principe corrects).
éà FlickrImport.webp

(par ailleurs, voici un copier-coller du texte apparu dans le champ de saisie, il donne le même résultat que dans la version « à gauche » sur la capture ci-dessus).

Bloc de code:
(1eÌaÌ) (2eÌaÌ) (3eÌaÌ) (4éà ) â SAISIE (1 : LibreOff avt export csv/txt/europeOccApple) (2 fichier txt) (3 finder info) (4 comm IPTC viaGC)


Et voici le résultat final dans flickr, l'affichage que voient les utilisateurs, le résultat final. C'est assez sibtil mais regardez bien les 3 premiers, on distingue de l'espace après le é et après le à et un décalage des accents, chose qu'on ne voit pas dans les 2 derniers qui sont « corrects ».

éà FlickrFinal.webp

et malheureusement, je n'arrive pas à filtrer ces mauvais caractères via l'outil recherche de flickr (pour pouvoir tous les retrouver et les corriger) et je ne parviens pas non plus à les rechercher-remplacer avec le néanmoins excellent « FoxReplace ».

Donc je pense que je vais être bon pour refaire à zéro tous mes derniers albums mis en ligne.


J'étais tellement content de cette méthode qui paraissait si simple, c'est rageant.


Du coup, si la méthode que j'utilisais avec GC pose ce problème, ça ne va pas me convenir.
Auriez-vous une idée pour tenter de passer directement du fichier txt (ou un csv si ça passe mieux) vers la description IPTC avec un script sans passer par commentaire spotlight + GC ?
Ou une idée de réglage à trouver dans GC pour contourner ce problème là ?

L'image en question est ici https://www.flickr.com/photos/128004560@N07/33210240355/in/dateposted-ff/
on peut voir aussi cette première tentative https://www.flickr.com/photos/128004560@N07/32395181063/in/dateposted-ff/ que j'avais interrompue en cours de route (j'avais cliqué dans le champ de commentaires pour en faire la capture d'écran ci-dessus) et pour laquelle les caractères ne se sont donc pas semi auto-corrigés.
 
Coucou, me revoilà !
Je viens de voir ton problème !
Alors il suffit d'enregistrer ton fichier texte avec textedit au format occidental (Mac OS Roman)

De plus j'ai trouvé comment mettre directement le commentaire dans le champs légende de IPTC (toujours en passant par GraphicConverter) mais sans intervention manuelle.
Voilà le script modifié.
Tiens moi au courant si cela fonctionne avec le nouveau format .

tell application "Finder"
set ledossier to choose folder with prompt "Sélectionnez le dossier images" --Choix du dossier images
set CheminTXT to choose file with prompt "Sélectionnez le fichier texte" --Choix du fichier texte

set ledossier to ledossier as string

-- traitement du fichier texte
open for access CheminTXT
read CheminTXT
set le_texte to the result -- récupère le fichier dans la variable
close access CheminTXT

set AppleScript's text item delimiters to (ASCII character 9)

set NBtab to (count of text item of le_texte) -- compte le nombre de tabulation trouvé

set chemindef to ((path to desktop folder as text) & "Log erreur.txt") as text --crée le fichier log erreur

repeat with i from 1 to NBtab - 1
set laligne to paragraph i of le_texte as string -- récupère la ligne i
set image to text item 1 of laligne as string --récupère le nom de l'image
set commentaire to text item 2 of laligne as string --récupère le commentaire
set chemin to ledossier & image as string

if exists file chemin then
set chemin to chemin as alias
tell application "GraphicConverter 10"
set lalistiptc to get file iptc chemin
set item 1 of lalistiptc to commentaire
set file iptc of chemin to lalistiptc
end tell

--set comment of chemin to commentaire -- écrit le commentaire dans commentaire finder
else
try
set lefichier to open for access chemindef with write permission
write "fichier " & image & " pas trouvé" & return to lefichier starting at eof
close access lefichier
end try
end if

end repeat
end tell

tell application "Finder"
display dialog "Ok j'ai terminé"
end tell
 
  • J’aime
Réactions: baron et ccciolll
En fonction du résultat, on peut envisager une autre solution sans graphicConverter en passant par exiftool.

Mais il y a tellement de champs de données gérer par exiftool que je ne sais pas lequel doit être utilisé pour ton besoin.
 
Zeltron54, je pense que tu tiens la bonne solution, ce coup ci.
Ça a vraiment l'air de marcher.
Faudra que je re-teste plus massivement dans la semaine.
 
content pour toi !
J' attends avec impatience le résultat définitif.
bon test!
 
Il restera néanmoins un truc qui me laissera perplexe : pourquoi ça passe quand tu le fais dans GC via un appleScript mais pas quand on le fait à la mimine.
Dans les 2 cas, GC reste GC.
 
Non, je pense que le problème des accents est résolu par l'encodage du fichier en mac os roman par textedit.
Le fait de l'envoyer directement ne doit pas jouer car dans GC il est marqué comme UTF8.

j'avais commencer à tester exiftool , mais comme je ne connaît pas .... je découvre ce logiciel et c'est laborieux vu que l'anglais et moi on est pas trop copain !
Enfin si cela fonctionne avec GC c'est très bien. j'attends la fin de tes tests.
 
Autre analyse - lorsque je met direct dans le champ IPTC, je ne passe pas par le champ commentaire (visible sous finder Mac OS), je suppose que ce champ doit être interprété par graphicConverter comme venant d'un encodage Mac et il doit le réencoder pour le transféré dans le champ IPTC avec la commande "copier les commentaires spotlight...".
 
Je pencherai pour ta deuxième analyse car j'avais fait des tests poussés à chaque étape et ion y constatait bien un basculement de toutes les sources au moment du passage par GC.
 
Je confirme que non seulement ton nouveau script fonctionne du tonnerre, mais MIEUX, il écrase les anciennes données IPTC présentes sur les fichiers. Du coup, ça va être facile de corriger ceux qui ont été corrompus lors de mes précédents imports.
 
OK ! content pour toi !
 
ahah, moi aussi je suis content pour moi. Merci !
 
Bonjour, je cherche une solution qui ressemble à celle que je lis dans ces échanges.
Enfin pour une partie.
J'aimerai attribuer un code IPTC unique à chaque photo importée dans lightroom.
Soit le code devrait être généré par un plugin dans lightroom, soit il serait intégré depuis un fichier de données exterieur, tableur, qui lui aurait été généré .. je ne sais pas encore comment, et contiendrait par exemple 10000 codes uniques et non sequentiels qui serait utilisés les uns après les autres dès qu'une photo serait ajoutée dans lightroom.
Au final, chaque photo doit se voir attribuer un code d'identification unique.
Ca parle à quelqu'un ?
Je ne suis pas développeur mais photographe.
Merci de vos idées, solution, commentaires !