Discussion :

[Jipété]

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"

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

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


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

[BeanzMaster]

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

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

[Jipété]

Salut !

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

Tu as modifié la fonction "Description" ?

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

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

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
- en bas le même fichier dans l'outil de Mitchell


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

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

[Jipété]

Et oui...

Regardez l'image :

à 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 : FondRVB.bmp.zip

[BeanzMaster]

Et oui...

Regardez l'image :

à 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 : FondRVB.bmp.zip

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)



C'est franchement bizarre

[Jipété]

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 :


C'est + clair, là ?

[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

[Jipété]

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

[Jipété]

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

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

[BeanzMaster]

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

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.

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.

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

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

[Jipété]

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

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

1^re option,

[BeanzMaster]

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

Tiens, en échange

Menu Outils / Options...

1^re option,

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

Sinon pour le détail, tiens voila un zip tout neuf fastbitmap.zip
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



et sous Linux



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.

[BeanzMaster]

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

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

Code :

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

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

[Jipété]

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

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

Tu plaisantes, j'espère ?


Machine virtuelle Debian7.2 Lazarus 1.6rc1

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 :


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

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 :

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
//===[ 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 :

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

Code :

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

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


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

/EDIT

[BeanzMaster]

Tu plaisantes, j'espère ?


Machine virtuelle Debian7.2 Lazarus 1.6rc1

Non !

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

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

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

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

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

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

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

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 :





et le bench sous linux


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

[BeanzMaster]

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 :



et sous Linux Mint :



Voila, va comprendre et surtout comment l'expliquer ?

Je vais essayer de passer linux mint avec gnome pour voir

[Jipété]

Yop !

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 !

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.

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 :

C'est pas brillant.
Et si je demande à l'ouvrir, ça l'est encore moins...


Le fichier en question, si tu veux jouer : ColorCheckerCalculator.tif.zip

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

[Jipété]

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

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 :

C'est pas brillant.
Et si je demande à l'ouvrir, ça l'est encore moins...


Le fichier en question, si tu veux jouer : ColorCheckerCalculator.tif.zip

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 :

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

[tourlourou]

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

[Jipété]

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é...
(quand le forum sera réparé, je rajouterai l'image qui est prête et que je ne peux pas insérer -ici-)


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

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 :

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