Discussion :

[BeanzMaster]

Pour en revenir à ton zip avec la méthode 5, ce qui m'a surpris, c'est que tu as dégagé les tests de base du TBitmap qui s'appuie maintenant sur le truc à Mitchell, si j'ai bien décodé, et donc on ne peut plus trop comparer grand chose...

Oui et non, on a encore le zip de mon post précédent, c'est que c'était beaucoup rapide de changer le TFastBitmap par TCompactImage que surcharger tout le bouzin pour accepter les 2 composants. Mais c'est vrai ca serai sympa d'avoir les 2 dans le même projet. J'y jetterai un oeil dimanche. Avec mes horaires coupées et juste 1h30/2h en gros l'apres-midi c'est pas le top pour se concentrer. Et le soir idem.

[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,

[Jipété]

Jai voulu tester TLazIntfImage, me disant "on ne sait jamais..."
On va sans doute penser que j'y mets de la mauvaise volonté mais je suis tout simplement parti d'un bout de code trouvé dans le wiki, et ça donne ça :

1- d'abord le bout copié/collé est foireux, ça commence bien :

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
procedure TForm1.Button1Click(Sender: TObject);
var
  b: TBitmap;
  t: TLazIntfImage;
begin
  b := TBitmap.Create;
  if opd.Execute then // ajout
  try
    b.LoadFromFile(opd.FileName);
    t := b.CreateIntfImage;
    // Read and/or write to the pixels
//    t.Colors[10,20] := colGreen; // erreur sur colGreen (l'original), erreur sur clGreen (pour essai rapide) -- heureusement, je n'en ai pas besoin pour ce test.
    b.LoadFromIntfImage(t);
    img.Canvas.Draw(0,0, b); // ajout
  finally
    t.Free;
    b.Free;
  end;
end;

2- ensuite je rajoute juste un TOpenPictureDialog (opd) et un TImage (img), je choisis le fichier "maudit" et voilà ce que ça donne :



à gauche dans le prog de test et à droite un afficheur quelconque de Linux, pour comparer.
C'est vraiment à vomir, quoi...

D'aucuns diront que c'est à cause du fichier d'origine qui a un souci, c'est possible (on en a causé là aujourd'hui), mais alors comment expliquer que la miniature de ce fichier sur le bureau soit bonne, que ça soit ok dans le visionneur comme ci-dessus et que The Gimp et ImageMagick l'ouvrent sans problèmes ?

Le souci est clairement dans le camp de Lazarus/FreePascal, et je n'ai pas les compétences pour dépatouiller cet énorme morceau.

[mm_71]

Jai voulu tester TLazIntfImage, me disant "on ne sait jamais..."
On va sans doute penser que j'y mets de la mauvaise volonté mais je suis tout simplement parti d'un bout de code trouvé dans le wiki, et ça donne ça :

1- d'abord le bout copié/collé est foireux, ça commence bien :

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
procedure TForm1.Button1Click(Sender: TObject);
var
  b: TBitmap;
  t: TLazIntfImage;
begin
  b := TBitmap.Create;
  if opd.Execute then // ajout
  try
    b.LoadFromFile(opd.FileName);
    t := b.CreateIntfImage;
    // Read and/or write to the pixels
//    t.Colors[10,20] := colGreen; // erreur sur colGreen (l'original), erreur sur clGreen (pour essai rapide) -- heureusement, je n'en ai pas besoin pour ce test.
    b.LoadFromIntfImage(t);
    img.Canvas.Draw(0,0, b); // ajout
  finally
    t.Free;
    b.Free;
  end;
end;

2- ensuite je rajoute juste un TOpenPictureDialog (opd) et un TImage (img), je choisis le fichier "maudit" et voilà ce que ça donne :



à gauche dans le prog de test et à droite un afficheur quelconque de Linux, pour comparer.
C'est vraiment à vomir, quoi...

D'aucuns diront que c'est à cause du fichier d'origine qui a un souci, c'est possible (on en a causé là aujourd'hui), mais alors comment expliquer que la miniature de ce fichier sur le bureau soit bonne, que ça soit ok dans le visionneur comme ci-dessus et que The Gimp et ImageMagick l'ouvrent sans problèmes ?

Le souci est clairement dans le camp de Lazarus/FreePascal, et je n'ai pas les compétences pour dépatouiller cet énorme morceau.

Ça me fait penser à une inversion de couleurs, ci-dessous le résultat donné par un swap U/V avec Avidemux suivi d'une inversion de couleurs avec Gimp. Si j'ai raison ça devrait être simple à corriger.

[Jipété]

Salut,

Ça me fait penser à une inversion de couleurs, ci-dessous le résultat donné par un swap U/V avec Avidemux suivi d'une inversion de couleurs avec Gimp. Si j'ai raison ça devrait être simple à corriger.

Tu as très certainement raison.
La seule chose que je ne m'explique pas, dans ta manip d'inversion, c'est la disparition du petit bout de ligne en vrac, en bas à droite :
Zoomé :
(Bon, déjà je ne m'explique pas d'où il sort...)

Et sinon,

D'aucuns diront que c'est à cause du fichier d'origine qui a un souci, [...] mais alors comment expliquer que la miniature de ce fichier sur le bureau soit bonne, que ça soit ok dans le visionneur comme ci-dessus et que The Gimp et ImageMagick l'ouvrent sans problèmes ?

Je viens de faire un test à l'instant : le fichier d'origine s'ouvre parfaitement bien avec le basique MSPaint d'un vieux XP sp2...
Tout comme LazPaint 6.3, d'ailleurs (qui se vautre sur le fichier CIE L*a*b*...)

[Jipété]

Bonjour,

je crois que j'ai enfin réussi à déboucher de l'autre côté du tunnel, que je pensais sans fin,

À l'inverse de l'ami Jérôme et son usine à gaz (mais ce n'est pas un reproche, il faut des usines à gaz pour alimenter les habitants des grandes villes), en ce qui me concerne et n'ayant qu'un petit besoin limité à quelque chose de précis, je me suis dit qu'un simple campingaz posé sur trois pierres ça le ferait (à condition de bien le caler, pas qu'il fiche le feu à la forêt, ).

J'ai testé le code qui suit avec les deux unités "Mitchell", savoir CompImages.pas & LCLCompImages.pas et les quelques lignes ci-après.

Pour le mettre en œuvre, il faut un bouton, un TImage, une case à cocher accessoire, un TMemo accessoire aussi, et une OpenPictureDialog, that's all, folks !

Tout est là, et cette chose a pu ouvrir tous mes bmp 24 et 32 bits, même celui que LazPaint n'ouvre pas...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
procedure TForm1.Button1Click(Sender: TObject);
var
  Start:  DWORD;
  bmp: TBitmap;
  p: pRGBQuad;
  OffsetToDatas, VersionHeader, biBitCount: integer;
 
  function GetVersionHeader(biSize: integer): integer;
  begin 
    case biSize of
       12: Result:=9; // perso : pour os/2
       40: Result:=1;
       52: Result:=2; // non documenté, utilisé par Adobe
       56: Result:=3; // non documenté, utilisé par Adobe
      108: Result:=4;
      124: Result:=5;
      else Result:=0;
    end;
  end;
 
  procedure GetHeaderInfos(f: string; b: TBitmap);
  var
    bs: TBytesStream;
  begin
    bs := TBytesStream.Create;
    if b = nil then bs.LoadFromFile(f);
    if f = ''  then b.SaveToStream(bs);
    bs.Position   := 10; // bfOffBits  @0A
    OffsetToDatas := bs.ReadDWord;
    bs.Position   := 14; // biSize     @0E
    VersionHeader := GetVersionHeader(bs.ReadDWord);
    bs.Position   := 28; // biBitCount @1C
    biBitCount    := bs.ReadWord;
    bs.Free;
  end;
 
  procedure WorkWithMitchell(Filename: String);
  var
    w,h: Integer;
  begin
    ci := TCompactImage.Create(0,0);
    ci.LoadFromFile(FileName);
    with img do begin
      Picture := nil;
      Width := ci.Width;
      Height:= ci.Height;
    end;
    lclci := TLCLCompactImage.Create(ci); // Update des dimensions inclus dans le Create
    //Memo1.Text:=lclci.Description;
    GetHeaderInfos(filename, nil);
    bmp:=TBitmap.Create;
    with bmp do begin
      //PixelFormat et dimensions inutiles, positionnés par Assign
      Assign(lclci.ImageBitmap);
      if biBitCount = 32 then begin // +1 et PAS PixelFormat qui est tjrs à 32 !
        BeginUpdate();
        for h := 0 to Height-1 do begin
          p := pRGBQuad(RawImage.GetLineStart(h));
          for w := 0 to Width-1 do begin 
            if p[w].rgbReserved = 0
            then p[w].rgbReserved := 255
            else if (p[w].rgbReserved < 255) then p[w].rgbReserved := 255-p[w].rgbReserved;
            // < 255 car si 00 dans le fichier alors Mitchell inverse à 255. Des heures là-dessus...
          end;
        end; //for h
        EndUpdate();
      end; //if BC
      if ckbxSave.Checked then SaveToFile('/chemin/test.bmp');
    end; //with bmp
    img.Picture.Bitmap.Assign(bmp);
 
    if ckbxShowInfos.Checked then
      Memo1.Text:=StringReplace(img.Picture.Bitmap.RawImage.Description.AsString, ' ', LineEnding, [rfReplaceAll]);
    bmp.Free;
    lclci.Free;
    ci.Free;
  end;
 
begin
  if opd.Execute then begin
    Start := GetTickCount;
    WorkWithMitchell(opd.Filename);
    Caption := IntToStr(GetTickCount-Start) + ' millisec';
  end;
end;

Voilà,
Merci de tester et de me dire -- attention, il n'y a aucun contrôle sur la validité des fichiers passés, à vous de gérer correctement vos trucs.

[Jipété]

Merci pour les explications, le retour, les tests, le zip, toussa toussa, je verrai ça demain, car là maintenant je commence à en avoir un peu franchement marre, entre les màj moisies et une nouvelle galère pas piquée des vers, c'est bon, là, au pieu !

[BeanzMaster]

Salut à tous, me revoilà

Ce petit projet m'a permis de faire un peu de ménage dans quelques un de mes codes source. Et m'a permis de mieux comprendre certaines chose sur les "Bitmaps" avec FPC.
Malgré quelques déboire notamment avec une variable de type TPoint, ou sa valeur disparaissait d'une procédure à l'autre et quelques soucis avec les accès aux pointers. Voila un Benchmark sur les différentes façon d'accéder aux pixels d'un Bitmap. Tout fonctionne très bien chez moi sous Win 10 64bit et y'a pas de fuite de mémoire. Et en plus tout est "In French" Un petit screen de la bête :



et voila les sources complètes pour tester : fastbitmap.zip

Vous trouverez dans le zip un package "FastBitmap.LPK" à installer. Celui-ci vous ajoutera un jolie nouvel onglet avec 1 composant TFastImage.
J'ai essayé de commenter du mieux que je pouvais les sources (FastBitmap.pas, CustomFastBitmapHandler.pas, LCLFastBitmapHandler.pas)
Ensuite dans le dossier Demos 2 sous dossiers avec 2 petits test. 1 le Benchmark et le 2 c'est l'exemple de Mitchell

Bon on peux maintenant pousser plus loin en ajoutant un affichage avec transparence (du moins sous windows) en utilisant AlphaBlend au lieu de StrechBit. On peux bien sur aussi ajouter toutes les fonctions de dessins usuel à notre TFastBitmap (line, circle, rectangle ect...)

Voila chez vous les tests en terme de perf ça donne quoi ?

Bonne soirée

[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