Récupérer la date de numérisation d'un fichier jpeg

Version imprimable

30/10/2013, 18h59
tintinux

Récupérer la date de numérisation d'un fichier jpeg

Bonjour

Est-ce que quelqu'un saurait comment récupérer efficacement la date de numérisation d'un fichier .jpg avec un programme Lazarus, et sous Linux.

C'est une propriété exif qu'on peut récupérer facilement par script avec diverses commandes, mais je voudrais éviter la solution bestiale de lancer une commande externe pour chaque fichier et d'en décoder la sortie.

J'ai essayé de chercher dans les sources de LazPaint, mais je n'ai pas trouvé...

Merci pour vos tuyaux.
30/10/2013, 19h12
Invité

Bonsoir,

Pourtant la solution bestiale* :aie: est à mon avis la plus simple. Sous Debian (Ubuntu ?) je dirais : exiftran -d monfichier.jpg avec lequel on peut faire pleins d'autres choses que le dump d'exif.
*C'est simplement l'utilisation de librairies : tout OS en utilise un nombre faramineux...

Enfin chacun son approche : Sur ma Squeeze, j'ai dû l'installer : apt-get install exiftran [dépôts officiels de Debian]. Autant que je me souvienne, il fonctionne totalement en ligne de commande. Mais mes essais datent un peu :?.

Si c'est pour un usage personnel, à priori, il ne semble pas difficile de piloter à partir du code du programme par un process...

Si c'est pour diffuser, d'abord il faut savoir si dans les déclinaisons rpm, cela existe sous ce nom. Je ne pratique pas. Pour les deb, il faut inclure la dépendance dans votre paquet d'installation.

Evidemment cela ne répond pas à votre question... mais vous avez demandé "facilement"...

Bonne soirée.
Cordialement. Gilles
30/10/2013, 21h12
tourlourou

Quelques pistes ici, peut-être.
31/10/2013, 08h52
tintinux

Bonjour,

Citation:

Envoyé par Selzig

Evidemment cela ne répond pas à votre question...

C'est exact !

Citation:

Envoyé par Tourlourou

Quelques pistes ici, peut-être

Merci pour le lien, j'avais tendance à oublier Delphi ces derniers temps.
J'ai essayé rapidement dyExif, mais tel quel il ne compile pas sous Lazarus car il contient notamment un uses Windows. Peut-être n'est-ce pas trop difficile à porter.

Je n'ai plus le temps de regarder ça, ni d'essayer les autres solutions, cela viendra peut-être.

Pour l'instant la solution bestiale fonctionne.
31/10/2013, 10h12
Invité

Citation:

Envoyé par tintinux

Bonjour,
J'ai essayé rapidement dyExif, mais tel quel il ne compile pas sous Lazarus car il contient notamment un uses Windows. Peut-être n'est-ce pas trop difficile à porter.
Pour l'instant la solution bestiale fonctionne.

Donc... retour aux réalités... Au moins pour la facilité et également pour la productivité. Finalement l'autre approche n'est pas si "inexacte" que cela. :mrgreen:... et je peux l'argumenter assez facilement. C'est un forum et suggérer que d'utiliser des commandes externes est une solution inférieure est d'une part une erreur, d'autre part un non-sens et enfin, à mon avis, uniquement un choix personnel... choix que je ne conteste absolument pas... mais qu'il ne faut pas présenter comme une évidence pour cause d'infériorité.

C'est le mot "bestial" qui m'a fait réagir. Intrinsèquement, il est mal choisi. Je rappelle quand même que l'énorme faiblesse de Lazarus (à mon avis) c'est justement, qu'hormis fpGUI qui n'est pas abouti, il utilise tous les widgets natifs avec plus ou moins de bonheur et surtout de "mise au point et de suivi" (ie ceux des OS qui évoluent tellement rapidement qu'il faut -faudrait- des moyens pour suivre...). Ce n'est pas bestial... mais c'est très compliqué... Ma dernière tentative a été les TRichMemo en Win32 [OK d'origine], Win64 [non fonctionnel], Nux32[OK d'origine] et Nux64 [ininstallable]. J'en suis venu à bout au bout d'une cinquantaine d'heures pour m'apercevoir qu'aucun éditeur d'état ne pouvait actuellement les imprimer ! Entretemps, j'ai "regardé" une fonction RTF<->HTML... En prenant appui d'ailleurs sur le forum Delphi, je crois.

Comme je pratique désormais régulièrement C++/QT -disons en phase d'apprentissage intensif-, je vois une ENORME différence surtout en productivité... Pour info, j'ai tenté Lazarus avec QT... Déjà l'installation Win/Nux est "coton". Hormis le fait que le code est défiguré pour s'adapter à QT, QT est totalement brimé dans son utilisation.... Evidemment le langage Pascal est toujours fabuleux... mais c'est incroyable le nombre de librairies disponibles en C++ et directement intégrables dans un programme pouvant les utiliser, ce qui n'est pas le cas de Lazarus qui ne comprend pas les entêtes C++...

Tout cela pour dire qu'en Lazarus, quand je peux faire appel à une bibliothèque externe dans l'OS natif qui répond à mes exigences, "bestialement" je l'utilise, comme vous devez utiliser les librairies d'accès aux bases de données par exemple... L'énorme avantage, c'est que tout le reste du code est semblable et reste du Pascal... Il suffit de différencier les librairies utilisées pour chaque OS... Cela ne diminue en rien la qualité du code et permet de se consacrer -comme vous dites- "à porter" les éléments non réellement multi-OS mais nécessaires si on veut développer dans cette configuration.

Bonne journée.
Cordialement. Gilles

Yep !

Citation:

Envoyé par tintinux

J'ai essayé rapidement dyExif, mais tel quel il ne compile pas sous Lazarus car il contient notamment un uses Windows. Peut-être n'est-ce pas trop difficile à porter.

Trois choses à faire et ça compile, mais je n'ai pas de projet pour tester...
- 1
Code:

1 2 3 4 5 6 uses // JPEG unit has been merged into ImagesForLazarus package. // Add ImagesForLazarus as your project's dependency (Project Options->New Requirement) // and change JPEG in uses clause to LazJPG. // http://community.freepascal.org/bboards/message?message_id=336739&forum_id=24083 Classes, {Windows,} SysUtils, Math, dialogs, Graphics {, Jpeg}, LazJPG;
- 2, lignes 320-335
Code:

1 2 3 4 5 6 7 8 9 // inverse les octets d'un cardinal si Big_Endian function Swap32_si_Moto(C : Cardinal) : Cardinal; var S : Cardinal; begin // http://wiki.freepascal.org/Lazarus_Inline_Assembler/fr //This is required with Lazarus on x86: {$ASMMODE intel} asm
à ajouter également dans la fonction qui est juste sous celle que je cite.

- et 3, lignes 520-525
Code:

1 2 3 4 5 6 7 8 else begin SetLength(TmpStr, Ln); Card := Swap32_Si_Moto(Value); // http://forum.lazarus.freepascal.org/index.php?topic=18653.0 // CopyMemory(@TmpStr[1], @Card, Ln); Move(TmpStr[1], Card, Ln); StrInd := EXIF_Data.Str.Add(TmpStr); end;
Note : c'est le .pas récupéré chez Phidels dans le projet Photoscd.

Enjoy 8-)

01/11/2013, 00h34
Jipété
:calim2:

Mauvaise nouvelle, ce soir :

J'ai compilé le projet PhotosCD en D7 dans mon w2k virtualisé, et ma foi, du peu que j'en ai vu, ça a l'air de fonctionner, tout au moins pour ce qui nous intéresse, à savoir récupérer les infos d'horodatage Exif incluses dans un fichier Jpeg.
Sous w2k j'en ai vu (bien qu'un Readme dise que le prog est développé pour XP, mais j'avais viré XPMan dans le "uses" et la compil a roulé).

Suis ensuite repassé sous Debian pour aller fouiller dans le dossier Laz.../components/images/example, y ai lu le Readme et n'y ai pas compris grand chose (plus à jour... :roll:), ai vraiment bataillé pour faire compiler cet exemple de la distrib officielle (quelle misère...) mais y suis arrivé et j'ai pu lui faire ouvrir des jpg, avec et sans données Exif.
Bien.

Enfin, j'ai rajouté à ce projet d'exemple le fichier dyexif.pas modifié comme indiqué cet aprème, l'ai déclaré, l'ai compilé et ça a foiré !
L'erreur est sur la ligne 1350 :
Code:

1 2 3 // if not(FileExists(DestFile)) or DeleteFile(PChar(DestFile)) then begin // à remplacer par if not(FileExists(DestFile)) or DeleteFile(DestFile) then begin
Je n'ai pas eu cette erreur cet aprème, peut-être parce que la procédure qui inclue cette ligne n'était pas invoquée ?
Bref, comme indiqué ci-dessus ça compile.

Je fouille le projet de Phidels et je trouve quelques lignes intéressantes pour faire afficher une date d'une image chargée, j'implémente dans mon projet d'exemple, je compile, j'exécute, et...
ça crashe à l'appel de cette fonction dans dyexif.pas :
Code:

1 2 // fonction de décodage des données EXIF ; retourne un code d'erreur function GetExifInfos(var Source_Stream : TMemoryStream ; var EXIF_Data : TEXIF_Data ; var ErrorCode : integer) : Boolean;
:aie:

À l'heure où j'écris je n'ai pas encore fouillé, pas trop le courage... :cry:
01/11/2013, 09h19
tourlourou

Mince ! J'étais presque sûr d'avoir traduit le truc pour Lazarus, mais je ne remets pas la main dessus... C'était pê seulement pour le décodage JPEG.

Sinon, il existe de très jolies fonctions Built-In pour l'endianité, en Lazarus.

Je vais pê regarder ça rapidement.
01/11/2013, 09h27
tintinux

Bonjour,

Citation:

Envoyé par tourlourou

J'étais presque sûr d'avoir traduit le truc pour Lazarus

En partant de ton source qui ne compilait pas, j'ai fait des corrections qui m'ont permis de compiler et d'exécuter sous Lazarus-Linux-i386, au moins pour ce que je voulais faire, lire la date de cliché.

Mais j'ai des fichiers qui ont apparemment des data jfif et non exif et, là, il ne me semble pas que ce soit prévu, ou je ne sais pas comment faire... J'ai donc provisoirement abandonné la piste.
01/11/2013, 09h42
tintinux

Citation:

Envoyé par Jipété

J'ai compilé le projet PhotosCD en D7 dans mon w2k virtualisé

Merci pour ton aide, mais tu ne nous as pas dit ou tu avais trouvé le source.

Il a l'air, d'après les corrections que tu proposes, un peu différent de celui de Tourlourou. Je suppose que c'en est un fork, mais c'est embêtant qu'il possède exactement le même nom.

Si ça lit aussi le JFIF, ça peut m'intéresser, mais je ne peut pas le vérifier pour l'instant.

J'ai aussi regardé ccr-exif qui a l'air, excusez moi les gars, plus vivant et plus riche. Mais il ne compile pas non plus sous Lazarus. Si tu as du temps, il me semblerait plus utile d'essayer de porter celui-ci.
01/11/2013, 10h37
Jipété

Citation:

Envoyé par tintinux

Merci pour ton aide, mais tu ne nous as pas dit ou tu avais trouvé le source.

Si si :P :

Citation:

Envoyé par Jipété

Note : c'est le .pas récupéré chez Phidels dans le projet Photoscd.
01/11/2013, 10h52
tintinux

Citation:

Envoyé par Jipété

Si si :P :
Citation:
Envoyé par Jipété http://www.developpez.net/forums/ima...s/viewpost.gif
Note : c'est le .pas récupéré chez Phidels dans le projet Photoscd.

Mais ça ne me dit pas où se trouve ce projet.

Sur Phidels je ne vois que le source de Tourlourou et pas de projet Photoscd. Le source dont tu proposes la correction est apparemment différent.

Citation:

Envoyé par tintinux

Mais ça ne me dit pas où se trouve ce projet.

Sur Phidels je ne vois que le source de Tourlourou et pas de projet Photoscd. Le source dont tu proposes la correction est apparemment différent.

Là.

J'ai également récupéré le source de Tourlourou, qui incorpore des fonctions supplémentaires, mais qui crashe de la même manière :aie:

Yves, j'ai truffé la fonction citée de "ShowMessage", et voilà ce que je peux en dire :
Code:

1 2 3 4 5 6 7 8 9 10 for IF_Nb := IFD0 to IFD1 do with EXIF_Data.IFD[IF_Nb], EXIF_Data do begin // détermination de la position PositionFound := False; case IF_Nb of ... end; // case showmessage('calcul'); // vu 2 ou 3 fois puis crash -- hé oui, c'est aléatoire // le calcul suivant est permis grâce à l'existence d'IFD[0] !!! ...
J'ai dit que j'avais truffé de "ShowMessage" : ce qui est curieux, c'est que certains s'affichent avec le texte que j'y ai mis, et d'autres s'affichent sans texte !
Va comprendre.
Et ce sont de bêtes strings sans accents, sans calculs, sans rien d'autre qu'une string :koi:

Citation:

Envoyé par tourlourou

Quelques pistes ici, peut-être.

Je suis aussi parti de la source postée par l'OP où il disait que ça lui affichait systématiquement "non trouvé" et qu'il avait corrigée, là, et moi aussi j'ai systématiquement "non trouvé", avant et après correction, avec des photos prises avec un Canon 450D 8O
[EDIT] Fallait rajouter un swap avant le test, pour le passer !
Code:

1 2 3 4 5 ... AStream.ReadBuffer(Mot, 2); Mot:=Swap(Mot); // <--- nécessaire sinon Mot = D8FF ! if Mot<>$FFD8 then Exit; // pas JPEG ...
Et maintenant ça crashe avec un "Stream read error"...
Compliqué tout ça [/EDIT]

Bonjour,

J'ai passé une partie du week-end à farfouiller le web, et à jouer avec mon Lazarus.

Citation:

Envoyé par tintinux

(...) Est-ce que quelqu'un saurait comment récupérer efficacement la date de numérisation d'un fichier .jpg avec un programme Lazarus, et sous Linux.

C'est une propriété exif qu'on peut récupérer facilement par script avec diverses commandes, mais je voudrais éviter la solution bestiale de lancer une commande externe pour chaque fichier et d'en décoder la sortie. (...)

Il apparait que "efficacement" et "facilement" ne sont pas en adéquation avec les fichiers JPEG, si l'on veut un programme universel :

Citation:

Certains fichiers JPEG contiennent seulement un bloc JFIF, d'autres contiennent seulement un bloc EXIF, et d'autres contiennent un bloc JFIF et un bloc EXIF.

Source

Donc tout dépend du fichier et de la manière dont il a été généré (appareil photo, scanner, logiciel de retouche, etc.).

Si je prends mon cas particulier et l'appareil avec lequel je joue en ce moment, le Canon 450D de mon fils, plus les fichiers que l'on peut trouver ici (non installés, juste ajoutés au projet) et à condition de corriger une fonction (voir + bas), j'ai pu monter un petit prog de test qui me récupère très facilement la demande originale : une form, un mémo (nommé memo) et en avant :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 implementation {$R *.lfm} uses dEXIF; { TForm1 } procedure TForm1.FormCreate(Sender: TObject); var p, f: ansistring; sl: TStringList; i: integer; ImgData: TImgData; begin p := ExtractFilePath(Application.ExeName); // '/' inclus à la fin f := p + 'IMG_4809.JPG'; // mon fichier d'étude ImgData := TImgData.Create; if ImgData.ProcessFile(f) then begin sl := TStringList.Create; memo.Lines.Add('Processing...'); with ImgData do begin //if HasComment then memo.Lines.Add(' HasComment'); // pas vu //if HasIPTC then memo.Lines.Add(' HasIPTC'); // pas vu if HasEXIF then memo.Lines.Add(' HasEXIF'); if HasMetaData then memo.Lines.Add(' HasMetaData'); if HasThumbnail then memo.Lines.Add(' HasThumbnail'); if ReadExifInfo(f) then memo.Lines.Add(' HasMetaData from ReadExifInfo'); sl := ImgData.ExifObj.EXIFArrayToXML; //ok sl.SaveToFile(p + 'sltext.txt'); for i := 0 to sl.Count-1 do memo.Lines.Add(UTF8ToAnsi(sl.Strings[i])); // ! U2A sinon memo vide // et voilà, tout ce qui précède c'est pour découvrir le bazar et peut être viré. // ! CreateDate is called DateTimeDigitized by the EXIF spec. // DateTimeOriginal ne change pas de nom, ouf ! :-) for i := 0 to sl.Count-1 do if sl.Strings[i] = ' <DateTimeOriginal>' then ShowMessage('DateTimeOriginal: ' + sl.Strings[i+1]); end; sl.Free; end; ImgData.Free; end;
Le code à corriger dans dEXIF.pas :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 function TImgData.ProcessFile( const aFileName :ansistring):boolean; var extn:ansistring; begin reset; result := false; if not FileExists(aFileName) then // rajouter "a" exit; SetFileInfo(aFileName); // rajouter "a" try errstr := 'Not an EXIF file'; extn := AnsiString(AnsiLowerCase(ExtractFileExt(aFileName))); // rajouter "a" if (extn = '.jpg') or (extn = '.jpeg') or (extn = '.jpe') then begin if not ReadJpegFile(aFileName) then // rajouter "a" exit; end else if (extn = '.tif') or (extn = '.tiff') or (extn = '.nef') then begin if not ReadTiffFile(aFileName) then // rajouter "a" exit; end else begin exit; end; errstr := '<none>'; // msAvailable := ReadMSData(Imageinfo); // msName := gblUCMaker; result := true; except errstr := 'Illegal Exif construction'; end; end;
Pour ceux qui veulent creuser (changements de noms, sous-clés, etc.), voir ici.

Valà,

08/11/2013, 01h04
Jipété

Yop !

Je remonte un peu ce sujet, un truc m'ayant titillé les neurones :

Citation:

Envoyé par tintinux

(...) Mais j'ai des fichiers qui ont apparemment des data jfif et non exif et, là, il ne me semble pas que ce soit prévu, ou je ne sais pas comment faire... J'ai donc provisoirement abandonné la piste.

D'après Wikipedia, il semblerait que les fichiers jfif n'incorporent pas d'informations d'horodatage, ou en tout cas, ça n'est pas noté dans les tableaux de leur page, et pas plus dans le pdf récupérable à la référence 3, tout en bas...
J'ai récupéré un sample d'un fichier pur jfif et l'ai analysé avec l'excellentissime exiftool (c'est à tomber par terre tout ce que ce truc remonte d'un jpeg-exif) --> pas de date.

Du coup, chez Torry on peut trouver un texif v1.3 avec une ch'tite démo qui n'a besoin que de la ligne {$ASMMODE intel} dans son unique petite unité (rien à voir avec l'usine CCR :mrgreen:) pour compiler et récupérer la date d'un jpeg-exif. :ccool:

Enjoy,
08/11/2013, 08h13
tintinux

Bonjour

Citation:

Envoyé par Moi

j'ai des fichiers qui ont apparemment des data jfif et non exif

Je pense que tu as donné la réponse :

Citation:

Envoyé par Jipété

Certains fichiers JPEG contiennent seulement un bloc JFIF, d'autres contiennent seulement un bloc EXIF, et d'autres contiennent un bloc JFIF et un bloc EXIF.

Je n'ai plus les fichiers sous la main, ni le temps de reprendre ce sujet à fond, mais je me rappelle que les outils linux en mode ligne trouvaient bien la date de cliché dudit fichier. L'utilitaire dyExif ne la trouvait pas.

Il est probable que le bloc EXIF suivait le bloc JFIF dans ce cas là, et que c'est ça qui posait problème.
09/11/2013, 11h13
tourlourou

Citation:

Il est probable que le bloc EXIF suivait le bloc JFIF dans ce cas là, et que c'est ça qui posait problème.

Effectivement. La norme Exif 2.3 prévoit que le marqueur EXIF suive immédiatement le marqueur JPEG, alors que s'intercale parfois un marqueur JFIF (exemple : cliché avec données EXIF réorienté par la visionneuse Windows).

Cela sera traité dans l'évolution du code.

Yop !

Citation:

Envoyé par tourlourou

Effectivement. La norme Exif 2.3 prévoit que le marqueur EXIF suive immédiatement le marqueur JPEG, alors que s'intercale parfois un marqueur JFIF (exemple : cliché avec données EXIF réorienté par la visionneuse Windows).

Cela sera traité dans l'évolution du code.

Si cela peut aider, voici ce que j'ai trouvé au début de la (bien nommée) procédure ReadFromFile du projet texif dont je parlais hier :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 . . . BlockRead(f,SOI,2); if SOI=$D8FF then begin //Is this Jpeg BlockRead(f,j,9); if j.Marker=$E0FF then begin //JFIF Marker Found Seek(f,20); //Skip JFIF Header BlockRead(f,j,9); end; //Search Exif start marker; if j.Marker<>$E1FF then begin . . .
Le micro-souci de ce micro-projet, c'est qu'il y a des petites erreurs de parsing des données (entre autres les infos du flash, déjà corrigées par votre serviteur ;), qui passe son temps le nez dans les infos d'exiftool, remarquables !)