Discussion :

[BeanzMaster]

Comme quoi rester simple est ce qui paye le mieux

Elle se passe ou la Teuf et quand ? Peut-être à la première "Lazcon" de France

[Alcatîz]

N'y aurait-il pas matière à un copieux article de fond sur la gestion des bitmaps avec Lazarus ?

[Jipété]

Merci

N'y aurait-il pas matière à un copieux article de fond sur la gestion des bitmaps avec Lazarus ?

Oh, on peut résumer en sept mots : tu prends, tu testes et tu jettes.

Si t'as tout lu, tu as découvert mon plan "je verrouille la form pendant que les contrôles sont mis à jour par-dessous" et ce matin j'ai découvert avec une stupéfaction vraiment attristée que ça verrouille tellement bien que si je trafique la couleur des pixels avec Scanline (plus rapide que le traitement à base de TLaz et ses couleurs sur 16 bits pour des fichiers 24 bits), ben en fin de proc le TImage n'est pas mis à jour...
Peut-être à cause du Begin/EndUpdate du bitmap de travail ? Je ne sais pas, en attendant, supprimés, les verrouillages, tant pis pour le scintillement.

Sans compter que le traitement à base de ScanLine a encore une blague ; dans l'image ci-dessous on a de haut en bas l'image source, l'image modifiée (bleu -20 plusieurs fois) avec TLaz et en bas même chose avec ScanLine où on voit bien qu'il y a un souci, toujours le même avec ScanLine : non-concordance des je-sais-pas-quoi puisque là tout est en 24 bits...


Je sais pas où chercher, vraiment je sais pas, je mets le bout de code à tout hasard mais franchement, c'est juste impensable...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
    try // pSrc et pDst sont des pRGBTriple, tmpBmp c'est le bitmap source
      bmpDst.BeginUpdate;
      for h := 0 to tmpBmp.Height-1 do begin
         pSrc := pRGBTriple(tmpBmp.RawImage.GetLineStart(h));
         pDst := pRGBTriple(bmpDst.RawImage.GetLineStart(h));
         for w := 0 to tmpBmp.Width-1 do pDst[w] := CorrigeLesPixels(pSrc[w]);
      end;
      Result := True;
    finally
      bmpDst.EndUpdate;
    end;
    if Result then img4result.Canvas.Draw(0,0, bmpDst);

Je précise à tout hasard que si je fais jouer la proc de correction plusieurs fois avec tous les coeff's à 0 alors l'image résultante n'est pas modifiée, ce qui est le résultat escompté, mais n'est pas abîmée non plus.
Pour obtenir l'image foireuse, j'avais donc demandé Blue-20 et j'aurais mieux compris si le défaut avait été présent sur toute la largeur de l'image, mais ShowMessage(IntToStr(tmpBmp.Width)); montre une valeur correcte.

Encore un brave mystère...

[BeanzMaster]

Salut j'ai essayé ça vite fait cela fonctionne nickel chez moi, donc je sais 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
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
 
Unit unit2;
 
{$mode objfpc}{$H+}
 
Interface
 
Uses
  lclIntf, lclType,Classes, Sysutils, Fileutil, Forms, Controls, Graphics, Dialogs, ExtCtrls, StdCtrls, ComCtrls, ExtDlgs;
 
Type
 
  { Tform1 }
 
  Tform1 = Class(Tform)
    btnOpen : Tbutton;
    img4Result : Timage;
    OPD : Topenpicturedialog;
    tbAdjustR : Ttrackbar;
    tbAdjustG : Ttrackbar;
    tbAdjustB : Ttrackbar;
    Procedure Btnopenclick(Sender : Tobject);
    Procedure Formcreate(Sender : Tobject);
    Procedure Formdestroy(Sender : Tobject);
    Procedure Tbadjustrchange(Sender : Tobject);
  Private
 
  Public
    bmpDest, bmpSrc : TBitmap;
    rp,gp,bp : Integer;
    procedure AdjustBitmap;
  End;
 
Var
  Form1 : Tform1;
 
Implementation
 
{$R *.lfm}
 
{ Tform1 }
 
procedure Tform1.AdjustBitmap;
  function CorrigePixels(aColor: TRGBTriple): TRGBTriple;
      var
        r,g,b: integer;
      begin
        r:=aColor.rgbtRed  +rp; if r > 255 then r:=255; if r < 0 then r:=0;
        g:=aColor.rgbtGreen+gp; if g > 255 then g:=255; if g < 0 then g:=0;
        b:=aColor.rgbtBlue +bp; if b > 2555 then b:=255; if b < 0 then b:=0;
        Result.rgbtred:=r; Result.rgbtgreen:=g; Result.rgbtblue:=b;
        // 2 lignes gardées pour tests : 1re = couleurs fixes,ok - 2e = copie à l'identique
        //Result.red:=255 shl 8; Result.green:=255 shl 8; Result.blue:=0 shl 8;
        //Result.red:=aColor.Red shl 8; Result.green:=aColor.Green shl 8; Result.blue:=aColor.Blue shl 8;
        //Result.alpha:=255 shl 8;
        // alpha inutile ? Commenté = fonctionne tout aussi bien
      end;
var
  pDst, pSrc : pRGBTriple;
  h,w : Integer;
begin
// pSrc et pDst sont des pRGBTriple, tmpBmp c'est le bitmap source
  bmpDest.BeginUpdate;
  for h := 0 to BmpSrc.Height-1 do begin
     pSrc := pRGBTriple(BmpSrc.RawImage.GetLineStart(h));
     pDst := pRGBTriple(bmpDest.RawImage.GetLineStart(h));
     for w := 0 to BmpSrc.Width-1 do
     begin
       pDst[w] := CorrigePixels(pSrc[w]);
     End;
  end;
 
  bmpDest.EndUpdate;
  img4result.Canvas.Draw(0,0, bmpDest);
End;
 
Procedure Tform1.Formcreate(Sender : Tobject);
Begin
  bmpDest := TBitmap.Create;
  BmpSrc := TBitmap.Create;
End;
 
Procedure Tform1.Btnopenclick(Sender : Tobject);
Begin
  if OPD.Execute then
  begin
    bmpSrc.LoadFromFile(OPD.FileName);
    bmpDest.Height := bmpSrc.Height;
    bmpDest.PixelFormat := pf24bit;
    bmpDest.Width := bmpSrc.Width;
    bmpSrc.PixelFormat := pf24bit;
    img4result.Canvas.Draw(0,0, bmpSrc);
  End;
End;
 
Procedure Tform1.Formdestroy(Sender : Tobject);
Begin
  FreeAndNil(bmpDest);
  FreeAndNil(BmpSrc);
End;
 
Procedure Tform1.Tbadjustrchange(Sender : Tobject);
Begin
  rp := tbAdjustR.Position;
  gp := tbAdjustG.Position;
  bp := tbAdjustB.Position;
  Screen.Cursor := crHourGlass;
  AdjustBitmap;
  Screen.Cursor := crDefault;
End;
 
End.

Voila j'ai ouvert ton fichier 400x300x32_v3_96.bmp

[Jipété]

Salut j'ai essayé ça vite fait cela fonctionne nickel chez moi, donc je sais pas

Salut salut, et merci pour ton test (qui est d'ailleurs fort sympathique, avec les curseurs -- on se croirait dans 'toshop ou Gimp, ), il y a cependant une petite (ou énorme) différence avec ma manip :
- quand toi tu joues à appliquer des réglages différents toujours sur le fichier source,
- j'ai l'option qui me permet de rejouer en prenant comme source le résultat du précédent essai.
Elle est peut-être là, la blague !

Allez, je vais chercher...

EDIT :
D'ailleurs, comme la nuit porte conseil, ce matin je joue avec ça :

Code :

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

1
2
3
4
5
6
  if UseOriginal then
//    bmpSrc.Assign(img4source.Picture.Bitmap)
    bmpSrc.Assign(bmpFic)
  else
//    bmpSrc.Assign(img4result.Picture.Bitmap);
    bmpSrc.Assign(bmpDst);

C'est mieux, c'est beaucoup mieux puisque je n'ai plus les raies avec le fichier d'hier, j'étais prêt à crier victoire ! quand j'ai eu l'idée de tester avec un .jipègue et là, patatras, les raies verticales reviennent

Or, la procédure d'ouverture des fichiers est identique dans le sens où, quel que soit le type de fichier, ça se termine par les données dans bmpFic, et ça s'appuie sur ce qui est fourni par Lazarus (je vous la fais courte, tout ça est basé sur cette source puis, en fouillant dans Graphics.TPicture, je me suis rendu compte que je pouvais synthétiser) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Var
  pic: TPicture;
Begin
  pic := TPicture.Create;
  try
    pic.LoadFromFile(f);
    // la détermination jipègue <> béhèmpé se base sur l'extension du fichier
    if jipègue then o.Assign(pic.Jpeg); // "o" c'est bmpFic
    if béhèmpé then o.Assign(pic.Bitmap);
  finally
    pic.Free;
  end;
end;

Voilà.
À partir de ce point, je ne sais pas trouver où se cache la blagounette qui fait que la même image a un comportement différent avec ScanLine selon son extension, étant entendu que je pars toujours du même fichier .xcf (c'est du Gimp) pour faire des exports vers .bmp ou .jpg (sans compression pour ce genre de fichier de test).

Dans le zip joint, Lena en 400x300 un coup en béhèmpé et un coup en jipègue : Lena_bmp_jpg.zip

Pour cette image,

1. j'ai choisi le fichier .jpg
2. j'ai mis un 5 devant le 0 pour diminuer le rouge
3. j'ai coché l'utilisation de Scanline
4. j'ai gardé "l'image d'origine" (choix par défaut)
5. j'ai cliqué sur "Appliquer" et paf !, vous avez dans la petite fenêtre du ColorPicker un zoom sur le ciel au-dessus de la queue de l'avion

Les mêmes opérations sur le .bmp :


Un dernier mot : j'ai généré depuis le .bmp dans XP avec un récent XNViewer et un vieux PaintShopPro des .jpg qui, ouvert avec l'outil en cours de dév' et les réglages indiqués ci-dessus, présentent le même défaut.

Et mes 3 fichiers .jpg ouverts avec l'outil recompilé sous XP présentent le même défaut.
Étant entendu, je le rappelle, que les .bmp n'ont pas le défaut, sous Linux comme sous XP, j'en conclus que le problème est localisé dans la couche jpeg du TPicture.

Ah, sous XP je suis en 1.6rc1.
J'attends toujours la 1.8 définitive avant de migrer, mais elle est loooooongue à sortir...

[BeanzMaster]

Salut j'ai voulu essayé avec ton jipègue mais pff la misère

J'ai essayé tout ça et grrr l'image est juste noire

Code :

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

1
2
3
4
5
6
7
8
9
 
   Img4Result.Picture.LoadFromFile(OPD.FileName); //--> Ok je vois bien mon image dans le TImage
   bmpSrc.LoadFromFile(OPD.FileName);  // Wrong Image format ! pffffff quelle misère
   bmpsrc.Assign(Img4Result.Picture.Bitmap); // Ecran Noir
   bmpsrc.Assign(Img4Result.Picture.Jpeg); // Ecran Noir ///POURQUOI FAUT PASSER PAR JPEG !!! juste un truc à embrouilles supplémentaires
   bmpSrc.LoadFromRawImage(Img4Result.Picture.Jpeg.RawImage,false); // Ecran Noir
   bmpSrc.LoadFromRawImage(Img4Result.Picture.Bitmap.RawImage); // Ecran Noir
   bmpSrc.LoadFromBitmapHandles(Img4Result.Picture.Jpeg.BitmapHandle,Img4Result.Picture.Jpeg.MaskHandle); // Ecran Noir
   bmpSrc.Canvas.Draw(0,0,img4result.Picture.Bitmap); //idem

Que des choses aussi basiques ne fonctionnent pas c'est vraiment rageant que les devs de fpc/lazarus arrêtent de vouloir ressembler à DELPHI et qu'ils nous pondent des choses fonctionnels plutôt.

Bon je retourne à ma solution, c'est plus simple, et au moins quand je fais BmpSrc.LoadFromFile(Fic.BMP) ou fic.JPG, fic.PNG, fic.TGA, fic.PCX ect.... au moins l'image est chargée et si je fais bmpDest.Assign(bmpSrc); tout fonctionne.

A+ et bon courage

[Jipété]

Salut j'ai voulu essayé avec ton jipègue mais pff la misère

J'ai essayé tout ça et grrr l'image est juste noire

On dirait que tu as oublié ton principe fondamental

Comme quoi rester simple est ce qui paye le mieux

Et certaines erreurs sont justifiées, genre tu essayes de charger un TBitmap avec des données provenant directement d'un fichier contenant une structure Jpeg, ça ne peut pas le faire, donc "wrong format" c'est normal

Regarde, je te remets ce bout de code, plus simple c'est pas possible, si on fait abstraction du fait que jipègue et scanline ne font pas bon ménage et qu'on ne maîtrise rien à ce niveau, et là, oui, et  !

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Var
  pic: TPicture;
Begin
  pic := TPicture.Create;
  try
    pic.LoadFromFile(f);
    // la détermination jipègue <> béhèmpé se base sur l'extension du fichier
    if jipègue then o.Assign(pic.Jpeg); // "o" c'est bmpFic, utilisé comme source principale
    if béhèmpé then o.Assign(pic.Bitmap);
  finally
    pic.Free;
  end;
end;

Va donc jeter un œil dans Graphics.TPicture, tu vas y constater que ce machin est aussi capable d'ouvrir .ico, .png, .pnm et les pixmaps ! Pas mal, non ?

[BeanzMaster]

On dirait que tu as oublié ton principe fondamental

Et certaines erreurs sont justifiées, genre tu essayes de charger un TBitmap avec des données provenant directement d'un fichier contenant une structure Jpeg, ça ne peut pas le faire, donc "wrong format" c'est normal
.....

ah bon alors pourquoi c'est bon avec le TPicture du TImage Img4Result.Picture.LoadFromFile(OPD.FileName); //--> Ok je vois bien mon image dans le TImagehein dis moi ?
Regardes biens c'est pas le chargement qui foire c'est l'assignation de celui-ci vers au autre bitmap en l'occurence "bmpSrc" et Img4Result.Picture c'est bien un TPicture, non ?

Que ce soit du BMP ou du JPG elle est ou la différence a l'arrivée dans les données quand tu fais un Assign à ce stade du format on s'en balance, cela ne devrait pas être le problème.

bmpSrc.loadfromfile('fic.BMP') c'est ok si tu fais bmpSrc.LoadFromFile('fic.JPG') tu prend un mur "Wrong Image format !" en gros le format JPG n'est pas pris en charge pffff. Donc ce que tu me dis c'est qu'il faut utiliser TPicture et arrêter d'utiliser TBitmap. Ou bien faut que je passe par TLazIntImage pour certain format comme le XPM pour que tout soit ok. Je veux bien, mais pouquoi un simple Assign après le chargement BmpSrc.Assign(Image1.Picture.Bitmap) ça ne fonctionne pas ? tu peux l'expliquer ça ? parce que moi je ne comprend pas.
bmpSrc = TBitmap ---> Image1.Picture.Bitmap = TBitmap alors quid ???? si c'est pas un bug,faut m'expliquer, en

Franchement la base de TFPImage et et TLazIntf est bonne mais piouf ils ont du boulots l'équipe de dev de se coté parce que juste pour charger un simple JPG dans un TBitmap et pouvoir l'assigner à un autre c'est la misère.

[Jipété]

ah bon alors pourquoi c'est bon avec le TPicture du TImage Img4Result.Picture.LoadFromFile(OPD.FileName); //--> Ok je vois bien mon image dans le TImage hein dis moi ? Regarde bien c'est pas le chargement qui foire c'est l'assignation de celui-ci vers un autre bitmap en l'occurence "bmpSrc" et Img4Result.Picture c'est bien un TPicture, non ?

Non ! D'un côté c'est Graphics.TPicture et de l'autre c'est ExtCtrls.Timage.Picture sans T, rien à voir ! C'est vrai que la similitude de nom est perturbante, alors ne tombe pas dans ce piège, ces deux choses n'ont rien à voir.

Franchement la base de TFPImage et et TLazIntf est bonne mais piouf ils ont du boulot l'équipe de dev de ce côté parce que juste pour charger un simple JPG dans un TBitmap et pouvoir l'assigner à un autre c'est la misère.

Arrête arrête, on dirait que tu ne me lis pas, alors je suis cool, je te la remets encore, juste la partie qui te pose problème :

Code :

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

1
2
    pic.LoadFromFile(f); // pic c'est le TPicture de Graphics
    if jipègue then o.Assign(pic.Jpeg); // "o" c'est bmpFic, un TBitmap utilisé comme source principale que j'assigne à un TImage pour voir l'image

En fait, au plus j'y pense au plus je me dis qu'il faut bien séparer les choses : le TBitmap pour tout ce qui est travail sur pixels et autres, et complètement à la fin l'affichage sur le TImage pour voir le rendu des travaux.

Allez je retourne à ce caprice scanline/jipègue, les mains dans le cambouis à coups d'éditeur hexa...

[Jipété]

Allez je retourne à ce caprice scanline/jipègue, les mains dans le cambouis à coups d'éditeur hexa...

Jipété, le retour !

Yep !

je crois que j'ai trouvé... Ce qui m'a mis la puce à l'oreille c'est qu'en travaillant avec un tout petit fichier de 1 ligne de 3 pixels en 24 bits, si je demandais juste une modif du rouge, le premier pixel était bien modifié et le deuxième non, c'était le canal vert qui était impacté !

Ça, plus le fait que lors du chargement du bitmap de travail depuis le fichier image puis enregistrement direct du dit bitmap (bitmap_chargé.SaveToFile('/chemin/fichier.bmp');), sa taille passait de 134 à 66 octets selon que la source était .bmp ou .jpg, alors que je n'interviens absolument pas là-dessus, à part regarder avec l'éditeur Hexa qui montre des données bien identiques au niveau des datas de l'image :
(sur l'image est écrit deux fois "Enregistrement du TImage" et, oui, ça ne correspond pas à ce que j'ai écrit ci-dessus, mais comme le résultat est absolument identique, ben tant pis, ça reste -- marre de faire des copies d'écran...)
18₁₆ = 24₁₀ bits par pixel

Alors des vieilles réminiscences d'études de ScanLine m'ont fait me souvenir de décalages de couleurs, traits verticaux et autres embrouilles et, oui, vous me voyez venir :

pour jouer avec ScanLine sur un fichier Jpeg, il faut utiliser les pRGBQuad.

Gravez-le dans le marbre, ça, ou incrusté dans l'image de fond d'écran de votre bureau !

Ne me demandez pas pourquoi, je n'en sais rien, mais je le constate :

l'original, .bmp ou .jpg, aucune différence au niveau de son affichage dans son TImage après avoir été chargé dans le TBitmap ; je précise que le fichier source ainsi que son bitmap de travail et le TImage d'affichage ne sont jamais modifiés. ici, l'image, enfin, le bitmap de travail, a été corrigé en enlevant 50 points au canal rouge, source .bmp et scanline pRGBTriple en entrée et en sortie, c'est tout bon ; ensuite, chargement du .jpg et même correction, paf !, les raies verticales ; on continue dans la folie avec les mêmes fichier jpg et réglages, entrée pRGBQuad et sortie pRGBTriple ; là tout pareil sauf en inversant entrée et sortie ; et enfin victoire en utilisant pRGBQuad en entrée et en sortie ! Un truc de malade puisque le fichier source est en 24 bits...

Une histoire de widgetset ? Je ne sais pas trop, en tout cas le problème et sa solution étant identiques sous XP, va donc falloir que je blinde mon code de {$IFDEF JIPEGUE} si je veux conserver les calculs avec Scanline.

Merci de m'avoir lu jusqu'ici et de m'avoir supporté.
est déjà coché ? Tutti va bene, alors

[BeanzMaster]

Non ! D'un côté c'est Graphics.TPicture et de l'autre c'est ExtCtrls.Timage.Picture sans T, rien à voir ! C'est vrai que la similitude de nom est perturbante, alors ne tombe pas dans ce piège, ces deux choses n'ont rien à voir.

Code :

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

1
2
    pic.LoadFromFile(f); // pic c'est le TPicture de Graphics
    if jipègue then o.Assign(pic.Jpeg); // "o" c'est bmpFic, un TBitmap utilisé comme source principale que j'assigne à un TImage pour voir l'image

ExtCtrls.Timage.Picture = Graphics.TPICTURE remontes dans le code

C'est pour çà je persiste à dire que c'est buggé

On est capable de faire TImage.Picture.Bitmap.Assign(TBitmap) mais pas TBitmap.Assign(Timage.Picture.Bitmap) et ça c'est pas normal. On ne devrait pas se soucier de faire un test sur l'extension du fichier chargé comme tu le fais if jipègue then o.Assign(pic.Jpeg) de même que passer par un TPicture supplémentaire pour charger un fichier. Celui du TImage (comme j'ai voulu le faire) devrait être largement suffisant.

Dans tous les cas, une chose est sur ça bug sous la 1.8rc4
ce code pour charger un JPG, un PNG, PNM ou autre

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
   Begin
      pic := TPicture.Create;
      try
        pic.LoadFromFile(OPD.FileName);       
        BmpSrc.Assign(pic.Jpeg); // ---> Ne Fonctionne pas, idem avec Pic.PNG, Pic.PNM ect...
        //BmpSrc.Assign(pic.Bitmap); // Fonctionne qu'avec les BMP 
        // img4result.Picture.Assign(pic);  //-->La ok peut importe le format, mon image est affichée
      finally
        pic.Free;
      end;
    end;

ne fonctionne pas chez moi. BmpSrc est tout noir avec les fichier JPEG, pixmap, png, il n'y a que le bmp qui passe de cette façon
Le soucis des "scanlines" c'est dans la prise en charge du JPEG (et des autres) par FPC/Lazarus (je pense que c'est surement du à un mauvais remplissage du RawImage.Description) et c'est là que ça coince. (+ se problème d'assignation chez moi)
Avec un fichier BMP 24 ou 32 bits tout fonctionne, tes procédures sont donc juste.

[Jipété]

Dans tous les cas, une chose est sure ça bug sous la 1.8rc4

C'est désespérant !

Bon, pour être bien sûr de chez sûr, je te mets tout :

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
  procedure OuvreFichier(f: string);
  var
    pic: TPicture;
  begin
    pic := TPicture.Create;
    try
      pic.LoadFromFile(f);
      if (UpperCase(ExtractFileExt(f)) = '.JPG')
      or (UpperCase(ExtractFileExt(f)) = '.JPEG') then begin
          bmpFic.Assign(pic.Jpeg);
      end
      else
      if UpperCase(ExtractFileExt(f)) = '.BMP' then begin
          bmpFic.Assign(pic.Bitmap);
      end;
    finally
      pic.Free;
    end;
 
    //bmpFic.SaveToFile('/chemin/fichier.bmp'); // 4 test
  end;

Cette chose est appelée par une fonction qui en profite pour faire un test sur la taille (que je n'ai pas mis ici), et dans la vraie vie ça donne ça :

Code :

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

1
2
3
4
  if OuvreFichier(f) then begin 
    img4source.Picture.Assign(bmpFic);
    // etc.
  end;

Et que dire d'autre si ce n'est que ça fonctionne très bien, avec .bmp comme avec .jpg (j'ai zappé les autres formats).

Et ça fonctionne aussi avec la 1.6rc1 sous XP et sous une Debian avec la 1.6.2 et Qt mais là, le gag se trouve dans le code de correction : si je charge un jpeg (je le vois dans le TImage "source"), le code de correction à base de TLazIntfImage ne fonctionne pas (image noire), il me faut passer par Scanline !
On n'est pas rendus...

Et j'avais noté ça, qui traînait dans un bout de code mort, et qui vient de "remonter" avec cette 1.6.2, du coup je commente toute la ligne :

Code :

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

1
2
3
4
     {$IFNDEF WINDOWS}
     // ne compile pas sous Windows -- ni sous Debian et 1.6.2
     ////Img1.DataDescription.MaskBitsPerPixel:=0;
     {$ENDIF}

J'ai écrit "sous Windows" il y a un bout de temps, peut-être au passage à la 1.6.

Mais s'ils s'amusent à nous faire des blagues en changeant du code, je sais pas comment on va faire...

[BeanzMaster]

Resalut, bon peitit test vite j'ai fais j'ai trouvé pourquoi mes images ne sont pas assignée correctement
Après l'assignation j'avais cette ligne qui foutait la m.... bmpSrc.PixelFormat := pf24bit; du coup image noire (le plus drôle c'est qu'avec un fichier BMP 32bits cette ligne est ok)
2emment j'ai rajouté après pic.LoadFromFile(OPD.FileName);, ShowMessage(StringReplace(Pic.Bitmap.RawImage.Description.AsString, ' ', LineEnding, [rfReplaceAll]));histoire de voir et voila ce que ca donne avec tes fichiers 400x300
le bmp à gauche et le jpeg à droite


et voila pourquoi tu dois utiliser des RGBQuad avec les Jpeg. C'est ce que je disais le rawimage.description est mal rempli. C'est quand même un truc de fou ça !!!
Du coup au lieu de faire {$IF JIPEGUE} il faudrait mieux tester le "BitsperPixel" If BmpSrc.RawImage.Description.BitsPerPixel = 32 then else if = 24 else pas pris en charge voir peut-être "depth" car on sait que même si un fichier est en 32bits les données elles, peuvent être traité comme des 24bits. A tester.


EDIT : chez moi du coup maintenant pic.LoadFromFile(OPD.FileName); BmpSrc.Assign(pic.Bitmap); ça roule et pas besoin de tester l'extension du fichier

[Jipété]

Hé ben tu vois, tu vas finir par t'en dépatouiller,

De mon côté j'ai mené mes tests dans 3 environnements et je note les résultats ici, ça peut servir à d'autres :

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
utilisation d'une routine de calcul à base de TLazIntfImage
résultats :
avec fic jpg
Debian8 = image noire    (Laz 1.6.2)
Debian7 = image correcte (Laz 1.4)
Windows = image correcte (Laz 1.6rc1)

avec fic bmp
Debian8 = image correcte
Debian7 = image correcte
Windows = image correcte

utilisation de Scanline à base de pRGBTriple ou de pRGBQuad
résultats :
base pRGBTriple et fic jpg
Debian8 = raies verticales
Debian7 = raies verticales
Windows = raies verticales

base pRGBTriple et fic bmp
Debian8 = image correcte
Debian7 = image correcte 
Windows = image correcte


base pRGBQuad et fic jpg
Debian8 = image correcte
Debian7 = image correcte 
Windows = image correcte 

base pRGBQuad et fic bmp
Debian8 = SIGSEGV
Debian7 = SIGSEGV 
Windows = SIGSEGV

Ckiquez sur "Visualiser dans une fenêtre à part", ça sera plus confortable pour tout voir d'un coup.

[Jipété]

Salut,

Après l'assignation j'avais cette ligne qui foutait la m.... bmpSrc.PixelFormat := pf24bit; du coup image noire (le plus drôle c'est qu'avec un fichier BMP 32bits cette ligne est ok)

Je comprends mieux mes sacs de nœuds, sauf que je ne suis pas du tout d'accord avec tes conclusions :
tu t'appuies sur cette cochonnerie de TRawImage.Description, et j'insiste sur le mot "cochonnerie" car, concernant cette histoire de BPP pour les Jpeg, tout le monde s'accorde à dire qu'un Jpeg a 24 BPP, un exemple parmi tant d'autres (et feuilleter le bouquin en ligne, pas loin de 500 pages, montre qu'on n'a pas affaire à des guignols) :


source : Research and Advanced Technology for Digital Libraries: 13th European Conference, EDCL 2009 Corfu, Greece, September/October 2009

Alors quand je vois ça :


la conclusion qui s'impose c'est qu'il doit s'agir de leur cuisine interne mais en aucun cas tu ne dois l'utiliser, sinon tu vas dans le mur, garanti !
Regarde, tu veux utiliser un truc mal rempli :

et voila pourquoi tu dois utiliser des RGBQuad avec les Jpeg. C'est ce que je disais le rawimage.description est mal rempli. C'est quand même un truc de fou ça !!!

Du coup au lieu de faire {$IF JIPEGUE} il faudrait mieux tester le "BitsperPixel"

tu ne vas pas t'en sortir...


Sinon, pour parler d'autre chose,

EDIT : chez moi du coup maintenant pic.LoadFromFile(OPD.FileName); BmpSrc.Assign(pic.Bitmap); ça roule et pas besoin de tester l'extension du fichier

Rends-toi compte que même les dév's de Laz s'appuient sur l'extension de fichier pour faire leur taf' (chose que je ne trouve pas très sécure, d'où un test que je rajoute avant tout en allant lire le "magic number" dans le fichier) :

Méfiance sur l'ensemble du front !

Allez, bonne journée,

[BeanzMaster]

Salut,
Je comprends mieux mes sacs de nœuds, sauf que je ne suis pas du tout d'accord avec tes conclusions :
tu t'appuies sur cette cochonnerie de TRawImage.Description, et j'insiste sur le mot "cochonnerie" car, concernant cette histoire de BPP pour les Jpeg, tout le monde s'accorde à dire qu'un Jpeg a 24 BPP, un exemple parmi tant d'autres (et feuilleter le bouquin en ligne, pas loin de 500 pages, montre qu'on n'a pas affaire à des guignols) :

Bon on est d'accord depuis un moment tous les 2 sur le RawImage. C'est comme le plombier qui oublie de mettre des joints pour éviter les fuites. C'est du travail non fini et erroné.

la conclusion qui s'impose c'est qu'il doit s'agir de leur cuisine interne mais en aucun cas tu ne dois l'utiliser, sinon tu vas dans le mur, garanti !
Regarde, tu veux utiliser un truc mal rempli :

tu ne vas pas t'en sortir...

Oui mais malheureusement si tu veux utiliser TBitmap et des fonctions faisant appel au "scanline". Tu es obligé. Le rawImage.Description NE décrit PAS le format de fichier que tu charges. Il décrit les informations pour accéder aux Pixels. 2 choses différentes (mais normalement....je pense la même chose que toi ce n'est pas très logique). Regardes aussi le paramètre "LineEnd" il y a padding !!!, Rien avoir avec les Jpeg ça aussi.

Le rawImage.Description c'est un peu les ingrédients de la recette. Après à toi de les utiliser correctement.
Mais le pire, c'est surtout comme tu le dis ils font leurs cuisine en interne. Et le hic c'est que parfois le chemin emprunté n'est pas logique et surtout les informations retournées au final par rapport au fichier source sont erronées.
On le voit bien ici avec le Jpeg. Ce qui provoque d'énorme confusions vu que les normes ne sont pas respectés. On le voit à travers tes captures et des liens que tu as mis sur le Jpeg.

Sinon, pour parler d'autre chose,
Rends-toi compte que même les dév's de Laz s'appuient sur l'extension de fichier pour faire leur taf' (chose que je ne trouve pas très sécure, d'où un test que je rajoute avant tout en allant lire le "magic number" dans le fichier) :
Méfiance sur l'ensemble du front !
Allez, bonne journée,

Oui dans TPicture.LoadFromFile ils testent les extensions, à ce stade c'est un peu normal car TPicture par rapport à l'extension va créer la classe permettant de charger le fichier. Le test du "MagicID" si il y en à un se fera dans cette classe (Cela serai beaucoup plus compliquer et surtout un perte de performance importante si il faudrait tester tous les formats à ce stade. De plus cela impliquerait de modifier le TPicture à chaque fois que tu rajoutes une nouvelle classe pour prendre en charge un nouveau format. Néanmoins, ils pourrais rajouter une méthode de recherche du "MagicID" dans le TPicture seulement si le fichier n'a pas d'extension) Donc, pour la faire courte et rester simple on vérifie l'extension on renvoie la bonne classe (TBitmap, TJpegImage, TPortableNetworkGraphic ect..., qui eux même font appel aux différents FPReaderXXX et c'est cette dernière qui se charge de vérifier le "MagicID" et de dire si le format est valide ou non.

Bonne fin de journée également