Une info pour ceux qui font du graphisme pointu

Citation:

---

Envoyé par BeanzMaster

T'as plus besoin de ce fichier, tout est dans fastbitmapcore

---

Je ne pouvais pas le deviner, je ne suis pas équipé avec l'option "voyance" :ptdr:

Citation:

---

Envoyé par BeanzMaster

voila l'unit FastBitmapCore corrigée, maintenant ton image devrait s'afficher

---

Un .jpg oui, un .png aussi, mais un simple .bmp toujours pas... Je n'ai plus la bande cyan, tout est uniformément noir... :koi:

Et il a fallu là aussi que je modifie dans FastBitmapCore, comme tout à l'heure :
Pièce jointe 225979

Bon, allez, au pieu, j'en peux plus...

Citation:

---

Envoyé par Jipété

Un .jpg oui, un .png aussi, mais un simple .bmp toujours pas... Je n'ai plus la bande cyan, tout est uniformément noir... :koi:

Et il a fallu là aussi que je modifie dans FastBitmapCore, comme tout à l'heure :

---

Tu as modifié la fonction "Description" ?
Ca doit être ton bmp car chez moi sous Windows et sous ma mv Linux le bmp se charge parfaitement. Dans tous les cas se coup ci c'est pas moi :D

Pièce jointe 225990

Salut !

Les grands esprits se rencontrent ! J'étais justement en train de regarder tout ça quand ma messagerie a sonné, :D !

Citation:

---

Envoyé par BeanzMaster

Tu as modifié la fonction "Description" ?

---

Oh ben non, surement pas ! Ou alors je l'aurais signalé.

Citation:

---

Envoyé par BeanzMaster

Ca doit être ton bmp car chez moi sous Windows et sous ma mv Linux le bmp se charge parfaitement. Dans tous les cas se coup ci c'est pas moi :D

---

En fait, il semblerait que ça soit l'outil de Mitchell qui a du mal avec les exports de Gimp...

Démonstration :
- en haut à gauche le .png d'origine ouvert dans The Gimp pour être exporté en .bmp
- dessous la miniature sur le Bureau du fichier exporté : déjà là, on reconnaît correctement l'image
- en haut à droite ce fichier .bmp affiché dans un visionneur quelconque, et tutti va bene :P
- en bas le même fichier dans l'outil de Mitchell :aie:
Pièce jointe 225992

Alors c'est sûr que si tu t'appuies sur son code, ça ne peut que foirer, sur ce coup-là...
Ce qui est curieux, c'est que d'autres .bmp générés par code (genre Bitmap.SaveToFile) sont correctement affichés chez Mitchell :koi:

Bon, on ne va pas passer le dimanche là-dessus, fait trop beau 8-)

Et oui...

Regardez l'image :
Pièce jointe 225996
à gauche l'aperçu d'un fichier dans la fenêtre d'un dialogue OpenPictureDialog ;
au milieu le fichier dans l'explorateur de fichiers PCmanFM fourni avec mon vieux Linux Debian Wheezy 7 / 32 bits (pb identique dans une récente mv Debian Jessie8) ;
à droite le même fichier dans un visionneur.

Alors ces traits verticaux à gauche, les ayant déjà vécus quand je jouais avec Scanline et les histoires 24/32 bits Windows <> Linux, j'en conclus que l'OpenPictureDialog n'est pas bien fini, ou c'est les routines sur lesquelles il s'appuie qui ont un souci.

Ci-dessous le fichier (zippé because le forum ne supporte pas les .bmp) en question, si certains veulent l'examiner sous toutes les coutures : Pièce jointe 225997

Citation:

---

Envoyé par Jipété

Et oui...

Regardez l'image :
Pièce jointe 225996
à gauche l'aperçu d'un fichier dans la fenêtre d'un dialogue OpenPictureDialog ;
au milieu le fichier dans l'explorateur de fichiers PCmanFM fourni avec mon vieux Linux Debian Wheezy 7 / 32 bits (pb identique dans une récente mv Debian Jessie8) ;
à droite le même fichier dans un visionneur.

Alors ces traits verticaux à gauche, les ayant déjà vécus quand je jouais avec Scanline et les histoires 24/32 bits Windows <> Linux, j'en conclus que l'OpenPictureDialog n'est pas bien fini, ou c'est les routines sur lesquelles il s'appuie qui ont un souci.

Ci-dessous le fichier (zippé because le forum ne supporte pas les .bmp) en question, si certains veulent l'examiner sous toutes les coutures : Pièce jointe 225997

---

Le problème vient de ton lunux car regardes chez moi sous Windows 10 et dans la mv Linux Mint ton Bitmap s'affiche bien partout et même dans le projet que j'ai recréer (cf http://www.developpez.net/forums/d16...u/#post8806265)

Pièce jointe 225998

C'est franchement bizarre :weird:

Citation:

---

Envoyé par BeanzMaster

Le problème vient de ton lunux car regardes chez moi sous Windows 10 et dans la mv Linux Mint ton Bitmap s'affiche bien partout et même dans le projet que j'ai recréer (cf http://www.developpez.net/forums/d16...u/#post8806265)

---

Je ne vois nulle part dans ton image trace d'un OpenPictureDialog pour lequel j'ai bien précisé que c'est l'aperçu sur la droite de la fenêtre qui foire...

Je te le refais :
Pièce jointe 226001

C'est + clair, là ?

Effectivement j'ai le même bug, il semblerai que suivant les options d'enregistrement du format bmp , il y ai un problème à la lecture. Du coup dans gimp j'ai ouvert ton FondRVB.Bmp et l'ai exporté avec les options "Ne pas inscrire l'information d'espace de couleur" cochée et en RVB 24 bit. La pas de soucis d'affichage dans la boite de dialogue

Citation:

---

Envoyé par BeanzMaster

Effectivement j'ai le même bug, il semblerai que suivant les options d'enregistrement du format bmp , il y ai un problème à la lecture. Du coup dans gimp j'ai ouvert ton FondRVB.Bmp et l'ai exporté avec les options "Ne pas inscrire l'information d'espace de couleur" cochée et en RVB 24 bit. La pas de soucis d'affichage dans la boite de dialogue

---

Avec mes derniers tests (suite à ton post), c'est le 24 bits qui fait la différence. Ben on n'est pas rendu moi j'dis...

Si tu veux en savoir plus, je suis parti de là, dans le sous-forum voisin...

Je reviens deux secondes là-dessus car j'y ai beaucoup pensé, ce soir :

Citation:

---

Envoyé par BeanzMaster

Effectivement j'ai le même bug, il semblerai que suivant les options d'enregistrement du format bmp , il y ai un problème à la lecture. Du coup dans gimp j'ai ouvert ton FondRVB.Bmp et l'ai exporté avec les options "Ne pas inscrire l'information d'espace de couleur" cochée et en RVB 24 bit. La pas de soucis d'affichage dans la boite de dialogue

---

Et je ne suis pas d'accord du tout ! Il y a un problème avec Lazarus et tu le contournes en modifiant le fichier, ça ne va pas du tout ! Comme à certaines époques on arrachait des pages dans certains livres car elles étaient trop... trop ce que tu veux, mais hors normes on va dire.

Le problème est dans Lazarus, puisque l'explorateur de fichiers m'affiche une miniature correcte, un visionneur quelconque affiche correctement l'image, The Gimp l'ouvre sans problèmes, tout comme LibreOffice Writer qui l'importe sans souci pour illustrer un document, par exemple.

Mais quand on voit le bazar dans intfgraphics.pas et sa somptueuse collection de ToDo (12 ! J'ai vérifié avec une vieille 1.0.10, ma 1.4 de prod et une 1.6.2 toute fraîche et en tests, cette quantité ne varie pas... La taille du fichier augmente mais les ToDo's ne diminuent pas...), on peut se dire que ce n'est pas près d'évoluer, hélas.

---

Sinon, pour en revenir au sujet d'origine, j'ai retrouvé ça, dans un coin, je te laisse y jeter un œil et si tu veux le downloader, passe par le second lien, le svn, il est plus à jour que l'autre il me semble (ah, les joies de l'internet et du non-suivi des informations...)

Citation:

---

Envoyé par Jipété

Je reviens deux secondes là-dessus car j'y ai beaucoup pensé, ce soir :
Et je ne suis pas d'accord du tout ! Il y a un problème avec Lazarus et tu le contournes en modifiant le fichier,

---

D'accord avec toi bien sur que l'on parle de Lazarus, pas de vaches. C'est sous entendu évidemment dans ma phrase ("Effectivement j'ai le même bug, il semblerai que suivant les options d'enregistrement du format bmp ")
Et oui on contourne, le problème, on le sait donc on trouve des solutions alternatives. Ce que je peux dire la dessus c'est que ce n'est pas le chargement du bitmap qui pose problème, c'est la fonction "StrechDraw" de lazarus qui bug (j'ai vérifié)

Citation:

---

Envoyé par Jipété

Mais quand on voit le bazar dans intfgraphics.pas et sa somptueuse collection de ToDo (12 ! J'ai vérifié avec une vieille 1.0.10, ma 1.4 de prod et une 1.6.2 toute fraîche et en tests, cette quantité ne varie pas... La taille du fichier augmente mais les ToDo's ne diminuent pas...), on peut se dire que ce n'est pas près d'évoluer, hélas.

---

Oui d'accord mais bon, les développeurs font déjà un super boulot je pense (et gratuitement sur leur temps de libre pour la majeur partie, c'est pas microsoft ou sun avec leurs milliers de développeurs qui sont payés et à qui on met une pression monstre) donc aussi à nous de les aidez si on peux et du mieux que l'on peux. :oops:

C'est dans beaucoup de chose comme ça malheureusement et on y peux rien. (un truc bête par exemple sous linux quand tu ouvre Lazarus tu te retrouve avec 15 boutons dans la barre des taches en bas 1 par fenêtre, et cela fait combien de temps que les utilisateurs peste avec ça ? hein ? idem qu'ici. Ou pire regardes avec nos politiciens)

Pour en revenir au sujet. C'est déja compliqué pour nous de faire quelques choses de portable, alors pour les developpeurs de Lazarus/FPC j'imagine même pas. Par contre un truc qui serai sympa de vérifier ça serai avec code typhon pour voir si ce bug apparait aussi.

Citation:

---

Envoyé par Jipété

Sinon, pour en revenir au sujet d'origine, j'ai retrouvé ça, dans un coin, je te laisse y jeter un œil et si tu veux le downloader, passe par le second lien, le svn, il est plus à jour que l'autre il me semble (ah, les joies de l'internet et du non-suivi des informations...)

---

Merci j'avais déja vu 8-)

Bref j'ai continué mon dev avec le fastbitmap, j'ai rajouté quelques fonctions pour tracé des lignes, cercles, ellipses ect....

Citation:

---

Envoyé par BeanzMaster

Et oui on contourne, le problème, on le sait donc on trouve des solutions alternatives. Ce que je peux dire la dessus c'est que ce n'est pas le chargement du bitmap qui pose problème, c'est la fonction "StrechDraw" de lazarus qui bug (j'ai vérifié)

---

Détaille, ça m'intéresse...

Tiens, en échange

Citation:

---

Envoyé par BeanzMaster

C'est dans beaucoup de choses comme ça malheureusement et on n'y peux rien. (un truc bête par exemple sous linux quand tu ouvre Lazarus tu te retrouves avec 15 boutons dans la barre des tâches en bas 1 par fenêtre, et cela fait combien de temps que les utilisateurs pestent avec ça ? hein ? idem qu'ici.)

---

Menu Outils / Options...
Pièce jointe 226050
1^re option,
8-)

Citation:

---

Envoyé par Jipété

Détaille, ça m'intéresse...

Tiens, en échange

Menu Outils / Options...
Pièce jointe 226050
1^re option,
8-)

---

Marche pas sous ma mv car je peux pas compiler l'ide :aie: il me trouve pas la librairie "GL"

Sinon pour le détail, tiens voila un zip tout neuf Pièce jointe 226115
par contre effaces les anciens codes ou met les ailleurs afin que ca ne rentre pas en conflit avant de tester
Pour tester le StretchDraw va dans le Beanz.inc et active {.$DEFINE FORCE_USE_LCL}, mais je crois que c'est déjà fait. Ouvre le projet DrawTest. J'ai pas pu tester sous ma mv Linux car impossible de compiler l'ide. faudrait que je vire l'opengl dans ce projet pour tester

Sinon ben me suis amuser un peu aujourd'hui. Et j'ai ressortie des vieux bout de code de plus de 15 ans et ai fais quelques démos qui fonctionnent sous windows

Pièce jointe 226117

et sous Linux

Pièce jointe 226118

Ha oui petite info avec ton FondRVB.Bmp il apparait sans soucis dans la boite de dialogue sous Windows et s'affiche très bien également avec "StretchDraw" donc voila dis moi apres avoir tester avec le projet DrawTest

Et en plus dans FastBitmap comme je l'avais dis j'ai rajouté quelques fonctions basiques de dessin : Ligne, cercle, ellipse, box, + les Textes avec le compo de Mitchell mais pas super l'affichage, faudra que j'y jette un œil plus profondément pour améliorer ça.

Bon je viens de tester Drawtest, j'ai viré l'opengl.

pour afficher ton FondRVB.Bmp faut faire dans la procedure drawto :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

Var P:TPoint; begin UpdateData; P := TGTKDeviceContext(Canvas.Handle).Offset; Inc(R.Left, P.X); Inc(R.Top, P.Y); gdk_draw_rgb_32_image(TGTKDeviceContext(Canvas.Handle).Drawable, TGTKDeviceContext(Canvas.Handle).GC, R.Left, R.Top, Width, Height, GDK_RGB_DITHER_NORMAL, RawImage.Data, RawImage.Description.BytesPerLine); End;

---

par contre marche pas ton truc pour les fenêtres dans ma mv. Alors quand virant LAzOpenGLContext l'EDI à bien compiler cette fois :weird:

Citation:

---

Envoyé par BeanzMaster

par contre marche pas ton truc pour les fenêtres dans ma mv. Alors quand virant LAzOpenGLContext l'EDI à bien compiler cette fois :weird:

---

Citation:

---

Envoyé par BeanzMaster

Marche pas sous ma mv car je peux pas compiler l'ide :aie: il me trouve pas la librairie "GL"

---

Tu plaisantes, j'espère ?
Pièce jointe 226125

Machine virtuelle Debian7.2 Lazarus 1.6rc1

Citation:

---

Envoyé par BeanzMaster

Sinon pour le détail, tiens voila un zip tout neuf
par contre efface les anciens codes ou mets-les ailleurs afin que ça ne rentre pas en conflit avant de tester

---

Je fatigue, là, je fatigue...
Tu me dis de virer mes vieux (oh, d'hier ou avant-hier, pas plus vieux) modules, résultat je retombe sur cette erreur et il y en a une tartine :
Pièce jointe 226126

Tu es sûr que tu testes sous Windows ET sous Linux :koi:

Bon, pour me sortir de cette pagaille, j'ai (à nouveau !) viré ce ucrossplatform.pas qui ne sert à rien ici (juste récupéré une nouvelle fonction...) à part nous embrouiller : rappel, on est dans l'étude d'un composant graphique, pas dans le montage d'une grosse application cross-platform, alors tout ce bazar de taille mémoire, espace disque, etc., on s'en tamponne un peu, ça complique et c'est tout ce que ça fait.

Donc, dans FastBitmapCore :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

//===[ TFASTFONT ]============================================================== Constructor TFastFont.Create(Image: TFastBitmap); Var Path:String; // Fixe les problèmes de délimiteur de path suivant le système procedure FixPathDelimiter(var S: string); // vient de uCrossPlatform.pas var I: Integer; begin for I := Length(S) downto 1 do if (S[I] = '/') or (S[I] = '\') then S[I] := PathDelim; end; Begin FImage := Image; BuildGammaTables; FFreeTypeFont := TFreeTypeFont.Create; FFreeTypeFont.ClearType := False; FFreeTypeFont.Quality:=grqHighQuality; Path:=ExtractFilePath(ParamStr(0))+'fonts\'; FixPathDelimiter(Path); FFontPath:=Path; End;

---

et dans umainform.pas, j'ai fait plus lisible :

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

procedure TMainForm.FormCreate(Sender: TObject); begin With BackgroundColor Do Begin Red := 0; Green := 0; Blue := 0; Alpha := 255; End;   TestImage := TFastImage.Create(nil); with TestImage do begin Parent:=self; Align:=alClient; Picture.Width :=TestImage.Parent.Width; Picture.Height:=TestImage.Parent.Height; Picture.Clear(BackgroundColor); Picture.Changed(); Center:=true; Stretch:=true; Proportional:=true; Picture.Font.LoadFromFile(Picture.Font.FontPath+'Sawasdee-Bold.ttf'); Picture.Font.Color:=ccolWhite; end;   OpenGLControl := TOpenGLControl.Create(nil); with OpenGLControl do begin Parent:=self; Align:=alClient; Visible:=false; OnPaint:=@OpenGLControlPaint; end; end;

---

et j'ai rendu pérenne l'information utile dans actLoadImageExecute (parce qu'une fois que t'as cliqué, t'as perdu l'info :aie:) :

Code:

---

1 2	//ShowMessage('Fast Bitmap Load Time: '+FormatFloat('0.00', MSecsPerDay*LoadTime)+'ms'); Caption := 'Fast Bitmap Load Time: '+FormatFloat('0.00', MSecsPerDay*LoadTime)+' ms';

---

Par contre, le benchmark est curieux, maintenant : il me semblait qu'il comptait à toute allure jusqu'à 255 et là tout ce que j'ai c'est ce 2 minable (ou le reste est à droite ?) :
Pièce jointe 226129

Ah, j'ai trouvé : comportement normal si on le lance à l'ouverture du prog, comportement déglingué si on le lance après avoir ouvert une image d'abord :koi:
Résultats en mode "lancé à l'ouverture" :
16,66 ms (60 fps) en OpenGL
49,02 ms (20 fps) en FastBitmap : t'es sûr que c'est fast ?

Question code, je n'ai touché à rien mis à part ce qui est indiqué ci-dessus.
Le souci c'est que pendant quelques jours je vais avoir moins, beaucoup moins de disponibilité, à cause d'un autre truc à faire avancer...

EDIT : certaines images ont du mal, c'est terrible... Là, c'est le cercle que j'ai montré hier, d'abord ouvert en .bmp puis en .png : quand la mémoire ou je ne sais quoi est corrompue par le .bmp, ça le reste pour le .png...
Pièce jointe 226132
/EDIT

Citation:

---

Envoyé par Jipété

Tu plaisantes, j'espère ?
Pièce jointe 226125

Machine virtuelle Debian7.2 Lazarus 1.6rc1

---

Non !
Pièce jointe 226134

Citation:

---

Envoyé par Jipété

Je fatigue, là, je fatigue...
Tu me dis de virer mes vieux (oh, d'hier ou avant-hier, pas plus vieux) modules, résultat je retombe sur cette erreur et il y en a une tartine :
Tu es sûr que tu testes sous Windows ET sous Linux :koi:

---

je ne me l'explique pas chez moi ça fonctionne.

Citation:

---

Envoyé par Jipété

et dans umainform.pas, j'ai fait plus lisible :
...et j'ai rendu pérenne l'information utile dans actLoadImageExecute (parce qu'une fois que t'as cliqué, t'as perdu l'info :aie:) :

Par contre, le benchmark est curieux, maintenant : il me semblait qu'il comptait à toute allure jusqu'à 255 et là tout ce que j'ai c'est ce 2 minable (ou le reste est à droite ?) :
..
Ah, j'ai trouvé : comportement normal si on le lance à l'ouverture du prog, comportement déglingué si on le lance après avoir ouvert une image d'abord :koi:
Résultats en mode "lancé à l'ouverture" :

---

J'ai fais tes changements. Par contre impossible de tester avec opengl sous Linux dans ma mv
Pour que le benchmark soit correct faut rajouter dans:
- procedure TMainForm.actUseOpenGLExecute(Sender: TObject);
- procedure TMainForm.actUseFastBitmapExecute(Sender: TObject);
- procedure TMainForm.actBenchmarkExecute(Sender: TObject);

Code:

---

1 2	TestImage.Picture.SetSize(ClientWidth,ClientHeight);

---

Car des que tu ouvres une image cela modifie la taille du buffer.

Citation:

---

Envoyé par Jipété

16,66 ms (60 fps) en OpenGL
49,02 ms (20 fps) en FastBitmap : t'es sûr que c'est fast ?

EDIT : certaines images ont du mal, c'est terrible... Là, c'est le cercle que j'ai montré hier, d'abord ouvert en .bmp puis en .png : quand la mémoire ou je ne sais quoi est corrompue par le .bmp, ça le reste pour le .png...

---

ben regardes les captures chez moi. Et pour ton fichier FondRVB.Bmp je confirme il s'affiche bien dans le Drawtest sous Linux et Windows :
Pièce jointe 226140
Pièce jointe 226136
Pièce jointe 226137
Pièce jointe 226138

et le bench sous linux
Pièce jointe 226139

je vais installer dans la semaine ta version linux debian 7.2 dans une mv. Comme ca on aura les 2 la même base pour l'os linux

Bonjour,

Alors voila je viens d'installer une mv Debian Jessie, installer Lazarus 1.6.2 et lancer le projet DrawTest en essayant d'afficher le FondRVB.Bmp et ben c'est tout comme toi Jipete j'ai le même rendu dans le OpenPictureDialog et l'image ne s'affiche pas que j'utilise la fonction StretchDraw (Pour tester le StretchDraw va dans le Beanz.inc et active {.$DEFINE FORCE_USE_LCL}, désactive pour avoir les meilleurs perfs ) ou que j'utilise la fonction GTK. Il semblerai donc que ce ne soit pas Lazarus le fautif de ce mauvais affichage mais plutôt de la Distribution Debian. Y'aurait-il une mise à jour spéciale des librairies GTK à faire ? Est-ce que le gestionnaire d'environnement Gnome est la cause ?

Debian :
Pièce jointe 226309
Pièce jointe 226310

et sous Linux Mint :

Pièce jointe 226312

Voila, va comprendre et surtout comment l'expliquer ?

Je vais essayer de passer linux mint avec gnome pour voir

Yop !

Citation:

---

Envoyé par BeanzMaster

Non !

---

À propos de tes multiples boutons dans la barre de tâches malgré l'option cochée : c'est le moment de faire remonter le bug !

Citation:

---

Envoyé par BeanzMaster

Il semblerait donc que ce ne soit pas Lazarus le fautif de ce mauvais affichage mais plutôt de la Distribution Debian.

---

Pas d'accord, puisque le gestionnaire de fichiers affiche correctement la miniature et le visionneur d'images affiche correctement le fichier entier. Donc non, ce n'est pas un pb Debian, c'est un pb avec nos binaires...
D'autant plus que t'as dû toucher quelque chose dans la dernière version car maintenant, même le binaire dans la machine physique n'ouvre plus le fichier qui est prévisualisé avec les traits ! (il est bien affiché avec la version précédente : mal prévisualisé mais bien affiché...)

Mais ce qui m'ennuie surtout, c'est que j'ai ouvert un fichier en 24 bits et là tout va bien (prévisu OK, affichage OK), sauf que dans une machine virtuelle XP équipée d'un vieux PaintShoPro c'est pour ce fichier bien affiché sous Nux que PSP me dit que "ce n'est pas un fichier valide" !
À côté de ça, PSP affiche très bien celui que nos Debian n'arrivent pas à afficher. :mur:

Et ce qui ne va pas nous faciliter la tâche pour dépatouiller tout ça (je me demande si on ne perd pas notre temps), c'est que les infos remontées par Picture.Description sont les mêmes quelle que soit l'image...

EDIT : je viens d'essayer d'ouvrir un .tif, et voilà ce que ça donne :
au milieu en haut la miniature dans l'explorateur, à droite le fichier en question dans Gimp, et à gauche l'aperçu dans la fenêtre OpenPictureDialog :
Pièce jointe 226341
C'est pas brillant.
Et si je demande à l'ouvrir, ça l'est encore moins...
Pièce jointe 226342

Le fichier en question, si tu veux jouer : Pièce jointe 226343

C'est marrant, ça me fait penser à un vieux bug que j'avais découvert dans le reader FreePascal des .tiff's, faudra que je fouille...
/EDIT

Bonjour,
Je me cite, car j'ai creusé un peu tout ça :

Citation:

---

Envoyé par Jipété

EDIT : je viens d'essayer d'ouvrir un .tif, et voilà ce que ça donne :
au milieu en haut la miniature dans l'explorateur, à droite le fichier en question dans Gimp, et à gauche l'aperçu dans la fenêtre OpenPictureDialog :
Pièce jointe 226341
C'est pas brillant.
Et si je demande à l'ouvrir, ça l'est encore moins...
Pièce jointe 226342

Le fichier en question, si tu veux jouer : Pièce jointe 226343

C'est marrant, ça me fait penser à un vieux bug que j'avais découvert dans le reader FreePascal des .tiff's, faudra que je fouille...
/EDIT

---

Alors d'abord, ça n'a pas de rapport avec le bug repéré il y a quelques années.

Et ensuite, en fouillant dans fpcsrc/2.6.2/pacakages/fcl-image/src/fpreadtiff.pas, on trouve ça (je n'ai mis que ce qui est significatif) :

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

TFPReaderTiff = class(TFPCustomImageReader) private s: TStream;   procedure TFPReaderTiff.ReadDirectoryEntry(var EntryTag: Word); case EntryTag of 262: begin // PhotometricInterpretation UValue:=ReadEntryUnsigned; case UValue of 0: ; // bilevel grayscale 0 is white 1: ; // bilevel grayscale 0 is black 2: ; // RGB 0,0,0 is black 3: ; // Palette color 4: ; // Transparency Mask 5: ; // CMYK else TiffError('expected PhotometricInterpretation, but found '+IntToStr(UValue)); end; // mon message : "" "" but found 8 at position 80   // l'explication du complément au message : procedure TFPReaderTiff.TiffError(Msg: string); begin Msg:=Msg+' at position '+IntToStr(s.Position);   //L'appel vient de function TFPReaderTiff.ReadIFD(Start: DWord): DWord; var Count: Word; i: Integer; EntryTag: Word; p: Int64; begin {$ifdef FPC_Debug_Image} if Debug then writeln('ReadIFD Start=',Start); {$endif} Result:=0; SetStreamPos(Start); IFD.IFDStart:=Start; Count:=ReadWord; EntryTag:=0; p:=s.Position; for i:=1 to Count do begin ReadDirectoryEntry(EntryTag); // là inc(p,12); s.Position:=p; // et ça pour la fin du message ("at position 80") end;

---

On trouve la même chose dans la 3.0.0, ligne 740 et suivantes.

Quand on compare les ToDo des deux fichiers, ce sont exactement les mêmes...

Ce n'est donc pas un bug, mais une lacune ? Voir http://www.awaresystems.be/imaging/t...pretation.html indiquant que l'image serait dans un espace de couleur non supporté : https://en.wikipedia.org/wiki/Lab_color_space

Bonjour, Y.

Tiens, tu m'as mis la puce à l'oreille, j'ai réouvert le fichier (d'abord avec mon vieux PaintShopPro de '95 qui se vautre au niveau des couleurs mais qui l'ouvre quand même) avec Gimp et l'ai enregistré sans compression LZW ! et bingo : la prévisu fonctionne, l'affichage dans l'outil aussi, juste que le fichier passe de 55 ko à 1,7 Mo, ouch !
Ça fait mal à l'espace disque, ça !
Et il faut encore adapter le fichier à l'outil, quand ça devrait être l'inverse. Pas viable pas fiable, ça...

À noter que PSP n'a plus de problème de couleur avec le non-compressé... :koi:
(quand le forum sera réparé, je rajouterai l'image qui est prête et que je ne peux pas insérer -ici-)
Pièce jointe 226570

J'aurais bien aimé retrouver l'original, j'ai saisi l'url qu'on peut lire, plein de choses intéressantes mais plus ce fichier, dommage...

Citation:

---

Envoyé par tourlourou

l'image serait dans un espace de couleur non supporté

---

Comment ça, non supporté ? Ton premier lien (dommage que les sous-liens vers Adobe soient morts -- quelle misère cet internet...) le dit lui -même :

Citation:

---

These values are considered an extension:

5 = Seperated, usually CMYK.
6 = YCbCr
8 = CIE L*a*b* (see also specification supplements 1 and 2)
9 = CIE L*a*b*, alternate encoding also known as ICC L*a*b* (see also specification supplements 1 and 2)

---

Parce que si CIE L*a*b* (et, non, ces étoiles ne sont pas le signe d'espaces insécables suite au passage du post dans LibreOffice, elles font partie du nom) n'est pas supporté, autant que je lâche le clavier pour me mettre au violoncelle :mouarf: