Discussion :

[BeanzMaster]

Salut

Tu plaisantes, j'espère ?

Non, en faite mon gestionnaire d'archive voit le fichier comme un dossier mais j'ai finalement pu l'extraire.

Alors avec ou sans l'unité Graphics, et AnimatedGIF je n'ai pas eu de problèmes Le seul truc c'est sans AnimatedGIF et avec "animaux" ou la transparence n'était pas correctement pris en compte

Solution native ? Aurais-je loupé un épisode ? Dis m'en plus, stp.

Je parle ici de l'unité FPReadGIF car c'est elle qui se charge de charger les GIF

De mon côté, j'ai dégotté un truc sympa sur un forum espagnol, mais qui date de 2010, résultat, bien que la chose soit certifiée pour Lazarus, il y a de gros problèmes de dézippage (ou autres) qui se manifestent par des images incomplètes.
Sous Windows, parce que sous Linux, après avoir remplacé les CopyMemory(dest source size) par des Move(source dest size) c'est du grand n'importe quoi : images juste pleines de bruits (pixels multicolores) et c'est tout.
Pour les curieux, c'est là, en bas, mais pas le .rar : il faut être enregistré...
Remontez un poil au-dessus. C'est commenté en espagnol, mais compréhensible.

Ce qui est rigolo avec ce truc, c'est qu'il enregistre bien les images qu'il affiche mal,

Le problème d'affichage vient de Lazarus et du TBitmap c'est courrant ce genre de chose. Encore un truc du RawImage mal initialisé.

Et du coup ce composant fonctionne du feu de Dieu, sauf un méchant problème de Invalid Palette Index (255) avec 1 fichier, pas le même que jusqu'à présent, et le pire c'est que je ne vois pas où cette valeur est calculée, que la pile d'appels me montre que le contrôle et la remontée de l'erreur c'est dans fppalette.inc mais qu'un point d'arrêt à l'endroit qui va bien n'arrête rien du tout...

J'ai testé et chez moi ce n'est pas du feu de dieu qu'il fonctionne. J'ai eu le même problème avec la palette sur certain GIF

Le problème semble venir de TGIFAnim car l'erreur est un dépassement d'index (ex 32 couleurs dans la palette. Et GIFAnim indique des index allant de 0 à 32 au lieu de 0 à 31)

Dans la procedure TGifLoader.WriteScanLine(Img: TFPCustomImage); J'ai modifié un peu le code vite fait comme un bourrin

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
procedure TGifLoader.WriteScanLine(Img: TFPCustomImage);
var
  Row, Col,pi: integer;
  Pass, Every: byte;
  P: PByte;
begin
  pi:=0;
  P := FScanLine;
  if Interlaced then
  begin
    for Pass := 1 to 4 do
    begin
      case Pass of
        1:
        begin
          Row   := 0;
          Every := 8;
        end;
        2:
        begin
          Row   := 4;
          Every := 8;
        end;
        3:
        begin
          Row   := 2;
          Every := 4;
        end;
        4:
        begin
          Row   := 1;
          Every := 2;
        end;
      end;
      //Showmessage('Palette Count 1 :'+FPalette.Count.ToString);
      repeat
        for Col := 0 to FLocalWidth - 1 do
        begin
          pi:=P^;
          if (pi>FPalette.Count-1) then pi:=FPalette.Count-1;
          Img.Colors[Col, Row] := FPalette.Color[Pi];
 
          inc(p);
        end;
        Inc(Row, Every);
      until Row > FLocalHeight-1;
    end;
  end
  else
  begin
    // Showmessage('Palette Count 2 :'+FPalette.Count.ToString);
    for Row := 0 to FLocalHeight - 1 do
      for Col := 0 to FLocalWidth - 1 do
      begin
        pi:=P^;
        if (pi>FPalette.Count-1) then pi:=FPalette.Count-1;
        Img.Colors[Col, Row] := FPalette.Color[Pi];
        inc(p);
      end;
  end;
end;

Ca passe mais l'affichage me semble incorrect c'est comme si il y avait une image en trop. Bref

Sinon j'en ai profité pour faire un petit ImageTestSuite-GIF.zip avec quelques fichiers mal encodés.

A+

[BeanzMaster]

J' ai fait des tests supplémentaire avec TGifAnim le problème de l'index de la palette vient du fait qu'il réinitialise à zero FPalette pour chaque image au lieux d'ajouter les couleurs dans la palette globalement

Petite correction donc à faire à la place de ce que j'ai fait dans mon message précédent : en plus

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
procedure TGifLoader.ReadPalette(Stream: TStream; Size: integer);
var
  RGBEntry: TRGB;
  I: integer;
  C: TFPColor;
begin
  // FPalette.Clear;   //-------> Ces  2
  // FPalette.Count := 0;  // lignes sont à commenter
  With RGBEntry do
  begin
    Red:=0;
    Green:=0;
    Blue :=0;
  End;
  for I := 0 to Size - 1 do
  begin
    Stream.Read(RGBEntry, SizeOf(RGBEntry));
    with C do
    begin
      Red   := RGBEntry.Red or (RGBEntry.Red shl 8);
      Green := RGBEntry.Green or (RGBEntry.Green shl 8);
      Blue  := RGBEntry.Blue or (RGBEntry.Blue shl 8);
      Alpha := alphaOpaque;
    end;
    FPalette.Add(C);
  end;
end;

EDIT : Il y a quand même un soucis de lecture avec les palettes de couleurs dans le TGIFAnim

[Jipété]

hello,
il existe un autre composant pour visualiser des gifs animés , c'est le THTMLviewer (ou TFrameViewer) qui se trouve dans le paquet HTMLViewer ( disponible dans les paquets en ligne)

Je parle ici de l'unité FPReadGIF car c'est elle qui se charge de charger les GIF

Laissez-moi un peu de temps pour étudier tout ça.

Sinon j'en ai profité pour faire un petit ImageTestSuite-GIF.zip avec quelques fichiers mal encodés.

Grand grand merci pour ce zip
Et c'est là qu'on se rend compte qu'on a encore un looooong chemin à parcourir. Je les ai testés (sauf les 7 que je connaissais déjà et qui ne posent pas de problèmes particuliers à part le fond, parfois), voilà ce qu'il en sort (je n'ai mis que les 2 premières lettres des fichiers, ça devrait suffire) :

Code TEXT :

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
2b : invalid palette index 255
5f idem
6d kc (manque des données)
9f idem
55 corrompue
24 kc
06 invalid palette index 32
70 idem
38, 48 : pas vu de souci
ad, ad kc
a_image : rien d'affiché (GIF87a)
bc invalid pointer operation
ce invalid palette index 126
d5 : invalid palette index 255
e6 = ras 
e3 plante la preview, mais c'est un fichier vide qui ne contient que l'entête GIF89ad.d. (10 octets) Renommé en .nogif
ea = ras
ee rien d'affiché (GIF87a)
f8 invalid palette index 32
f6 = ras
fc pas d'animation 
tahoe = rien d'affiché mais c'est pas un gif, c'est un htm

Flemme de regarder le code, mais de mémoire il me semble y avoir vu des tests sur GIF89a, donc les 2 fichiers GIF87a, pas sûrs qu'ils soient acceptés...
Bon, maintenant, l'immense majorité des erreurs ci-dessus se retrouve dans le viewer Lxde. Quelque part c'est rassurant.

[Jipété]

Bonjour,

j'ai travaillé pour vous : voilà un fichier "testimgs.htm" à dézipper dans le dossier contenant les images fournies hier par Jérome et à ouvrir avec votre navigateur préféré.
testimgs.zip

L'affichage se présentera ainsi :
nom_du_fichier_sans_extension=<<et ici l'image si elle veut bien s'afficher>>
ligne_de_commentaire, éventuellement
ligne_vide
et on continue...

Dans les commentaires il y a parfois des messages d'erreur, relevés avec l'outil bâti sur TGifAnim.

Un truc curieux : j'ai vu plusieurs fois avec le navigateur bâti sur le compo THtmlViewer proposé par J.P une image grise et bleue affichant "Membership", ainsi qu'une autre montrant une lettre disparaissant dans une boîte aux lettres : sont-ce des images génériques ?
Quand je regarde les miniatures générées par mon Linux, je ne vois qu'une seule image "boîte aux lettres" et aucune "membership",



Sinon, pour visualiser tout ça, il est parfaitement possible d'ouvrir le .htm avec une des démos fournies avec le composant, et disponibles dans le dossier HtmlViewer\Demos\Compiled Framedemo (récupérable ici).

Au vu des résultats, on se rend compte que les rendus sont parfois différents selon le navigateur et le défaut présent dans le fichier.

• image non visible dans FF car invalid palette index 255 mais visible avec FrameDemo
• point d'exclamation car manque des datas -- visible dans FF
• point d'exclamation car invalid pointer operation -- visible avec FF
• GIF87a, correct sous FF, erreur avec FrameDemo
• pas d'image sous FF, pas d'animation sous FrameDemo

Voilà.
Je m'en vais maintenant voir s'il y aurait moyen de n'utiliser que la partie "visualiseur de gif's" du compo THtmlViewer, tout en pensant à bien blinder de try les ouvertures de fichiers, car on n'est pas au bout de nos surprises dans ce monde mal fini...

[BeanzMaster]

Bonjour,

j'ai travaillé pour vous : voilà un fichier "testimgs.htm" à dézipper dans le dossier contenant les images fournies hier par Jérome et à ouvrir avec votre navigateur préféré.
testimgs.zip

L'affichage se présentera ainsi :
nom_du_fichier_sans_extension=<<et ici l'image si elle veut bien s'afficher>>
ligne_de_commentaire, éventuellement
ligne_vide
et on continue...

Dans les commentaires il y a parfois des messages d'erreur, relevés avec l'outil bâti sur TGifAnim.

Salut,

Cool ton petit fichier sous Opera preseques toutes les images s'affichent. Et il y a presque les même soucis que dans les commentaires que tu as mis pour

0646caeb9b9161c777f117007921a687 idem
243d9798466d64aba0acaa41f980bea6 idem
2b5bc31d84703bfb9f371925f0e3e57d celle-ci ne s'affiche pas
5f09a896c191db3fa7ea6bdd5ebe9485 idem
7092f253998c1b6b869707ad7ae92854 visible mais l'animation se fige comme les deux premier
adaf0da1764aafb7039440dbe098569b visible mais l'animation se fige
d5a0175c07418852152ef33a886a5029 ici "Point d'exclamation"

les autres s'affichent toute correctement

En passant bien vu pour l'image "tahoe-tiny". J'ai mis à jour le Zip je n'avais pas vu que j'avais mal enregistré ce fichier. Cette dernière est correcte et s'affiche.

EDIT :

Affichage sous l'explorateur dans Windows 10

]

Affichage dans mon outil de visualisation "FastOne ImageViewer"

[Jipété]

Cool ton petit fichier

En passant bien vu pour l'image "tahoe-tiny". J'ai mis à jour le Zip je n'avais pas vu que j'avais mal enregistré ce fichier. Cette dernière est correcte et s'affiche.

Voilà mes commentaires :
Pas d'animation dans FF ni dans FrameDemo, prog de test -> TGif: Invalid GIF Signature Code.
Et pourtant, on voit bien GIF89a avec l'éditeur hexa.
Comme je disais, ...

Bien vu, ça, dessous, mais...

Affichage sous l'explorateur dans Windows 10
Affichage dans mon outil de visualisation "FastOne ImageViewer"

... tu devrais essayer de refaire tes images avec le même nombre de colonnes, pour pouvoir visuellement comparer aisément, et tant qu'à refaire, mets donc 8 images par ligne, ça sera tip-top.
, suis pas là c't'aprème...

[BeanzMaster]

... tu devrais essayer de refaire tes images avec le même nombre de colonnes, pour pouvoir visuellement comparer aisément, et tant qu'à refaire, mets donc 8 images par ligne, ça sera tip-top.
, suis pas là c't'aprème...

C'est fait

[Jipété]

Salut,

C'est fait

Trop bien trop fort

En plus il est sympa ton outil FastOne ImageViewer : il indique en haut à gauche le nombre d'images dans le fichier,

Bon, du coup je ne pouvais pas faire moins que proposer à mon tour la vision du dossier par XnView dans un vieux XP virtuel :


C'est quand même curieux ces images "Membership" sorties d'on ne sait où, tout comme les boîtes aux lettres...
- - -

Sinon, j'ai compilé tes retours sur les .gif dans mon fichier .htm, peux-tu y jeter un œil ?

Car quand tu dis "les autres s'affichent toutes correctement", tu laisses planer un doute...
Regarde ce commentaire avec les tests de ce matin :
"67 images dans fichier, pas d'anim dans FF, ok avec FrameDemo" concernant f88b6907ee086c4c8ac4b8c395748c49 (le pingouin en bas à gauche).
As-tu ou pas une anim' pour ce fichier ?
EDIT :
"67 images dans fichier, se fige en fin d'anim dans FF, ok avec FrameDemo" concernant f88b6907ee086c4c8ac4b8c395748c49 (le pingouin en bas à gauche).
J'avais noté "pas d'anim", c'est parce que comme l'image est en bas de page et que l'anim est très rapide, le temps que je regarde tout ce qui la précédait, quand j'arrivais dessus l'anim était finie et FF ne la reprend pas.
Testé avec un fichier htm dédié à cette image. /EDIT

Pareil pour ce774930ac70449f38a18789c70095b8 :
"5 images dans fichier, pas d'anim dans FF, ok avec FrameDemo et BM Opera"
Et on voit bien, avec ton outil, que le nombre d'images est le même que celui que j'ai relevé de mon côté en utilisant des bouts de code du compo THtmlViewer.

Et aussi tahoe : y-a-t'il une anim' ? Car je n'ai pas l'impression que le fichier ait plusieurs images. EDIT : En tout cas ton outil a du mal avec ce fichier, puisque pas d'indications.
il semblerait que ton outil n'indique pas 1 quand il n'y a qu'une image :
Voir post suivant pour petite explication de cet outil de comptage.
EDIT de l'EDIT : je découvre à l'instant avec un autre outil que ce fichier est aussi un GIF87a -- ceci explique peut-être cela -- pourtant mon XnView le montrait, mais trop de choses à regarder, on en oublie... /EDIT de l'EDIT.
/EDIT

Bref, j'ai regénéré un fichier .htm en enlevant toutes les images correctes, histoire de se concentrer sur celles qui foirent, ça donne ça :
testimgsbadonly.htm

À pluche,

[Jipété]

il existe un autre composant pour visualiser des gifs animés , c'est le THTMLviewer (ou TFrameViewer) qui se trouve dans le paquet HTMLViewer ( disponible dans les paquets en ligne)
--snip--
En pièce jointe le gif animé google.

Le même code (j'insiste sur le même code car c'est carrément le même binaire : compilé hier soir, je ne passe pas par l'EDI ce matin) avec un bête bouton qui va bêtement ouvrir un bête fichier dont l'ami J.P nous a montré qu'il était plaisant et en ce qui me concerne je me contente de lire son nombre d'images, avec une gestion d'erreurs sophistiquée :

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
// essai avec HtmlGif1 et HTMLGif2 de THtmlViewer
procedure TForm1.Button1Click(Sender: TObject);
var
  str: TMemoryStream;
  aGif: HTMLGif2.TGIFImage;
  s: string;
  FPUExceptionMask: TFPUExceptionMask;
begin
  if not opd.Execute then exit;
  s := '';
  str:= TMemoryStream.Create;
  str.LoadFromFile(opd.FileName);
  str.Position:=0;
  aGif:= HTMLGif2.TGIFImage.Create;
  try
    {$IFDEF LCLGTK2}
    FPUExceptionMask := GetExceptionMask;
    SetExceptionMask(FPUExceptionMask - [exInvalidOp, exZeroDivide, exOverflow]); // unmask
    {$ENDIF}
    try
      aGif.LoadFromStream(str); 
      if aGif.IsAnimated then s:='yes ' else s:='no ';
      s := s + IntToStr(aGif.NumFrames) + ' ' + IntToStr(aGif.NumIterations);
      Caption := s;
      // en attente pour la suite
    finally
      //ShowMessage('test de passage...');// ok, vu dans tous les cas
      {$IFDEF LCLGTK2}
      SetExceptionMask(FPUExceptionMask);// return previous masking immediately, we must not let Gtk2 internals to be called without the mask
      {$ENDIF}
      str.Free;
      aGif.Free;
    end;
  except
    ShowMessage('Ooops...');
  end;
end;

Et vous l'aurez compris, des fois j'ai le ShowMessage('Ooops...'); et des fois j'ai le nombre d'images dans la barre de titre.

Et comment je fais pour avoir le nombre d'images affiché, après le message d'erreur ? Je reclique pour choisir un autre fichier, tout simplement, puis je reclique pour choper l'image de J.P et si c'est pas bon je recommence.
Au bout d'un nombre aléatoire d'essais, un coup ça tombe en marche et je découvre que ce fichier a 42 images.


Ça me gonfle, mais alors ça me gonfle, même pas vous imaginez !

Rien n'est fiable...

D'ailleurs, en étudiant hier soir le code du THtmlViewer, je suis tombé sur ça que j'ai noté à votre intention et là, franchement, ça ne donne pas envie de rigoler :

Code :

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

1
2
3
4
5
{$ifdef Linux}
  PaintPanel.Update;
{$else}
  PaintPanel.Invalidate;
{$endif}

Parce que c'est le genre de choses qu'on va oublier, concentré sur les problèmes de plus haut niveau, et comme je l'avais déjà signalé, "write once, compile anywhere", execute et bim bam boum selon la cible

PS : merci pour l'idée de ce compo, J.P, mais c'est trop compliqué de n'extraire que la partie "viewer de gif".

[Jipété]

Résumé de deux jours (ou presque) de souffrance :

le code espagnol : il doit y avoir un souci avec le code de décompression car en générant un petit fichier avec 2 images 6x8 ça fonctionne, mais le même fichier en 5x10 présente des défauts de couleurs sur la dernière colonne, quant aux fichiers plus grands c'est même pas la peine d'en parler, ils sont complètement en vrac en termes de couleurs...
Une piste : un autre fichier 4 calques en 12x16 fonctionne bien aussi.
En 12x17 toujours ok
En 13x16 dernière colonne en vrac ! Ah ah ! Une piste !
12x12 ok
13x13 dernière colonne en vrac
14x14 ok
15x15 dernière colonne en vrac
16x16 ok
17x17 dernière colonne en vrac
17x20 dernière colonne en vrac
18x18 ok
Il y a bien un problème avec les largeurs impaires.

Mais 32x32 ok aussi, alors pourquoi le spinner 32x32 est tout en vrac ? Le fait que mes tests sont faits avec des images unies ? Yes, car recolorier les 12 dessins du spinner avec des couleurs unies = plus de problème.
Et 33x32 --> défaut dans dernière colonne.

Va falloir aller fouiller dans la routine de dézippage et construction des bitmaps d'affichage, basée sur du scanline et autres pointeurs (préparez les mouchoirs !), ou alors j'adapte, j'adapte : je viens de trouver chez Torry une proc de décompression LZW prévue pour D7 qui a accepté de compiler sans souci. À suivre...


le compo TGifAnim : si l'image à afficher est plus grande que la zone disponible sur la fiche (petite fiche et grande image), le redimensionnement de la fiche en tirant "en bas à droite" à la souris va faire afficher un défaut en bas de l'image, défaut de la hauteur de l'espace absent au départ.
Si quelqu'un veut aller voir dans le compo, il peut essayer avec le fichier 48487099.gif (petit feu d'artifice) ou le 38732719 (grand f. d'a.), et voilà une image pour illustrer :



Le prog a été lancé de manière à ce que le grand f. d'a. ne rentre pas, j'ai ensuite agrandi la fiche, et on voit sur l'image, en incruste (à la bonne hauteur mais trop à droite) et zoomée à 200 % comment le défaut se manifeste. Très désagréable, et comme je suis très mauvais, je n'ai pas trouvé où se cachait le problème, désolé.

Sinon, BM, j'ai mis en place tes modifs sans souci particulier.

[BeanzMaster]

Bonjour Jipété

le compo TGifAnim : si l'image à afficher est plus grande que la zone disponible sur la fiche (petite fiche et grande image), le redimensionnement de la fiche en tirant "en bas à droite" à la souris va faire afficher un défaut en bas de l'image, défaut de la hauteur de l'espace absent au départ.
Si quelqu'un veut aller voir dans le compo, il peut essayer avec le fichier 48487099.gif (petit feu d'artifice) ou le 38732719 (grand f. d'a.), et voilà une image pour illustrer :



Le prog a été lancé de manière à ce que le grand f. d'a. ne rentre pas, j'ai ensuite agrandi la fiche, et on voit sur l'image, en incruste (à la bonne hauteur mais trop à droite) et zoomée à 200 % comment le défaut se manifeste. Très désagréable, et comme je suis très mauvais, je n'ai pas trouvé où se cachait le problème, désolé.

Sinon, BM, j'ai mis en place tes modifs sans souci particulier.

Sous Windows, je ne remarque rien d'anormal dans l'affichage (peut-être trop rapide avec mon PC). Par contre il y a un truc qui me semble pas logique dans la procedure paint du TGifImage. J'ai commenté:
C'est peut-être la cause du problème.

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
procedure TGifAnim.Paint;
begin
  if (not Empty) and Visible then
  begin
    if not (csDesigning in ComponentState) then
    begin
      if (FCurrentImage < GifBitmaps.Count) then
        with GifBitmaps.Items[FCurrentImage] do
        begin
          BufferImg.Canvas.Brush.Color := (self.Color);
          if FCurrentImage = 0 then
            BufferImg.Canvas.FillRect(Rect(0, 0, Width, Height));
          if Delay <> 0 then FWait.Interval := Delay * 10;
          // BufferImg.Canvas.Draw(PosX, PosY, Bitmap); // ---> Ces 2 lignes doivent normalement se trouver après les méthodes d'effacement et non avant, 
          // CurrentView.Assign(BufferImg); // ce n'est pas logique de transférer le "Bitmap" dans "BufferImg" puis d'effacer une partie ou la totalité. "Method" fait référence à ce qui faut appliquer à l'image en cours et non à la prochaine il me semble
 
          case Method of
            //0 : Not specified...
            //1 : No change Background
            2: BufferImg.Canvas.FillRect(
                Rect(PosX, PosY, Bitmap.Width + PosX, Bitmap.Height + PosY));
 
            3: BufferImg.Canvas.FillRect(Rect(0, 0, Width, Height));
          end;
          BufferImg.Canvas.Draw(PosX, PosY, Bitmap); // Lignes replacées
          CurrentView.Assign(BufferImg);
        end;
 
    end
    else
    begin
      Canvas.Brush.Color := (self.Color);
      Canvas.FillRect(Rect(0, 0, Width, Height));
    end;
    Canvas.Draw(0, 0, CurrentView);
  end;
  inherited Paint;
end;

J'ai aussi remarqué TGifImage prend en charge que les GIF version 89a

Un autre truc qui ne fonctionne pas correctement si tu mets le GifImage avec "Align := alClient" et "AutoSize := False" (avec true c'est idem) le compo ne se redimensionne pas lors du "Resize" de la fenêtre

[Jipété]

Bonsoir,

Bon, je crois que je vais laisser tomber :
TGifAnim n'est pas capable de gérer ces histoires de tailles plus grandes que la fenêtre de départ, c'est lassant.
L'alClient ne sert à rien, tout comme l'AutoSize (à True par défaut) qui a l'air de n'avoir aucune action, ou alors faut nous expliquer, et comme y a pas d'aide...

L'espagnol, je ne sais pas si je vais m'en sortir avec ces histoires de compression LZW, je me suis rendu compte ce matin que le fait de remplacer le CopyMemory(dest, src, length) (inconnu sous Linux) par du Move(src, dest, length) générait des blagues.
Et de toute façon, c'est comm' d'hab', ça fonctionne mieux moins mal sous Windows que sous Linux, mais c'est loin d'être une réussite : regardez un peu girl.gif, gros problème de background et de décodage des couleurs.
Et pareil que TGifAnim, gros problème aussi avec le resize, qui n'est pas géré.

Quant à TAnimatedGif.pas, on se souvient de plantages violents sur des fichiers qui passent bien ailleurs.

Il me reste à regarder d'un peu plus près les possibilités de FPreadGif, et si ça fait comme les trois autres, ben, je jette l'éponge.

[BeanzMaster]

Re-bonsoir sinon il y a le composant TGifImage pour Delphi qui marchait très bien.Il est téléchargeable ici. Un portage vers Lazarus ne devrait pas être trop compliquer je pense. C'est d'ailleur sur ce compo que l'auteur de TGifImage pour Lazarus a voulu se baser.

PS : J'ai bientôt terminer la version "Alpha" de ma solution (il me reste à faire un peu de nettoyage dans le code, et uniformiser les commentaires). Je te promet que tu galéras moins avec les images. Tu peux allez voir sur ma chaine youtube j'ai posté quelques vidéos de démos alla "OldSchool" Je posterai dès que j'ai le temps des démos plus techniques et plus orienter traitements d'images.

[Jipété]

Re-bonsoir sinon il y a le composant TGifImage pour Delphi qui marchait très bien.Il est téléchargeable ici. Un portage vers Lazarus ne devrait pas être trop compliqué je pense.

Je l'ai testé et ai été obligé d'abandonner le portage tellement ce compo est plein de fonctions Windows sans équivalents Linux,

Sinon, j'ai trouvé hier soir comment utiliser FPreadGif et accéder aux données internes du fichier Gif :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
procedure TForm1.ShowGifwithFP(s: string);
var
  imgtmp: TFPCustomImage;
  //reader: TFPCustomImageReader;
  reader: TFPReaderGif;
  DelayTime: word;
begin
  imgtmp := TFPMemoryImage.Create(10, 10);
  reader := TFPReaderGif.Create;
  imgtmp.LoadFromFile(s, reader);
  DelayTime := reader.GraphicsCtrlExt.DelayTime;
  stb.SimpleText:= 'DelayTime: '+ inttostr(DelayTime);
  reader.Free;

Ce (bout de) code vient du wiki, je me suis inspiré de ce qu'il y a tout en bas de la page, et si la première mouture n'était pas intéressante, avec ce TFPCustomImageReader qui faisait que la complétion sur reader. n'apportait quasiment rien, c'est en regardant mieux le code et cette ligne reader:= TFPReaderGif.Create; qui j'ai tenté ce que vous lisez ci-dessus et là, bingo !

Plus qu'à exploiter ce filon, j'y retourne !

[Jipété]

Plus qu'à exploiter ce filon, j'y retourne !

C'est pas gagné, mon affaire : je comptais m'appuyer sur SkipBlock mais cette fonction est inaccessible (protected).
Au passage, tiens, j'ai remarqué que la complétion n'offre pas les mêmes propositions selon que je fais

Code :

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

1
2
3
  writer := TFPWriterPNG.Create;
  TFPWriterPNG(Writer).Us // qui propose UseAlpha, ou
  writer.Us // qui ne propose rien.

Qui peut m'expliquer ça ? Merci.

Sinon, je me pose la question de savoir quand les choses vont-elles avancer¹ ?

Code :

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

1
2
3
FPCSRC 2.6.2 fichier FPReadGif, 544 lignes, 14580 bytes (15124 sous Windows), daté de 2009
ligne  16   ToDo: read further images
ligne 246   ToDo: read further images

Code :

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

1
2
3
FPCSRC 3.0.4 fichier FPReadGif, 544 lignes, 14580 bytes (15124 sous Windows), daté de 2009
ligne  16   ToDo: read further images
ligne 246   ToDo: read further images

(Impossible de télécharger des vieilles versions, leurs pages web sont en vrac...)

Ce commentaire se trouve dans une procedure TFPReaderGif.InternalRead(Stream: TStream; Img: TFPCustomImage); override; déclarée dans la section protected et appelée par personne.
Mais on la retrouve dans FPimage rubrique TFPCustomImageReader = class (TFPCustomImageHandler) section protected, tout comme procedure InternalRead (Str:TStream; Img:TFPCustomImage); virtual; abstract;.
Bonjour pour savoir qui fait quoi, sans aucun commentaire, aucune explication

¹ : j'ai bien peur que ça soit mort... Quand on regarde la page où sont listées les choses qui avancent, il n'y a pas un mot sur ça.

[BeanzMaster]

[QUOTE=Jipété;10271173]C'est pas gagné, mon affaire : je comptais m'appuyer sur SkipBlock mais cette fonction est inaccessible (protected).

Ce commentaire se trouve dans une procedure TFPReaderGif.InternalRead(Stream: TStream; Img: TFPCustomImage); override; déclarée dans la section protected et appelée par personne.
Mais on la retrouve dans FPimage rubrique TFPCustomImageReader = class (TFPCustomImageHandler) section protected, tout comme procedure InternalRead (Str:TStream; Img:TFPCustomImage); virtual; abstract;.

Salut, tout ça ce sont des conceptes de la POO. Je te conseil de lire les tutoriels de Gilles à ce sujet, cela t'aidera à mieux comprendre certains aspects :

• https://gilles-vasseur.developpez.co...rientee-objet/
• https://gilles-vasseur.developpez.co...es-proprietes/
• https://gilles-vasseur.developpez.co...es-methodes-1/
• https://gilles-vasseur.developpez.co...es-methodes-2/

InternalRead n'est pas appelé par le reader, c'est totalement normal, elle est déclarée Virtual; Abstract ce qui signifie que cette fonction doit être implentée dans une classe enfant.
Les "Reader" et "Writer" sont des passerelles entre les formats de fichiers et la gestion des données de l'images.
Le skipBlock est "protected" normal, l'utilisateur final n'a pas besoin de cette fonction.
Le truc que tu peux faire c'est copier la classe du reader complétement dans une unité à toi et renommer la classe en TMyReaderGIF par exemple. Et tu déplace la procedure SkipBlock en public si tu en as vraiment besoin.
L'utlisation restera la même avec FPImage.

Code :

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

1
2
3
4
5
6
7
8
var
  imgtmp: TFPCustomImage;
  reader: TMyFPReaderGif;
  DelayTime: word;
begin
  imgtmp := TFPMemoryImage.Create(10, 10);
  reader := TMyFPReaderGif.Create;
  imgtmp.LoadFromFile(s, reader);

PS : Dans mon souvenir le FPReadGIF ne lit pas les animations.

[Jipété]

Le truc que tu peux faire c'est copier la classe du reader complétement dans une unité à toi et renommer la classe en TMyReaderGIF par exemple. Et tu déplaces la procedure SkipBlock en public si tu en as vraiment besoin.
L'utlisation restera la même avec FPImage.

j'ai suivi ton conseil, nouvelle unité myfpreadgif.pas qui est un clône de celle qui a au moins 9 ans, mise dans le dossier du projet et changé le uses de unit1, un coup de compil ça roule, ok.
J'ai déplacé deux procédures de protected à public, merci pour le tuyau, il ne m'était pas venu à l'esprit car, en agissant ainsi, je m'éloigne de la distro officielle et le jour où ça leur prend de faire avancer les todo, j'aurai surement des problèmes.

InternalRead n'est pas appelé par le reader, c'est totalement normal, elle est déclarée Virtual; Abstract ce qui signifie que cette fonction doit être implentée dans une classe enfant.

Rien compris.
cette fonction doit être implentée dans une classe enfant. : c'est le cas, son code est dans fpreadgif, section protected.
Ça doit être l'implémentation selon ta description, mais personne ne l'appelle, alors comment peut-elle être exécutée ?
Bon, c'est pas grave.
Mais j'aurais bien aimé une explication sur cette histoire de complétion à géométrie variable selon comment c'est goupillé. Je remets la manip :

Code :

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

1
2
3
  writer := TFPWriterPNG.Create;
  TFPWriterPNG(Writer).Us // qui propose UseAlpha, ou
  writer.Us // qui ne propose rien.

Le skipBlock est "protected" normal, l'utilisateur final n'a pas besoin de cette fonction.

C'est pourtant comme ça que font les autres codes : ils parcourent tout le fichier à la recherche des délimiteurs de zones (le point d'exclamation, la virgule).

Salut, tout ça ce sont des concepts de la POO. Je te conseille de lire les tutoriels de Gilles à ce sujet, cela t'aidera à mieux comprendre certains aspects : [--snip--]

Impression d'être obligé de repasser mon permis de conduire chaque fois que je dois prendre ma bagnole pour aller faire les courses.
+ un doctorat de mécanique des fluides sinon la carburation se fait mal, sans oublier la thèse sur la résistance des matériaux sinon la tenue de route c'est plus ça.
Tu vois le truc ?

PS : Dans mon souvenir le FPReadGIF ne lit pas les animations.

Ben oui, c'est tout à fait le sens du "todo" que j'ai relevé : c'est à faire...
Depuis au moins 9 ans...

EDIT : en fait, mon problème c'est qu'il y a des gens qui n'appellent pas un chat un chat, et ça, ça perturbe ma compréhension.
Regarde ce que je trouve dans AnalyzeHeader : FLineSize := FWidth * (FHeight+1); !
Je ne sais pas encore si c'est ImageSize ou FullBlocksSize, mais LineSize ça n'a pas de sens.

Je lis souvent du code comme je lis un roman, mais si les bons mots n'y sont pas employés, je ne capte rien à l'histoire.
/EDIT

[BeanzMaster]

Rien compris.
cette fonction doit être implentée dans une classe enfant. : c'est le cas, son code est dans fpreadgif, section protected.
Ça doit être l'implémentation selon ta description, mais personne ne l'appelle, alors comment peut-elle être exécutée ?
Bon, c'est pas grave.

InternalRead est appelé dans cette procedure :

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
function TFPCustomImageReader.ImageRead (Str:TStream; Img:TFPCustomImage) : TFPCustomImage;
begin
  try
    if not assigned(Str) then
      raise FPImageException.Create(ErrorText[StrNoStream]);
    FStream := Str;
    if not assigned(img) then
      result := FDefImageClass.Create(0,0)
    else
      result := Img;
    FImage := result;
    if FImage.UsePalette then
      FImage.Palette.Clear;
    if CheckContents (Str) then
      begin
      InternalRead (Str, result)
      end
    else
      raise FPImageException.Create ('Wrong image format');
  finally
    FStream := nil;
    FImage := nil;
  end;
end;

Mais j'aurais bien aimé une explication sur cette histoire de complétion à géométrie variable selon comment c'est goupillé. Je remets la manip :

Code :

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

1
2
3
  writer := TFPWriterPNG.Create;
  TFPWriterPNG(Writer).Us // qui propose UseAlpha, ou
  writer.Us // qui ne propose rien.

C'est pourtant comme ça que font les autres codes : ils parcourent tout le fichier à la recherche des délimiteurs de zones (le point d'exclamation, la virgule).

Ici tu fais du "transtypage" je suppose donc que ton writer est de type TFPCustomImageWriter ta fonction "UseAlpha" n'est donc pas présente dedans, mais elle l'est dans "TFPWriterPNG". Cette même fonction ne sera pas présente dans TFPWriterBMP par exemple. et ces 2 classes sauvegarderont bien un fichier depuis un TFPImage. Tu me suis ? C'est ça la magie de la POO

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
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
 
Type
  TFPCustomImageHandler = class
    private
      FOnProgress : TFPImgProgressEvent;
      FStream : TStream;
      FImage : TFPCustomImage;
    protected
      procedure Progress(Stage: TProgressStage; PercentDone: Byte;  RedrawNow: Boolean; const R: TRect;
                         const Msg: AnsiString; var Continue: Boolean); Virtual;
      property TheStream : TStream read FStream;
      property TheImage : TFPCustomImage read FImage;
    public
      constructor Create; virtual;
      Property OnProgress : TFPImgProgressEvent Read FOnProgress Write FOnProgress;
  end;
 
  TFPCustomImageWriter = class (TFPCustomImageHandler)
    protected
      procedure InternalWrite (Str:TStream; Img:TFPCustomImage); virtual; abstract;
    public
      procedure ImageWrite (Str:TStream; Img:TFPCustomImage);
      // writes given image to stream
  end;
 
  TFPWriterPNG = class (TFPCustomImageWriter)
    private
      FUsetRNS, FCompressedText, FWordSized, FIndexed,
      FUseAlpha, FGrayScale : boolean;
      FByteWidth : byte;
      FChunk : TChunk;
      CFmt : TColorFormat; // format of the colors to convert from
      FFmtColor : TColorFormatFunction;
      FTransparentColor : TFPColor;
      FTransparentColorOk: boolean;
      FSwitchLine, FCurrentLine, FPreviousLine : pByteArray;
      FPalette : TFPPalette;
      OwnsPalette : boolean;
      FHeader : THeaderChunk;
      FGetPixel : TGetPixelFunc;
      FDatalineLength : longword;
      ZData : TMemoryStream;  // holds uncompressed data until all blocks are written
      Compressor : TCompressionStream; // compresses the data
      FCompressionLevel : TCompressionLevel;
      procedure WriteChunk;
      function GetColorPixel (x,y:longword) : TColorData;
      function GetPalettePixel (x,y:longword) : TColorData;
      function GetColPalPixel (x,y:longword) : TColorData;
      procedure InitWriteIDAT;
      procedure Gatherdata;
      procedure WriteCompressedData;
      procedure FinalWriteIDAT;
    protected
      property Header : THeaderChunk read FHeader;
      procedure InternalWrite (Str:TStream; Img:TFPCustomImage); override;
      procedure WriteIHDR; virtual;
      procedure WritePLTE; virtual;
      procedure WritetRNS; virtual;
      procedure WriteIDAT; virtual;
      procedure WriteTexts; virtual;
      procedure WriteIEND; virtual;
      function CurrentLine (x:longword) : byte;
      function PrevSample (x:longword): byte;
      function PreviousLine (x:longword) : byte;
      function PrevLinePrevSample (x:longword): byte;
      function  DoFilter (LineFilter:byte;index:longword; b:byte) : byte; virtual;
      procedure SetChunkLength (aValue : longword);
      procedure SetChunkType (ct : TChunkTypes);
      procedure SetChunkType (ct : TChunkCode);
      function DecideGetPixel : TGetPixelFunc; virtual;
      procedure DetermineHeader (var AHeader : THeaderChunk); virtual;
      function DetermineFilter (Current, Previous:PByteArray; linelength:longword):byte; virtual;
      procedure FillScanLine (y : integer; ScanLine : pByteArray); virtual;
      function ColorDataGrayB(color:TFPColor) : TColorData;
      function ColorDataColorB(color:TFPColor) : TColorData;
      function ColorDataGrayW(color:TFPColor) : TColorData;
      function ColorDataColorW(color:TFPColor) : TColorData;
      function ColorDataGrayAB(color:TFPColor) : TColorData;
      function ColorDataColorAB(color:TFPColor) : TColorData;
      function ColorDataGrayAW(color:TFPColor) : TColorData;
      function ColorDataColorAW(color:TFPColor) : TColorData;
      property ChunkDataBuffer : pByteArray read FChunk.data;
      property UsetRNS : boolean read FUsetRNS;
      property SingleTransparentColor : TFPColor read FTransparentColor;
      property SingleTransparentColorOk : boolean read FTransparentColorOk;
      property ThePalette : TFPPalette read FPalette;
      property ColorFormat : TColorformat read CFmt;
      property ColorFormatFunc : TColorFormatFunction read FFmtColor;
      property byteWidth : byte read FByteWidth;
      property DatalineLength : longword read FDatalineLength;
    public
      constructor create; override;
      destructor destroy; override;
      property GrayScale : boolean read FGrayscale write FGrayScale;
      property Indexed : boolean read FIndexed write FIndexed;
      property CompressedText : boolean read FCompressedText write FCompressedText;
      property WordSized : boolean read FWordSized write FWordSized;
      property UseAlpha : boolean read FUseAlpha write FUseAlpha;
      property CompressionLevel : TCompressionLevel read FCompressionLevel write FCompressionLevel;
  end;
 
TFPWriterBMP = class (TFPCustomImageWriter)
  private
    StartPosition : int64; { save start of bitmap in the stream, if we must go back and fix something }
    FBpp : byte;
    FRLECompress : boolean;
    BFH : TBitMapFileHeader;
    BFI : TBitMapInfoHeader;
    Colinfo : array of TColorRGBA;
    fXPelsPerMeter,
    fYPelsPerMeter : integer;
    procedure SetColorSize (AValue : Byte);
    function GetColorSize : byte;
    procedure SetBpp (const abpp : byte);
    procedure FillColorMap(Img : TFPCustomImage);
    procedure Setup16bpp;
    function PackWord555(const col : TFPColor) : word;
    function PackWord565(const col : TFPColor) : word;
    function Pack4bpp(const img : TFPCustomImage; var Col : integer; const Row : integer) : byte;
    function Pack1bpp(const img : TFPCustomImage; var Col : integer; const Row : integer) : byte;
    procedure CompressScanLineRLE8(ALine : pbyte; const Row, Width : Integer; Stream : TStream);
    procedure CompressScanLineRLE4(ALine : pbyte; const Row, Width : Integer; Stream : TStream);
  protected
    function  SaveHeader(Stream:TStream; Img: TFPCustomImage):boolean; virtual;
    procedure InternalWrite (Stream:TStream; Img: TFPCustomImage); override;
  public
    constructor Create; override;
    property BitsPerPixel : byte read FBpp write SetBpp;
    property XPelsPerMeter : integer read fXPelsPerMeter write fXPelsPerMeter;
    property YPelsPerMeter : integer read fYPelsPerMeter write fYPelsPerMeter;
    property RLECompress : boolean read FRleCompress write FRleCompress;
    Property BytesPerPixel : Byte Read GetColorSize Write SetColorSize; deprecated;
  end;

Impression d'être obligé de repasser mon permis de conduire chaque fois que je dois prendre ma bagnole pour aller faire les courses.
+ un doctorat de mécanique des fluides sinon la carburation se fait mal, sans oublier la thèse sur la résistance des matériaux sinon la tenue de route c'est plus ça.
Tu vois le truc ?

Oui je comprend, c'est complexe surtout la gestion des images dans FPC/Lazarus. Ca m'a pris du temps pour comprendre le fonctionnement et j'ai pas encore tout compris.
Lis les tutoriels de Gilles, comme je te l'ai suggéré, cela t'aideras à mieux comprendre le fonctionnement des classes. Je sais, ce n'ai pas forcement évident. Mais les exemples de Gilles sont très simples Et si tu as des questions par rapport à tout ça, n'hésites pas

Ben oui, c'est tout à fait le sens du "todo" que j'ai relevé : c'est à faire...
Depuis au moins 9 ans...

Cela est dû au fait qu'il n'y presque pas de personnes qui veulent utiliser cette fonctionnalités comparer à d'autres demandes qui sont faite à l'équipe de développement de FPC.
C'est comme moi en gros, au restaurant, je vais faire des rognons tous les 10 mois, et je vais en faire seulement pour 1 service . Et pas toutes les semaine car très (très peu) de gens aime ça, dans le quartier ou je travail. (et je te parle même pas des tripes ou de la tête de veau ! c'est même pas la peine que j'y pense ). Là c'est un peu la même chose. Il y a trop peu de demandes pour l'amélioration de cette partie.

EDIT : en fait, mon problème c'est qu'il y a des gens qui n'appellent pas un chat un chat, et ça, ça perturbe ma compréhension.
Regarde ce que je trouve dans AnalyzeHeader : FLineSize := FWidth * (FHeight+1); !
Je ne sais pas encore si c'est ImageSize ou FullBlocksSize, mais LineSize ça n'a pas de sens.
Je lis souvent du code comme je lis un roman, mais si les bons mots n'y sont pas employés, je ne capte rien à l'histoire.
/EDIT

D'accord avec toi pour le coup. C'est clair FLineSize := FWidth * (FHeight+1); le nom de cette variable n'a aucun sens par rapport au calcul effectué. Elle correspond plus a un FBlockSize ou FSubImageSize (dans le cadre d'un gif animé). En plus elle est incorrecte, ils ont rajouté 1 ligne entière de pixels pour être sure de ne pas dépasser la taille du buffer (FScanLine). ce qui doit signifier un décalage quelques part dans le code lors de la lecture des données (je pencherai dans la méthode de décompression. J'ai déja eu ce genre de cas dans avec la décompression RLE dans le format TGA. Et j'ai bien galéré à trouver ce qui causait ce petit décalage. Il y a aussi un calcul un peu foireux du même genre dans le format BMP pour trouver le début des données. Il y à un décalage de 4 octets )

T'y comprendra pas grand chose, mais voila un extrait de mon lecteur de BMP :

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
...
 //FInternalReadSize := 14 + FHeaderSize + 4; // 14 = Taille de l'en-tête commun à tous les BMP, FHeaderSize = Taille de l'en-tête secondaire, différente d'une version à l'autre. 4 = Taille du paramètres décrivant la taille de FHeaderSize
  FInternalReadSize := Memory.Position;
....
  { On connait ou se trouve les données, on sait combien de données on a lu
    On peut donc déterminer le 1er "GapSize" c'est à dire l'espace perdu entre
    la palette de couleurs et les données.
    Le GapSize peut-être égal à 0.
    Cette espace perdu est présent surtout avec les en-tête Windows 1,4 et 5
    Si la compression est égale à BITFIELD si ce "GapSize" est égal à 12
    alors cet espace contient les masques RGBA donc BitCount = 24.
    Si égal à 16 alors cet espace contient les masques RGBA donc BitCount = 32.
    Si ce gapSize est egal à zero alors format par defaut BGRA. Et pour les version 4 et 5
    on doit utiliser les masques présents dans l'en-tête.
    La valeur de bfOffBits peut également être  "erronée", souvent de 4 octets (je n'arrive pas à comprendre pourquoi )
  }
 
  If ((FInternalReadSize) > FBMPFileHeader.bfOffBits) Then
  Begin
   // Result := False;
   // RaiseInvalidImageFile('Erreur de lecture dans le fichier'+#13+#10+'InternalRead :'+Inttostr(FInternalReadSize)+#13+#10+
   // 'OffBits : '+Inttostr(FBMPFileHeader.bfOffBits));
   // On se replace simplement
   // Memory.Seek(FBMPFileHeader.bfOffBits, soBeginning);
  End
  Else
  Begin
    GapSize1 := (FBMPFileHeader.bfOffBits) - (FInternalReadSize);
  End;

Du coup j'ai commenté la partie qui doit réajuster le position, et le chargement de tous mes fichiers BMP se passe nickel. Mais je comprend toujours pas ce décalage de 4 octets. J'ai l'impression que le paramètre de la taille de l'en-tête secondaire n'est pas ajouté dans le calcul bfOffbits

Bref je m'éloigne du sujet. Mais des fois c'est vraiment des truc à la c....

Bonne nuit

[Jipété]

Bon, allez, j'abandonne.

Voulant repartir à la base de chez base et en zappant les animations, j'ai généré un tout petit fichier .gif que XnView sous XP et l'afficheur d'images sous Linux affichent sans problème, en partant du code du wiki (à gauche sur l'image -- en bleu à droite ce que j'ai rajouté :un TOpenDialog pour choisir le fichier, et un TImage pour espérer l'y voir) mais un nouveau projet avec juste le strict minimum n'empêche pas la 1.8.2 de se vautrer lamentablement, et un clic sur "Coupure" m'affiche un truc qui n'a absolument rien à voir (en haut à gauche) :



Oui, ce fichier .gif est un 87a, et alors ? FPReadGif l'accepte :

Code :

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

1
2
3
4
5
    if (Signature = 'GIF') and
       ((Version = '87a') or
       (Version = '89a')) then
    else
    Raise Exception.Create('Unknown/Unsupported GIF image type');

Dégoûté, complètement dégoûté,

[Jipété]

Une dernière précision :

Code :

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

Image.LoadFromFile(od.FileName, Reader); // c'est cette ligne qui fait planter

et impossible d'aller y voir en pas-à-pas : on n'entre pas dans le code...


Et last but not least, le plantage dépend des fichiers !
Jérome, dans ton zip, a_image.gif (GIF87a) s'affiche très bien alors que le papillon jaune ee6d fait planter (87a également).

Alors bon, voilà, quoi...