Discussion :

[BeanzMaster]

Salut Jipete,

Je viens de commencer à ajouter le support du format GIF à mon projet. Pour l'instant je ne lit que les en-têtes. Au vue de mes premiers tests sur les images GIF de notre "Test Suite" seulement 2 images ont des en-têtes erronées :



Comme tu le voir il manque le "G" de GIF. Sous un éditeur Hexa on peux voir que celui-ci est un caractère NULL



Dans celui-là il n'y a pas de "Graphic Control Extension" valide

Le reste est tout bon. J'ai également pu determiner que nous avons donc que 2 fichiers au format 87a (a_anime.gif et le petit papillon jaune)

En gros ce qui veux dire c'est que dans les solutions que nous avons vu FPReadGIF, TGIfAnim, la solution espagnole. Le problème vient de la lecture de ces "GCE" et je suis presque sure qu'il y a des erreurs lors de la decompression LZW surtout que d'après ce que j'ai pu lire un GIF peux aussi être compressé en RLE

Bref, maintenant j'essaye de déterminer le nombre de frame en parcourant tout le fichier et en séparant ces "GCE" et lire les infos qu'il y a dedans. Je n'arrive pas encore à obtenir les bons nombres, j'ai un truc qui ne joue pas dans mes boucles. Je continuerai à chercher demain. Et je m'attaquerai par la suite à l'extraction des données pour l'affichage.

Sinon une unité que l'on a oublié dans le lot c'est GraphicEx qui prend également en charge les GIF, mais moins bien que TGIFImage dans mes souvenirs.

A+

[Jipété]

Yep, Jérome !

Pour le premier, en mettant un "G" à la place du byte vide, on ne va pas bien loin mais ça permet d'avoir un fichier pour tester la compression :

Dans celui-là il n'y a pas de "Graphic Control Extension" valide

(Note : c'est un message à toi ? un "bloque" ça n'existe pas, en français c'est "bloc"), ce fichier (que j'avais d'ailleurs renommé ".nogif") est tellement vide qu'on lui filerait une pièce, le pauvre !


Tiens d'ailleurs je voulais te poser la question : ils sortent d'où, ces fichiers ?

Le reste est tout bon. J'ai également pu déterminer que nous avons donc que 2 fichiers au format 87a (a_anime.gif et le petit papillon jaune)

Attention ! a_anime.gif --> a_image.gif !

Le reste est tout bon. ?

Le petit papillon jaune aussi c'est tout bon ?
Chez moi, juste avec ça :

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
uses
  fpreadgif,
  //myfpreadgif,
  fpimage;
 
procedure TForm1.btnBrowseClick(Sender: TObject);
var
  image:  TFPCustomImage;
  reader: TFPCustomImageReader;
begin
  if not od.Execute then exit; // opendialog
  Image  := TFPMemoryImage.Create(10, 10);
  Reader := TFPReaderGIF.Create;
  //Reader := TmyFPReaderGIF.Create;
  Image.LoadFromFile(od.FileName, Reader); 
  imgDisplay.Picture.Assign(image); // TImage pour voir : a_image.gif magnifique
  Reader.Free; Image.Free;
end;

le programme tourne en boucle sans trouver la sortie, et ça se passe (mal !) dans function TFPReaderGif.ReadScanLine(Stream: TStream): Boolean; :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
    // search end of compressor table
    OldPos:=Stream.Position;
    PackedSize := 0;
    Repeat
      Stream.read(B, 1);
      if B > 0 then
      begin
        inc(PackedSize, B);
        Stream.Seek(B, soFromCurrent);
        CodeMask := (1 shl CodeSize) - 1;
      end;
    until B = 0;

Il tourne en rond dans ce repeat... until,

[...] d'après ce que j'ai pu lire un GIF peux aussi être compressé en RLE

Première nouvelle, et pas un mot dans la "bible" (lien de dl presque tout en bas de la page).
Par contre il existe un gif sans compression sur le wiki in english, prévois un bon dictionnaire et de l'aspirine,

Bref, maintenant j'essaye de déterminer le nombre de frame en parcourant tout le fichier et en séparant ces "GCE" et lire les infos qu'il y a dedans. Je n'arrive pas encore à obtenir les bons nombres, j'ai un truc qui ne joue pas dans mes boucles. Je continuerai à chercher demain. Et je m'attaquerai par la suite à l'extraction des données pour l'affichage.

Bon courage !
Tiens, si ça peut t'aider, je me suis bricolé 1 gif89 et 3 87 (juste la couleur qui change) ultra petits, sans animation, juste pour repérer les différences (le 89 et le 1^er 87 dessous ont la même couleur) :

4_petits_gif.zip

Sinon une unité que l'on a oublié dans le lot c'est GraphicEx qui prend également en charge les GIF, mais moins bien que TGIFImage dans mes souvenirs.

Pas oubliée, juste zappée car c'est pour Windows pur et dur (déjà testée).

[Jipété]

Code :

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

1
2
3
4
5
6
7
8
9
var
  aByte: byte;
begin
  //Stream.Seek(-1, soFromEnd); // test sur file terminator
  // une manière ou l'autre de se déplacer à la fin - 1 byte du fichier, résultat identique
  Stream.Seek(Stream.Size-1, soFromBeginning); // test sur file terminator
  if Stream.Read(aByte, 1) = 59 then Exit;
  try
    Stream.Position:=0;

Le Stream est passé à cette procedure TmyFPReaderGif.InternalRead(Stream: TStream; Img: TFPCustomImage); par FPimage.

Et ce qui ne devait pas arriver arriva : j'exécute, je choisis un fichier valide et quand je mets la souris sur aByte (c'est facile, j'ai mis un point d'arrêt dessous, et j'y suis arrêté ), l'infobulle m'affiche 59, qui est bien la valeur attendue.
Mais alors, le test,





Au départ le test c'est ... <> 59 then Exit; et je ne comprenais pas pourquoi quelque chose clochait.

EDIT
Mais bon, tout va bien, juste qu'aujourd'hui le code a décidé de fonctionner à l'envers...

Au secours.

Faut faire les choses en deux temps (moi qui aime la concision, ça ne me plaît qu'à moitié, mais sinon, bonjour le piège) :

Code :

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

1
2
3
  Stream.Read(aByte, 1);
  if aByte <> 59 then Exit; // on sort si le terminator n'est pas $3B
  try

et là c'est enfin bon.
/EDIT

[DomDA91]

Bonjour,

Ho-ho! tu n'a pas les yeux en face des trous aujourd'hui !!

Code :

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

if Stream.Read(aByte, 1) = 59 then Exit;

Ce que TStream.Read renvoie c'est le NOMBRE d'octets lus et non pas l'octet lui-même.
Dans le cas présent ce ne peut être que 1 (ou 0 si erreur ou fin de fichier), la comparaison à 59 n'a pas de sens.

Bon week-end

[BeanzMaster]

Salut,

Yep, Jérome !

Tiens d'ailleurs je voulais te poser la question : ils sortent d'où, ces fichiers ?

Ils proviennent de ce site :

Bon j'ai été cherché d'autres GIF ici, la et j'ai trouvé ce projet GIFLIB (en C) ou il y a de très bonne explication sur le format GIF (en anglais malheureusement) disponible dans l'archive à télécharger

Sinon voici la nouvelle ImageTestSuite-GIF

Attention ! a_anime.gif --> a_image.gif !

Le reste est tout bon. ?

Le petit papillon jaune aussi c'est tout bon ?
Chez moi, juste avec ça :
....
le programme tourne en boucle sans trouver la sortie, et ça se passe (mal !) dans function TFPReaderGif.ReadScanLine(Stream: TStream): Boolean; :
.....
Il tourne en rond dans ce repeat... until,

Comme je te le disais pour l'instant je me suis chargé de lire que l'en-tête et les extensions par les données des images
Donc oui l'en-tête pour le papillon est bonne ainsi que les extensions.

Première nouvelle, et pas un mot dans la "bible" (lien de dl presque tout en bas de la page).
Par contre il existe un gif sans compression sur le wiki in english, prévois un bon dictionnaire et de l'aspirine,

C'est dans le TGIFImage pour Delphi que j'ai vu ça

Bon courage !
Tiens, si ça peut t'aider, je me suis bricolé 1 gif89 et 3 87 (juste la couleur qui change) ultra petits, sans animation, juste pour repérer les différences (le 89 et le 1^er 87 dessous ont la même couleur) :

Merci, ça m'a bien aidé. T'imagines lors de mes permiers essais avec ils ne passaient pas. Cela m'a permis de trouver l'erreur

Pas oubliée, juste zappée car c'est pour Windows pur et dur (déjà testée).

Oui, c'est vraie mais le code reste une très bonne référence pour la prise en charge des formats image

Bref sinon j'ai bien avancé depuis ma découverte de GIFLIB, j'ai repris mon code à zero et j'arrive à obtenir le nombre de "Frame" correctes pour pratiquement tous les fichiers.
Ils y en a quelques un qui me résistent. Car en fait le nombre de "Frame" (pas d'images, car dans un gif tu peux avoir une seule image en référence et plusieurs "GCE" qui vont permettre le contrôle de l'animation). Il me reste donc à analyser ces "GCE" + avec les "Application Extension" pour en sortir une petite formule mathématique pour calculer le nombre de "frames" exactes. Le format GIF au final c'est pas si simple

Ci-joint un log de test avec 2 GIF

Le premier me ressort bien le bon nombre de frames mais pas le deuxieme

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
[STATUS]  Read GIF Image : H:\BeanzMaster\Documents\Projets\Images Test Suite\gif\pen-anime.gif
[NOTICE]   [ 17:33:44 ] Skip Global  Color table : 768
[STATUS]  Begin Count Frame - Stream Position : 781
[STATUS]  Begin Skip Application Extension - Stream Position : 783
[STATUS]  Begin Skip Application NS Extension - Stream Position : 795
[NOTICE]   [ 17:33:44 ] Application NS Extension Loop : 0
[STATUS]  End Skip Application NS Extension - Stream Position : 800
[STATUS]  End Skip Application Extension - Stream Position : 800
[STATUS]  Begin Skip Comment Extension - Stream Position : 802
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 15
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 77
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 101
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 114
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 103
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 101
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 100
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 32
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 98
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 121
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 32
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 79
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 115
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 97
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 109
[NOTICE]   [ 17:33:44 ] Comment Extension String Size : 117
[STATUS]  End Skip Comment Extension - Stream Position : 819
[STATUS]  Begin Skip Graphic Control Extension - Stream Position : 821
[NOTICE]   [ 17:33:44 ] Graphic Control Extension Size  : 4
[STATUS]  End Skip Graphic Control Extension - Stream Position : 827
[STATUS]  Begin Skip Image Data - Stream Position : 828
[STATUS]  End Skip Image Data - Stream Position : 15396
[STATUS]  Begin Skip Graphic Control Extension - Stream Position : 15398
[NOTICE]   [ 17:33:44 ] Graphic Control Extension Size  : 4
[STATUS]  End Skip Graphic Control Extension - Stream Position : 15404
[STATUS]  Begin Skip Image Data - Stream Position : 15405
[STATUS]  End Skip Image Data - Stream Position : 15484
[STATUS]  Begin Skip Graphic Control Extension - Stream Position : 15486
[NOTICE]   [ 17:33:44 ] Graphic Control Extension Size  : 4
[STATUS]  End Skip Graphic Control Extension - Stream Position : 15492
[STATUS]  Begin Skip Image Data - Stream Position : 15493
[STATUS]  End Skip Image Data - Stream Position : 15561
[STATUS]  Begin Skip Graphic Control Extension - Stream Position : 15563
[NOTICE]   [ 17:33:44 ] Graphic Control Extension Size  : 4
[STATUS]  End Skip Graphic Control Extension - Stream Position : 15569
[STATUS]  Begin Skip Image Data - Stream Position : 15570
[STATUS]  End Skip Image Data - Stream Position : 16408
[STATUS]  Begin Skip Graphic Control Extension - Stream Position : 16410
[NOTICE]   [ 17:33:44 ] Graphic Control Extension Size  : 4
[STATUS]  End Skip Graphic Control Extension - Stream Position : 16416
[STATUS]  Begin Skip Image Data - Stream Position : 16417
[STATUS]  End Skip Image Data - Stream Position : 17172
[STATUS]  Begin Skip Graphic Control Extension - Stream Position : 17174
[NOTICE]   [ 17:33:44 ] Graphic Control Extension Size  : 4
[STATUS]  End Skip Graphic Control Extension - Stream Position : 17180
[STATUS]  Begin Skip Image Data - Stream Position : 17181
[STATUS]  End Skip Image Data - Stream Position : 18007
[STATUS]  Begin Skip Graphic Control Extension - Stream Position : 18009
[NOTICE]   [ 17:33:44 ] Graphic Control Extension Size  : 4
[STATUS]  End Skip Graphic Control Extension - Stream Position : 18015
[STATUS]  Begin Skip Image Data - Stream Position : 18016
[STATUS]  End Skip Image Data - Stream Position : 18208
[STATUS]  Begin Skip Graphic Control Extension - Stream Position : 18210
[NOTICE]   [ 17:33:44 ] Graphic Control Extension Size  : 4
[STATUS]  End Skip Graphic Control Extension - Stream Position : 18216
[STATUS]  Begin Skip Image Data - Stream Position : 18217
[STATUS]  End Skip Image Data - Stream Position : 19180
[STATUS]  Begin Skip Graphic Control Extension - Stream Position : 19182
[NOTICE]   [ 17:33:44 ] Graphic Control Extension Size  : 4
[STATUS]  End Skip Graphic Control Extension - Stream Position : 19188
[STATUS]  Begin Skip Image Data - Stream Position : 19189
[STATUS]  End Skip Image Data - Stream Position : 19430
[STATUS]  End Count Frame - Stream Position : 19431
[NOTICE]   [ 17:33:44 ] Nb Extension found : 20
[NOTICE]   [ 17:33:44 ] Nb Frame found : 9
[NOTICE]   [ 17:33:46 ] Picture.Bitmap.Size : 327x360

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
 
[STATUS]  -----------------------------------------------------
[STATUS]  Read GIF Image : H:\BeanzMaster\Documents\Projets\Images Test Suite\gif\6d939393058de0579fca1bbf10ecff25.gif
[NOTICE]   [ 17:33:50 ] Skip Global  Color table : 768
[STATUS]  Begin Count Frame - Stream Position : 781
[STATUS]  Begin Skip Application Extension - Stream Position : 783
[STATUS]  Begin Skip Application NS Extension - Stream Position : 795
[NOTICE]   [ 17:33:50 ] Application NS Extension Loop : 0
[STATUS]  End Skip Application NS Extension - Stream Position : 800
[STATUS]  End Skip Application Extension - Stream Position : 800
[STATUS]  Begin Skip Graphic Control Extension - Stream Position : 802
[NOTICE]   [ 17:33:50 ] Graphic Control Extension Size  : 4
[STATUS]  End Skip Graphic Control Extension - Stream Position : 808
[STATUS]  Begin Skip Image Data - Stream Position : 809
[NOTICE]   [ 17:33:50 ] Skip Local  Color table : 0
[STATUS]  End Skip Image Data - Stream Position : 8507
[STATUS]  End Count Frame - Stream Position : 8684
[NOTICE]   [ 17:33:50 ] Nb Extension found : 3
[NOTICE]   [ 17:33:50 ] Nb Frame found : 1
[NOTICE]   [ 17:33:51 ] Picture.Bitmap.Size : 160x120

Un autre truc qui est sure c'est que aussi bien l'explorateur de windows, que mes outils de visualisation sont très permissifs et souples avec des fichiers images incorrectes, au niveau de certaines données. Elle sont fausses mais ils n'en tiennent pas compte et lisent quand même les fichiers.

Bon ca va me prendre encore un peu de temps pour achever le support de ce format GIF, mais c'est déja pas mal et beaucoup mieux que toutes les solutions vu jusqu'ici

[Jipété]

Ho-ho! tu n'a pas les yeux en face des trous aujourd'hui !!

Bien vu !
Effectivement, à force je me fais des nœuds dans le cerveau.

[Jipété]

j'ai trouvé ce projet GIFLIB (en C) où il y a de très bonnes explications sur le format GIF (en anglais malheureusement) disponible dans l'archive à télécharger

Mouais...
En ouvrant doc/whatsinagif/index.html j'ai pu constater qu'il manque des fichiers (le logo dans le bandeau du haut, et en bas de la page animation, le lien vers the documentation of the GIFLIB API renvoie 404).

Et je ne sens pas le courage d' (je n'ai pas l'énergie pour) essayer de comprendre ces histoires de compression et décompression.

Enfin, j'ai pu générer les binaires de la manière classique (./configure puis make) mais ceux-ci ne sont pas foutus d'ouvrir les fichiers que la complétion de la ligne de commande m'aide à saisir : les binaires ne trouvent pas les cibles, c'est gonflant et décourageant, puisqu'ils existent.
Bon, j'ai trouvé, cet outil ne supporte pas les espaces dans les noms de dossiers ! En 2018 ! On croit rêver...

Et quand enfin j'ai corrigé les défauts, je lance util/gifcolor pic/gifgrid.gif et ça ne me rend pas la main...
Comme si je n'avais pas assez de soucis avec Pascal, v'là les embrouilles C qui débarquent,

Sinon voici la nouvelle ImageTestSuite-GIF

Vu, tu y as introduit mes fichiers, ceux de Giflib, d'autres sans doute aussi, je suggère de faire 2 dossiers : 87 et 89.
Et puisque je parle de 87 et que la norme l'autorise, j'aimerais bien un jour voir un fichier multi-images : ça te parle ?

[Jipété]

Salut,

Pour le papillon, qui est un gif87a, j'ai une piste !

Dans FPreadGif.AnalyzeHeader il faut ajouter 2 lignes de test sur la version, comme ça (la fonction n'est pas grande, vous trouverez vite) :

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
    FTransparent:= FBackground <> 0;
    if version = '89a' then // jpt
      if FGraphCtrlExt then
      begin
        FTransparent:=(FGraphicsCtrlExt.Packedbit and $01)<>0;
        If FTransparent then
          FBackground:=FGraphicsCtrlExt.ColorIndex;
      end;    
    FLineSize:=FWidth*(FHeight+1);
    GetMem(FScanLine,FLineSize);
    if version = '89a' then // jpt
      If FTransparent then
      begin
        C:=FPalette.Color[FBackground];
        C.alpha:=alphaTransparent;
        FPalette.Color[FBackground]:=C;
      end;

Et tant qu'à y être, j'ai modifié la fin de la fonction :

Code :

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

1
2
3
4
    Result:=true;// jpt
  end;
  //Result:=true;  jpt -- pourquoi ici ? ça n'a pas de sens !
end;

L'original me fait penser à une fonction bâclée pour pouvoir accepter d'une manière bourrin des fichiers mal fichus, genre "je mets ça en place vit' vit' pour faire avancer", pi on zappe, celui qui bossait sur le projet bosse sur autre chose, c'est oublié et ça part en prod'... Vrai ou faux ?


Ce n'est pas tout : dans la fonction ReadScanLine, là aussi j'ai rajouté des lignes :
une au tout début :

Code :

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

1
2
begin
  FInitialCodeSize:=0; CodeSize:=0; B:=0; // jpt: 3 missing

puis une ici :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
    // search end of compressor table
    OldPos:=Stream.Position;
    PackedSize := 0;
    Repeat
      Stream.read(B, 1);
      if B > 0 then
      begin
        inc(PackedSize, B);
        Stream.Seek(B, soFromCurrent);
        CodeMask := (1 shl CodeSize) - 1;
      end;
      //until B = 0;   // jpt cette boucle ne finit jamais avec le papillon
      until (B = 0) or (Stream.Position > Stream.Size); // on passe

et une dernière là, à peine plus bas :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
    // read compressor table
    SourcePtr:=DataComp;
    Stream.Position:=OldPos;
    Repeat
      Stream.read(B, 1);
      if B > 0 then
      begin
        if B = 59 then B := 0; // jpt ajout détection "fin de fichier atteinte" sinon stream error dessous 
        Stream.ReadBuffer(SourcePtr^, B);
        Inc(SourcePtr,B);
      end;
    until B = 0;

Il y aurait peut-être moyen de faire mieux, je n'en sais rien, en tout cas le papillon passe avec ça, et ça ne casse pas ceux qui passaient avant sans souci.

Maintenant, je n'ai pas testé avec une centaine de fichiers, juste quelques petits 87 et quelques 89 (petites et grandes tailles), et je viens vous annoncer la nouvelle.

Si ce qui précède est valide (mais je ne suis pas dans la tête de celui qui a pensé le premier code), il restera à se palucher le multi-images, et là, deux grandes écoles s'affrontent :

• ou bien je conserve la "main" boucle de InternalRead blindée de tests if version = '87a' then begin ... end else begin ... end; ;
• ou bien il faut commencer par le test sur la version et créer deux boucles custom, étant entendu qu'à l'heure actuelle la boucle présente est adaptée à 89 mais ne gère pas le multi-images (// ToDo: read further images depuis 10 ans ou plus).

Bon dimanche,

[BeanzMaster]

Salut Jipete

J'ai été un peu occupé ces derniers jours.

Premièrement j'ai refait un zip avec les fichiers GIF et j'en ai rajouté quelques uns. Comme tu me l'a suggéré j'ai fait plusieurs sous-dossiers :

un pour les versions 87a et l'autre pour les version 89a plus encore des sous-dossiers "Bad", "Good" et "Problem" : ImageTestSuite-GIF

Je suis en pleine crise d'insomnie Je ne sais pas si je vais te faire pester, te rendre jaloux, ou bien les deux

Je me suis donc concentré sur ce format GIF ces derniers jours. je peux te dire que j'en ai bavé et je n'ai pas encore terminé. Sans plus attendre voila le premier résultat viable en video que j'ai pondu avec mon projet :

Dans l'ensemble ça fonctionne pas trop mal. Je suis assez content du résultat à ce stade. Par contre les fichiers dans le dossier "Problem" me font perdre les derniers cheveux que j'ai sur la tête.

Avec "SmallFullColour" et le feu d'artifice j'ai un problème de lecture avec l'extension "PlainText".
Avec "tahoe-tiny" il semblerai que ce soit un GIF en "True Color". Je n'ai pas encore trouvé de réelles infos sur comment prendre en charge ce "format exotique" du GIF. Ou surtout comment detecter qu'il s'agisse d'un GIF "TrueColor"
Avec les 2 autres je me prend de gros SIGSEGV pour je ne sais quelle raison. Il faut que je trouve ou j'ai une fuite de mémoire.

Voila, maintenant me reste encore à gérer l'animation et ça sera déjà pas si mal.

Niveau code c'est chaud patate le GIF pour lire toutes ces images, il faut faire l'impasse sur par mal de chose, vu que les standard du GIF ne sont pas correctement prise en charge dans bon nombre de logiciels . Et ça c'est une vrai m.... Donc la majorité des visualiseurs font l'impasse sur les messages d'erreurs. Moi même ici j'en ai zappé presque une dizaine. Sans cela tu ne peux pas afficher la moitié des images. Bref, c'est comme ça.
Pour le decodage LZW je n'ai pas réinventé la roue, j'ai repris le code de GraphicEx que j'ai légèrement modifié. Sinon ça reste basique.

A+

Bonne journée

EDIT : Je veins de remarqué que j'ai laissé trainé 2 gif 87a dans le dossier 89a. Oups

[Jipété]

Salute a tutti,

Je constate que tu galères autant que moi (peut-être que c'est pour ça qu'on se traîne un "ToDo" dans FPReadGif depuis 10 ans).

--snip--
Par contre les fichiers dans le dossier "Problem" me font perdre les derniers cheveux que j'ai sur la tête.
--snip--

Pour ce qui est de ces fichiers, c'est sûr que si les outils de l'OS les affichent correctement, c'est qu'on passe à côté de quelque chose.

De mon côté, j'en suis là, face à un mur grand comme l'Everest et pas la moindre prise pour s'accrocher :

j'ai d'abord pas mal étudié le projet "espagnol" en commençant par explorer un peu leur... forum, oui, et je n'y ai rien trouvé de particulier sauf le fait que c'est un forum Delphi donc Windows, et ça a son importance, car pour pouvoir compiler sous Linux il me faut, d'après le web, remplacer CopyMemory(dst src cnt) par Move(src dst cnt), comme ça :

Code :

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

1
2
3
4
5
{$IFDEF MSWINDOWS}
  CopyMemory(@b[0], GifLZW, blocksize); // code original, CopyMemory inconnu sous Linux
{$ELSE}
  Move(GifLZW^, b[0], blocksize);
{$ENDIF}

avec

Code :

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

1
2
3
GifLZW: PBYTE; 
b: array [0..255] of BYTE; // Read buffer
blocksize: integer; // Bytes in next block

Le problème c'est que des fichiers bien affichés sous Windows sont en vrac sous Linux.
Mais pas tous ! Les tout petits fichiers (6x8, 12x12, aux couleurs unies en aplat [Animaux-0, balle, Didll-0, etc.]) ne sont pas impactés.


Ce remplacement intervient 3 fois dans le code, toujours dans la function TGIF.UnZipImage mais est-ce vraiment la mise en œuvre du Move qui met sa pagaille ? Sans doute, car sous XP les 16 images de la girl s'affichent (mal assemblées, voir tout en bas).

Ensuite, la compatibilité avec Linux est loin d'être assurée, avec par exemple cette expérience vécue, et pour le moins curieuse : dans la procédure TBitmapStream.InitFromData(Width, Height, BitCount: DWORD);, si je mets un point d'arrêt sur la ligne SizeFile:= sizeof(BMPFILEHEADER) + (ColorCount-1) * 4 + SizeImage; lorsque j'y arrive dessus si je clique ensuite sur pas-à-pas les lignes suivantes ne sont pas exécutées, je me retrouve directement sur le end; de la proc et là, la souris sur SizeFile me donne une valeur farfelue.
Pour m'en sortir j'ai ajouté :

Code :

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

  sizeofBMPFILEHEADER := sizeof(BMPFILEHEADER);

et fait :

Code :

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

1
2
  //SizeFile:= sizeof(BMPFILEHEADER) + (ColorCount-1) * 4 + SizeImage;
  SizeFile:= sizeofBMPFILEHEADER + (ColorCount-1) * 4 + SizeImage;

Et là, la procédure s'exécute jusqu'à la dernière ligne, avec une valeur correcte pour SizeFile.
C'est assez perturbant.

Bref j'ai remplacé toutes les constructions avec sizeof par les deux lignes comme ci-dessus, mais les problèmes perdurent...
Voilà par exemple le rendu de girl.gif (1 seule image, les autres présentent des variations mais ça n'a aucun intérêt de poster l'animation) :

Le plus curieux c'est que cette pauvre girl toute moche est très belle avec XnView sous Windows et le visualisateur d'images sous Linux.

Alors c'est sûr que si le gars qui a fait le portage du code Delphi vers Lazarus n'a testé qu'avec des fichiers basiques, il n'a pas vu ce problème et nous voilà avec lui sur les bras 7 ans plus tard...

Un dernier truc : le bouton "Save" ne génère pas un fichier identique à l'original avec, entre autres, des valeurs différentes du byte 10 du header : mauvais calcul au niveau de la construction du fichier cible ? Je n'ai pas trouvé.


Puis j'ai essayé de faire avancer FPReadGif et, aussi curieux que ça paraisse, ça a avancé puisque je commence à gérer ça : // ToDo: read further images ! Mais c'est loin d'être opérationnel.
D'abord je n'ai pas d'animation dans l'ihm ; pour le moment j'arrive à récupérer les différentes images d'un .gif (s'il n'est pas trop compliqué [j'ai des images avec des erreurs sévères genre "out of memory" ou "invalid palette index 255" en mode multi-images])
Ensuite je ne sais pas comment passer ces images à l'ihm pour que le TImage qui s'y trouve les affiche ; j'avais pensé à une TImageList mais voilà ce qu'on peut lire dans ImgList.pp à son propos :

NOTE: due to its implementation, the TCustomImageList is not a TBitmap collection.
If a fast storage of bitmaps is needed, create your own list!

Vous conviendrez avec moi que ce n'est pas très encourageant.


Bref, j'en suis là : l'espagnol ne peut gérer que des petits fichiers, tout comme FPReadGif (ah !, la modif pour la prise en compte du multi-images : ajouter le while et le if dans FPReadGif.InternalRead :

Code :

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

1
2
3
4
5
6
    while True do  begin// jpt
      // skip extensions
      Repeat
        Introducer:=SkipBlock(Stream);
      until (Introducer = $2C) or (Introducer = $3B); // $2C = ',' image delimiter
      if Introducer = $3B then Break; // jpt '59' = EOF

et presque tout en bas :

Code :

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

1
2
3
4
     // ToDo: read further images
    inc(GCECount);// jpt ajout propriété pour compter les images 
    end;// jpt : fin du while 
  finally

) mais, rappel, les fichiers "sophistiqués" y sont mal gérés.


Je sens que je vais re-jeter un œil au compo Gif-Anim et à TAnimatedGif.pas, des fois que la lumière se fasse...
Et aussi à GraphicEx, merci pour la piste.
Mais j'ai la désagréable impression de faire du hors-piste dans des... marécages !

Pour conclure, les 16 images constituant le fichier girl.gif, on voit bien qu'il y en a une entière et que les autres ne sont que des bouts pour construire le rendu final.

Comment assembler tout ça dans un TImage ? That's the question,


EDIT
En relisant la page http://wiki.freepascal.org/fcl-image, je trouve dans le tableau Image formats, 2^e ligne, cette abomination (cest moi qui mets en gras) :

[...] supports up to 8 bits per pixels, which are 256 distinct colors chosen from the 24-bit RGB color space. This limitation makes it unsuitable for complex images, but useful for simple graphics.

Sauf que c'est faux, on sait aller au-delà !
Si le reste du code est du même tonneau ou s'appuie sur ce genre de niaiserie, je crois qu'on peut définitivement oublier FPReadGif...

Surtout en allant voir, comme suggéré par la 4^e colonne du tableau, Graphics.TGifImage où l'on découvre avec stupéfaction que la classe ne propose pas le délai pour les animations.

/EDIT

[Jipété]

Pour le decodage LZW je n'ai pas réinventé la roue, j'ai repris le code de GraphicEx que j'ai légèrement modifié. Sinon ça reste basique.

Un extrait de la routine de décompression :

à gauche un bout de FPReadGif.pas extrait de fpcsrc 2.6.2

Code :

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

1
2
3
{    This file is part of the Free Pascal run time library.
    Copyright (c) 2008 by the Free Pascal development team  
}

à droite un bout de GraphicCompression.pas extrait de la suite GraphicEx de Mike Leschke

Code :

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

1
2
3
4
5
// The original code is GraphicCompression.pas, released November 1, 1999.
//
// The initial developer of the original code is Mike Lischke (www.soft-gems.net),
//
// Copyright (C) 1999-2003 Mike Lischke. All Rights Reserved.

On notera curieusement à gauche le seul commentaire présent, en haut, et d'ailleurs absent à droite (remplacé par un saut de ligne) puisqu'on est dans la procédure TGIFLZWDecoder.Decode.

Aucun autre travail d'édition dans la partie droite, par contre j'ai remplacé à gauche l'absence des commentaires par des lignes vides, histoire que les lignes de code tombent en face.

La seule différence que je note, c'est lignes 135 et 144 où les gens de fpc ont utilisé une valeur en dur quand Mike a pris le soin de mettre en place une constante :

Code :

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

1
2
const // LZW encoding and decoding support
  NoLZWCode = 4096;

Sans commentaires.

[BeanzMaster]

Salut Jipete

Salute a tutti,

Je constate que tu galères autant que moi (peut-être que c'est pour ça qu'on se traîne un "ToDo" dans FPReadGif depuis 10 ans).

Pour ce qui est de ces fichiers, c'est sûr que si les outils de l'OS les affichent correctement, c'est qu'on passe à côté de quelque chose.
Bonne nouvelle, cet après midi pendant ma coupure avant et après ma petite sieste de 15 minutes. A grand coup de logs, j'ai pu corrigé les problèmes dans mon code et au final j'ai pu supprimer le dossier "Problem" Je peux maintenant afficher tous les GIF 10ans, ils abusent vraiment pour le coup

De mon côté, j'en suis là, face à un mur grand comme l'Everest et pas la moindre prise pour s'accrocher :

j'ai d'abord pas mal étudié le projet "espagnol" en commençant par explorer un peu leur... forum, oui, et je n'y ai rien trouvé de particulier sauf le fait que c'est un forum Delphi donc Windows, et ça a son importance, car pour pouvoir compiler sous Linux il me faut, d'après le web, remplacer CopyMemory(dst src cnt) par Move(src dst cnt), comme ça :

Code :

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

1
2
3
4
5
{$IFDEF MSWINDOWS}
  CopyMemory(@b[0], GifLZW, blocksize); // code original, CopyMemory inconnu sous Linux
{$ELSE}
  Move(GifLZW^, b[0], blocksize);
{$ENDIF}

avec

Code :

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

1
2
3
GifLZW: PBYTE; 
b: array [0..255] of BYTE; // Read buffer
blocksize: integer; // Bytes in next block

Le problème c'est que des fichiers bien affichés sous Windows sont en vrac sous Linux.
Mais pas tous ! Les tout petits fichiers (6x8, 12x12, aux couleurs unies en aplat [Animaux-0, balle, Didll-0, etc.]) ne sont pas impactés.


Ce remplacement intervient 3 fois dans le code, toujours dans la function TGIF.UnZipImage mais est-ce vraiment la mise en œuvre du Move qui met sa pagaille ? Sans doute, car sous XP les 16 images de la girl s'affichent (mal assemblées, voir tout en bas).

Je déteste utilisé move an mélangeant des "pointer" avec des tableaux. Il est préférable d'utiliser directement des "pointer"
Ou sinon c'est d'utiliser un truc genre :

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
 
Type
  TBytesArray : Array[0..255] of byte;
  PBytesArray = ^TBytesArray;
 
procedure MyMove(Buffer : Pointer;  B : TBytesArray; size : Longint);
var
  Bytes : TBytesArray absolute B;
begin
  Move(PByte(Buffer)^,  Bytes[0], Size)
end;
 
Ou bien direment utiliser le type PBytesArray
 
var
  B,BWorkerPtr : PBytesArray;
 
Getmem(B,Sizeof(TBytesArray));
BWorkerPtr := B;
B^:= valeur;
Inc(B);
ect...
PByte(BWorker+128)^:= valeur2;
 
BWorkerPtr := B;
Move(Buffer^, B^,Size);

Ensuite, la compatibilité avec Linux est loin d'être assurée, avec par exemple cette expérience vécue, et pour le moins curieuse : dans la procédure TBitmapStream.InitFromData(Width, Height, BitCount: DWORD);, si je mets un point d'arrêt sur la ligne SizeFile:= sizeof(BMPFILEHEADER) + (ColorCount-1) * 4 + SizeImage; lorsque j'y arrive dessus si je clique ensuite sur pas-à-pas les lignes suivantes ne sont pas exécutées, je me retrouve directement sur le end; de la proc et là, la souris sur SizeFile me donne une valeur farfelue.
Pour m'en sortir j'ai ajouté :

Code :

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

  sizeofBMPFILEHEADER := sizeof(BMPFILEHEADER);

et fait :

Code :

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

1
2
  //SizeFile:= sizeof(BMPFILEHEADER) + (ColorCount-1) * 4 + SizeImage;
  SizeFile:= sizeofBMPFILEHEADER + (ColorCount-1) * 4 + SizeImage;

Et là, la procédure s'exécute jusqu'à la dernière ligne, avec une valeur correcte pour SizeFile.
C'est assez perturbant.

J'ai eu se genre de soucis avec TBMPFileHeader et la propriété biSizeImageElle n'aime pas les nombres calculés dynamiquement, il faut passer par une variable biSizeImage := DWord(SizeFile);Pour le sizeof c'est SizeOf(TBitmapInfoHeader); et non [c]sizeof(BMPFILEHEADER)/[c] le 1er la structure, le 2eme le "pointer"

Comment assembler tout ça dans un TImage ? That's the question

La meilleur solution à mon avis pour l'intégré au TImage c'est dans le composant TGIFImage pour Delphi que tu trouveras la réponse. Sinon c'est d'avoir un controle dédié comme dans TGIFAnim

Sans commentaires.

C'est clair, en plus il faut faire quelques modifs pour que tout fonctionne correctement. CTRL-C / CTRL-V That's all folk !!!
Il ne se sont vraiment pas pris la tête.

Si ça t'intéresses, et si tu en as envie, je te contacterai en mp pour partager mes sources avec toi avant, que je ne sorte une version "Alpha" officielle. Tu pourras être mon cobaye Je suis sûr que tu auras des remarques pertinentes

Bonne journée

[Jipété]

Un peit mot ultra rapide juste pour ce point-là :

La meilleure solution à mon avis pour l'intégrer au TImage c'est dans le composant TGIFImage pour Delphi que tu trouveras la réponse.

Comme on le voit à la couleur du lien, j'ai déjà farfouillé dans cette direction, qui conduit les linuxiens dans le mur : solution non portable vers cet OS,

[Jipété]

Comme on le voit à la couleur du lien, j'ai déjà farfouillé dans cette direction, qui conduit les linuxiens dans le mur : solution non portable vers cet OS,

Et le plus rigolo, c'est l'essai que je viens de faire il y a trois minutes : j'ai démarré ma vieille machine virtuelle Win2k avec son D7 perso, ai ouvert le dossier de démo OneImage, la compilation (après adaptation des chemins) s'est bien passée mais zéro animation...
Ai fait de même avec le dossier Browser et le résultat est presque le même, car il y a en plus une différence de rendu du background...

(le titre du browser dit "5 images" et on n'en voit que 4 car j'ai coupé la copie d'écran pour ne pas alourdir).

Comment t'en es-tu sorti de ces misères, toi ?

Ah, j'ai également jeté un rapide coup d'œil aux sources du visualiseur d'images sous Linux, ce machin s'appuie sur les primitives du widgetset (gtk2 en ce qui me concerne) et du sous-système graphique cairo : impensable d'aller mettre les mains là-dedans.

[BeanzMaster]

Salut, pas d'animations, au vue du titre de la demo "OneImage" je dirais que c'est logique.

Avec TGIFImage sous delphi pour animer les GIF avec TImage il faut faire une truc dans le genre

TGifImage(Image.Picture.Graphic).Animate (ps je ne sais plus si c'est une procedure ou une propriété booleenne)

si je me souviens bien.

Sinon pour le reste je te prépare le zip dans la journée et je t'envoi le lien

[Jipété]

Salut,

Sinon pour le reste je te prépare le zip dans la journée et je t'envoie le lien

Hé bien c'est très gentil à toi et je regarderai ça avec plaisir et curiosité, cependant, il se pourrait que de mon côté j'aie enfin trouvé queqlue chose de très intéressant avec le compo TGifAnim.

Il aura suffi de passer la propriété CurrentView de protected à public pour la rendre disponible et ensuite :

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
  private
    ga: TGifAnim;
 
procedure TForm1.btnBrowseClick(Sender: TObject);
begin
  if not opd.Execute then exit; // previews ok
 
  if ga <> nil then FreeAndNil(ga);
 
  ga:= TGifAnim.Create(Self);
  with ga do begin
    Parent := pnl4display; // ! \ TPanel avec sa propriété Visible à False
    OnFrameChanged := @FrameChanged;
    FileName := opd.FileName;
  end;
end;
 
procedure TForm1.FrameChanged(Sender: TObject);
begin
  img.Picture.Bitmap.Assign(ga.CurrentView);
// img est un bête TImage en alClient et Stretch, Proportional, Center à True
end;
 
procedure TForm1.FormDestroy(Sender: TObject);
begin
  if ga <> nil then FreeAndNil(ga);
end;

et c'est tout !
Faudra juste que je me penche sur l'agrandissement, qui ne doit pas dépasser 1/1 sinon la qualité se dégrade, c'est un détail et je verrai ça + tard.

Mais, car il y a toujours un "mais", Diddl, la balle jaune et Animaux ont des problèmes de background avec ce compo, regardez le petit doigt de Diddl (j'ai mis les 2 images côte à côte pour mieux voir) :



On peut bien voir ce défaut avec le prog de Johann, qui inclut des boutons pour avancer/reculer d'image en image, et pour m'affranchir du défaut il me faut cliquer sur "Repaint".
Il est comment, Diddl, chez toi ?

[BeanzMaster]

Salut,

....
Mais, car il y a toujours un "mais", Diddl, la balle jaune et Animaux ont des problèmes de background avec ce compo, regardez le petit doigt de Diddl (j'ai mis les 2 images côte à côte pour mieux voir) :

On peut bien voir ce défaut avec le prog de Johann, qui inclut des boutons pour avancer/reculer d'image en image, et pour m'affranchir du défaut il me faut cliquer sur "Repaint".
Il est comment, Diddl, chez toi ?

Idem que chez toi et en fait ce décalage est normal car la seconde image à des dimension légèrement que celle définit dans l'en-tête et que dans la première image de l'animation. Et dans cette même deuxième image dans l'image descriptor" (Top/Left) c'est à dire la position d'affichage est à 0,0 d'ou ce décalage.
La première image à des dimensions 85x140 et la seconde 78x136. C'est d'ailleurs pour ça que je l'ai placé dans le dossier "Bad"

[BeanzMaster]

Pour obtenir une animation correcte il faut prendre en compte la méthode d'affichage décrite dans le "GCE" et ajuster en fonction

J'ai ajuster la position, mais je sais pas si ma formule est viable dans tous les cas de figures, mais elle fonctionne ici

[Jipété]

Idem que chez toi et en fait ce décalage est normal

Sauf que chez moi il n'y a pas de décalage, il y a juste un bout de doigt qui reste d'une image et se retrouve sur l'autre, et c'est tout (pb de refresh du background) !

Tu penses bien que s'il y avait eu un décalage comme tu le montres, il y a longtemps que j'en aurais parlé,

La première image a des dimensions 85x140 et la seconde 78x136.

Ah okéééééééééééé !

Cependant l'afficheur d'images de mon Linux ça lui fait ni chaud ni froid, il me les affiche tip-top l'une au-dessus de l'autre sans aucun décalage, tout comme le testgif de Johann : pas de décalage, juste le bout de doigt qui reste.

Et les navigateurs ?


Mon FF a l'air de s'en sortir sans souci.

C'est d'ailleurs pour ça que je l'ai placée dans le dossier "Bad"

Elle était pourtant fournie dans le sous-dossier "gif" du dossier "testgif" de Johann, si ma mémoire est bonne, sans indication particulière.

On n'est pas rendu, hein...

Ah, pendant qu'on y est, dans la rubrique "qui a copié qui", TGifAnim utilise également le système de décompression de FPReadGif et GraphicEx,

[BeanzMaster]

Sauf que chez moi il n'y a pas de décalage, il y a juste un bout de doigt qui reste d'une image et se retrouve sur l'autre, et c'est tout (pb de refresh du background) !

Tu penses bien que s'il y avait eu un décalage comme tu le montres, il y a longtemps que j'en aurais parlé,


Cependant l'afficheur d'images de mon Linux ça lui fait ni chaud ni froid, il me les affiche tip-top l'une au-dessus de l'autre sans aucun décalage, tout comme le testgif de Johann : pas de décalage, juste le bout de doigt qui reste.

Et les navigateurs ?


Mon FF a l'air de s'en sortir sans souci.

Ca c'est parce que tu ne le vois pas, qu'il ny a pas de décalage. tous ces composants redimensionnent l'image au moment du rendu

Elle était pourtant fournie dans le sous-dossier "gif" du dossier "testgif" de Johann, si ma mémoire est bonne, sans indication particulière.

Oui, mais ce n'est pas pour autant qu'elle a été encodée correctement

On n'est pas rendu, hein...

Ah, pendant qu'on y est, dans la rubrique "qui a copié qui", TGifAnim utilise également le système de décompression de FPReadGif et GraphicEx,

De toute façon c'est comme le code du TGifImage de Delphi, on peux le voir dans d'autres unité également