[1.8.2 Linux/Windows] Bugs de l'OpenPictureDialog EDIT : ou plutôt de l'unité Graphics

Version imprimable

Voir 40 message(s) de cette discussion en une page

02/06/2018, 01h27
BeanzMaster

2 pièce(s) jointe(s)

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 :

Pièce jointe 385354

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

Pièce jointe 385357

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 :weird:

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+

4 pièce(s) jointe(s)

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 :
Pièce jointe 385378

Citation:

Envoyé par BeanzMaster

Pièce jointe 385357

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 !
Pièce jointe 385382

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

Citation:

Envoyé par BeanzMaster

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. ?
:koi:
Le petit papillon jaune aussi c'est tout bon ?
Chez moi, juste avec ça :
Code:

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:

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, :aie:

Citation:

Envoyé par BeanzMaster

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

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, :mouarf:

Citation:

Envoyé par BeanzMaster

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) :
Pièce jointe 385385
Pièce jointe 385387

Citation:

Envoyé par BeanzMaster

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

1 pièce(s) jointe(s)

Pourquoi je pète les plombs...

Code:

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é :aie:), l'infobulle m'affiche 59, qui est bien la valeur attendue.
Mais alors, le test, :koi:

Pièce jointe 385410

:marteau: :marteau: :marteau:

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:

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

02/06/2018, 15h56
DomDA91

Bonjour,

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

Code:

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

2 pièce(s) jointe(s)

Salut,

Citation:

Envoyé par Jipété

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

Citation:

Envoyé par Jipété

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

Citation:

Envoyé par Jipété

Le reste est tout bon. ?
:koi:
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, :aie:

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.

Citation:

Envoyé par Jipété

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, :mouarf:

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

Citation:

Envoyé par Jipété

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 :P

Citation:

Envoyé par Jipété

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

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

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 8O

Ci-joint un log de test avec 2 GIF

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 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
Pièce jointe 385462
Code:

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
Pièce jointe 385466

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, :zen: mais c'est déja pas mal et beaucoup mieux que toutes les solutions vu jusqu'ici :yaisse1:

02/06/2018, 19h20
Jipété

Citation:

Envoyé par DomDA91

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.
03/06/2018, 00h52
Jipété

Citation:

Envoyé par BeanzMaster

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, :aie:

Citation:

Envoyé par BeanzMaster

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 ?

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:

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:

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:

1 2 begin FInitialCodeSize:=0; CodeSize:=0; B:=0; // jpt: 3 missing
puis une ici :
Code:

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:

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

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,

07/06/2018, 05h04
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 :lol:

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 : :zoubi:

https://www.youtube.com/watch?v=a-FFMkiWyzY

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 :aie:. 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 ;)

2 pièce(s) jointe(s)

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

Citation:

Envoyé par BeanzMaster

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

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:

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

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:

sizeofBMPFILEHEADER := sizeof(BMPFILEHEADER);

et fait :
Code:

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) :
Pièce jointe 386704
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 :

Citation:

Envoyé par ImgList.pp

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:

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:

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.
Pièce jointe 386705
Comment assembler tout ça dans un TImage ? That's the question,
:coucou:

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

Citation:

Envoyé par fcl-image

[...] 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...
:cry:
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.
:marteau:
/EDIT

1 pièce(s) jointe(s)

Qui a copié qui ?

Citation:

Envoyé par BeanzMaster

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:

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:

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.
Pièce jointe 386748

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:

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

Salut Jipete

Citation:

Envoyé par 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).

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 :yaisse1: 10ans, ils abusent vraiment pour le coup :mouarf:
Citation:
Envoyé par Jipété
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:

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:

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

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:

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);
Citation:
Envoyé par Jipété
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:

sizeofBMPFILEHEADER := sizeof(BMPFILEHEADER);

et fait :
Code:

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"

Citation:

Envoyé par Jipété

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

Citation:

Envoyé par Jipété

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 :zoubi: Je suis sûr que tu auras des remarques pertinentes

Bonne journée

08/06/2018, 07h37
Jipété

1 pièce(s) jointe(s)

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

Citation:

Envoyé par BeanzMaster

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.

Pièce jointe 386963
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, :aie: :weird: :calim2: :cry:
09/06/2018, 09h13
Jipété

1 pièce(s) jointe(s)

Citation:

Envoyé par 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, :aie: :weird: :calim2: :cry:

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

Pièce jointe 387346 (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.
09/06/2018, 11h58
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

1 pièce(s) jointe(s)

Salut,

Citation:

Envoyé par BeanzMaster

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:

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

Pièce jointe 387392

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 ?

09/06/2018, 16h09
BeanzMaster

1 pièce(s) jointe(s)

Citation:

Envoyé par Jipété

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"

Pièce jointe 387396
09/06/2018, 17h18
BeanzMaster

1 pièce(s) jointe(s)

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

Pièce jointe 387402
09/06/2018, 19h36
Jipété

1 pièce(s) jointe(s)

Citation:

Envoyé par BeanzMaster

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é, :mouarf:

Citation:

Envoyé par BeanzMaster

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 ?
Pièce jointe 387415

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

Citation:

Envoyé par BeanzMaster

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, :ptdr:
09/06/2018, 21h23
BeanzMaster

Citation:

Envoyé par Jipété

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é, :mouarf:

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 ?
Pièce jointe 387415

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

Citation:

Envoyé par Jipété

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

Citation:

Envoyé par Jipété

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, :ptdr:

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

Voir 40 message(s) de cette discussion en une page