Discussion :

[tintinux]

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.

[Invité]

Bonsoir,

Pourtant la solution bestiale* 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

[tourlourou]

Quelques pistes ici, peut-être.

[tintinux]

Bonjour,

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

C'est exact !

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.

[Invité]

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. ... 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

[Jipété]

Yep !

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[Jipété]

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... ), 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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;

À l'heure où j'écris je n'ai pas encore fouillé, pas trop le courage...

[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.

[tintinux]

Bonjour,

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.

[tintinux]

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.

[Jipété]

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

Si si :

Note : c'est le .pas récupéré chez Phidels dans le projet Photoscd.

[tintinux]

Si si :
Citation:
Envoyé par Jipété
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.

[Jipété]

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

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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
[EDIT] Fallait rajouter un swap avant le test, pour le passer !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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]

[Jipété]

Bonjour,

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

(...) 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 :

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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à,

[Jipété]

Yop !

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

(...) 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 ) pour compiler et récupérer la date d'un jpeg-exif.

Enjoy,

[tintinux]

Bonjour

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

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

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.

[tourlourou]

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.

[Jipété]

Yop !

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 !)